[Bug c/28833] New: GCC 4.1.1 ICEs compiling Xorg 6.8.2
Attached (gzipped) fbmmx.i (from Xorg 6.8.2 xc/programs/Xserver/fb/fbmmx.c)
gives "fbmmx.c:871: internal compiler error: in push_reload, at reload.c:1303"
when compiled with 4.1.1 on i686-linux-gnu. This is probably a regression as
I've previously compiled the same Xorg release fine with 4.1.0.
GCC also emits lots of warnings, but no errors.
--- GCC version
[EMAIL PROTECTED] fb]$ gcc --version
gcc (GCC) 4.1.1
--- GCC configured with
../g*/configure --prefix=/usr --enable-shared --enable-languages=c,c++,java
--enable-threads --enable-__cxa_atexit --with-system-zlib --disable-multilib
--- GCC command to trigger failure
gcc -m32 -c -O2 -O9 -march=pentium4 -mtune=pentium4 -mmmx -msse -msse2 -pipe
-ansi -pedantic -Wall -Wpointer-arith -Wundef-fno-merge-constants -c
-mmmx -Winline --param inline-unit-growth=1 --param
large-function-growth=1 fbmmx.i
--- GCC output
fbmmx.c:39: warning: specifying vector types with __attribute__ ((mode)) is
depr
ecated
fbmmx.c:39: warning: use __attribute__ ((vector_size)) instead
fbmmx.c:40: warning: specifying vector types with __attribute__ ((mode)) is
depr
ecated
fbmmx.c:40: warning: use __attribute__ ((vector_size)) instead
fbmmx.c:41: warning: specifying vector types with __attribute__ ((mode)) is
depr
ecated
fbmmx.c:41: warning: use __attribute__ ((vector_size)) instead
fbmmx.c:43: warning: ISO C90 does not support ?long long?
fbmmx.c:79: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:80: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:81: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:82: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:83: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:84: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:85: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:86: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:87: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:88: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:89: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:90: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:91: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:92: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:93: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c:94: warning: ISO C90 forbids specifying subobject to initialize
fbmmx.c: In function ?expand565?:
fbmmx.c:306: warning: ISO C90 forbids mixed declarations and code
fbmmx.c: In function ?fbCompositeSolidMask_nx8xmmx?:
fbmmx.c:658: warning: ISO C90 does not support ?long long?
fbmmx.c:701: warning: ISO C90 does not support ?long long?
fbmmx.c: In function ?fbCompositeSolidMask_nx8x0565mmx?:
fbmmx.c:764: warning: ISO C90 does not support ?long long?
fbmmx.c:824: warning: ISO C90 does not support ?long long?
fbmmx.c:871: internal compiler error: in push_reload, at reload.c:1303
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: GCC 4.1.1 ICEs compiling Xorg 6.8.2
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter at empeg dot com
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28833
[Bug c/28833] GCC 4.1.1 ICEs compiling Xorg 6.8.2
--- Comment #1 from peter at empeg dot com 2006-08-24 10:37 --- Created an attachment (id=12124) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12124&action=view) gzipped preprocessed source of testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28833
[Bug c++/35799] New: GCC uses inheritance information it doesn't yet know
In the following code (condensed from a real example where Fnord was
boost::intrusive_ptr), the call to the Fnord constructor in function make_fnord
only succeeds because Aubergine is derived from Base. But GCC doesn't "know"
that Aubergine is derived from Base until after it's seen make_fnord. (And
make_fnord itself isn't templated in any way, so this isn't a
delayed-instantiation thing, although similar examples where Fnord isn't
templated do successfully produce an error.) GCC 2.95.3 gave an error on this
code, but GCC 4.1.2, 4.2.3, and 4.3.0 accept it (even with
-fno-unit-at-a-time). Shouldn't it be an error?
template
class Fnord
{
public:
explicit Fnord(T* p) { intrusive_ptr_add_ref(p); }
};
class Base
{
};
void intrusive_ptr_add_ref(Base*);
class Aubergine;
Fnord make_fnord(Aubergine *p)
{
return Fnord(p);
}
class Aubergine: public Base
{
};
GCC 2.95.3's error:
wtf.cpp: In method `Fnord::Fnord(Aubergine *)':
wtf.cpp:18: instantiated from here
wtf.cpp:5: type `Base' is not a base type for type `Aubergine'
gcc -v on the 4.3.0 which fails to give an error:
Using built-in specs.
Target: x86_64-linux
Configured with: ../gcc-4.3.0/configure --prefix=/usr --enable-shared
--enable-languages=c,c++ --enable-threads --enable-__cxa_atexit
--with-system-zlib --disable-multilib x86_64-linux
Thread model: posix
gcc version 4.3.0 (GCC)
--
Summary: GCC uses inheritance information it doesn't yet know
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter at empeg dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35799
[Bug c++/60971] New: Wrong code when coercing unsigned char to bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971
Bug ID: 60971
Summary: Wrong code when coercing unsigned char to bool
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at empeg dot com
GCC 4.9.0 for x86_64 produces the wrong code for bar1 given this C++ file:
unsigned char foo();
bool bar1() { return foo() & 1; }
bool bar2() { return foo() & 2; }
gcc -O2 -S gcc49.cpp -Wall -Wextra
bar1 is compiled into a direct tailcall to foo() -- no and'ing with 1 is done
to the result (so it returns the Wrong Thing if foo() returns 0x40, say). bar2
is correct however.
GCC 4.8.2 got this right (its output for bar1 and bar2 is very similar except
for the constant being and'ed with).
GCC 4.9.0 gets it right if "unsigned char" is replaced with "unsigned short" or
"unsigned int".
4.9.0 built from release tarball, configured --enable-shared \
--enable-languages=c,c++ --disable-werror \
--enable-threads --disable-multilib \
--enable-__cxa_atexit --with-system-zlib
When GCC was compiled, CFLAGS, LIBCFLAGS, LIBCXXFLAGS, and BOOT_CFLAGS were all
set to "-O2 -O9 -march=core2 -mtune=core2 -pipe".
[Bug c++/42768] ICE: libstdc++-v3/libsupc++/vec.cc:354
--- Comment #4 from peter at empeg dot com 2010-01-26 19:29 --- I get the same error on host=build=x86_64-linux, target=i586-mingw32. At least in my case, this is a regression in 4.4.3, as 4.4.2 worked fine. -- peter at empeg dot com changed: What|Removed |Added CC||peter at empeg dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
