[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-06 06:14 --- Yes this is just a stack overflow, I don't know if there is anything that cane be done here since this is one of the reasons why -ftemplate-depth was added. I don't know what the standard says about how this limit has to be. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|When using excessive - |When using excessive - |ftemplate-depth g++ |ftemplate-depth g++ |segfaults |overflows the stack http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug target/27051] Compiler generates .sdata when -mno-sdata specified
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 06:17 --- embedded ia64, that is a new one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27051
[Bug c++/27053] New: symbol2.c:2102: internal error: Segmentation fault when i try to compile gSOAP in cross compilation
hi I've got a problem when I try to make a cross compilation of the gSOAP toolkit from a i686-pc-cygwin to i586-hadhat-linux. I downloaded the gSOAP toolkit from here:http://sourceforge.net/project/showfiles.php?group_id=52781package_id=68161release_id=394790 it's the version : gSOAP 2.7.6e for the error, it told me : Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. So, it's what i am doing, cause i don't find how to correct the error. So i give you : -the exact version of GCC : GNU CPP version 3.2.1 20020930 (MontaVista) (cpplib) (i386 Linux/ELF) GNU C version 3.2.1 20020930 (MontaVista) (i586-hardhat-linux) -the options given when GCC was configured/built: Configured with: /opt/src/gcc-3.2/configure -v --host=i686-pc-cygwin --build=i686-pc-cygwin --target=i586-hardhat-linux --prefix=/opt/hardhat/devkit/x86/586_mv30 --exec-prefix=/opt/hardhat/devkit/x86/586_mv30 --bindir=/opt/hardhat/devkit/x86/586_mv30/bin --sbindir=/opt/hardhat/devkit/x86/586_mv30/sbin --sysconfdir=/opt/hardhat/devkit/x86/586_mv30/etc --datadir=/opt/hardhat/devkit/x86/586_mv30/share --includedir=/opt/hardhat/devkit/x86/586_mv30/include --libdir=/opt/hardhat/devkit/x86/586_mv30/lib --libexecdir=/opt/hardhat/devkit/x86/586_mv30/libexec --localstatedir=/opt/hardhat/devkit/x86/586_mv30/var --sharedstatedir=/opt/hardhat/devkit/x86/586_mv30/share --mandir=/opt/hardhat/devkit/x86/586_mv30/man --infodir=/opt/hardhat/devkit/x86/586_mv30/info --program-transform-name=s,^,586-, --enable-cross --enable-shared --enable-languages=c,c++ --enable-threads --with-gxx-include-dir=/opt/hardhat/devkit/x86/586_mv30/i586-hardhat-linux/include/g++-3 --with-fp --with-cpu=i386 --with-local-prefix=/opt/hardhat/devkit/x86/586_mv30/i586-hardhat-linux -the compiler output (error messages, warnings, etc.): make[4]: Entering directory `/cygdrive/c/Stage/workspacegSOAP/gSOAP/soapcpp2/src' if i586-hardhat-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../..-DWITH_BISON -DWITH_FLEX -DLINUX -v -save-temps -g -O2 -MT soapcpp2-symbol2.o -MD -MP -MF .deps/soapcpp2-symbol2.Tpo -c -o soapcpp2-symbol2.o `test -f 'symbol2.c' || echo './'`symbol2.c; \ then mv -f .deps/soapcpp2-symbol2.Tpo .deps/soapcpp2-symbol2.Po; else rm -f .deps/soapcpp2-symbol2.Tpo; exit 1; fi Reading specs from /usr/bin/../lib/gcc-lib/i586-hardhat-linux/3.2.1/specs Configured with: /opt/src/gcc-3.2/configure -v --host=i686-pc-cygwin --build=i686-pc-cygwin --target=i586-hardhat-linux --prefix=/opt/hardhat/devkit/x86/586_mv30 --exec-prefix=/opt/hardhat/devkit/x86/586_mv30 --bindir=/opt/hardhat/devkit/x86/586_mv30/bin --sbindir=/opt/hardhat/devkit/x86/586_mv30/sbin --sysconfdir=/opt/hardhat/devkit/x86/586_mv30/etc --datadir=/opt/hardhat/devkit/x86/586_mv30/share --includedir=/opt/hardhat/devkit/x86/586_mv30/include --libdir=/opt/hardhat/devkit/x86/586_mv30/lib --libexecdir=/opt/hardhat/devkit/x86/586_mv30/libexec --localstatedir=/opt/hardhat/devkit/x86/586_mv30/var --sharedstatedir=/opt/hardhat/devkit/x86/586_mv30/share --mandir=/opt/hardhat/devkit/x86/586_mv30/man --infodir=/opt/hardhat/devkit/x86/586_mv30/info --program-transform-name=s,^,586-, --enable-cross --enable-shared --enable-languages=c,c++ --enable-threads --with-gxx-include-dir=/opt/hardhat/devkit/x86/586_mv30/i586-hardhat-linux/include/g++-3 --with-fp --with-cpu=i386 --with-local-prefix=/opt/hardhat/devkit/x86/586_mv30/i586-hardhat-linux Thread model: posix gcc version 3.2.1 20020930 (MontaVista) /usr/bin/../lib/gcc-lib/i586-hardhat-linux/3.2.1/cpp0.exe -lang-c -v -I. -I. -I../.. -iprefix /usr/bin/../lib/gcc-lib/i586-hardhat-linux/3.2.1/ -MD soapcpp2-symbol2.d -MF .deps/soapcpp2-symbol2.Tpo -MP -MT soapcpp2-symbol2.o -MQ soapcpp2-symbol2.o -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ -DHAVE_CONFIG_H -DWITH_BISON -DWITH_FLEX -DLINUX symbol2.c symbol2.i GNU CPP version 3.2.1 20020930 (MontaVista) (cpplib) (i386 Linux/ELF) ignoring nonexistent directory /usr/target/usr/include ignoring duplicate directory . #include ... search starts here: #include ... search starts here: . ../.. /usr/lib/gcc-lib/i586-hardhat-linux/3.2.1/include /usr/i586-hardhat-linux/include End of search list. /usr/bin/../lib/gcc-lib/i586-hardhat-linux/3.2.1/cc1.exe -fpreprocessed symbol2.i -quiet -dumpbase symbol2.c -mcpu=i386 -g -O2 -version -o symbol2.s GNU CPP version 3.2.1 20020930 (MontaVista) (cpplib) (i386 Linux/ELF) GNU C version 3.2.1 20020930 (MontaVista) (i586-hardhat-linux) compiled by GNU C version 3.2 20020927 (prerelease). symbol2.c: In function `gen_wsdl': symbol2.c:2102: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See
[Bug target/27054] New: C constant expressions vs. IBM extended format long double
static const double coeff[] = { +854513.0l /138 };
compiles as C almost everywhere, except ppc* with -mlong-double-128
-mabi=ibmlongdouble.
const_binop refuses to compute this:
/* Don't constant fold this floating point operation if the
result may dependent upon the run-time rounding mode and
flag_rounding_math is set, or if GCC's software emulation
is unable to accurately represent the result. */
if ((flag_rounding_math
|| (REAL_MODE_FORMAT_COMPOSITE_P (mode)
!flag_unsafe_math_optimizations))
(inexact || !real_identical (result, value)))
return NULL_TREE;
Now, is the above valid ISO C99? I couldn't find anything that would say this
is not a valid constant expression, certainly it fits into double's range.
Perhaps we should differentiate here if we are evaluating an initializer or
not.
--
Summary: C constant expressions vs. IBM extended format long
double
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27054
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #3 from bonzini at gnu dot org 2006-04-06 10:56 --- For 4.1 I'd surely go with Ulrich's patch. And for 4.2 I think that it starts being too expensive to have two vsplat and two adds. vspltisw 0,15 vspltisw 1,1 vadduwm 0,0,0 vadduwm 0,0,1 Ulrich, can you prepare a patch or should I do so? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug c++/23372] [4.0/4.1/4.2 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #36 from guillaume dot melquiond at ens-lyon dot fr 2006-04-06 10:59 --- The generated code is getting both better and worse. I just tested with GCC 4.1, and there is now a byte-by-byte (!) copy instead of memcpy. So not only does GCC use superfluous copies, but it generates code such that these copies are the slowest possible. On the other hand, there is only one copy left. So this is better than GCC 4.0, but still worse than GCC 3.4. pushl %ebp movl%esp, %ebp pushl %ebx subl$8004, %esp leal-4004(%ebp), %ebx movl%ebx, (%esp) callf xorl%edx, %edx subl$4, %esp .L3: cmpl$4000, %edx jb .L2 callg movl-4(%ebp), %ebx leave ret .p2align 4,,7 .L2: movzbl (%ebx,%edx), %eax movb%al, (%esp,%edx) incl%edx jmp .L3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug c/27055] New: Structures are copied byte by byte into function arguments
I tried the following testcase with various GCC versions available as Debian
packages. With 3.3.5, the copy from *a to the stack frame of g is done
word-by-word with rep movsl. With 3.4.4, it is done by memcpy. Both previous
methods are fine. With 3.4.6, the copy is done byte-by-byte without string
opcodes. With 4.0.3 and 4.1.0, it is done byte-by-byte and out-of-line: there
are two jumps for each copied byte! So argument copy got broken for x86 during
GCC 3.4 cycle and it did not get any better with GCC 4.
typedef struct A { int a[1000]; } A;
void g(A);
void f(A *a) { g(*a); }
Assembly output with GCC4 and -O3 optimization:
pushl %ebp
xorl%edx, %edx
movl%esp, %ebp
subl$4008, %esp
movl8(%ebp), %ecx
.L3:
cmpl$4000, %edx
jb .L2
callg
leave
ret
.p2align 4,,7
.L2:
movzbl (%ecx,%edx), %eax
movb%al, (%esp,%edx)
incl%edx
.p2align 4,,3
jmp .L3
$ LANG=C gcc-3.4 -v
Reading specs from /usr/lib/gcc/i486-linux-gnu/3.4.6/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal
--prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --with-tune=i686 i486-linux-gnu
Thread model: posix
gcc version 3.4.6 (Debian 3.4.6-1)
$ LANG=C gcc-4.1 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.0 (Debian 4.1.0-1)
--
Summary: Structures are copied byte by byte into function
arguments
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27055
[Bug tree-optimization/27056] New: ICE in loop_depth_of_name
On the attached testcase with today's gcc-4_1-branch -m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing minor changes in different routines makes the problem go away. What I see in the dumps is: 1) at *t26.ssa, in draw_digit, there are two SSA_NAMEs with version 2: ... D.52296_2 = dD.52286_1 * 2; # VUSE digit_texture_coordsD.52285_3; x1D.52291_4 = digit_texture_coordsD.52285[D.52296_2]; D.52296_5 = dD.52286_1 * 2; D.52297_6 = D.52296_5 + 1; # VUSE digit_texture_coordsD.52285_3; y1D.52292_7 = digit_texture_coordsD.52285[D.52297_6]; x2D.52293_8 = x1D.52291_4 + 2.5e-1; y2D.52294_9 = y1D.52292_7 + 2.5e-1; # VUSE cfgD.24335_2; ... 2) when DCE is run, it first sees cfgD.24335_2 and sets bit 2 in processed bitmap in mark_operand_necessary, later on thus removes the D.52296_2 = dD.52286_1 * 2; statement as dead, eventhough it is not dead, yet keeps the other 2 uses of D.52296_2 around 3) in copyprop, we look at D.52296_2 which is on the free list in the mean time and crash because it's SSA_NAME_DEF_STMT is NULL in bb_for_stmt called from loop_depth_of_name. Is already 1) a bug? BTW, in *t26.ssa I see cfgD.24335_2 being used in 2 different functions, load_background_image and draw_digit, in both cases only in VUSE. Maybe some tree sharing issue? -- Summary: ICE in loop_depth_of_name Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
[Bug tree-optimization/27056] ICE in loop_depth_of_name
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-06 11:51 --- Created an attachment (id=11216) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11216action=view) 188125.ii.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
[Bug c/27055] Structures are copied byte by byte into function arguments
--- Comment #1 from gdr at integrable-solutions dot net 2006-04-06 12:03 --- Subject: Re: New: Structures are copied byte by byte into function arguments guillaume dot melquiond at ens-lyon dot fr [EMAIL PROTECTED] writes: [...] | With 3.4.6, the copy is done byte-by-byte without string | opcodes. With 4.0.3 and 4.1.0, it is done byte-by-byte and | out-of-line: there are two jumps for each copied byte! So argument | copy got broken for x86 during GCC 3.4 cycle and it did not get any | better with GCC 4. That is insane, if I may. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27055
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #4 from gcc at magfr dot user dot lysator dot liu dot se 2006-04-06 12:08 --- The standard says the limit have to be more than 17, the g++ default is 500 in order, I assume, to be nice to users. The reason I reported the bug was that the compiler terminated with an internal error instead of a controlled error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-03-27 08:29:11 |2006-04-06 12:23:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #5 from gdr at integrable-solutions dot net 2006-04-06 12:23 --- Subject: Re: When using excessive -ftemplate-depth g++ overflows the stack gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes: | The standard says the limit have to be more than 17, No, the standard did not say that. the standard just said there is an implementation defined limit. An implementation may define that limit to be infinite. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug debug/27057] New: [4.0/4.1/4.2 Regression] ICE with -feliminate-dwarf2-dups and using namespace
// { dg-do compile }
// { dg-options -g -feliminate-dwarf2-dups }
namespace N
{
}
struct A
{
void foo ();
};
void A::foo ()
{
using namespace N;
}
ICEs with gcc-4_{0,1}-branch and HEAD in build_abbrev_table, as
DW_TAG_namespace
die that is being referenced doesn't have die_symbol.
--
Summary: [4.0/4.1/4.2 Regression] ICE with -feliminate-dwarf2-
dups and using namespace
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27057
[Bug c/27055] Structures are copied byte by byte into function arguments
--- Comment #2 from pluto at agmk dot net 2006-04-06 12:49 ---
for -march=i{345}86 I get:
f:
pushl %ebp
movl%esp, %ebp
subl$4008, %esp
movl%esp, %eax
pushl %edx
pushl $4000
pushl 8(%ebp)
pushl %eax
callmemcpy
addl$16, %esp
callg
addl$4000, %esp
leave
ret
for -march=i686,pentium2,... I get:
f:
pushl %ebp
xorl%edx, %edx
movl%esp, %ebp
subl$4008, %esp
movl8(%ebp), %ecx
.L3:
cmpl$4000, %edx
jb .L2
callg
leave
ret
.p2align 4,,7
.L2:
movzbl (%ecx,%edx), %eax
movb%al, (%esp,%edx)
incl%edx
.p2align 4,,3
jmp .L3
$ gcc version 4.1.1 20060405 (prerelease) (PLD-Linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27055
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #6 from gcc at magfr dot user dot lysator dot liu dot se 2006-04-06 12:52 --- (In reply to comment #5) gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes: | The standard says the limit have to be more than 17, No, the standard did not say that. the standard just said there is an implementation defined limit. An implementation may define that limit to be infinite. I am sorry for beeing imprecise. The standard says that it is implementation defined and goes on to recommend that it should be at least 17. ( As an aside that suggests that you could have a strictly conforming implementation where the max limit is 0, but that discussion is more fitting on comp.std.c++) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug c/27055] Structures are copied byte by byte into function arguments
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-04-06
13:05 ---
for -march=i{345}86 I get
for -march=i686,pentium2,... I get
Thanks to your tests, I noticed that the change of behavior between GCC 3.4
versions was actually caused by the addition of --with-tune=686 in Debian
packages. In fact, even older versions of GCC 3.4 are doing byte-by-byte copies
once you change the -march target to at least i686. GCC 3.3 is fine though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27055
Re: [Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes: | ( As an aside that suggests that you could have a strictly conforming | implementation where the max limit is 0, but that discussion is more fitting on | comp.std.c++) That is technically correct; but it is beside the point. -- Gaby
[Bug c++/27052] When using excessive -ftemplate-depth g++ overflows the stack
--- Comment #7 from gdr at integrable-solutions dot net 2006-04-06 13:09 --- Subject: Re: When using excessive -ftemplate-depth g++ overflows the stack gcc at magfr dot user dot lysator dot liu dot se [EMAIL PROTECTED] writes: | ( As an aside that suggests that you could have a strictly conforming | implementation where the max limit is 0, but that discussion is more fitting on | comp.std.c++) That is technically correct; but it is beside the point. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27052
[Bug debug/27057] [4.0/4.1/4.2 Regression] ICE with -feliminate-dwarf2-dups and using namespace
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00224.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-06 13:14:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27057
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #30 from jakub at gcc dot gnu dot org 2006-04-06 13:30 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug debug/27058] New: ICE in dwarf2out_finish
int
foo (void)
{
if (0)
{
static union
{
long i;
char c[8];
} u;
u.i = 0x01020304;
return u.c[0] == 0x01 u.c[1] == 0x02;
}
return 0;
}
ICEs at -g -O0 in dwarf2out_finish, because the UNION_TYPE has TYPE_CONTEXT
set, but not to some FUNCTION_DECL, but to BLOCK (that has been optimized out).
--
Summary: ICE in dwarf2out_finish
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27058
[Bug target/27059] New: %T output specifier doesn't work right for floating point registers
%T originally allowed to move between registers and memory, using an anadorned operand for the piece that comes first in memory, and using %T for the second part. This does not work with the SH4 floating point registers for little endian code. The #ifdef __LITTLE_ENDIAN__ sequences in lib1funcs.asm:udivsi3_i4 are work around this defect, but these kinds of ifdefs do not scale well. The SHMEDIA truncdisi2 pattern really should use %R - it couldn't originally because of a bug in %R, but that's fixed now. -- Summary: %T output specifier doesn't work right for floating point registers Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27059
[Bug tree-optimization/27056] ICE in loop_depth_of_name
--- Comment #2 from bonzini at gnu dot org 2006-04-06 13:53 --- The ICE was probably exposed by my changes for PR26830, but if I understand right it was causing a wrong code before that? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
[Bug tree-optimization/27056] ICE in loop_depth_of_name
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-06 13:59 --- I get the same ICE also with gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) which is much older than your PR26830 fix. So those 2 seem to be unrelated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
[Bug target/27059] %T output specifier doesn't work right for floating point registers
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-04-06 14:00 --- I intend to introduce a new modifier for the first part of a 64 bit value - I suppose %t is best suited for that - and change %T for little endian to be equivalent to %S. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |amylaar at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-06 14:00:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27059
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-04-06 14:03 --- (In reply to comment #3) Ulrich, can you prepare a patch or should I do so? It would be great if you could do that, I don't yet have a proper setup for ppc testing ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug target/27060] New: divide libcall size has increased
The new sped-optimized division library functions are larger than the functions that were originally used; unsigned and signed division are implemented in a modulte which has an object text size of 1060 bytes. This could cause problems with specialized embedded applications that are supposed to run in a very small memory area. -- Summary: divide libcall size has increased Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh4-*-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27060
[Bug target/27060] divide libcall size has increased
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-04-06 14:14 --- This can be fixed by providing an additional library, which provides udivsi3_i4i and sdivsi3_i4i implementations that are comparable in speed and size to what we had before, and which is linked in in preference to libgcc when linking with -Os, like the libic_invalidate_array*.a libraries provide taylored cache invalidataion arrays. I intend to provide implementations optimized for the sh4-100 / sh4-200 pipelines; libraries optimized for other pipelines could be added later. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27059 AssignedTo|unassigned at gcc dot gnu |amylaar at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-06 14:14:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27060
[Bug target/27006] [4.1/4.2 Regression] Invalid altivec constant loading code
--- Comment #5 from bonzini at gnu dot org 2006-04-06 14:47 --- Created an attachment (id=11217) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11217action=view) patch to fix the bug Patch untested but quite trivial. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27006
[Bug c++/27061] New: instantiation of template functions for locally defined classes
When the folliwng program is compiled:
template typename T void f(T x) {}
int main()
{
class A{} a;
f(a);
}
g++ syas:
test.cc: In function 'int main()':
test.cc:5: error: no matching function for call to 'f(main()::A)'
but if you move the class definition outside the main function, the error
disappears.
--
Summary: instantiation of template functions for locally defined
classes
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mmirzaza at cs dot uwaterloo dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27061
[Bug target/27059] %T output specifier doesn't work right for floating point registers
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-04-06 15:26 --- This does not actually affect lib1funcs.asm, since we don't have access to gcc's output modifiers there anyway. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|27060 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27059
[Bug target/27059] %T output specifier doesn't work right for floating point registers
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-06 15:33 --- Created an attachment (id=11218) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11218action=view) untested patch If this is not blocking the fix for some more serious bug, maybe we should wait with this till 4.2 has branched. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27059
[Bug tree-optimization/27056] ICE in loop_depth_of_name
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-06 16:13 --- *** This bug has been marked as a duplicate of 26757 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
[Bug c++/26757] [4.1 regression] ICE (Segmentation fault) building 3ddesktop source
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-04-06 16:13 --- *** Bug 27056 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug target/27054] C constant expressions vs. IBM extended format long double
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:13 --- This is a dup of bug 26374. *** This bug has been marked as a duplicate of 26374 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27054
[Bug middle-end/26374] Compile failure on long double
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-06 16:13 --- *** Bug 27054 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
Re: [Bug tree-optimization/27056] New: ICE in loop_depth_of_name
On Thu, 2006-04-06 at 11:49 +, jakub at gcc dot gnu dot org wrote: On the attached testcase with today's gcc-4_1-branch -m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing minor changes in different routines makes the problem go away. What I see in the dumps is: 1) at *t26.ssa, in draw_digit, there are two SSA_NAMEs with version 2: This is already wrong :)
[Bug tree-optimization/27056] ICE in loop_depth_of_name
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-04-06 16:15 --- Subject: Re: New: ICE in loop_depth_of_name On Thu, 2006-04-06 at 11:49 +, jakub at gcc dot gnu dot org wrote: On the attached testcase with today's gcc-4_1-branch -m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing minor changes in different routines makes the problem go away. What I see in the dumps is: 1) at *t26.ssa, in draw_digit, there are two SSA_NAMEs with version 2: This is already wrong :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
[Bug debug/27058] ICE in dwarf2out_finish
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:21 --- *** This bug has been marked as a duplicate of 26881 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27058
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-06 16:21 --- *** Bug 27058 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug c++/27061] instantiation of template functions for locally defined classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:24 --- The code is invalid as you cannot use a template with a local class as it has local linkage. I don't know if the error message could be improved or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27061
[Bug bootstrap/27063] New: Fail to build gcc-core-4.2 snapshots
If you download only the gcc-core-4.2 snapshot, for example ftp://ftp.uvsq.fr/pub/gcc/snapshots/4.2-20060401/gcc-core-4.2-20060401.tar.bz2 and do a ../configure --enable-languages=c make make will stop complaining about some objC file that is not in the package: make[2]: *** No rule to make target `../../gcc/objc/objc-act.c', needed by `s-gtype'. Stop. -- Summary: Fail to build gcc-core-4.2 snapshots Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebastian dot pop at cri dot ensmp dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
[Bug c++/27053] symbol2.c:2102: internal error: Segmentation fault when i try to compile gSOAP in cross compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:45 --- 3.2.1 is over 3 years old. Can you try a newer compiler like 4.0.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
[Bug other/27063] Fail to build gcc-core-4.2 snapshots
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 16:46 --- This is just a packing issue. There was a thread on gcc@ about this issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
[Bug fortran/27064] New: Fortran compiler options aren't documented
Most of options in gcc/fortran/lang.opt, like -fmax-stack-var-size=N, aren't documented in the gcc manual. -- Summary: Fortran compiler options aren't documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27064
[Bug fortran/27064] Fortran compiler options aren't documented
--- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 17:53 --- All of these options are documented in the gfortran manual. Is there really a needed for duplicating these options in the gcc manual? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27064
[Bug fortran/27064] Fortran compiler options aren't documented
--- Comment #2 from hjl at lucon dot org 2006-04-06 18:24 --- I think the gcc manual should at least have a line like, -fmax-stack-var-size=N, see gfortran manual since gcc can be used to compile Fortran code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27064
[Bug c/27065] New: error: array type has incomplete element type
a code below:
struct foo {
void (*pf)(struct foo (*ptr)[2]); /* error */
};
causes to report the following error:
ts.c:4: error: array type has incomplete element type
Isn't the compiler too restrictive ?
Even a typedef is rejected by compiler:
struct foo;
typedef struct foo (*foo_tab_ptr)[2];
typedef void (*pfun)(struct foo[2]);
or a function declaration:
void f(struct foo[]);
--
Summary: error: array type has incomplete element type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rdabrowa at poczta dot onet dot pl
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27065
[Bug fortran/27064] Fortran compiler options aren't documented
--- Comment #3 from kargl at gcc dot gnu dot org 2006-04-06 18:32 --- None of g77 specific options that I checked are documented in pre 4.0 gcc. As far as front-ends are concerned, the gcc manual documents the C family of languages options. I don't see any ada, java, or other front-ends represented. Is it too hard to read the gfortran manual? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27064
[Bug c/27065] error: array type has incomplete element type
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-06 18:42 --- This is invalid code, yes it might had been accepted before 4.1.0 but it was still invalid code. The array to pointer decay happens after the type is completed for functions so the element of the array type has to be complete still. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27065
[Bug fortran/27064] Fortran compiler options aren't documented
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-06 18:43 --- This is the way it has been for years now. If you don't like it, propose a patch to combine all four manuals (GCC, Ada, Fortran, and Java) into one big one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27064
[Bug c/27065] error: array type has incomplete element type
--- Comment #2 from rdabrowa at poczta dot onet dot pl 2006-04-06 19:09
---
(In reply to comment #1)
This is invalid code, yes it might had been accepted before 4.1.0 but it was
still invalid code. The array to pointer decay happens after the type is
completed for functions so the element of the array type has to be complete
still.
What happens ?
Consider the following code:
struct foo {
void (*pf)();
};
Later I can write:
void f(struct foo (*ptr)[2]);
struct foo x;
x.pf = f;
This compiles fine, but now I can assign any function to pf. Why I can't
specify required function prototype ? I can't understand this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27065
[Bug libgcj/27066] New: libgcj native socket code does not support IPv6
Java Sockets do not know on creation if they will be used for IPv6 or IPv4, so the gnu::java::net::PlainSocketImpl::create method should use PF_INET6 instead of AF_INET. The other methods - bind and connect - must then translate IPv4 addresses to IPv4-in-IPv6. Behavior with HAVE_INET6 not defined should probably not be changed. The code is in libjava/gnu/java/net/natPlainSocketImplPosix.cc . -- Summary: libgcj native socket code does not support IPv6 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cjw at daneel dot dyndns dot org GCC host triplet: powerpc-mandriva-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
[Bug libgcj/27066] libgcj native socket code does not support IPv6
--- Comment #1 from cjw at daneel dot dyndns dot org 2006-04-06 19:43 --- Created an attachment (id=11219) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11219action=view) Example patch to fix IPv6 support -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
[Bug libgcj/27066] libgcj native socket code does not support IPv6
--- Comment #2 from mckinlay at redhat dot com 2006-04-06 20:08 --- I'm not sure I follow this. create() does not get called until the socket is bound. Don't we know at that point whether we're binding to an IPV4 or IPV6 address? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
[Bug gcov/profile/20815] -fprofile-use barfs with coverage mismatch for function '...' while reading counter 'arcs'.
--- Comment #12 from hubicka at gcc dot gnu dot org 2006-04-06 20:33 --- Subject: Bug 20815 Author: hubicka Date: Thu Apr 6 20:33:21 2006 New Revision: 112738 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112738 Log: PR profile/20815 PR profile/26399 * coverage.c (coverage_checksum_string): Reorganize loop to not read after buffer. * g++.dg/bprob/g++-bprob-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/bprob/g++-bprob-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/coverage.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
[Bug gcov/profile/26399] -fprofile-use fails with unnamed namespaces
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-04-06 20:33 --- Subject: Bug 26399 Author: hubicka Date: Thu Apr 6 20:33:21 2006 New Revision: 112738 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112738 Log: PR profile/20815 PR profile/26399 * coverage.c (coverage_checksum_string): Reorganize loop to not read after buffer. * g++.dg/bprob/g++-bprob-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/bprob/g++-bprob-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/coverage.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-06 20:58 --- I am working on this again :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19719
[Bug c++/26757] [4.1 regression] ICE (Segmentation fault) building 3ddesktop source
--- Comment #10 from amacleod at redhat dot com 2006-04-06 21:05 ---
using the program from comment #5, I get IL for load_background_image that
looks like:
void load_background_image() ()
{
int D.1767;
int D.1766;
struct Config * cfg.2;
int D.1764;
int D.1763;
struct Config * cfg.1;
bb 0:
cfg.1 = cfg;
D.1763 = cfg.1-bg_size;
D.1764 = D.1763 + 1;
cfg.1-bg_size = D.1764;
cfg.2 = cfg;
D.1766 = cfg.2-autoacquire;
D.1767 = D.1766 + 1;
cfg.2-autoacquire = D.1767;
return;
}
THe two assignments of cfg into temps, (cfg.1 and cfg.2) are using DIFFERENT
cfg variables (ie, different addresses) on the RHS with the same UID. very
bad. either they should be the same var_decl (which I presume is what is
intended), or they should have different UIDs.
This patchlet provides an assert the triggers when it happens:
Index: tree-dfa.c
===
*** tree-dfa.c (revision 112248)
--- tree-dfa.c (working copy)
*** referenced_var_insert (unsigned int uid,
*** 610,615
--- 610,619
h-uid = uid;
h-to = to;
loc = htab_find_slot_with_hash (referenced_vars, h, uid, INSERT);
+ /* This assert can only trigger is a variable with the same UID has been
+ inserted already, but has a different pointer value. ie, we have 2
+ different variables with the same UID. Bug 26757. */
+ gcc_assert ((*(struct int_tree_map **)loc) == NULL);
*(struct int_tree_map **) loc = h;
}
what happens is that the referenced_var list hashes based on the UID of a
variable. referenced_var_insert is only called when a new variable is
discovered, so it presumes that the hash slot is already empty.
add_referenced_var calls referenced_var_insert when it sees a new variable, and
it determines a variable is new by hashing on the address of the variable in
the walk_state-vars_found table.
since there are 2 different 'cfg' vars, referenced_var_insert overwrote the
first 'cfg''s address when it looked up the UID.
WHen we go out of ssa, delete_tree_ssa removes all the var annotations of
referenced vars. The original 'cfg' no longer occurs in the referenced var
list, so it is not cleared.
Along comes the next function, and it is using the original 'cfg', and voila,
it still has a var_annotation, complete with current_def and lots of fun things
set.
I havent tracked down where the cfg variable is created, but Im willing to bet
a C++ front end person knows right off the bat by looking at the function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/27067] New: Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
When the sample code snippet (below) is compiled, errors (below) occur. This
issue breaks the compilation of wxWidgets' Media Library. The same problem
occurs with the latest snapshot (20060331, used in the example below) of GCC
4.1.1, on both CygWin and MinGW.
The sample code (virt-test.ii):
# 1 virt-test.cpp
# 1 built-in
# 1 command line
# 1 virt-test.cpp
struct top
{
virtual ~top() {}
virtual int __attribute__((__stdcall__)) fun1() = 0;
virtual char __attribute__((__stdcall__)) fun2() = 0;
virtual double __attribute__((__stdcall__)) fun3() = 0;
};
struct mid1 : public top
{
virtual int __attribute__((__stdcall__)) fun1() = 0;
virtual char __attribute__((__stdcall__)) fun2() = 0;
virtual double __attribute__((__stdcall__)) fun3() = 0;
virtual long __attribute__((__stdcall__)) fun4() = 0;
};
struct mid2 : public top
{
virtual int __attribute__((__stdcall__)) fun1() = 0;
virtual char __attribute__((__stdcall__)) fun2() = 0;
virtual double __attribute__((__stdcall__)) fun3() = 0;
virtual long __attribute__((__stdcall__)) fun5() = 0;
};
struct mid3 : public top
{
virtual int __attribute__((__stdcall__)) fun1() = 0;
virtual char __attribute__((__stdcall__)) fun2() = 0;
virtual double __attribute__((__stdcall__)) fun3() = 0;
virtual long __attribute__((__stdcall__)) fun6() = 0;
};
struct bottom : public mid1, public mid2, public mid3
{
int __attribute__((__stdcall__)) fun1();
char __attribute__((__stdcall__)) fun2();
double __attribute__((__stdcall__)) fun3();
long __attribute__((__stdcall__)) fun4()
{ return 345L; }
long __attribute__((__stdcall__)) fun5()
{ return 456L; }
long __attribute__((__stdcall__)) fun6()
{ return 567L; }
};
int __attribute__((__stdcall__)) bottom::fun1()
{ return 123; }
char __attribute__((__stdcall__)) bottom::fun2()
{ return 'a'; }
double __attribute__((__stdcall__)) bottom::fun3()
{ return 123.45; }
int main()
{
bottom b;
b.fun1();
b.fun2();
b.fun3();
b.fun4();
b.fun5();
b.fun6();
}
The command line to compile:
mingw32-g++ -v -save-temps -Wall -Wextra -pedantic -o virt-test.exe virt-test
.cpp
And compiler output:
Using built-in specs.
Target: mingw32
Configured with:
/usr/local/src/gcc/build-cross/source/gcc-4.1-20060331//configure -v
--prefix=/usr/local/cross-mingw-4.1 --target=mingw32
--with-headers=/usr/local/cross-mingw-4.1/mingw32/include --with-gcc
--with-gnu-ld --with-gnu-as --enable-threads=win32 --disable-nls
--enable-languages=c,c++ --disable-win32-registry --disable-shared
--enable-sjlj-exceptions --enable-libstdcxx-allocator=pool --without-newlib
Thread model: win32
gcc version 4.1.1 20060331 (prerelease)
/usr/local/cross-mingw-4.1/libexec/gcc/mingw32/4.1.1/cc1plus.exe -E -quiet -v
virt-test.cpp -Wall -Wextra -pedantic -fpch-preprocess -o virt-test.ii
ignoring nonexistent directory
/usr/local/cross-mingw-4.1/lib/gcc/mingw32/4.1.1/../../../../mingw32/sys-include
#include ... search starts here:
#include ... search starts here:
/usr/local/cross-mingw-4.1/lib/gcc/mingw32/4.1.1/../../../../include/c++/4.1.1
/usr/local/cross-mingw-4.1/lib/gcc/mingw32/4.1.1/../../../../include/c++/4.1.1/mingw32
/usr/local/cross-mingw-4.1/lib/gcc/mingw32/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/cross-mingw-4.1/lib/gcc/mingw32/4.1.1/include
/usr/local/cross-mingw-4.1/lib/gcc/mingw32/4.1.1/../../../../mingw32/include
End of search list.
/usr/local/cross-mingw-4.1/libexec/gcc/mingw32/4.1.1/cc1plus.exe
-fpreprocessed virt-test.ii -quiet -dumpbase virt-test.cpp -auxbase virt-test
-Wall -Wextra -pedantic -version -o virt-test.s
GNU C++ version 4.1.1 20060331 (prerelease) (mingw32)
compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ce3135ac5ab9fb49e72d849828fbe7dc
virt-test.cpp:66: error: 'char *LTHUNK2()' aliased to undefined symbol
'_ZN6bottom4fun2Ev'
virt-test.cpp:66: error: 'char *LTHUNK3()' aliased to undefined symbol
'_ZN6bottom4fun2Ev'
virt-test.cpp:66: error: 'double *LTHUNK4()' aliased to undefined symbol
'_ZN6bottom4fun3Ev'
virt-test.cpp:66: error: 'double *LTHUNK5()' aliased to undefined symbol
'_ZN6bottom4fun3Ev'
--
Summary: Compile errors with multiple inheritance where the
stdcall attribute is applied to virtual functions.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wszafran at users dot sourceforge dot net
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug libgcj/27066] libgcj native socket code does not support IPv6
--- Comment #3 from cjw at daneel dot dyndns dot org 2006-04-06 22:38 --- AFAICT create() is called in Socket's getImpl() method, which in turn is called from e.g. setTcpNoDelay() and calling that after a plain new Socket() means no bind was done yet... Anyway, the address is not passed to create() so this information is currently not available even when create() is called from bind(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
[Bug ada/27068] New: complilation abandoned on NML Ada test server
gcc -c -I/home/shackle/rcslib/src/ada -g nml_test_server_ada.adb +===GNAT BUG DETECTED==+ | 4.1.0 20060304 (Red Hat 4.1.0-3) (x86_64-redhat-linux-gnu) Storage_Error stack overflow (or erroneous memory access)| | Error detected at a-tags.adb:448:7 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. nml_test_server_ada.adb /home/shackle/rcslib/src/ada/nml.ads /home/shackle/rcslib/src/ada/cms.ads /home/shackle/rcslib/src/ada/nml_msg.ads nml_test_format_n_ada.ads /home/shackle/rcslib/src/ada/posemath_n_ada.ads otherheader_n_ada.ads compilation abandoned gnatmake: nml_test_server_ada.adb compilation error gnatmake nml_test_dl_read_ada -L/home/shackle/rcslib/lib -I/home/shackle/rcslib/src/ada -L/home/shackle/rcslib -L/home/shackle/rcslib/lib -cargs -g -largs -g gcc -c -I/home/shackle/rcslib/src/ada -g nml_test_dl_read_ada.adb +===GNAT BUG DETECTED==+ | 4.1.0 20060304 (Red Hat 4.1.0-3) (x86_64-redhat-linux-gnu) Storage_Error stack overflow (or erroneous memory access)| | Error detected at a-tags.adb:448:7 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. nml_test_dl_read_ada.adb /home/shackle/rcslib/src/ada/nml.ads /home/shackle/rcslib/src/ada/cms.ads /home/shackle/rcslib/src/ada/nml_msg.ads nml_test_format_n_ada.ads /home/shackle/rcslib/src/ada/posemath_n_ada.ads otherheader_n_ada.ads compilation abandoned gnatmake: nml_test_dl_read_ada.adb compilation error [EMAIL PROTECTED] test]$ uname -a Linux localhost.localdomain 2.6.16-1.2080_FC5 #1 SMP Tue Mar 28 03:38:47 EST 2006 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED] test]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) [EMAIL PROTECTED] test]$ Contact me at [EMAIL PROTECTED] if you want me to send you the source files it was compiling when this occurred. The files were compiling, it is not clear what changed but I now see this error every time. -- Will -- Summary: complilation abandoned on NML Ada test server Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wshackle at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27068
[Bug fortran/27069] New: -ffast-math crash
gfortran crashes when I use -ffast-math in this subroutine:
C ==
SUBROUTINE GRADEN(RHOE,V,GRAD,VTMP)
C ==--==
C == SMOOTHING OF THE DENSITY AND CALCULATION OF |nabla.RHO|==
C == ON INPUT : RHOE : DENSITY IN REAL SPACE==
C == V: UNDEFINED==
C == GRAD : UNDEFINED==
C == VTMP : UNDEFINED==
C == ON OUTPUT: RHOE : DENSITY IN REAL SPACE (SMOOTH) ==
C == V: UNDEFINED==
C == GRAD : (GRADIENT OF RHO)^2 IN REAL SPACE==
C == VTMP : DENSITY IN G SPACE (SMOOTH) ==
C ==--==
IMPLICIT NONE
INCLUDE 'system.h'
INCLUDE 'cnst.inc'
INCLUDE 'fft.inc'
INCLUDE 'cppt.inc'
C Arguments
COMPLEX*16 V(MAXFFT),VTMP(NHG)
REAL*8 RHOE(NNR1),GRAD(NNR1,4)
C Variables
REAL*8 GMAX,GCS,SMFAC,EG
INTEGERISUB,IR,IG
C ==--==
C == TRANSFORM DENSITY TO G SPACE==
C ==--==
CALL TISET('GRADEN',ISUB)
C$OMP parallel do private(IR)
DO IR=1,NNR1
V(IR) = DCMPLX(RHOE(IR),0.0D0)
ENDDO
CALL FWFFT(V)
C ==--==
C == SMOOTHING ==
C ==--==
IF(TSMOOTH) THEN
GMAX=HG(NHG)
GCS=SMF*GMAX
C$OMP parallel do private(IG,EG,SMFAC)
DO IG=1,NHG
EG=(HG(IG)-GCS)/(SDELTA*GMAX)
SMFAC=1.0D0/(1.0D0+EXP(EG))
VTMP(IG)=V(NZH(IG))*SMFAC
ENDDO
ELSE
CALL ZGTHR(NHG,V,VTMP,NZH)
ENDIF
C ==--==
C == FFT OF RHO AND NABLA(X)*RHOE==
C ==--==
CALL ZAZZERO(V,MAXFFT)
C$OMP parallel do private(IG)
DO IG=1,NHG
V(NZH(IG))=VTMP(IG)-TPIBA*GK(1,IG)*VTMP(IG)
V(INDZ(IG))=DCONJG(VTMP(IG)+TPIBA*GK(1,IG)*VTMP(IG))
ENDDO
CALL INVFFT(V)
C$OMP parallel do private(IR)
DO IR=1,NNR1
RHOE(IR)=DREAL(V(IR))
GRAD(IR,1)=DIMAG(V(IR))*DIMAG(V(IR))
GRAD(IR,2)=DIMAG(V(IR))
ENDDO
C ==--==
C == FFT OF NABLA(Y)*RHO AND NABLA(Z)*RHOE ==
C ==--==
CALL ZAZZERO(V,MAXFFT)
C$OMP parallel do private(IG)
DO IG=1,NHG
V(NZH(IG))=TPIBA*(UIMAG*GK(2,IG)-GK(3,IG))*VTMP(IG)
V(INDZ(IG))=TPIBA*(-UIMAG*GK(2,IG)+GK(3,IG))*DCONJG(VTMP(IG))
ENDDO
CALL INVFFT(V)
C$OMP parallel do private(IR)
DO IR=1,NNR1
GRAD(IR,1)=GRAD(IR,1)+DREAL(V(IR)*DCONJG(V(IR)))
GRAD(IR,3)=DREAL(V(IR))
GRAD(IR,4)=DIMAG(V(IR))
ENDDO
CALL TIHALT('GRADEN',ISUB)
C ==--==
RETURN
END
C ==
--
Summary: -ffast-math crash
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nuno dot bandeira at ist dot utl dot pt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug fortran/27069] -ffast-math crash
--- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 --- Don't use --fast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug fortran/27069] -ffast-math crash
--- Comment #2 from nuno dot bandeira at ist dot utl dot pt 2006-04-06 23:56 --- Subject: Re: -ffast-math crash kargl at gcc dot gnu dot org wrote: --- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 --- Don't use --fast-math. Is there a valid reason for it or is the implementation of the -ffast-math still uncertain ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
Re: [Bug fortran/27069] -ffast-math crash
nuno dot bandeira at ist dot utl dot pt wrote: --- Comment #2 from nuno dot bandeira at ist dot utl dot pt 2006-04-06 23:56 --- Subject: Re: -ffast-math crash kargl at gcc dot gnu dot org wrote: --- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 --- Don't use --fast-math. Is there a valid reason for it or is the implementation of the -ffast-math still uncertain ? -ffast-math is uncertain, not related to gfortran.
[Bug fortran/27069] -ffast-math crash
--- Comment #3 from jvdelisle at verizon dot net 2006-04-07 00:06 --- Subject: Re: -ffast-math crash nuno dot bandeira at ist dot utl dot pt wrote: --- Comment #2 from nuno dot bandeira at ist dot utl dot pt 2006-04-06 23:56 --- Subject: Re: -ffast-math crash kargl at gcc dot gnu dot org wrote: --- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 --- Don't use --fast-math. Is there a valid reason for it or is the implementation of the -ffast-math still uncertain ? -ffast-math is uncertain, not related to gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug fortran/27069] -ffast-math crash
--- Comment #4 from kargl at gcc dot gnu dot org 2006-04-07 00:07 --- (In reply to comment #2) kargl at gcc dot gnu dot org wrote: Don't use --fast-math. Is there a valid reason for it or is the implementation of the -ffast-math still uncertain ? Does your code work correctly if you omit -ffast-math? Have you audited your code to ensure all floating points operations meet the expectations of -ffast-math? I note that your computing an FFT and doing some complex arithmetic with numbers from the fft. I won't use -ffast-math in this situation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug fortran/27069] -ffast-math crash
--- Comment #5 from nuno dot bandeira at ist dot utl dot pt 2006-04-07 00:10 --- Subject: Re: -ffast-math crash jvdelisle at verizon dot net wrote: -ffast-math is uncertain, not related to gfortran. I notice speedups of up to 50% for my binary at the cost of some numerical error though... in every way this card works miracles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug fortran/27069] -ffast-math crash
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-07 00:18 --- What do you mean by crash? Aka What is the error you get? Also this source is no where near compilable by itself because of the includes. Also what is the exact version of GCC you are using? (use gcc -v to get that). -ffast-math can do unwantted stuff with complex if you don't understand what it does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug middle-end/27069] -ffast-math crash
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-07 00:20 --- What are the full options you are passing to gcc anyways since I see you have some openmp markers here too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug middle-end/27069] -ffast-math crash
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug middle-end/27069] -ffast-math crash
--- Comment #8 from nuno dot bandeira at ist dot utl dot pt 2006-04-07 00:32 --- Subject: Re: -ffast-math crash This is what I get from the compiler: $ gfortran -I../SOURCE -c -fdefault-real-8 -O3 -fforce-addr -march=pentium4 -fcray-pointer -ffast-math ./graden.f -o ./graden.o ./graden.f: In function 'graden': ./graden.f:2: internal compiler error: in find_lattice_value, at tree-complex.c:133 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Attached are also the include files for the compilation. Thank you all for such a quick reply ! The code is not mine by the way hence my ignorance... C == C == DYNAMIC ALLOCATION OF PERMANENT ARRAYS == C == C == TSHELS = FALSE if all TSHEL(IS) false== C ==--== LOGICAL TSHELS,TSHEL(MAXSP) COMMON/CPPSW/ TSHELS,TSHEL C == C == INYH(3,NHG) coordinates +NHI (I=1,2,3) for G-vectors == C == IGL(NHG)the index of the shell for each G-vector == C == NZH(NHG)index in PSI or RHO array (IG1=0) == C == INDZ(NHG) index in PSI or RHO array (IG1=0) == C == ISPTR(NHGL+1) last index IG for the shell== C == INDZS(NGW) index for G-compon. of wavefunction in PSI (I10)== C == NZH(NGW)index for G-compon. of wavefunction in PSI (I10)== C ==--== INTEGER INYH(3,NHG),IGL(NHG),NZH(NHG),INDZ(NHG), ISPTR(*),INDZS(NGW),NZHS(NGW) POINTER (IP_INYH,INYH), (IP_IGL,IGL), (IP_NZH,NZH), (IP_INDZ,INDZ), (IP_ISPTR,ISPTR), (IP_INDZS,INDZS), (IP_NZHS,NZHS) COMMON/CPPTI/ IP_INYH,IP_IGL,IP_NZH,IP_INDZ,IP_ISPTR,IP_INDZS, IP_NZHS C == C == HG(1:NHG) Square norm of G-vectors == C == GK(1:3,1:NHG) Components of G-vectors== C == GL(1:NHGL) Square norm of G-vectors for each shell == C == VPS(1:NSP,1:NHG) Local pseudopotential per species in G space== C == RHOPS: smeared ionic charge density in G space == C ==ionic point charges replaced by Gaussian charge == C ==distributions (see ener.inc) calculated in PUTPS == C == TWNL(1:NGW,1:NGH(IS),1:NSP) Non-Local projectors array == C ==for each G-components (Kleinman-Bylander form)== C == USED BY VANDERBILT PSEUDOPOTENTIALS == C == QRAD == C == YLMB(NHGK,LPMAX,NKPNT) Initialized in PUTWNL == C ==--== REAL*8HG(NHG),GK(3,NHG),GL(*), VPS(NSX,NHG),RHOPS(NSX,NHG), TWNL,QRAD,TWNLS,YLMB POINTER (IP_HG,HG), (IP_GK,GK), (IP_GL,GL), (IP_VPS,VPS), (IP_RHOPS,RHOPS), (IP_TWNL,TWNL), (IP_QRAD,QRAD), (IP_TWNLS,TWNLS), (IP_YLMB,YLMB) COMMON/CPPTR/ IP_HG,IP_GK,IP_GL,IP_VPS,IP_RHOPS, IP_TWNL,IP_TWNLS,IP_QRAD,IP_YLMB C == C == Dimension of HGPOT (for isolated system -- HIP) == C ==--== INTEGER NR1H,NR2H,NR3H,NR3PL COMMON/ISOSI/ NR1H,NR2H,NR3H,NR3PL C == REAL*8HGPOT(NR1S+1,NR2S+1,NR3PL),HIPZ(NHG) COMPLEX*16SCG(NHG),SCGX(NHG) POINTER (IP_HGPOT,HGPOT),(IP_HIPZ,HIPZ) POINTER (IP_SCG,SCG),(IP_SCGX,SCGX) COMMON/ISOSP/ IP_HGPOT,IP_HIPZ,IP_SCG,IP_SCGX C == C == C == INCLUDE FILE OF NUMERIC CONSTANTS (SEE SETCNST.F) == C ==--== C == UIMAG = DCMPLX(0.D0,1.D0)== C == PI PI NUMBER== C == FPI 4*PI == C == RY RYDBERG IN ELECTRON-VOLT
[Bug middle-end/27069] -ffast-math crash
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-07 00:34 --- Still need the version number? gfortran -v will give it to you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug middle-end/27069] -ffast-math crash
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-07 00:37 --- I bet this is a dup of bug 26717 which was fixed a week or so ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug middle-end/27069] -ffast-math crash
--- Comment #11 from nuno dot bandeira at ist dot utl dot pt 2006-04-07 00:38 --- Subject: Re: -ffast-math crash kargl at gcc dot gnu dot org wrote: Does your code work correctly if you omit -ffast-math? Yes it does albeit slower. The code also compiles well if I omit the -ffast-math in the buggy routines (only 3 of them in 581) and use them in all the rest. I note that your computing an FFT and doing some complex arithmetic with numbers from the fft. I won't use -ffast-math in this situation. Ok, point taken. A speedup is always welcome though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug middle-end/27069] -ffast-math crash
--- Comment #12 from nuno dot bandeira at ist dot utl dot pt 2006-04-07 00:42 --- Subject: Re: -ffast-math crash pinskia at gcc dot gnu dot org wrote: --- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-07 00:34 --- Still need the version number? gfortran -v will give it to you. The very latest (1st of April, 4.0.2). I submitted the version in my bug application may be it didn't get through. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug middle-end/27069] -ffast-math crash
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-07 00:53 --- Still not enough to compile it, we need you to attach (not copy and paste) the following files: system.h cnst.inc fft.inc cppt.inc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27069
[Bug c++/10591] PCH breaks anonymous namespaces
--- Comment #23 from geoffk at gcc dot gnu dot org 2006-04-07 00:55 ---
(In reply to comment #22)
The PCH problem with get_file_function_name is independent of the question of
giving anonymous namespace members internal linkage. We still need to give
them distinct names; we are giving up on address comparison of type_infos
because of problems with plugins.
If you're giving up address comparison on type_info, you still have to find a
way where two typeinfo objects with the same C++ name can be different, due to
this example:
A shared object contains
class A { };
class B __attribute__((visibility(hidden))) : class A { };
void f () { throw new B(); }
A main program contains:
class A { };
extern void f();
class B __attribute__((visibility(hidden))) { int x; }; // not an A
int main() {
try {
f();
} catch (B * p) {
abort();
} catch (A * p) {
exit (0);
}
abort();
}
This program should not abort, because the 'B' in the main program is not the
same as the 'B' in the dylib.
My suggestion would be to include __dso_handle in the typeinfo for objects
with hidden visibility, and also compare that.
Now, if you're doing this for visibility, you can also do it for anonymous
namespaces. Just find any address in the translation unit that contains the
anonymous namespace (hey, how about the address of the typeinfo itself?), and
consistently include that address in the typeinfo, and compare that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591
[Bug c++/27070] New: Different partial template specialization result with different optimization options?
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu3)
Different partial template specialization result with different optimization
options?
1. right result without optimization
$g++ -O0 -g3 -c test.cpp
$g++ -O0 -g3 -c a.cpp
$g++ -O0 -g3 -o test test.o a.o
$./test
DEFAULT
PARTIAL
2. wrong result with optimization
$g++ -O2 -g0 -c test.cpp
$g++ -O2 -g0 -c a.cpp
$g++ -O2 -g0 -o test test.o a.o
$./test
DEFAULT
DEFAULT
Bug???
3.if write three part in one file ,we get the right result
$g++ -O2 -g0 -o test2 test2
$./test2
DEFAULT
PARTIAL
$g++ -O0 -g3 -o test2 test2
$./test2
DEFAULT
PARTIAL
//
//a.h
//
#ifndef A_H
#define A_H
#include
using namespace std;
template
class A
{
public:
void echo() {cout ĬÈÏ endl;}
}
;
#endif
//
//a.cpp
//
#include a.h
template
void
A0::echo()
{
cout ÌØ»¯ endl;
}
//
//test.cpp
//
#include a.h
int main( int argc, char *argv[] )
{
A1 DEFAULT;
A0 PARTICULAR;
DEFAULT.echo();
PARTICULAR.echo();
return EXIT_SUCCESS;
}
//
//test2.cpp
//
#include
using namespace std;
template
class A
{
public:
void echo() {cout ĬÈÏ endl;}
}
;
template
void
A0::echo()
{
cout ÌØ»¯ endl;
}
int main( int argc, char *argv[] )
{
A1 DEFAULT;
A0 PARTICULAR;
DEFAULT.echo();
PARTICULAR.echo();
return EXIT_SUCCESS;
}
--
Summary: Different partial template specialization result with
different optimization options?
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meter dot ten at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27070
[Bug c++/27070] Different partial template specialization result with different optimization options?
--- Comment #1 from meter dot ten at gmail dot com 2006-04-07 02:37 --- this is not a bug. -- meter dot ten at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27070
[Bug rtl-optimization/27044] Loop variables incorrectly initialized with optimization on
--- Comment #4 from ned at bike-nomad dot com 2006-04-07 02:50 --- Tried 4.0.3 (compiled from source via Darwinports); works OK there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
[Bug rtl-optimization/27044] Loop variables incorrectly initialized with optimization on
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-07 03:17 --- Closing as fixed pre the reporter. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27044
[Bug c++/27053] symbol2.c:2102: internal error: Segmentation fault when i try to compile gSOAP in cross compilation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
[Bug ada/27068] complilation abandoned on NML Ada test server
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-07 03:19 --- Please attach the files. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27068
[Bug fortran/26766] [F2003] Recursive I/O still (again) broken
--- Comment #4 from patchapp at dberlin dot org 2006-04-07 04:00 --- Subject: Bug number PR26766 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00249.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26766
[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-07 05:23 --- The patch which exposed this issue was reverted so this is no longer a regression though it is still a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 Regression] C++ front- |C++ front-end (and others |end (and others parts of|parts of GCC) use the wrong |GCC) use the wrong check to |check to see if hidden |see if hidden visibility is |visibility is there |there | Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989
[Bug c++/27000] Problems with latest visibility changes
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-07 05:26 --- The patch which exposed the regression was reverted but this is still a bug as shown by comment #6. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||21581 nThis|| Severity|critical|normal Summary|[4.2 Regression] Problems |Problems with latest |with latest visibility |visibility changes |changes | Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27000
[Bug c++/26984] link error with (typeid(int)) in anonymous namespace
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-07 05:26 --- This is no longer a regression but it still is a bug as shown by comment #2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||21581 nThis|| Severity|critical|normal Summary|[4.2 Regression] link error |link error with |with (typeid(int)) in |(typeid(int)) in anonymous |anonymous namespace |namespace Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26984
[Bug target/25203] [4.0] enable checking failure in g++.dg/opt/mmx2.C
--- Comment #3 from roger at eyesopen dot com 2006-04-07 05:30 --- This appears to be a problem with instruction attributes in the x86 backend, and looks to be still present (but latent?) on mainline. The problem is that i386.c's memory define_attr tries to determine whether an insn is a load for insns of type mmxadd if either operands[1] or operands[2] is a memory operand. See the (match_operand 2 ...) line, shortly after line 460 of i386.md. This interacts badly with the definitions of the *movsi_1 and *movdi_1_rex64 define_insns where certain alternatives claim that they are of insn type mmxadd, even though they have only two operands. This leads the generated get_attr_memory to inspect the uninitialized operands[2] for these insns. The problem can be corrected by changing the insn type attribute for the problematic variants of *movsi_1 and *movdi_1_rex64. Which type they should be (and how that interacts with scheduling etc...) is beyond me. Perhaps a new mmxclr or mmxunary type, or resuse the existing mmxcvt type, to denote unary MMX operations. Alternatively, the memory attribute could be made more complex to recognize these two exceptions. Or a third alternative, is to specify the memory attribute of these two insns explicitly. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-07 05:30:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25203
