GCC 4.4.0 Status Report (2008-08-22)
Status == The end of stage1 for GCC 4.4 is approaching fast, you have about one week left to incorporate major changes into GCC for the next release. There are still two major projects scheduled for merging, the Integrated Register Allocator branch and the GRAPHITE branch. Please make sure to help reviewing the last bits of these branches to help them being merged in time. Quality Data Priority # Change from Last Report --- --- P1 14 + 1 P2 138 + 19 P37 + 5 --- --- Total 159 + 25 As changes have been coming at a fast pace recently the number of bugs has increased significantly over the last report. As usually this is expected in approaching the end of stage1 ;) Please keep in mind to re-confirm the bugs you filed for your not-so-widely accessible targets! Previous Report === http://gcc.gnu.org/ml/gcc/2008-08/msg00131.html The next report for 4.4.0 will be sent by Jakub. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Hi, apparently, between Revisions 139407 and 139411, this test started failing the build: FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors) Any idea what's going wrong? Maybe HJ can post the error? Thanks, Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Fri, Aug 22, 2008 at 8:59 AM, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Hi, > > apparently, between Revisions 139407 and 139411, this test started failing > the build: > > FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors) > > Any idea what's going wrong? Maybe HJ can post the error? > Executing on host: /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -I/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/libsupc++ -I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/include/backward -I/export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/util -L/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs -L/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs /export/gnu/import/svn/gcc-test/src-trunk/libstdc++-v3/testsuite/abi/cxx_runtime_only_linkage.cc -lsupc++ -lm -m32 -o ./cxx_runtime_only_linkage.exe(timeout = 600) /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o): In function `__exchange_and_add_dispatch':^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomicity.h:84: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'^M collect2: ld returned 1 exit status^M -- H.J.
RE: GCC 2.95.3 bug
Dear GCC folks:
I'm having a problem with GCC 2.95.3 that appears to be a compiler bug. It
seems to be optimizing out inlined function code with side effects, and is
related to binding a non-const pointer to a const pointer reference function
parameter. The problem only happens with optimization on, and goes away with
-O0.
I assume this must be known problem, but I'm having a hard time finding a patch
to fix it. It is not an option at this time to upgrade to a newer compiler
version, but we are planning to do that in the future.
Below is the test program and output.
I really appreciate any help you can give.
Thanks in advance,
--Ray
---
#include
#include
#include
typedef unsigned char byte;
inline unsigned unpack2 (const byte *&data)
{
unsigned val = data[0] << 8 | data[1];
data += 2;
return val;
}
inline unsigned unpack2 (const byte *&data, unsigned &count)
{
unsigned val = data[0] << 8 | data[1];
data += 2;
count -= 2;
return val;
}
/*
inline unsigned unpack2 (byte *&data)
{
unsigned val = data[0] << 8 | data[1];
data += 2;
return val;
}
inline unsigned unpack2 (byte *&data, unsigned &count)
{
unsigned val = data[0] << 8 | data[1];
data += 2;
count -= 2;
return val;
}
*/
void extractInfo (byte *&data, unsigned &datalen,
unsigned &f1, unsigned &f2)
{
cout << "data = " << data << ", datalen = " << datalen << endl;
f1 = unpack2 (data, datalen);
cout << "data = " << data << ", datalen = " << datalen << endl;
byte *peek = data;
//const byte *peek = data; // Adding "const" works around the
compiler problem
// Another work-around is to uncomment the
non-const f1 of unpack2() above
unsigned tmp = datalen;
cout << "peek = " << peek << ", tmp = " << tmp << endl;
(void) unpack2 (peek, tmp); // skip over irrelevant field
cout << "peek = " << peek << ", tmp = " << tmp << endl;
(void) unpack2 (peek, tmp); // skip over irrelevant field
cout << "peek = " << peek << ", tmp = " << tmp << endl;
unsigned xlen = unpack2 (peek, tmp);
cout << "peek = " << peek << ", tmp = " << tmp << endl;
f2 = xlen;
}
int
main(int, char**)
{
byte *x = "0123456789";
unsigned len = strlen(x);
unsigned fld1, fld2;
extractInfo (x, len, fld1, fld2);
cout << "x = " << x << endl;
cout << "len = " << len << endl;
cout << "fld1 = " << hex << fld1 << dec << endl;
cout << "fld2 = " << hex << fld2 << dec << endl;
return 0;
}
---
$ gcc-2.95.3-glibc-2.1.3/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-g++
-O0 -W -Wall -o foo foo.cpp
$ ./foo
data = 0123456789, datalen = 10
data = 23456789, datalen = 8
peek = 23456789, tmp = 8
peek = 456789, tmp = 6
peek = 6789, tmp = 4
peek = 89, tmp = 2
x = 23456789
len = 8
fld1 = 3031
fld2 = 3637
$ gcc-2.95.3-glibc-2.1.3/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-g++
-O2 -W -Wall -o foo foo.cpp
$ ./foo
data = 0123456789, datalen = 10
data = 23456789, datalen = 8
peek = 23456789, tmp = 8
peek = 23456789, tmp = 6
peek = 23456789, tmp = 4
peek = 23456789, tmp = 2
x = 23456789
len = 8
fld1 = 3031
fld2 = 3233
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
H.J. Lu wrote: On Fri, Aug 22, 2008 at 8:59 AM, Paolo Carlini <[EMAIL PROTECTED]> wrote: Hi, apparently, between Revisions 139407 and 139411, this test started failing the build: FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors) Any idea what's going wrong? Maybe HJ can post the error? /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o): In function `__exchange_and_add_dispatch':^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomicity.h:84: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'^M collect2: ld returned 1 exit status^M That's my exception_ptr code again (indirectly, this time). Apparently, __exchange_and_add has exactly the same problem as __sync_add_and_fetch_4: it's just not implemented on i386 targets. That makes the regression range incorrect, though: the specified range doesn't contain any changes to my code. This was introduced as early as r139091. The other weird thing is that the 32-bit target of the x86_64 compiler doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults to a i386 profile. Now, I understand that for the 32-bit x86 compiler, but the 64-bit compiler is not a cross-compiler and should merely target the 32-bit mode of x86_64 CPUs. It should have the __sync built-ins. Also, it's curious that we haven't seen this test failure for real x86 builds. They don't default to __GTHREADS undefined, do they? Sebastian
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
H.J. Lu wrote: /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o): In function `__exchange_and_add_dispatch':^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomicity.h:84: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'^M Thanks HJ. Essentially, is again the same annoying issue: this test fails on i686-linux (not x86_64-linux, of course) because currently libsupc++ depends on libstdc++ to export __exchange_and_add... We have to find a way to decouple the two, or maybe just provide the C++0x exception propagation only on targets supporting the atomic builtins. Probably the latter, barring better ideas, because I'm really fed up with this atomic builtins story, frankly... Paolo.
Re: GCC 2.95.3 bug
Balogh, Ray wrote:
Dear GCC folks:
I'm having a problem with GCC 2.95.3 that appears to be a compiler bug. It
seems to be optimizing out inlined function code with side effects, and is
related to binding a non-const pointer to a const pointer reference function
parameter. The problem only happens with optimization on, and goes away with
-O0.
inline unsigned unpack2 (const byte *&data)
{
unsigned val = data[0] << 8 | data[1];
data += 2;
return val;
}
inline unsigned unpack2 (const byte *&data, unsigned &count)
{
unsigned val = data[0] << 8 | data[1];
data += 2;
count -= 2;
return val;
}
void extractInfo (byte *&data, unsigned &datalen,
unsigned &f1, unsigned &f2)
{
cout << "data = " << data << ", datalen = " << datalen << endl;
f1 = unpack2 (data, datalen);
cout << "data = " << data << ", datalen = " << datalen << endl;
byte *peek = data;
//const byte *peek = data; // Adding "const" works around the
compiler problem
// Another work-around is to uncomment the
non-const f1 of unpack2() above
unsigned tmp = datalen;
cout << "peek = " << peek << ", tmp = " << tmp << endl;
(void) unpack2 (peek, tmp);// skip over irrelevant field
cout << "peek = " << peek << ", tmp = " << tmp << endl;
(void) unpack2 (peek, tmp);// skip over irrelevant field
cout << "peek = " << peek << ", tmp = " << tmp << endl;
unsigned xlen = unpack2 (peek, tmp);
cout << "peek = " << peek << ", tmp = " << tmp << endl;
f2 = xlen;
}
In my opinion, the bug is that this even compiles. It's invalid to write
char *pc;
const char **ppc = &pc;
Why should it be valid to write
char *pc;
const char *&rpc = pc;
?
Sebastian
Re: GCC 2.95.3 bug
Sebastian Redl wrote:
> Balogh, Ray wrote:
>> Dear GCC folks:
>>
>> I'm having a problem with GCC 2.95.3 that appears to be a compiler
>> bug. It seems to be optimizing out inlined function code with side
>> effects, and is related to binding a non-const pointer to a const
>> pointer reference function parameter. The problem only happens with
>> optimization on, and goes away with -O0.
>>
>> inline unsigned unpack2 (const byte *&data)
>> {
>> unsigned val = data[0] << 8 | data[1];
>> data += 2;
>> return val;
>> }
>> inline unsigned unpack2 (const byte *&data, unsigned &count)
>> {
>> unsigned val = data[0] << 8 | data[1];
>> data += 2;
>> count -= 2;
>> return val;
>> }
>>
>> void extractInfo (byte *&data, unsigned &datalen,
>>unsigned &f1, unsigned &f2)
>> {
>> cout << "data = " << data << ", datalen = " << datalen << endl;
>> f1 = unpack2 (data, datalen);
>> cout << "data = " << data << ", datalen = " << datalen << endl;
>>
>> byte *peek = data;
>> //const byte *peek = data; // Adding "const" works around
>> the compiler problem
>> // Another work-around is to uncomment
>> the non-const f1 of unpack2() above
>>
>> unsigned tmp = datalen;
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>> (void) unpack2 (peek, tmp);// skip over irrelevant field
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>> (void) unpack2 (peek, tmp);// skip over irrelevant field
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>>
>> unsigned xlen = unpack2 (peek, tmp);
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>>
>> f2 = xlen;
>> }
>>
> In my opinion, the bug is that this even compiles. It's invalid to write
> char *pc;
> const char **ppc = &pc;
>
> Why should it be valid to write
> char *pc;
> const char *&rpc = pc;
>
I agree. The code is invalid; modern g++ generates an error.
Andrew.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Sebastian Redl wrote: That's my exception_ptr code again (indirectly, this time). Apparently, __exchange_and_add has exactly the same problem as __sync_add_and_fetch_4: it's just not implemented on i386 targets. Not really, it would be too easy ;) It is implemented of course, but it is provided as an exported symbol by libstdc++. Thus, since the test only links libsupc++, it shows that the latter isn't selfcontained. That makes the regression range incorrect, though: the specified range doesn't contain any changes to my code. This was introduced as early as r139091. Yes, that's rather mysterious. The other weird thing is that the 32-bit target of the x86_64 compiler doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults to a i386 profile. Now, I understand that for the 32-bit x86 compiler, but the 64-bit compiler is not a cross-compiler and should merely target the 32-bit mode of x86_64 CPUs. It should have the __sync built-ins. I don't think the 32-bit mode of x86_64 CPUs provide the builtins but, anyway... Also, it's curious that we haven't seen this test failure for real x86 builds. We are seeing it, but only lately. Anwyay, one way or the other, l porpose for now let's just support the new facility only for targets providing the sync builtins and be done with it. Agreed? Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: H.J. Lu wrote: /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o): In function `__exchange_and_add_dispatch':^M /export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomicity.h:84: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'^M Thanks HJ. Essentially, is again the same annoying issue: this test fails on i686-linux (not x86_64-linux, of course) because currently libsupc++ depends on libstdc++ to export __exchange_and_add... We have to find a way to decouple the two, or maybe just provide the C++0x exception propagation only on targets supporting the atomic builtins. Probably the latter, barring better ideas, because I'm really fed up with this atomic builtins story, frankly... Could we simply export __exchange_and_add and __atomic_add from libsupc++ instead of libstdc++? They are pretty basic building blocks in my opinion. Sebastian
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: Anwyay, one way or the other, l porpose for now let's just support the new facility only for targets providing the sync builtins and be done with it. Agreed? I have no objection to doing that in principle, but it basically means programming effort in order to remove something, which I'm not happy about. Hmm ... we'd have to drop eh_ptr.cc and exception_ptr.h completely for that mode, and modify eh_throw.cc so that the cleanup function doesn't use the reference counting. I think we can leave the other modifications in; they don't affect the handling. What macro do I switch on? _GLIBCXX_ATOMIC_BUILTINS_4? Sebastian
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Sebastian Redl wrote: Could we simply export __exchange_and_add and __atomic_add from libsupc++ instead of libstdc++? They are pretty basic building blocks in my opinion. I agree, in principle. However, sorry, I don't feel like doing that, it's a non trivial change, because *anything* related to the atomic builtins is non-trivial. So... If you volunteer to do that, patches welcome, you can count on my to thorough and promptly review and help, but if you drop the ball, I will simply enable the C++0x feature on the safe subset of platforms, for 4.4.0, at least. Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: Sebastian Redl wrote: Could we simply export __exchange_and_add and __atomic_add from libsupc++ instead of libstdc++? They are pretty basic building blocks in my opinion. I agree, in principle. Well, thinking more about it, I don't see how you can do it without breaking the binary compatibility... Paolo.
RE: GCC 2.95.3 bug
Andrew & Sebastian,
Thank you very much for you help, guys!
It's easier to fix our source code anyway :-)
Best Regards,
--Ray
-Original Message-
From: Andrew Haley [mailto:[EMAIL PROTECTED]
Sent: Friday, August 22, 2008 12:35 PM
To: Sebastian Redl
Cc: Balogh, Ray; [EMAIL PROTECTED]
Subject: Re: GCC 2.95.3 bug
Sebastian Redl wrote:
> Balogh, Ray wrote:
>> Dear GCC folks:
>>
>> I'm having a problem with GCC 2.95.3 that appears to be a compiler
>> bug. It seems to be optimizing out inlined function code with side
>> effects, and is related to binding a non-const pointer to a const
>> pointer reference function parameter. The problem only happens with
>> optimization on, and goes away with -O0.
>>
>> inline unsigned unpack2 (const byte *&data)
>> {
>> unsigned val = data[0] << 8 | data[1];
>> data += 2;
>> return val;
>> }
>> inline unsigned unpack2 (const byte *&data, unsigned &count)
>> {
>> unsigned val = data[0] << 8 | data[1];
>> data += 2;
>> count -= 2;
>> return val;
>> }
>>
>> void extractInfo (byte *&data, unsigned &datalen,
>>unsigned &f1, unsigned &f2)
>> {
>> cout << "data = " << data << ", datalen = " << datalen << endl;
>> f1 = unpack2 (data, datalen);
>> cout << "data = " << data << ", datalen = " << datalen << endl;
>>
>> byte *peek = data;
>> //const byte *peek = data; // Adding "const" works around
>> the compiler problem
>> // Another work-around is to
uncomment
>> the non-const f1 of unpack2() above
>>
>> unsigned tmp = datalen;
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>> (void) unpack2 (peek, tmp);// skip over irrelevant field
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>> (void) unpack2 (peek, tmp);// skip over irrelevant field
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>>
>> unsigned xlen = unpack2 (peek, tmp);
>> cout << "peek = " << peek << ", tmp = " << tmp << endl;
>>
>> f2 = xlen;
>> }
>>
> In my opinion, the bug is that this even compiles. It's invalid to
write
> char *pc;
> const char **ppc = &pc;
>
> Why should it be valid to write
> char *pc;
> const char *&rpc = pc;
>
I agree. The code is invalid; modern g++ generates an error.
Andrew.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: Sebastian Redl wrote: Could we simply export __exchange_and_add and __atomic_add from libsupc++ instead of libstdc++? They are pretty basic building blocks in my opinion. I agree, in principle. However, sorry, I don't feel like doing that, it's a non trivial change, because *anything* related to the atomic builtins is non-trivial. So... If you volunteer to do that, patches welcome, you can count on my to thorough and promptly review and help, I'll look into it over the weekend. Sebastian
Re: GCC 2.95.3 bug
On Fri, Aug 22, 2008 at 05:34:30PM +0100, Andrew Haley wrote:
> >> I'm having a problem with GCC 2.95.3 that appears to be a compiler
> >> bug.
The handling of overloads with respect to const and non-const modifiers
on pointers was badly broken in gcc 2.95.3. That compiler accepted
so much crud that if you learned C++ by writing code that it would
accept, you haven't learned C++.
(It did OK with correct C++ that was within its limitations, for the most
part, the problem was with all the things it accepted that it should have
rejected).
Your options are to fix your code (so that you always give any non-const
references an exactly matching type), "fix" the compiler yourself ("fix"
is in quotes since you want the compiler to accept non-standard code and
interpret it in a non-standard way), or hire someone to fix it for you.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Hi, What macro do I switch on? _GLIBCXX_ATOMIC_BUILTINS_4? Yes, should be safe for static switching. I think you should consider also the option of having less stuff exported from libsupc++: if you somehow manage to have the different code paths in the headers, then you can dynamically switch on |__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which changes depending on the actual compiler switches (i.e., it's defined if on x86_linux, you use -march=i486)| Anyway, I will be waiting for concrete proposals: also make sure that if, on a specific target, parts of N2179 are not available users understand it, easily, ideally with a compile-time error. ||| |Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Sebastian Redl wrote: The other weird thing is that the 32-bit target of the x86_64 compiler doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults to a i386 profile. Now, I understand that for the 32-bit x86 compiler, but the 64-bit compiler is not a cross-compiler and should merely target the 32-bit mode of x86_64 CPUs. It should have the __sync built-ins. Not true. We want very much for -m32 on the 64-bit compiler to produce the same output as the 32-bit compiler. r~
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: I think you should consider also the option of having less stuff exported from libsupc++: if you somehow manage to have the different code paths in the headers That's impossible without exposing unwind-cxx.h to the public, and that's a can of worms I don't even want to look at, much less open. The reference counting must act on the count in the __cxa_exception_header object, and that structure is strictly internal. The problem is that the core exception mechanism (__gxx_exception_cleanup, to be specific) needs the atomic instruction. This means that if the target doesn't have support for it, you'd need a different libsupc++. You can't have the same libsupc++ for i386 and i486 if one has exception_ptr and the other doesn't. Doing this thing conditionally is just not possible, in my opinion. Meanwhile, I'm looking at the __exchange_and_add implementation. This is quite a hack: it's implemented in a "header" file in config/cpu//atomicity.h, but then src/Makefile.am creates a symlink in the target directory that it calls atomicity.cc, and compiles that. I think that hack could be simply moved to libsupc++/Makefile.am, though. Sebastian
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Fri, Aug 22, 2008 at 10:06 AM, Richard Henderson <[EMAIL PROTECTED]> wrote: > Sebastian Redl wrote: >> >> The other weird thing is that the 32-bit target of the x86_64 compiler >> doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults to >> a i386 profile. Now, I understand that for the 32-bit x86 compiler, but the >> 64-bit compiler is not a cross-compiler and should merely target the 32-bit >> mode of x86_64 CPUs. It should have the __sync built-ins. > > Not true. We want very much for -m32 on the 64-bit compiler to produce > the same output as the 32-bit compiler. > Can we declare that Linux/ia32 generates i486 insn by default? -- H.J.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
H.J. Lu wrote: Can we declare that Linux/ia32 generates i486 insn by default? Even if we do that, we'll still get errors if someone forces i386. And the people doing that are more likely to want to link against the standalone libsupc++, too, since i386 is mostly used in embedded systems nowadays. Sebastian
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
H.J. Lu wrote: Can we declare that Linux/ia32 generates i486 insn by default? Yes, but again, I have to remind you that the problem is with *any* target or subtarget not implementing the atomic builtins. Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Fri, Aug 22, 2008 at 10:53 AM, Sebastian Redl <[EMAIL PROTECTED]> wrote: > H.J. Lu wrote: >> >> Can we declare that Linux/ia32 generates i486 insn by default? >> > > Even if we do that, we'll still get errors if someone forces i386. And the > people doing that are more likely to want to link against the standalone > libsupc++, too, since i386 is mostly used in embedded systems nowadays. > Can we disable those new C++ features for i386? Do embedded systems use/need those new C++ features? -- H.J.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Sebastian Redl wrote: Paolo Carlini wrote: I think you should consider also the option of having less stuff exported from libsupc++: if you somehow manage to have the different code paths in the headers That's impossible without exposing unwind-cxx.h to the public, and that's a can of worms I don't even want to look at, much less open. The reference counting must act on the count in the __cxa_exception_header object, and that structure is strictly internal. Ok, then, we declare here, that, for gcc4.4.0 this C++0x feature is available only for targets unconditionally implementing the atomic builtins. I'll take care of the configury bits. Thanks, Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Fri, Aug 22, 2008 at 11:05:12AM -0700, H.J. Lu wrote: > On Fri, Aug 22, 2008 at 10:53 AM, Sebastian Redl > <[EMAIL PROTECTED]> wrote: > > H.J. Lu wrote: > >> > >> Can we declare that Linux/ia32 generates i486 insn by default? > >> > > > > Even if we do that, we'll still get errors if someone forces i386. And the > > people doing that are more likely to want to link against the standalone > > libsupc++, too, since i386 is mostly used in embedded systems nowadays. > > > > Can we disable those new C++ features for i386? Do embedded systems > use/need those new C++ features? People are putting everything on embedded systems these days, including things like Qt-based GUIs, threaded apps that need locking, the works. And some embedded processors might support only i386 instructions. Certainly we could default to i486, but we can't wish the i386 problems away.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: Ok, then, we declare here, that, for gcc4.4.0 this C++0x feature is available only for targets unconditionally implementing the atomic builtins. I'll take care of the configury bits. And even this, given the current structure of the patch, we don't want to do, because there are too many changes scattered around in the libsupc++ code. I'm going to revert again the whole thing and wait for a different, safe, approach, sorry. Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: Paolo Carlini wrote: Sebastian Redl wrote: Could we simply export __exchange_and_add and __atomic_add from libsupc++ instead of libstdc++? They are pretty basic building blocks in my opinion. I agree, in principle. Well, thinking more about it, I don't see how you can do it without breaking the binary compatibility... Paolo. What part, exactly? libstdc++.so still exports the symbol, since the supc++ and stdc++ libraries are both in there. libsupc++.a will export it and libstdc++.a won't, but do ABI considerations apply to static libraries? Sebastian
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Sebastian Redl wrote: What part, exactly? libstdc++.so still exports the symbol, since the supc++ and stdc++ libraries are both in there. So, essentially, you want to *duplicate* all the exports now in libstdc++ also in libsupc++? Because certainly you can't remove the exports from libstdc++. No, no, I don't think we want to do that. Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: So, essentially, you want to *duplicate* all the exports now in libstdc++ also in libsupc++? Because certainly you can't remove the exports from libstdc++. No, no, I don't think we want to do that. Disregard the above. Anyway, I'm not at all convinced that your plan is doable, in particular given versioning. The symbols that you would start exporting from libsupc++ would have to appear to the users of libstdc++ as GLIBCXX_3.4, not as CXXABI_1.3.4. Anyway, I don't want to appear too pessimistic, give the thing a try... Paolo.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
H.J. Lu wrote: Can we declare that Linux/ia32 generates i486 insn by default? We the gcc team? I'm not sure. For now I'll say no. We an individual linux distributor? Certainly. In fact I would be surprised if i586 wasn't a decent minimum these days. r~
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
Paolo Carlini wrote: I'm going to revert again the whole thing and wait for a different, safe, approach, sorry. In the short time frame, i.e., something solid for 4.4.0, I would suggest two possible strategies: 1- Try to re-organize the new code in order to make possible using in *few* selected places _GLIBCXX_ATOMIC_BUILTINS_4 to enable / disable the new feature completely. 2- Learn from guard.cc. In that libsupc++ implementation file, *certainly* atomic builtins are safely used, with fall-backs. Paolo.
g++ optimization bug version 4.2.3 and version 4.1.3
Hi,
When i run with the options g++ prog.c -o prog and run the exectuable
it gives me the correct output
but when i do g++ prog.c -o prog -O2 i get the wrong output
The inputs are below
[EMAIL PROTECTED]:/home/junk/prog# g++ bug_gccopt.cpp -O2
[EMAIL PROTECTED]:/home/junk/prog# ./a.out
1
10333
3135439247023686131
[EMAIL PROTECTED]:/home/junk/prog# g++ bug_gccopt.cpp
[EMAIL PROTECTED]:/home/junk/prog# ./a.out
1
10333
4511787964595
[EMAIL PROTECTED]:/home/junk/prog#
the file is attached.
i think i know where the bug is because i did it the wrong way and
then later corrected the overflow.
ull is unsigned long long.
for (it = pm.begin (); it != pm.end (); it++)
{
ull a = it->first, b = it->second;
/* These lines are getting optimized and overflow is occuring */
##ull num= (ull) (pow (( double) a, (double) b + 1) - 1);
##ull den=a-1;
##gg=gcd(num,den);
##num/=gg;
##den/=gg;
numprod *=num;
denprod *=den;
gg = gcd (numprod, denprod);
numprod /= gg;
denprod /= gg;
}
i got the wrong result when it were (the optimized code is giving the
answer when the actual code was below
The result i got from the below code is the same that i get from -O2
of the above code which is resulting in overflow )
for (it = pm.begin (); it != pm.end (); it++)
{
ull a = it->first, b = it->second;
nprod*= (ull) (pow (( double) a, (double) b + 1) - 1);
denprod*=a-1;
gg = gcd (numprod, denprod);
numprod /= gg;
denprod /= gg;
}
Am i doing anything wrong above ? is the typecast of ull and double wrong.
[EMAIL PROTECTED]:~/prog$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
[EMAIL PROTECTED]:~/prog$ g++-4.1 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20080308 (prerelease) (Ubuntu 4.1.2-21ubuntu1)
[EMAIL PROTECTED]:~/prog$
bug_gccopt.cpp
Description: Binary data
Re: g++ optimization bug version 4.2.3 and version 4.1.3
On Fri, Aug 22, 2008 at 2:47 PM, Niklaus <[EMAIL PROTECTED]> wrote: > Hi, > > > When i run with the options g++ prog.c -o prog and run the exectuable > it gives me the correct output > but when i do g++ prog.c -o prog -O2 i get the wrong output > On the trunk with -O2 I get the same value as with -O0. With -Wstrict-overflow=2, I get some warnings though: t.c:217: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 t.c:206: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 t.c:251: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 t.c: In function 'int main()': t.c:210: warning: assuming signed overflow does not occur when simplifying conditional to constant t.c:210: warning: assuming signed overflow does not occur when simplifying conditional to constant Thanks, Andrew Pinski
Re: g++ optimization bug version 4.2.3 and version 4.1.3
On Fri, Aug 22, 2008 at 3:14 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Fri, Aug 22, 2008 at 2:47 PM, Niklaus <[EMAIL PROTECTED]> wrote: >> Hi, >> >> >> When i run with the options g++ prog.c -o prog and run the exectuable >> it gives me the correct output >> but when i do g++ prog.c -o prog -O2 i get the wrong output >> Note by the way I think your ispow2 is incorrect. It is doing a "a == 1 & a != 0" and not ((a-1)&a) == 0. We do warn about this too: t.c:189: warning: suggest parentheses around comparison in operand of & -- Pinski
Re: g++ optimization bug version 4.2.3 and version 4.1.3
hi andrew,
this is C code. I don't use the functions ispow2 etc.
see the code below .
[EMAIL PROTECTED]:/home/junk/prog/tju# gcc bug_short.c -lm -O2
[EMAIL PROTECTED]:/home/junk/prog/tju# ./a.out
2383,1
31727,1
132265613,1
3145439247023686464
[EMAIL PROTECTED]:/home/junk/prog/tju# gcc bug_short.c -lm
[EMAIL PROTECTED]:/home/junk/prog/tju# ./a.out
2383,1
31727,1
132265613,1
10004511787964928
[EMAIL PROTECTED]:/home/junk/prog/tju# cat bug_short.c
#include
#include
typedef unsigned long long ull;
ull
gcd (ull a, ull b)
{
if (b == 0)
return a;
return gcd (b, a % b);
}
int
main ()
{
ull numprod, denprod, gg;
ull arr[] = { 2383, 31727, 132265613 };
ull acnt[] = {1,1,1};
int cntm = sizeof (arr) / sizeof (arr[0]), i;
numprod = denprod = 1;
for (i = 0; i wrote:
> On Fri, Aug 22, 2008 at 3:14 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>> On Fri, Aug 22, 2008 at 2:47 PM, Niklaus <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>>
>>> When i run with the options g++ prog.c -o prog and run the exectuable
>>> it gives me the correct output
>>> but when i do g++ prog.c -o prog -O2 i get the wrong output
>>>
>
> Note by the way I think your ispow2 is incorrect. It is doing a "a ==
> 1 & a != 0" and not ((a-1)&a) == 0. We do warn about this too:
> t.c:189: warning: suggest parentheses around comparison in operand of &
>
>
> -- Pinski
>
gcc-4.4-20080822 is now available
Snapshot gcc-4.4-20080822 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080822/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 139502 You'll find: gcc-4.4-20080822.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080822.tar.bz2 C front end and core compiler gcc-ada-4.4-20080822.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080822.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080822.tar.bz2 C++ front end and runtime gcc-java-4.4-20080822.tar.bz2 Java front end and runtime gcc-objc-4.4-20080822.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080822.tar.bz2The GCC testsuite Diffs from 4.4-20080815 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [PATCH][RFT] Optimization pass-pipeline re-organization [3/n]
Richard Guenther wrote: the redundancy elimination performed by DOM can be better handled elsewhere. The interesting question is there redundancy elimination left in DOM that is unique and if not, can we get the same overall effect if we remove the redundancy elimination from DOM and instead using existing passes for redundancy elimination. Same overall effect doesn't mean identical code, but ... though I am not sure (I didn't investigate) how much of the redundancy elimination code feeds the jump threading parts. I was thinking of moving the jump threading parts over to SCCVN instead, given that VRP lacks capabilities regarding to symbolical conditions. It's reasonably common. At one time I had mostly convinced myself that fixing PRE was the way to go as many of the complex threading cases would be much simpler if PRE was more effective at removing partial redundancies. But the more I pondered the problem the more I realized that the frameworks we have simply weren't sufficient to solve the class of problems I wanted to look at. In fact, there was a master's thesis (don't have it handy right now) which argued that what we're doing (poorly) in DOM is actually a whole new class of context/path specific optimizations and that solving them with traditional techniques was ultimately a horrid compile-time sink. They came up with a new framework to perform these context/path sensitive optimizations, but I wasn't ever able to wrap my head around it well enough to understand or explain it. In essence it was a context/path sensitive PRE-like algorithm. It looked expensive, but far less so than running multiple passes of our iterating DOM optimizer. Thanks. It seems the last DOM pass doesn't do very much as well, so I'll be playing with removing that as a last step of cleaning up the pipeline. Even if that might need another run of FRE instead of DOM. One of the indicators to watch is whether or not the RTL jump threading code starts to become more important -- if it does, then we're ripping too much out of DOM. When I last looked, the only common case left where the RTL version was still useful were cases where our tree aliasing code sucked horribly bad causing DOM/PRE to miss stuff which we later caught in the RTL jump threading code. jeff
Re: g++ optimization bug version 4.2.3 and version 4.1.3
Hi ,
are you getting the bug with latest trunk on this code. If you can
tell me , i'll forward it to debian/ubuntu mainters.
On Sat, Aug 23, 2008 at 4:07 AM, Niklaus <[EMAIL PROTECTED]> wrote:
> hi,
> -O0 gives me correct output
> but -O1 or -O2 gives me wrong output. i've attached .s files.
> Can it be a distro (ubuntu ) problem ?
>
> i tried with gcc-3.4 on ubuntu , 4.1,4.2 on ubuntu.
>
> Can some body tell me which file in gcc handles the overflow ?
> Files to look at in gcc or distro gcc-source ?
>
>
> On Sat, Aug 23, 2008 at 3:55 AM, Niklaus <[EMAIL PROTECTED]> wrote:
>> hi andrew,
>> this is C code. I don't use the functions ispow2 etc.
>>
>> see the code below .
>>
>>
>> [EMAIL PROTECTED]:/home/junk/prog/tju# gcc bug_short.c -lm -O2
>> [EMAIL PROTECTED]:/home/junk/prog/tju# ./a.out
>> 2383,1
>> 31727,1
>> 132265613,1
>> 3145439247023686464
>> [EMAIL PROTECTED]:/home/junk/prog/tju# gcc bug_short.c -lm
>> [EMAIL PROTECTED]:/home/junk/prog/tju# ./a.out
>> 2383,1
>> 31727,1
>> 132265613,1
>> 10004511787964928
>> [EMAIL PROTECTED]:/home/junk/prog/tju# cat bug_short.c
>> #include
>> #include
>> typedef unsigned long long ull;
>> ull
>> gcd (ull a, ull b)
>> {
>> if (b == 0)
>>return a;
>> return gcd (b, a % b);
>> }
>> int
>> main ()
>> {
>> ull numprod, denprod, gg;
>> ull arr[] = { 2383, 31727, 132265613 };
>> ull acnt[] = {1,1,1};
>> int cntm = sizeof (arr) / sizeof (arr[0]), i;
>> numprod = denprod = 1;
>> for (i = 0; i >{
>> ull a = arr[i], b = acnt[i];
>> printf ("%llu,%llu\n", a, b);
>> ull num = (ull) (pow ((double) a, (double) b + 1) - 1);
>> ull den = a - 1;
>> gg = gcd (num, den);
>> num /= gg;
>> den /= gg;
>> numprod *= num;
>> denprod *= den;
>> gg = gcd (numprod, denprod);
>> numprod /= gg;
>> denprod /= gg;
>>}
>> gg = gcd (numprod, denprod);
>> numprod /= gg;
>> denprod /= gg;
>> printf ("%llu\n", numprod);
>> return 0;
>> }
>> [EMAIL PROTECTED]:/home/junk/prog/tju#
>>
>>
>> [EMAIL PROTECTED]:~/prog/tju$ gcc bug_short.c -Wall -Wstrict-overflow=2 -lm
>> [EMAIL PROTECTED]:~/prog/tju$ gcc bug_short.c -Wall -Wstrict-overflow=2 -lm
>> -O2
>> [EMAIL PROTECTED]:~/prog/tju$ gcc -v
>> Using built-in specs.
>> Target: i486-linux-gnu
>> Configured with: ../src/configure -v
>> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
>> --enable-shared --with-system-zlib --libexecdir=/usr/lib
>> --without-included-gettext --enable-threads=posix --enable-nls
>> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
>> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
>> --enable-mpfr --enable-targets=all --enable-checking=release
>> --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
>> Thread model: posix
>> gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
>> [EMAIL PROTECTED]:~/prog/tju$
>>
>>
>> Do you want the asm files or other files ? tell me how to give to
>> you. you want me to do gcc -S and send you the output ?
>>
>> On Sat, Aug 23, 2008 at 3:48 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>>> On Fri, Aug 22, 2008 at 3:14 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On Fri, Aug 22, 2008 at 2:47 PM, Niklaus <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> When i run with the options g++ prog.c -o prog and run the exectuable
> it gives me the correct output
> but when i do g++ prog.c -o prog -O2 i get the wrong output
>
>>>
>>> Note by the way I think your ispow2 is incorrect. It is doing a "a ==
>>> 1 & a != 0" and not ((a-1)&a) == 0. We do warn about this too:
>>> t.c:189: warning: suggest parentheses around comparison in operand of &
>>>
>>>
>>> -- Pinski
>>>
>>
>
bug_short.c
Description: Binary data
