gmane.comp.gcc.devel

Re: C++98/C++11 ABI compatibility for gcc-4.7

Jeffrey Yasskin — 2012-05-24T03:00:30

I've posted this to http://gcc.gnu.org/wiki/Cxx11AbiCompatibility. I
would greatly appreciate any corrections or improvements.

On Tue, May 22, 2012 at 9:04 AM, Jeffrey Yasskin <jyasskin< at >googlers.com> wrote:

Re: MPC/MPFR/GMP Usage

niXman — 2012-05-23T22:51:15

2012/5/24 Andrew Burks:
Only for internally using by GCC.

MPC/MPFR/GMP Usage

Andrew Burks — 2012-05-23T22:46:50

Hey everyone,

I'm using gcc-4.6.3 as part of the YAGARTO toolchain
(http://www.yagarto.de) with an STM32 ARM Cortex-M3 chip and was
wondering: what are the math libraries (MPC, MPFR, and GMP) used for?
Are they only required internally by gcc or are they implicitly added
to the final binary produced by gcc?

Thanks,
Andrew

Please Update the Installing GCC: Binaries Page

Colin Prior — 2012-05-23T22:37:48

Dear GCC

This is Colin Prior from Sunfreeware and UNIX Packages.

Please would you be good enough to update
http://gcc.gnu.org/install/binaries.html and add www.unixpackages.com
We as you will see from the Sunfreeware site we have removed the majority of
our packages including GCC (Solaris 2.5, 2.6 7, 8, and 9) over to the our
new site.

We may well be interested in doing some joint marketing with you. Let me
know if that's of interest.

BTW you may want to consider removing the Blastwave link as to all intents
and purposes that site has been dead for some time now.

Cheers

Colin


Colin Prior
Unix Packages
+1 206 310 4610
colin< at >unixpackages.com

Re: mkconfig.sh incrementality?

Ian Lance Taylor — 2012-05-23T22:13:34


No.  This is all about having make do the right thing.  Look at the
rules that invoke mkconfig.sh in gcc/Makefile.in.

Ian

Re: Effect of 'register' keyword on debug info

Ian Lance Taylor — 2012-05-23T22:10:53




This question as stated is not really appropriate for the mailing list
gcc< at >gcc.gnu.org, which is for the development of GCC itself.  This
question would be appropriate for gcc-help< at >gcc.gnu.org.  Please take any
followups to gcc-help.  Thanks.

This has nothing to do with using the register keyword.

Yes, you should ideally be told when a value is unavailable.  This
specific area of GCC has been much improved since GCC 4.5.2.



That looks like better output to me.

Ian

mkconfig.sh incrementality?

Jay K — 2012-05-23T16:04:29

At the bottom of mkconfig.sh in 4.6.2 and 4.7.0:


# Avoid changing the actual file if possible.
if [ -f $output ] && cmp ${output}T $output >/dev/null 2>&1; then
    echo $output is unchanged >&2
    rm -f ${output}T
else
    mv -f ${output}T $output
fi

# Touch a stamp file for Make's benefit.
rm -f cs-$output
echo timestamp > cs-$output



Shouldn't the timestamp > cs-$output only be a) mainly if the other file updated, by the mv and b) corner case, if it doesn't exist?
Maybe rm -rf by the mv, and echo if not exist?



 - Jay

Re: making sizeof(void) different from sizeof(void()())

Georg-Johann Lay — 2012-05-23T14:39:54

The AVR port does the same: Function addresses are word addresses whereas
data addresses are byte addresses.

Johann

Effect of 'register' keyword on debug info

Rohit Arul Raj — 2012-05-23T13:22:57

Hello All,

I came across this issue while working with PowerPC GCC tool chain
v4.5.2 for e500mc(64bit)/e5500.
Test case compiled with '-O0 -g'.

/************************** Test Case ************************/
 1: int main()
 2: {
 3:int i=0;
 4:
 5:register float f1 = 55.77f;
 6:register double d1 = 22.99f;
 7:
 8:while (i <= 100)  -----------------------------------(A)
 9:{
10:i++;
11:f1 = (float)i / 177 + (float)d1;
12:d1 = (double)i / 155677 + f1;
13:i += (int)d1;
14:}
15: }

/**************** Debug Info *************************************/
 <2><5d>: Abbrev Number: 3 (DW_TAG_variable)
    <5e>   DW_AT_name        : f1
    <61>   DW_AT_decl_file   : 1
    <62>   DW_AT_decl_line   : 5
    <63>   DW_AT_type        : <0x7f>
    <67>   DW_AT_location    : 2 byte block: 90 3f (DW_OP_regx: 63)
 <2><6a>: Abbrev Number: 3 (DW_TAG_variable)
    <6b>   DW_AT_name        : d1
    <6e>   DW_AT_decl_file   : 1
    <6f>   DW_AT_decl_line   : 6
    <70>   DW_AT_type        : <0x86>
    <74>   DW_AT_location    : 2 byte block: 90 3f (DW_OP_regx: 63)


/**************** Generated Assembly *************************/
...
.LCFI1:
.cfi_def_cfa_register 31
 # main.c:3
.loc 1 3 0
li 0,0 # tmp129,
stw 0,48(31) # i, tmp129
 # main.c:5
.loc 1 5 0
lfs 31,.LC0< at >toc(2) #, f1 --------------------- > (variable F1)
 # main.c:6
.loc 1 6 0
lfd 31,.LC1< at >toc(2) #, d1 --------------------> (variable D1)
 # main.c:8
.loc 1 8 0
b .L2 #
.....

Looking at the debug info and the generated assembly, the values of
variables 'f1' and 'd1' are stored in the same register.
Due to this, while debugging, after setting the break point at (A)
[line no 8], if we print the value of 'f1' i get the wrong value.

/**************** Debugger Output *********************/
(gdb) n
5               register float f1 = 55.77f;
(gdb) n
6               register double d1 = 22.99f;
(gdb) n
8               while (i <= 100)
(gdb) p f1
$1 = 22.9899998
(gdb) p d1
$2 = 22.989999771118164
/************************************************************/

Q: Is this the side effect of using 'register' keyword? If 'f1' is
getting optimized out, shouldn't we get that info while debugging?

Also, using -fvar-tracking, i get this output while debugging the same code.

/**************** Debugger Output *********************/
5               register float f1 = 55.77f;
(gdb) n
6               register double d1 = 22.99f;
(gdb) n
8               while (i <= 100)
(gdb) p f1
$5 = <optimized out>
(gdb) p d1
$6 = 22.989999771118164
/************************************************************/

Regards,
Rohit

Re: A question about loop ivopt

Andrew Pinski — 2012-05-23T03:14:52

As far as I can tell it is exposed already to the middle-end via that
hook in that you should be able to use MODES_TIEABLE_P from
tree-ssa-loop-ivopts.c without modifying anything else.
It looks like the arm and i386 are have both broken xxx-protos.h.
Both rs6000 and mips will work without touching their xxx-protos.h.  I
think it is better if you just fix the targets which have a broken
xxx-protos.h.


Thanks,
Andrew Pinski

RE: A question about loop ivopt

Jiangning Liu — 2012-05-23T03:04:37



Richard,

But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I
would have to modify xxx-protos.h for all back-ends.

An alternative way is I define a new function hook. This way I needn't to
change all back-ends, but support several back-ends required first.

Which solution is usually preferred?

Thanks,
-Jiangning

Re: MULTILIB_OPTIONS and DRIVER_SELF_SPEC

Paulo J. Matos — 2012-05-22T15:48:20

OK, thanks for letting me know about this.

Cheers,

RE: Enabling a function based on Language

Iyer, Balaji V — 2012-05-22T15:18:44

Thanks Tobias,

I am wanting to call this function right before we hit the gimplify_function_tree (), so I guess I am right before the middle-end.......

-Balaji V. Iyer.

-----Original Message-----
From: Tobias Burnus [mailto:burnus< at >net-b.de] 
Sent: Tuesday, May 22, 2012 3:25 AM
Cc: Iyer< at >google.com; Iyer, Balaji V; 'gcc< at >gcc.gnu.org'
Subject: Re: Enabling a function based on Language

Ian Lance Taylor wrote:

Unless, of course, one goes the route which Richard once suggested: 
Adding array and scalarizer support to the middle end, http://gcc.gnu.org/wiki/GCCGathering2011Fortran#Scalarizer

(See all three links; mistakes in the Wiki are mine, made when I tried to summarize/understand Richard's draft patches. The project got stalled as there was not enough developer time on the Fortran side and as the current approach works relatively well. ME support would be beneficial as it would allow for certain optimizations which are not possible in the front end.)

Tobias

C++98/C++11 ABI compatibility for gcc-4.7

Jeffrey Yasskin — 2012-05-22T14:04:46

I've put together the following description of C++98/11 ABI
(in)compatibility, so people can tell which libraries need to be
recompiled. This is useful when you've bought a library that didn't
come with source code, and you're trying to figure out if you need to
buy a new version. I think this belongs on the Wiki somewhere, but I
wanted to run it by the list first to make sure it's accurate. You can
probably skip the first section, since it's just a description of how
to use the subsequent list.



This page explains how to identify when your pre-compiled library (.a
or .so) defines a symbol that has a different enough definition in
C++98 vs C++11 that it could cause runtime problems if it's linked
into a program compiled for the other version.

First, get a list of demangled symbols from your .a or .so:

$ (find . -name '*.a'|xargs nm -f posix; find . -name '*.so' | xargs
nm -f posix -D)|cut -f1 -d' '|LANG=C sort -u|c++filt|sort

(There may be better ways to get this list.)

Next, find instances in this list of the ABI changes listed below.
For example, you might find:

  std::_List_base<FooBar, std::allocator<FooBar> >::_M_clear()

Since std::_List_base::_M_clear() destroys nodes, it's affected by the
addition of the _M_size field and can't be used by C++11 code if it
was compiled for C++98, or vice versa.  If it's possible that code
outside the library would use this instance of _List_base, then you
have to recompile the library. On the other hand, if FooBar is a type
used only inside this library, then code using the library is safe.
If FooBar is defined by the library but exposed in one of the
library's headers, then the library still needs to be recompiled,
since code using it could wind up including the other version's
implementation.


=== ABI Changes ===

complex::{real,imag}(), std::{real,imag}(complex)

The non-const overloads go from returning _Tp& to _Tp.
[Since gcc-4.4]


std::list, std::_List_impl, and std::_List_base

New _M_size member, meaning any method that adds or removes nodes or
inspects the size has a new ABI.
[Since gcc-4.7]


std::operator-(reverse_iterator) and std::operator-(__normal_iterator)
may return a different type if
reverse_iterator<_IteratorL>::difference_type (respectively,
__normal_iterator<_IteratorL, _Container>::difference_type) isn't
accurate.
[Since gcc-4.4]


map::erase(iterator), multimap::erase(iterator),
set::erase(const_iterator), set::erase(const_iterator,
const_iterator), multiset::erase(const_iterator),
multiset::erase(const_iterator, const_iterator):

Return type changes from void to iterator.
[Since gcc-4.5]


_Rb_tree<T, T>::erase(const_iterator), _Rb_tree<T,
T>::erase(const_iterator, const_iterator), _Rb_tree<T,
pair>::erase(iterator):

Return type changes from void to iterator. these are instantiated from
map and set.
[Since gcc-4.5]


vector::data()'s return type changes from pointer to _Tp*

This is a no-op with most allocators, but any allocator that defines a
non-default pointer typedef will be incompatible.
[Since gcc-4.6]



Probably safe: istreambuf_iterator::reference changes from _CharT& to _CharT.

This could affect return types if they mention 'reference', but they
appear not to mention it when istreambuf_iterator is involved.
[Since gcc-4.7]


Probably safe: map::erase(iterator, iterator),
multimap::erase(iterator, iterator)

C++11 uses const_iterator, which doesn't collide.  Other versions of
gcc are unlikely to have defined this overload in C++98 mode, and
C++11 is unlikely to have defined the iterator version.

[Since gcc-4.5]


Probably safe: Types with node allocators, like deque and tree

C++11 uses _M_get_Node_allocator().construct(node, ...), while C++98
uses get_allocator().construct(node->_M_value_field, ...).  The node's
constructor forwards to the value_field's constructor, so this works
by default.  Can this cause problems with some mix of C++98/C++11
allocator compilations?




I haven't analyzed the debug and profile headers.




I found these differences by grepping for GXX_EXPERIMENTAL_CXX0X
inside libstdc++, and examining each instance to see if there was an
#else clause that had different behavior in C++11 vs C++98.


=== ABI non-changes ===

libstdc++'s binary component is nearly ABI-compatible between C++98
and C++11.  Most incompatibilities are in the templates defined in
headers, but the complex<> stream operators call the real() and imag()
methods that change return type.  If these calls aren't inlined, (and
they're likely to be inlined), then libstdc++ (which is compiled in
C++98 mode by default) could cause problems when linked into C++11
programs.  (http://gcc.gnu.org/PR53429)

There have been some claims that the change in the definition of POD
types causes an ABI incompatibility, but apparently it doesn't in
practice: http://gcc.gnu.org/ml/gcc/2012-01/msg00056.html.

Re: A question about loop ivopt

Richard Guenther — 2012-05-22T10:35:59

You are already in the middle-end and thus can use MODES_TIABLE_P
directly.  Modes are also available on gimple variables via DECL/TYPE_MODE.

Richard.

RE: A question about loop ivopt

Jiangning Liu — 2012-05-22T09:19:28



OK, yes, the thing that matter most is just address cost, so I can improve
force_expr_to_var_cost.

Would it sound OK if I expose MODES_TIEABLE_P to middle-end by defining a
new target hook? I need this function to strip some operations and make the
cost estimate more accurate. If I don't expand to RTL, I would need a method
to check the modes conversion in middle end, anyway. Any idea?

Thanks,
-Jiangning

Re: Enabling a function based on Language

Tobias Burnus — 2012-05-22T07:24:48

Unless, of course, one goes the route which Richard once suggested: 
Adding array and scalarizer support to the middle end,
http://gcc.gnu.org/wiki/GCCGathering2011Fortran#Scalarizer

(See all three links; mistakes in the Wiki are mine, made when I tried 
to summarize/understand Richard's draft patches. The project got stalled 
as there was not enough developer time on the Fortran side and as the 
current approach works relatively well. ME support would be beneficial 
as it would allow for certain optimizations which are not possible in 
the front end.)

Tobias

Re: Enabling a function based on Language

Ian Lance Taylor — 2012-05-22T00:31:10


By definition, no, there isn't.  The middle-end is compiled once, into a
library.  Then each frontend is linked against that library.

Calling a frontend function like build_array_ref from the middle-end is
always a mistake.  In the middle-end you should probably be making a
POINTER_PLUS_EXPR node or something along those lines.

Ian

Enabling a function based on Language

Iyer, Balaji V — 2012-05-21T22:52:12

Hello Everyone,
Is there a #define in GCC that will turn on only for certain languages? I am trying to use build_array_ref but it is giving me a undefined reference for f951. This code that I am trying to use will ONLY execute  if we have a C/C++ code.  Is it possible for me to enclose this inside some #defines (or a combination of them)?

Any help is greatly appreciated!

Thanks,

Balaji V. Iyer.

Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)

Ian Lance Taylor — 2012-05-21T20:50:06


Answered previously.



Sure, why not?  We make similar changes for much smaller benefits.

It's worth bearing in mind that it is causing you trouble because 1) you
are not using the recommend and tested build procedure, and 2) you are
using the non-recommended procedure starting with a compiler that is 7
years old.  You have perfectly good reasons for doing that, but the
reality is that if you want to do this kind of thing, you have to be
prepared for problems.



You don't need to try it either way, because if <tr1/unordered_map> is
unavailable the Go frontend will simply use <ext/hash_map>.  And if
<ext/hash_map> is unavailable, the Go frontend will use <map>.  In other
words, the Go frontend is already prepared to fall back, based on the
results of configure tests.  The problem here is that the configure test
sees that <tr1/unordered_map> is available, but does not realize that
although the header is available it does not actually work when using
-fno-rtti.

Ian

Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)

Ian Lance Taylor — 2012-05-21T20:35:08


I thought I answered that earlier.  When building C++ code that is part
of GCC itself, we use -fno-rtti because GCC never uses RTTI, and using
-fno-rtti causes the compiler to be smaller.  So there is an advantage
to using -fno-rtti, and there is no benefit to using -frtti.  So we use
-fno-rtti.

You are running into a problem with that, but the problem has nothing to
do with mainline GCC.  It is a bug in GCC 4.0.  It's unfortunate that
GCC 4.0 has a bug with -fno-rtti, but there is no way that we
retroactively fix that.

Ian

gmane.comp.gcc.devel

Re: C++98/C++11 ABI compatibility for gcc-4.7

Re: MPC/MPFR/GMP Usage

MPC/MPFR/GMP Usage

Please Update the Installing GCC: Binaries Page

Re: mkconfig.sh incrementality?

Re: Effect of 'register' keyword on debug info

mkconfig.sh incrementality?

Re: making sizeof(void*) different from sizeof(void(*)())

Effect of 'register' keyword on debug info

Re: A question about loop ivopt

RE: A question about loop ivopt

Re: MULTILIB_OPTIONS and DRIVER_SELF_SPEC

RE: Enabling a function based on Language

C++98/C++11 ABI compatibility for gcc-4.7

Re: A question about loop ivopt

RE: A question about loop ivopt

Re: Enabling a function based on Language

Re: Enabling a function based on Language

Enabling a function based on Language

Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)

Re: -fno-rtti in configure.ac breaks building go? (older g++, -disable-bootstrap)

Re: making sizeof(void) different from sizeof(void()())