--- Comment #3 from dhazeghi at yahoo dot com 2003-05-31 01:00 ---
Hello,
with gcc 3.2.3, I can reproduce this bug on an i686-linux to i386-mingw32 cross
compiler. With
gcc 3.3 branch, and mainline (20030530), I cannot reproduce this error. Should
this bug be
closed? Thanks,
Dara
-
--- Comment #6 from neroden at gcc dot gnu dot org 2003-05-22 17:19 ---
toggling
--- Comment #7 from neroden at gcc dot gnu dot org 2003-05-22 17:19 ---
toggling
--- Comment #8 from neroden at gcc dot gnu dot org 2003-05-22 17:19 ---
toggling
--- Comment #9 fr
--- Comment #4 from bangerth at dealii dot org 2003-05-24 01:42 ---
Not a bug. Your code is roughly equivalent to this:
--
template
struct Ptr {
~Ptr()
{
if (ptr_) {
if (ptr_->unref())
delete ptr_;
ptr_ =
--- Comment #3 from mmitchel at gcc dot gnu dot org 2003-08-30 01:45
---
Fixed in GCC 3.4.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
St
The comparison between 0 and the largest power of 2 that fits in a long double
gives a non-zero result!!!
Environment:
System: OSF1 spe171.testdrive.hp.com V5.1 2650 alpha
Architecture: alphaev56-dec-osf5.1
host: alphaev56-dec-osf5.1
build: alphaev56-dec-osf5.1
target: alphaev56-dec-osf5.1
config
--- Comment #17 from pinskia at gcc dot gnu dot org 2004-10-11 03:42
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
no bug here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
There is no bug in this bug number.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
--- Comment #9 from neroden at gcc dot gnu dot org 2005-05-16 11:59 ---
Committed fix to mainline.
--
neroden at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from nathan at gcc dot gnu dot org 2005-07-12 11:29 ---
fixed on 4.0 branch
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
Stat
GCC accepts that a function is defined several times under the same
name, provided it is static inline. It seems to rely on the assembler
to check this kind of issues.
Environment:
System: Linux nostromo 2.4.27-2-686-smp #1 SMP Tue Aug 16 15:57:25 JST 2005
i686 GNU/Linux
Architecture: i686
ho
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 -mfloat-
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-gn
The new gcc.c-torture/compile/20050622-1.c testcase fails on Tru64 UNIX
V5.1B:
+FAIL: gcc.c-torture/compile/20050622-1.c (test for excess errors)
FAIL: gcc.c-torture/compile/20050622-1.c (test for excess errors)
Excess errors:
currfunc_frameoffset = 75497488
currfunc_regoffset =
Between 20050525 and 20050627 there appeared a couple of new libstdc++
testsuite failures on Tru64 UNIX V5.1B:
+FAIL: 23_containers/bitset/18604.cc (test for excess errors)
+FAIL: 23_containers/deque/14340.cc (test for excess errors)
+FAIL: 23_containers/deque/18604.cc (test for excess errors)
+F
Several testcases fail producing invalid assembler code, e.g.
FAIL: gcc.dg/gnu89-init-1.c (test for excess errors)
Excess errors:
as1: Warning: /tmp//ccuPshWt.s, line 1: Length of .lcomm was less than 1:
__compound_literal.1
FAIL: gcc.dg/range-test-1.c (test for excess errors)
Excess errors:
as
The gcc.dg/vect/pr18536.c testcase fails on alpha-dec-osf5.1b:
FAIL: gcc.dg/vect/pr18536.c (test for excess errors)
Excess errors:
/vol/gnu/src/gcc/gcc-dist/gcc/testsuite/gcc.dg/vect/pr18536.c:13: internal
compiler error: in alphaev4_insn_pipe, at config/alpha/alpha.c:8625
Environment:
System:
A missing procedure declaration in test.ads causes test.adb to generate an
ice. Compiler output is:
+===GNAT BUG DETECTED==+
| 3.4.2 20040901 (prerelease) (i686-pc-linux-gnu) Assert_Failure sinfo.adb:2479|
| Error detected at test.adb:27:16
Between 20050627 and 20050805, several C and C++ testcases begain to fail
on Solaris 10/x86 with the native as, e.g.
+FAIL: g++.old-deja/g++.brendan/crash63.C (test for excess errors)
Excess errors:
Assembler: crash63.C
"/var/tmp//ccnloMW3.s", line 22 : Illegal mnemonic
"/var/tmp
gcc generates supruious warnings about switches not handling things which it
could (or should) be easily able to deduce are impossible (e.g. assert(v!=FOO)
just before the switch that gets reported for not handling FOO.
Environment:
System: Linux duncan 2.6.11.10 #34 Thu May 26 11:47:48 BST 2005
libstdc++ registers some handlers with pthreads in conjunction
with throw statements. Those handlers are not properly removed
when libstdc++ is unloaded, causing pthread_join to jump to a
bad address.
gcc -ldl -lpthread main.c -o main
g++ -shared -lstdc++ -lc -lm plug.cc \
-o plug.so
./main
In p
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...@-
[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 cont
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
../../../../gnusrc/
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 in
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
---
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 âeâ:
test.ii:19:8: instantiated from here
test.ii:16:32: internal compiler error: Segmentation fault
The
Here is the minimal test case exhibiting my trouble:
$ cat bug.cc
#include
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 command:
__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
x
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: x
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
reporting
Gcc complains about legal code. Test case stripped down from a gdb
testsuite test case.
Environment:
System: Linux fishfood.ninemoons.com 2.6.14-1.1656_FC4 #1 Thu Jan 5 22:13:22
EST 2006 i686 i686 i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc
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
/vol
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
/vol/gcc/share/i386
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 (e
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
sec
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 d
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/
-B/vol/gcc/sh
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 /vol/gcc/share/alp
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 /vol/gcc/share/alp
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 | \
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.
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 ..
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
Ar
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__))
template
T PROGMEM * rom(const T& init)
{
static T PROGMEM t = i
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
int main() {
std::tr1::array foo = {0, 1};
return foo[1];
}
// end
[2]
array2.cpp: In function 'int main()
All libjava execution tests fail on IRIX 6 like this:
% LD_LIBRARYN32_PATH=../../../gcc:../.libs ./PR9577
3709255:./PR9577: rld: Error: unresolvable symbol in ../.libs/libgcj.so.7:
pthread_kill
3709255:./PR9577: rld: Error: unresolvable symbol in ../.libs/libgcj.so.7:
pthread_sigmask
3709255:./
Bootstrapping mainline on i386-pc-solaris2.10 with the native as fails in
stage2:
stage1/xgcc -Bstage1/ -B/vol/gcc/share/i386-pc-solaris2.10/bin/ -c -g -O2
-gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada
/vol/gnu/src/gcc/gcc-dist/gcc/ada/exp_ch3.adb -o ada/exp_ch3.o
Assemb
During a make check on Solaris 10/x86, make check in boehm-gc fails (which
unfortunately goes almost unnoticed since the failure is not included in
mail-report.log, cf. PR libgcj/11412):
/bin/ksh: 2246 Segmentation Fault
FAIL: gctest
===
1 of 1 tests failed
===
mak
The amd64 multilib of boehm-gc doesn't build on i386-pc-solaris2.10: the
compilation fails with
/vol/gnu/src/gcc/gcc-dist/boehm-gc/include/private/gcconfig.h:435: error: parse
error before '--' token
Environment:
System: SunOS cumaru 5.10 Generic_Patch i86pc i386 i86pc
Architecture: i86pc
Building the O32 libffi on IRIX 6.5 fails, thus we get a bootstrap failure
with --enable-libgcj:
/bin/ksh ./libtool --mode=link
/.vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc-java/gcc/xgcc
-B/.vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc-java/gcc/
-B/.vol/gcc/share/mips-sgi-irix6.5/bin/ -B/.vol/gcc/share/
libgcj.so doesn't link on IRIX 6:
/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/xgcc -shared-libgcc
-B/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/ -nostdinc++
-L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/mips-sgi-irix6.5/libstdc++-v3/src
-L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/mips-sgi-irix6.5/li
Even with the patch to fix PR libfortran/15234
http://gcc.gnu.org/ml/fortran/2005-06/msg00118.html
(and already mentioned there), all gfortran execution tests fail on
alpha-dec-osf4.0f like this:
% LD_LIBRARY_PATH=../../alpha-dec-osf4.0f/libgfortran/.libs:.. ./PR19754_2.exe
4552:./PR197
During a mainline bootstrap with Ada included (and the patch from PR
tree-optimization/21029 to avoid an infinite loop in stage3) on Tru64 UNIX,
there occur many warnings like this:
% stage1/xgcc -Bstage1/ -B/vol/gcc/share/alpha-dec-osf5.1b/bin/ -c -g -O2
-gnatpg -gnata -I- -I. -Iada -I/vol
NOTE: Defaulting component because reported component no longer exists
Many tmpdir-gcc.dg-struct-layout-1 tests fail on mainline on Tru64 UNIX
V5.1B:
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_com
On Tru64 UNIX V4.0F, gcc.dg-struct-layout-1_generate fails to link since
the platform lacks snprintf:
Executing on host: gcc -g -O2 -o
/vol/gcc/obj/gcc-4.1.0-20050525/4.0f-gcc/gcc/testsuite/gcc.dg-struct-layout-1_generate
/vol/gnu/src/gcc/gcc-dist/gcc/testsuite/gcc.dg/compat/struct-layout-1_ge
Bootstrapping current mainline on IRIX 6.5 with --enable-libgcj fails building
the 64-bit zlib:
/.vol/gcc/obj/gcc-4.1.0-20050607/6.5-gcc-java/./gcc/xgcc
-B/.vol/gcc/obj/gcc-4.1.0-20050607/6.5-gcc-java/./gcc/
-B/.vol/gcc/share/mips-sgi-irix6.5/bin/ -B/.vol/gcc/share/mips-sgi-irix6.5/lib/
-isys
There's a linking error when I use std::basic_string with
g++ 3.3, but it works perfectly in g++ 3.4 and 4.0 . I've tried it on both
my Debian box with g++-3.3 and another with 5.3-RELEASE-p5 and g++32. Both
of the cases cause the same error message
(http://victor.csie.org/tmp/error.txt).
Than
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: GCC should combine adjacent stdio calls
GCC should optimize adjacent stdio calls. For example:
printf("foo %d %d\n", i, j);
printf("bar %d %d\n", x, y);
coul
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21975
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: GCC should combine adjacent stdio calls
GCC should optimize adjacent stdio calls. For example:
printf("foo %d %d\n", i, j);
printf("bar %d %d\n", x, y);
coul
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: [4.0/4.1 Regression] Segmentation
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: New: __m64 return value should be returned in %mm0
Calling convetions for x86 specify that __m64 values should be returned in %mm0
MMX register [1]. Gcc returns __m64 values on stack.
The
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Segmentation fault while compiling ipw2100
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: [4.0/4.1 Regression] Segmentation
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: Preprocessing fortran files has some flaws
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09
14:02 ---
Confirmed, it works fine with t.F but not with t.F90
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: java.rmi.server.RMIClassLoader.getClassLoader() is private, should be
public
--- Additional Comments From gbenson at redhat dot com 2005-06-09 13:48
---
I need it in Fedora 5
--- Additional Comments From gcc-bugzilla at gcc dot gnu dot org
2005-06-09 16:11 ---
Subject: class friend declaration doesn't allow use in class scope
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-06-09
13:58 ---
Not a bug. The clause you referr
Between 20050414 and 20050606, there occured a new testsuite failure on the
3.4 branch on alpha-dec-osf4.0f and alpha-dec-osf5.1b:
+FAIL: g++.dg/warn/conversion-function-1.C (test for excess errors)
Excess errors:
/vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/testsuite/g++.dg/warn/conversion-function
If switching from SGI as to GNU as 2.15, a couple of new testsuite failures
occur on the 3.4 branch as of 20050607:
+FAIL: gcc.dg/range-test-1.c (test for excess errors)
FAIL: gcc.dg/range-test-1.c (test for excess errors)
Excess errors:
/var/tmp//ccj9FSrW.s:1483: Warning: .space repeat count is
Between 20050113 and 20050609, there occured a new testsuite failure on the
4.0 branch on Tru64 UNIX V4.0F:
+FAIL: g++.dg/eh/cleanup1.C (test for excess errors)
FAIL: g++.dg/eh/cleanup1.C (test for excess errors)
Excess errors:
Stack overflow: pid 11784, proc cc1plus, addr 0x11fdfffe0, pc 0x1201
gcc ICE when I did:
===
$ m6811-elf-g++ -Os -mshort -msoft-reg-count=32 -m68hc12 -c n.cpp
The ICE message is:
===
n.cpp: In function 'void getNewTableEntry()':
n.cpp:49: error: unable to find a register to spill in class 'D_REGS'
n.cpp:49: error: this is the insn:
g++ gives an ICE on the following source (no optimization required):
$ ~/gcc/build/gcc/cc1plus -quiet x.cc
x.cc: In function 'C f(const C&)':
x.cc:6: internal compiler error: in check_pointer_types_r, at gimplify.c:4198
Please submit a full bug report,
with preprocessed source if appropriate.
Se
I'm forwrading a bugrepport from "Klaus S. Madsen" <[EMAIL PROTECTED]>
reported to the debiag bugtracking system. I've verified that the problem is
still in version 3.4.3:
When using avr-gcc to compile for TinyOS (a operating-system for
embedded devices), the nesc-compiler (used to compile TinyOS
The current gcc 4 development compiler does not generate DWARF2
DW_TAG_inlined_subroutine entries for concrete instances of inlined
subroutines. The correct entries are generated by the compiler
included in Fedora Core 3, which identifies itself as "gcc version
3.4.2 20041017 (Red Hat 3.4.2-6.fc
For the supplied example, the current development gcc generates
incorrect line number information for one instruction from the inlined
subroutine. The Fedora Core 3 gcc, which identifies itself as "gcc
version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)", generates correct line
information.
Environmen
It seems that if you have a template class derived from another template
class, that the derived class can not access the super-class protected
members.
I've put a short code segment below. It compiles and works as expected using
gcc 2.95.2, 3.2.3, 3.3.2, and 3.3.5. It doesn't compile using g
The code below passes a union (type ct1) as a var arg. The callee
checks
that the union is indeed received correctly by checking each field.
This
fails in line 38:
assert (hv1.bv1 == nv1.bv1);
Environment:
System: IRIX64 mars 6.5 07080049 IP27
g++ generates bad code for the program below if -O3 is used.
If optimization is off, it works correctly.
$ g++ -o x x.cc
$ ./x
$ g++ -o x x.cc -O3
$ ./x
fail
$
Here is the generated code for main() (with exception-handling labels elided):
main:
pushl %ebp
movl%esp, %ebp
I configured gcc-3.4.3 with the above command line,
note I gave a relative path to ../gcc-3.4.3 from my .
Everything worked fine (I even submitted my test results :), until I
tried
make DESTDIR=/usr/local/TEST_NEW_gcc install
this failed with :
(Link to original mail: http://gcc.gnu.org/ml/libstdc++/2005-01/msg00059.html)
On FreeBSD 5.3, if I run the following test program (compiled w/ system gcc,
which is 3.4.2; or a hand-compiled current CVS snapshot):
#include
#include
int main(void)
{
g++ dies with a tree check ICE when the source below is compiled with -g:
$ cc1plus -g x.cc
void foo()
x.cc:6: internal compiler error: tree check: expected class 'declaration', have
'exceptional' (@@dummy) in lookup_decl_die, at dwarf2out.c:5415
Please submit a full bug report,
with preproc
A simple program causes gcc to use inordinate amounts of memory
and finally crash.
Environment:
System: Linux glauke 2.6.8-powerpc #1 Sun Oct 3 13:22:21 CEST 2004 ppc GNU/Linux
Architecture: ppc
host: powerpc-unknown-linux-gnu
build: powerpc-unknown-linux-gnu
target: powerpc-unknown-linux-gnu
c
gcc -maix64 code generated :-
lwz r3,116(r31)
bl
cc -q64 (AIX compiler) code generated :-
lwz r3,116(r1)
rldicr 3,3,32,31
bl
Environment:
System: AIX ibmbj 2 5 000972024C00
host: powerpc-i
gcc generates incorrect code for static members in some cases. Consider the
following code:
struct C {
static __thread int x;
static __thread int y;
};
__thread int C::x;
void g() {
int z = C::x;
z = C::y;
}
When this is compiled on an x86 machine with gcc -S,
NOTE: Defaulting component because reported component no longer exists
When compiling the following two lines:
typedef double R;
typedef R _Complex C;
with the flags -std=c99 -pedantic, gcc gives the bogus warning:
foo.c:2: warning: ISO C does not support complex integer types
(Code based on t
With the option -foptimize-sibling-calls tail recursion is
performed. Adding -g destroys this optimization. In my opinion,
adding compiler option -g should not change the behaviour of
the compiled program.
Environment:
System: SunOS rungner.nada.kth.se 5.9 Generic_
simple subtraction works for small values of doubles, but fails for
larger values
TEST CODE FOLLOWS:
int main (int argc, char **argv)
{
double n1, n2;
n1=74925983.0;
n2=n1-1;
if (n1==n2) printf ("BUG: the numbers are equal.\n");
else printf ("NO
g++ crashes on the (invalid) code below:
$ g++ -c x.cc
x.cc: In function 'void foo(void*)':
x.cc:4: error: invalid use of undefined type 'struct C'
x.cc:1: error: forward declaration of 'struct C'
x.cc:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preproces
When I compile a simple test program that declares an SSE constant and checks
that it is 8-byte aligned (see below), the alignment check fails in the
gcc 4.0 snapshot (it succeeds in 3.3.5).
I'm not sure whether the constant is actually misaligned or the alignment
check itself is miscompiled...ch
The code below, when compiled by "gcc -O3 -msse", gives the following
error (same code compiles fine in gcc 3.3.5):
bug2.c: In function 'main':
bug2.c:17: error: Invalid reference prefix.
&fooD.1292;
bug2.c:17: internal compiler error: verify_stmts failed.
Please submit a full bug report,
with p
ice.cpp:8: internal compiler error: in tree_low_cst, at tree.c:3315
The problem happens with gcc-3.3 also.
Environment:
System: Linux grajagop-lnx 2.6.10-1-686 #1 Tue Jan 18 04:34:19 EST 2005 i686
GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux
Certain read accesses to objects marked as "volatile" are optimized away.
This happens when both "-O2" and "-fno-strict-aliasing" are specified.
This has been observed with the Linux kernel which is unusable in certain
configurations due to this problem. This used to work with 3.4.0.
Enviro
Using the option "-mfpmath=sse" in g77 (to use SSE instructions for
floating point arithmetic) can create illegal code, or at least
code that is called with illegal arguments. Specifically, I have a
test case where a "movapd" instruction is called with a second argu
I expect the following program to produce the following output:
a 2
b 1 1
i.e, two elements go into the set, we delete one, and one remains.
However, when i compile this with the current cvs head, the program
actually does the following:
$ g++ -g -o x x.cc
$ ./x
a 2
b 0 1
$
i.e., two element
NOTE: Defaulting component because reported component no longer exists
The bootstrap process fails during stage 3 when the
stage 2 xgcc is used to compile the root file of the
Ada Standard library, the package Ada itself:
stage2/xgcc -Bstage2/ -B/usr/local2/mips-sgi-irix6.2/bin/ -c -g -O2 -gn
Bootstrapping current mainline fails when configuring libjava/libltdl on
both Tru64 UNIX V4.0F and V5.1B with the following error:
configure: configuring in libltdl
configure: running /bin/ksh '/vol/gnu/src/gcc/gcc-dist/libjava/libltdl/configure'
--prefix=/vol/gcc '--cache-file=./config.cache'
Bootstrapping current mainline on Solaris 10/SPARC fails with an ICE in
stage2 (both with GCC 3.3.2 und 3.4.3 as bootstrap compiler):
stage1/xgcc -Bstage1/ -B/vol/gcc/share/sparc-sun-solaris2.10/bin/ -c -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedant
Due to the bootstrap problem described in PR bootstrap/18224, I tried to
bootstrap mainline with Sun cc instead (using Sun Studio 8 cc aka cc 5.5),
configuring with CC='/opt/SUNWspro-8.0/bin/cc -xc99=%none -xildoff'.
The bootstrap failed in stage1, though:
/opt/SUNWspro-8.0/bin/cc -xc99=%none -x
I am not positive about this bug report, but I cannot see what G++
wants from me, and in addition all the other compilers I have access
to accept the following code (including 3.4).
template < template class Traits_ >
struct Factory
{
};
template < templ
101 - 200 of 224 matches
Mail list logo
