When a while loop with the true condition (while (1)) contains
an if statement with a modulus evaluated on a counter variable, it
appears that gcc incorrectly optimizes out the modulus check as a
constant (even though the counter variable is updated after the if
statement). If the counter
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-01 01:25 ---
That is because it is the same as PR 31217.
*** This bug has been marked as a duplicate of 31217 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I have isolated the problem to a very small test program.
There are 2 tests in main, testa builds an anonymous union with
bit-fields in it. testb builds a similar anonymous union but this time with a
named structure in it but otherwise identical members.
testa gives
libgo fails to build. Here's the error output:
gmake[4]: Entering directory
`/usr/home/chris/gnuobj/gccgo/i386-unknown-freebsd8.1/libgo'
rm -f syscall.gox syscalls/libsyscall.a
test -d syscalls || mkdir -p syscalls
files=`echo ../../../../gnusrc/gccgo/libgo/syscalls/errstr.go
[I know this is a duplicate of 43810, but the information there is
partly misleading, so I decided to file a new report.]
If GCC is configured for powerpc with --enable-target-optspace,
libgcc_s objects get compiled with -Os, and this causes libgcc_s
to
g++ 4.5.0 produces an ICE (segmentation fault) on the code in the
How-To-Repeat section. The error is (the first non-blank line of the
example is line 1):
test.ii: In instantiation of âeintâ:
test.ii:19:8: instantiated from here
test.ii:16:32: internal compiler error: Segmentation fault
PowerPC suboptimal add with carry optimization
Environment:
System: Linux gentoo-jocke 2.6.31-gentoo-r6 #1 SMP PREEMPT Sun Feb 28 22:54:53
CET 2010 i686 Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz GenuineIntel GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
ICE while building cross-compiler for ARM.
$ /usr/src/gcc-build/./gcc/xgcc -B/usr/src/gcc-build/./gcc/
-B/usr/src/armtest/arm-none-eabi/bin/ -B/usr/src/armtest/arm-none-eabi/lib/
-isystem /usr/src/armtest/arm-none-eabi/include -isystem
/usr/src/armtest/arm-none-eabi/sys-include-g -O2
This is a general m68k code generation regression. Starting with revision
150588 GCC for m68k generates surprising code for auto increments, eg.
for a strlcpy implementation. Compiling this code with the 4.5.0 snapshot
from 20100107 yields:
-- 4.5.0 --
_strlcpy:
movel d3,s...@-
ICE on ia64 at -O1 and higher, seen with gcc 4.3 and 4.4 but not 4.2.
% gcc -O -c t.c
t.c: In function 'main':
t.c:5:1: error: unrecognizable insn:
(insn 5 4 6 3 t.c:3 (set (reg:DF 344)
(unsigned_float:DF (reg/f:DI 328 sfp))) -1 (nil))
t.c:5:1: internal compiler error: in
A simple function to store a small struct ends up writing the struct to
memory twice unnecessarily (plus writing it for real the third time).
The function's args are passed in r0-r3 (with r1-r3 being the struct).
It compiles to a sequence containing the following loads and stores,
among others:
err_bad_typedef.c leads to a call to initialize_aggregate with
arg-elemnts==NULL. This sets ptr on line 46 of
libffi/src/prep_cif.c to NULL, which is then dereferenced on
line 48.
Environment:
System: Linux dps 2.6.30.1-nofb #3 SMP PREEMPT Tue Jul 7 13:26:53
compile the attached code with the -std=c++0x flag.
Environment:
System: Linux x 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --prefix=/home/x/gcc-4.4-20090616
Compiling the following (nonsense but valid) code triggers an internal
compiler error.
Environment:
System: Linux thanatos 2.6.26-2-686-bigmem #1 SMP Thu Mar 26 02:03:34 UTC 2009
i686 GNU/Linux
How-To-Repeat:
Compile the following:
-- snip --
struct s {
When building a program that uses an objc library as a DLL, libobjc
can't find its classes. When the program and the library are statically
linked, it works.
My libobjc itself is linked as a static library.
Environment:
System: Linux asgard.webkeks.org 2.6.28.5 #1
Example program works with option -O1, but not with -O2
Problem occurs with gcc 4.3.2 and 4.4.0, but not with 4.2.4
Environment:
System: Linux andiunx 2.6.27-11-generic #1 SMP Fri Dec 19 16:29:52 UTC 2008
i686 GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target:
In the context of a function returning int, and rfp-signed is a
one-bit field,
return rfp-signed_flag ? 1 : 0;
yields -1. This is an optimization problem, seen with -O2 but not -O1.
Isolated to -ftree-vrp. Not seen in gcc-4.3 or earlier.
Environment:
System:
When the below code (see How-To-Repeat) is compiled and run, the
program waits for input after initializing the Scanner. That input is
then returned to the first input.next() call, and each input.next()
call returns the user input given during the previous call.
Environment:
System: Linux
NOTE: Defaulting component because reported component no longer exists
ICE: Segmentation fault when compiling with an incorrect used
__attribute__((noreturn));
Environment:
System: Linux molybdaen 2.6.26-1-686 #1 SMP Wed Sep 10 16:46:13 UTC 2008 i686
GN
U/Linux
host: i486-pc-linux-gnu
Executing 'gcc -E -dM -fpreprocessed - /dev/null' gives:
stdin:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Environment:
G++ reports a segmentation fault when compiling the code below.
Environment:
System: Linux temporal.corp.google.com 2.6.18.5-gg34workstation-mixed64-32 #1
SMP Thu May 8 01:31:23 UTC 2008 x86_64 GNU/Linux
Architecture: x86_64
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target:
Compiling the attached piece of code produces this:
foo.c: In function 'bar':
foo.c:8: warning: 'bar_thing.member' is used uninitialized in this function
but line 8 is in foo(), not bar, and bar_thing isn't in scope.
It has inlined foo (confirmed in the assembler output) and it's
__has_trivial_destructor() returns false for all reference types, but
should return true according to documentation. The documented behavior
is consistent with what is required by the c++0x draft.
Environment:
System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007
The __is_pod() built-in returns false for pod class types that have base
classes, which is allowed by c++0x.
Environment:
System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build:
g++ is unable to compile a call to a templatized method from a template
function that takes the class that contains the templatized methods as
a template parameter.
Environment:
System: Linux bnell-deb4-64 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007
x86_64 GNU/Linux
Architecture: x86_64
Building Regina-REXX-3.4 from source distribution. The linker fails
with the following error:
/usr/local/bin/gcc -O2 -I/usr/local/include -pthreads -L/usr/local/lib -o
execiser32 execiser.o -L. -lregina -lfl -lm -lnsl -lsocket -lcrypt -ldl
-lpthread
/usr/local/bin/ld: execiser32:
Here is the minimal test case exhibiting my trouble:
$ cat bug.cc
#include iostream
class c { public: c (); };
c::c ()
{
int i = 42;
std::cout i std::endl;
}
int
main (int argc, char** argv)
{
c* C = new c;
}
I compile it with the following
GCC generates odd code sequence..
Part of the source (full source in attachment):
usbd_status
usbd_do_request_flags_pipe(usbd_device_handle dev, usbd_pipe_handle pipe,
usb_device_request_t *req, void *data, u_int16_t flags, int *actlen,
u_int32_t timeout)
{
Gcc's friend-mechanism seems to expand to nested classes as well, although
the C++ standard explicitly tells differently.
The following example is almost straight from the C++ standard (11.4/2). The
only change is that inheritance is commented out for class X (in order to
remove the first error
Bootstrapping current mainline as of 20070903 fails on alpha-dec-osf5.1b
building the stage 1 libgcc:
/vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.3.0-20070903/5.1b-gcc/./gcc/
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem
By using an integer variable as the size of an array to be
initialized on the stack, you can trick gcc into accepting
and trying to create a negatively-sized array. The assembly
it generates in such a case seems to indicate it really thinks
it has a negatively-sized array.
As of 20070730, all gfortran tests fail on alpha-dec-osf4.0f:
25729:./PR19754_2.exe: /sbin/loader: Error: Unresolved symbol in
/amnt/sequoia/export/vol/gcc/obj/alpha/gcc-4.3.0-20070730/4.0f-gcc/alpha-dec-osf4.0f/./libgfortran/.libs/libgfortran.so.3:
vsnprintf
25729:./PR19754_2.exe: /sbin/loader:
On both alpha-dec-osf4.0f and alpha-dec-osf5.1b, current mainline (as of
r126588) fails to bootstrap:
/vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.3.0-20070712/4.0f-gcc/./gcc/
-B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/lib/ -isystem
Bootstrapping mainline on sparc-sun-solaris2.10 as of r126588 fails
building the sparcv9 stage2 libgcc:
/vol/gccsrc/obj/gcc-4.3.0-20070712/10-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.3.0-20070712/10-gcc/./gcc/
-B/vol/gcc/sparc-sun-solaris2.10/bin/ -B/vol/gcc/sparc-sun-solaris2.10/lib/
-isystem
On both the 4.2 branch and mainline, libjava fails to build on
mips-sgi-irix6.5:
* sysdeps_dir isn't set in configure.host, so the generic locks.h is used
which just errors out
* libgcj_interpreter is set to yes in the general mips-* clause in
configure.host, but this cannot work for IRIX 6
Even with the fix for PR libgcj/32651 (which sets libgcj_interpreter=no),
libgcj doesn't build on IRIX 6.5 (or any other platform) because several
types and classes from java-interp.h are used even with INTERPRETER
undefined. This is a regression from 4.1 and 4.2 and can easily be
reproduced
Bootstrapping the current 4.2 branch on alpha-dec-osf5.1b with GCC 3.4 as
the bootstrap compiler, I get a comparison failure in exp_aggr.o:
Comparing stages 2 and 3
Bootstrap comparison failure!
./ada/exp_aggr.o differs
make[2]: *** [compare] Error 1
There's only a minimal difference in the
All gnat.dg tasking tests FAIL on IRIX 5.3 since the platform lacks thread
support:
failed run-time assertion : Tasking not implemented on this configuration
FAIL: gnat.dg/curr_task.adb execution test
Instead of failing, the tests should be marked UNSUPPORTED as is done for
ACATS.
Environment:
When running the gnat.dg tests on multilib-targets (like
sparc-sun-solaris2*, i386-pc-solaris2*, or mips-sgi-irix6*), most tests for
a non-default multilib fail with confusing error messages:
Running /vol/gcc/src/gcc/gcc/testsuite/gnat.dg/dg.exp ...
Executing on host:
sample code:
#include stdio.h
int main()
{
char cp[2];
cp[0] = 'A';
cp[1] = 'B';
printf(%x %x\n,cp[0],cp[1]);
cp[0] ^= (cp[1]^=(cp[0]^=cp[1]));
printf(%x %x\n,cp[0],cp[1]);
return 0;
}
The complex byte swapping instruction is far fetched but seems legal.
It actually swaps bytes
All libgomp tests fail to link on IRIX 6:
Executing on host: /vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/xgcc
-B/vol/gcc/obj/gcc-4.3.0-20070622/6.5-gcc/gcc/
/vol/gcc/src/gcc-dist/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90
I noticed that the libstdc++ testsuite fails to run on mips-sgi-irix6.5 and
mips-sgi-irix5.3::
ERROR: tcl error sourcing
/vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not link libtestc++.a
while executing
error could not link libtestc++.a
(procedure
A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas
2.15 fails to link libgcj.so:
ld: fatal: relocation error: R_386_GOTOFF: file java/.libs/process-Posix.o:
symbol java::lang::PosixProcess::queueLock: relocation must bind locally
collect2: ld returned 1 exit status
A mainline bootstrap as of 20070618 on Solaris 10/x86 with the bundled gas
2.15 and my patch to support boehm-gc for x86-64
http://gcc.gnu.org/ml/java-patches/2007-q2/msg00330.html
fails when linking the 64-bit libgcj:
[ca. 6800 lines omitted]
NOTE: Defaulting component because reported component no longer exists
Environment:
System: Linux marko2 2.6.15-28-686 #1 SMP PREEMPT Thu Feb 1 16:14:07 UTC 2007
i686 GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: m68hc11-unknown-none
configured with:
All gfortran execute tests fail on alpha-dec-osf4.0f since snprintf is
missing in libc, but used in libgfortran.
Environment:
System: OSF1 hindemith V4.0 1229 alpha
Machine: alpha
host: alpha-dec-osf4.0f
build: alpha-dec-osf4.0f
target: alpha-dec-osf4.0f
configured with:
During a mainline bootstrap on alpha-dec-osf5.1b, the libstdc++ configure
failed:
checking for exception model to use... configure: error: unable to detect
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
config.log reveals:
configure:13794: checking for exception model to
When Linux vanilla kernel 2.4.34.5 is compiled with -march=c3 (VIA C3)
- kernel crashes after boot on a VIA C3
.config: CONFIG_MCYRIXIII=y
Environment:
System: Linux bongo 2.4.34.5-ARXc3 COHERENT #9-ARX (Build 3359) Fri Jun 8
16:41:33 CEST 2007 i686 i686 i386 GNU/Linux
Let us consider the following code:
-
void qHash(double) {}
template class T
struct QSet
{
void foo()
{
qHash(T());
}
};
// void qHash(double) {} // ok if placed here
void qHash(int*) {}
int main()
{
QSetdouble s;
s.foo(); // ok
QSetint* sp;
sp.foo(); // do not compile,
g++ parses the code correctly and calls the correct overloaded
increment operators, but in the wrong postfix order. The semantics of
postfix are to take the rvalue before invoking the method. Note this
is not related to multiple reference ordering between sequence points
as the object is only
Compilation of the attached code yields an ICE in certain cases.
Environment:
System: Linux chii 2.6.20 #3 SMP Sun Feb 11 23:52:47 EET 2007 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-pc-linux-gnu
build: x86_64-pc-linux-gnu
target: x86_64-pc-linux-gnu
configured with:
// BUG DEMO for gcc 4.1.2 (and 4.1.1) for 32-bit x86
//
// If operator delete() is over-ridden in a base class, then
// if the implementation of delete() stores into the storage used
// by the object, the store seems to be removed by the compiler
// (maybe because the compiler thinks stores to a
The following code tests that values are passed correctly from a
call to a function. This fails, when the followign code is
compiled with -O2 and executed:
foo: foo.c:65: callee_b0f: Assertion `b14.b3 == b20.b3' failed.
The code below is automatically generated explicitly to test for
Installing GCC [1] explicitly encourages building the source code
with objdir separate from srcdir.
[1] http://gcc.gnu.org/install/configure.html
In particular:
mkdir objdir
cd objdir
srcdir/configure [options] [target]
../hercules/general2.c: In function 'z900_test_and_set':
../hercules/general2.c:1415: error: unrecognizable insn:
(insn 130 128 131 17 (set (reg:QI 102)
(const_int 255 [0xff])) -1 (nil)
(nil))
../hercules/general2.c:1415: internal compiler error: in
extract_insn,
Changed nothing in sources, build just from unpacked
`gcc-4.1.1.tar.bz2'. Still tests try to run `autogen'.
make: Entering directory `gcc-4.1.1-rhysling'
make[1]: Entering directory `gcc-4.1.1-rhysling'
make[2]: Entering directory `gcc-4.1.1-rhysling/fastjar'
make[2]: Leaving directory
`-fdump-tree-inlined' creates no files.
Environment:
System: Linux 2.2.19-7.1.asp.2.gin #1 Tue Jun 15 16:42:13 MSD 2004 i686
unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure
How-To-Repeat:
./xgcc -B./ \
# ...
-DL__gcc_bcmp -c SHARED_DIR/gcc-4.1.1/gcc/libgcc2.c -o libgcc/./__gcc_bcmp.o
/var/tmp//ccBzKd2Z.s: Assembler messages:
/var/tmp//ccBzKd2Z.s:690: Error: misaligned data
make[3]: *** [libgcc/./_divdi3.o] Error 1
The same for targets:
libgcc/./_udivdi3.o
libgcc/./_umoddi3.o
`gcc-4.1.1/INSTALL/specific.html' specifies `#sparc-sun-solaris2' link
for `sparc-sun-solaris2*' item, but there is no such anchor in the
document. Instead, this item is anchored with
`sparc_002dsun_002dsolaris2'.
How-To-Repeat:
Point browser to the file, try to follow the link in the document.
For setting individual bits of a register, the construct
unsigned char BitLocation = Whatever;
REG |= (1BitLocation);
is commonly used. avr-gcc fails to realize that the target register
is only 8 bits wide and performs an unnecessary 16-Bit shift of 1.
Compilation of functions/subroutines with optional derived type arguments
gives segmentation fault.
a.F90: In function 'func':
a.F90:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html
I'm trying to compile svgalib (http://www.svgalib.org/) on my
FreeBSD/amd64 system.
Although the package uses assembler in a few places, this can be
disabled with the -DNO_ASSEMBLY flag. After the pre-processor
there is no assembler code in the
Stalin is a Scheme compiler that generates C code. Stalin is itself written in
C and can compile itself. I am preparing a new release of Stalin for Debian
Etch. This release compiles with earlier versions of gcc, such as gcc-4.0, but
not with gcc-4.1. It gives an ICE.
The preprocessed source is
System include file is broken as described in Fix section.
fixincludes does not create any modification of it, let alone fixed as
described. Newly built gcc includes broken file when run. This may
break just any program built with gcc, and does break compiling
`toplev.c' with `stage1/xgcc' as
When executing `make bootstrap', the following error occurs.
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -O2 -g
-fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition
Observing it at least on stage 1 compiler, and exactly the same way as
in 3.3.2.
If inline function, later called a functional, is passed a function
argument that is constant and inline, and said argument is called in
the functional body, and when inline expansions are on, compiler
expand inline
Some targets in `gcc/Makefile.in' built while `make bootstrap' specify
`-B$(build_tooldir)/bin/'. All of this is done when nothing from gcc
being built is installed in that directory yet. What is installed
there, if any, generally has nothing to do with gcc at all. It may
easily be files from
-std=c89 doesn't warn about gcc's ?: extension
Environment:
System: Linux rho 2.6.15-1-amd64-k8 #2 Tue Mar 7 06:53:26 UTC 2006 x86_64
GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with:
libstdc++ fails to bootstrap on Tru64 UNIX as of 20060710:
/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060710/4.0f-gcc/alpha-dec-osf4.0f/libstdc++-v3/src
While investigating the root cause of PR libgcj/28189, I noticed that both
on the 4.1 branch and on mainline (where the libjava testsuite timeouts
occur) the boehm-gc test had started failing as well (which easily goes
unnoticed due to PR boehm-gc/11412): gctest fails like this:
Key creation
Bootstrapping current mainline on Tru64 UNIX fails in stage1 as of 20060705:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
Bootstrapping current mainline as of 20060705 fails on Tru64 UNIX V5.1B
when trying to genererate the PCH file for extc++.h:
/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc -nostdinc++
libgomp just doesn't configure any more on Tru64 UNIX V5.1B:
configure: error: Pthreads are required to build libgomp
This is due to the last configure.ac change:
2006-07-05 Eric Christopher [EMAIL PROTECTED]
* configure.ac: Depend addition of -pthread on host OS.
*
An array of 64K labels triggers the error.
Environment:
System: FreeBSD FreeBSD.jphartmann.net 6.1-RELEASE FreeBSD 6.1-RELEASE
#1: Sat Jun 17 11:51:42 CEST 2006
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/KERNEL i386
machine, os, target, libraries (multiple lines)
host:
Between 20050805 and 20060208, many libjava execution tests started to time
out on Tru64 UNIX (both V4.0F and V5.1B), as can be seen comparing the
following test results:
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00708.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00899.html
Since at least 20060503, libjava fails to bootstrap on IRIX 6.5.28:
/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc/xgcc -shared-libgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.2.0-20060616/6.5-gcc-java/mips-sgi-irix6.5/32/libstdc++-v3/src
Trying to bootstrap mainline on IRIX 6.5 with java included failed since
boehm-gc (which is required for libjava) isn't built:
In file included from /vol/gcc/src/gcc-dist/libjava/include/jvm.h:25,
from /vol/gcc/src/gcc-dist/libjava/include/java-interp.h:14,
from
A memory leak happens when std::ios::sync_with_stdio(false);
valgrind:
...
==13644==
==13644== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==13644== malloc/free: in use at exit: 122,880 bytes in 6 blocks.
==13644== malloc/free: 6 allocs, 0 frees, 122,880 bytes allocated.
Bootstrapping current mainline with Ada included fails on Tru64 UNIX V5.1B
when linking gnatbind:
/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/5.1b-gcc/./prev-gcc/
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
Bootstrapping mainline on Solaris 10/x86 (configured for
i686-pc-solaris2.10 to work around the still unfixed PR target/26146) fails
compiling several Ada files:
/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.2.0-20060606/10-gcc-gas-amd64/./gcc/
I was trying to install the amule-2.0.3-r4 package from source in my gentoo
linux.
The package is public so if it could be a package error it should be reported
on their web site, but it is not.
I send this bug directly to you gcc-team, without interesting the gentoo
forums, cause it is
Current mainline fails to bootstrap on IRIX 5.3:
configure: error: Pthreads are required to build libgomp
make[1]: *** [configure-target-libgomp] Error 1
Environment:
System: IRIX lyra 5.3 11091812 IP22 mips
host: mips-sgi-irix5.3
build: mips-sgi-irix5.3
target: mips-sgi-irix5.3
configured
When compiling a C++ program (for the AVR target) that defines interrupt
vectors using the externally_visible attribute, I get this ICE message:
avrlib/bits/atmega128_usart.cpp:20: internal compiler error: tree check:
expected tree that contains 'decl minimal' structure, have 'omp_atomic' in
If you use memcmp to compare strings, it does not stop reading when it
finds the terminating null byte of the shortest string, which can
trigger an attempt to read unallocated memory. I'd recommend
replacing instances of memcmp on strings with strncmp, which won't
attempt to read past the end
When building gdb with -Werror, the compile fails due to what looks
like a spurious warning from using -Wuninitialized. I've reduced the
testcase down to a minimal one, hopefully preserving the original
cause of the warning.
Environment:
System: Linux puffer.diveadx.com 2.6.16-1.2069_FC4smp #1
NOTE: Defaulting component because reported component no longer exists
When compile with gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c,
there will be the error:
[EMAIL PROTECTED]:~/src/qemu-bug$ gcc-3.4 -O1 -fgcse -c -o qemu-bug.o qemu-bug.c
qemu-bug.c: In function `main':
qemu-bug.c:2: error:
when compile following file[1] with option `-Wall', it will give a
warning[2]. g++-4.0 do not has this problem. I don't think this
warning is proper.
[1]
// begin array2.cpp
#include tr1/array
int main() {
std::tr1::arrayint, 2 foo = {0, 1};
return foo[1];
}
// end
[2]
array2.cpp: In
This program (which has no included files) causes an ICE and a bus error:
--
typedef unsigned char uint8_t ;
typedef unsigned short uint16_t ;
typedef unsigned long uint32_t ;
#define PROGMEM __attribute__((__progmem__))
templatetypename T
T PROGMEM * rom(const T init)
{
static T
During bootstrap line 3072 of varasm.c generates a warning that
shift = width of type, and the build dies due to -Werror.
This diagnosis is correct but the shift is unreachable.
Environment:
System: Linux dps 2.6.15 #2 PREEMPT Sat Jan 7 17:47:27 GMT 2006 i686 GNU/Linux
The code below generates a compiler ICE with g++ 3.3 (debian stable),
g++ 3.4 (debian testing):
[pollindd] ~ g++-3.3 -c ice-typeid.cc
1036
ice-typeid.cc: In function `int bug5(BaseB*)':
ice-typeid.cc:43: internal compiler error: in expand_expr, at expr.c:8833
Please submit a full bug
As described in PR libobjc/26309, defining _XOPEN_SOURCE in thr-objc.c
breaks bootstrap on Tru64 UNIX V4.0F. It is yet unclear why this
definition is necessary at all, so instead of the fix/workaround commited
for that PR, it might be possible to avoid defining _XOPEN_SOURCE in the
first place.
We are targetting the compilers for a system-on-chip solution we are
developing based on an ARM 926 which is without an FPU so we have
defaulted on SOFTWARE FLOATING POINT.
#define TARGET_DEFAULT (ARM_FLAG_SOFT_FLOAT | ARM_FLAG_APCS_32 | \
Mainline as of 20060206 fails to bootstrap on alpha-dec-osf4.0f while
building libgomp:
/vol/gcc/obj/gcc-4.2.0-20060206/4.0f-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.2.0-20060206/4.0f-gcc/./gcc/
-B/vol/gcc/share/alpha-dec-osf4.0f/bin/ -B/vol/gcc/share/alpha-dec-osf4.0f/lib/
-isystem
Mainline as of 20060206 and the 4.1 branch as of 20060208 fail to bootstrap
in libobjc:
/vol/gcc/obj/gcc-4.2.0-20060206/4.0f-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.2.0-20060206/4.0f-gcc/./gcc/
-B/vol/gcc/share/alpha-dec-osf4.0f/bin/ -B/vol/gcc/share/alpha-dec-osf4.0f/lib/
-isystem
When casting a pointer and checking for == NULL, the check is skipped
when -O3 is enabled. I found this problem while compiling bind with
uClibc,
but could reproduce the problem with the debian version of gcc and this
simple
test file.
Environment:
System: Linux
Trying to bootstrap mainline as of 20060206 on i386-pc-solaris2.10 with gas
2.15 and no options to select a specific target fails when trying to build
the amd64 libgcc multilib:
/vol/gcc/obj/gcc-4.2.0-20060206/10-gcc-gas/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.2.0-20060206/10-gcc-gas/./gcc/
When trying to bootstrap mainline on Solaris 10/x86 with the native
assembler, building libffi fails:
/vol/gcc/obj/gcc-4.2.0-20060126/10-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.2.0-20060126/10-gcc/./gcc/
-B/vol/gcc/share/i386-pc-solaris2.10/bin/
-B/vol/gcc/share/i386-pc-solaris2.10/lib/ -isystem
Current mainline (as of 20060131) fails to bootstrap on Solaris 10/x86 in
libgcc-math:
/vol/gcc/obj/gcc-4.2.0-20060131/10-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.2.0-20060131/10-gcc/./gcc/
-B/vol/gcc/share/i386-pc-solaris2.10/bin/
-B/vol/gcc/share/i386-pc-solaris2.10/lib/ -isystem
Since at least 20060126, make check on Solaris 10/x86 fails with a SEGV if
expect is invoked. I could trace this down to libgcc_s.so.1: If I point
LD_LIBRARY_PATH at the newly built libgcc_s.so.1, expect crashes
immediately, if I use one from e.g. GCC 3.1, it works as expected. Other
programs
When configuring the 4.1 branch (I haven't tried this on mainline yet since
I only recently found a workaround for PR target/24334) on IRIX 6.5 with
GNU as 2.16.1 and the SGI MIPSpro ld, libstdc++.so fails to link:
ld32: FATAL 2 : Internal: at ../../ld/section_type.c In load_info() unknown
1 - 100 of 224 matches
Mail list logo
