[Bug target/14454] [3.3 Regression] virtual function with vararg won't compile
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 06:44 --- Notice that the original bugreport is against 3.3.2 though, which means that the user really hit this problem on the 3.3 branch. And moving to 3.4 is non- trivial for much C++ code due to the new parser. OK, this is convincing. I'm going to install it on the 3.3 branch too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug target/14454] [3.3 Regression] virtual function with vararg won't compile
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-14 06:55 --- Subject: Bug 14454 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2004-10-14 06:54:52 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.c sparc.md gcc/doc: tm.texi gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/inherit: thunk1.C Log message: PR target/14454 * config/sparc/sparc.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Set to sparc_can_output_mi_thunk. (sparc_output_mi_thunk): Simplify handling of delta offset. Add handling of vcall offset. (sparc_can_output_mi_thunk): New predicate. * doc/tm.texi (TARGET_ASM_OUTPUT_MI_THUNK): Document VCALL_OFFSET. (TARGET_ASM_OUTPUT_MI_VCALL_THUNK): Delete. (TARGET_ASM_CAN_OUTPUT_MI_THUNK): New target hook. * config/sparc/sparc.md (movdi): Remove redundant test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1022r2=1.16114.2.1023 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.233.4.12r2=1.233.4.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.md.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.181.4.13r2=1.181.4.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/tm.texi.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.182.2.8r2=1.182.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.384r2=1.2261.2.385 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/thunk1.C.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.5r2=1.5.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug target/14454] [3.3 Regression] virtual function with vararg won't compile
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 07:03 --- Fixed on all active branches. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14454
[Bug other/17991] New: [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
This patch appears to have broken two-process fixincludes: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02301.html. When attempting to link applyfix.exe, link fails because pz_mn_name_pat is undefined. The two-process mode is only used for MS-DOS and BeOS, which is probably why noone noticed. I noticed because it appears that, other than this and some other soon-to-be-fixed problems, two process fixincludes also works for Windows. The problem is that mn_name_pat was made into an environment variable, which are only defined in fixincl.c, which is only included in the fixincl executable. However, it is used in fixlib.c, which is included in the applyfix executable in a two-process build. As I'm not really familiar with fixincludes, I can't say how this should be fixed. It can be worked around by copying the environment variable definitions and initializations from fixincl.c to the SEPARATE_FIX_PROC section of fixfixes.c, but I'm not sure this is appropriate as applyfix doesn't need any of these environment variables otherwise. Perhaps just this single environment variable could be defined. -- Summary: [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i?86-*-mingw32, i?86-*-msdosdjgpp, *-*-beos* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug other/17900] [4.0 Regression] GCC's source path in ICE is wrong
--- Additional Comments From bje at gcc dot gnu dot org 2004-10-14 07:04 --- It's a simple bug. Patch sent to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17900
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
-- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug fortran/17992] New: reading empty line does not return 0
This program should return 2 zeros if the file psfres.dat consist of 2 empty lines. This is true in case of g77, but gcc version 4.0.0 20041013 reports an end of file error. integer n,m open(unit=8,file='psfres.dat',status='unknown') read(8,'(/2i2)')n,m write(*,*)n,m end psfres.dat ( is just 2 empty lines ) If non empty then it works OK, but this is not fortran standard. I havent check the f95 standard :-( The program is taken from a much larger program (CHARMM), this is why there is / in the format. Another strange behavior is if I put numbers in the firat line (which should be ignored), then there is no eof error in gfortran. g77 behaves OK also in this case. -- Summary: reading empty line does not return 0 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
-- What|Removed |Added OtherBugsDependingO||17832 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug other/17900] [4.0 Regression] GCC's source path in ICE is wrong
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-14 07:15 --- Subject: Bug 17900 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-14 07:15:41 Modified files: gcc: ChangeLog diagnostic.c Log message: PR other/17900 * diagnostic.c (trim_filename): Fix logic bug in walking backwards up the filename looking for a previous directory separator. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.5873r2=2.5874 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/diagnostic.c.diff?cvsroot=gccr1=1.143r2=1.144 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17900
[Bug target/15267] libgcc_s.so.1 fails to link on Solaris 8/SPARC with GNU as 2.14.91
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15267
[Bug target/3195] STL warning on Solaris with GCC 3.0
-- What|Removed |Added AssignedTo|nobody at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|SUSPENDED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3195
[Bug target/17943] building gcc head (20041011) for arc-elf32 results in a lot of warnings
--- Additional Comments From saurabh dot verma at codito dot com 2004-10-14 07:53 --- Agreed. Used dummy define_predicates to check. The warnings are due to the lack of them only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17943
[Bug debug/17993] New: Error in dwarf2 debug output of bitfield members
avr-gcc-v:
Reading specs from c:/programs/WinAVR/bin/../lib/gcc/avr/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=e:/avrdev/install
--build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++
Thread model: single
gcc version 3.4.1
command line:
avr-gcc -gdwarf-2 bitfieldbug.c -o bf.elf
The debug output as shown by avr-readelf -w bf.elf shows that the first bitfield
member has a DW_AT_data_member_location of ff ff ff ff ff, which is obviously
wrong.
This behaviour seems to persist no matter how I define the bitfield.
---source---
typedef struct
{
int j:5;
int k:6;
int m:5;
int n:8;
} faultybitfield_t;
int main(int arcg, char **argv)
{
faultybitfield_t bf;
bf.j = 3;
return 0;
}
---end source---
--
Summary: Error in dwarf2 debug output of bitfield members
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsandnes at atmel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: 386
GCC target triplet: AVR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-14 08:16:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug debug/17994] New: avr-gcc does not output a dwarf2 .debug_frame section
avr-gcc-v: Reading specs from c:/programs/WinAVR/bin/../lib/gcc/avr/3.4.1/specs Configured with: ../gcc-3.4.1/configure --prefix=e:/avrdev/install --build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++ Thread model: single gcc version 3.4.1 command line: avr-gcc -gdwarf-2 anycode.c -o anyobject.elf No matter how I tweak the command line parameters to avr-gcc I am unable to make it output dwarf2 callstack information (.debug_frame). I have confirmed that this is a missing feature for the AVR port. -- Summary: avr-gcc does not output a dwarf2 .debug_frame section Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsandnes at atmel dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: 386 GCC target triplet: AVR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug debug/17993] Error in dwarf2 debug output of bitfield members
--- Additional Comments From tsandnes at atmel dot com 2004-10-14 08:24 --- This has been discussed on the gcc mailinglist: http://gcc.gnu.org/ml/gcc/2004-05/msg00186.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug libstdc++/17995] New: gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
gcc-3.4.2 ../gcc-3.4.2/configure --with-gnu-as --enable-languages=c,c++,objc make bootstrap How to post my attachement? = make[7]: Entering directory `/usr/hjs/gcc-3.4.2-obj/i386-pc- sco3.2v5.0.5/pic/libstdc++-v3/libsupc++' /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /usr/hjs/gcc- 3.4.2-obj/gcc/xgcc -shared-libgcc -B/usr/hjs/gcc-3.4.2-obj/gcc/ -nostdinc++ - L/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/src - L/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/src/.libs - B/usr/local/i386-pc-sco3.2v5.0.5/bin/ -B/usr/local/i386-pc-sco3.2v5.0.5/lib/ - isystem /usr/local/i386-pc-sco3.2v5.0.5/include -isystem /usr/local/i386-pc- sco3.2v5.0.5/sys-include -fPIC -I/usr/hjs/gcc-3.4.2/libstdc++-v3/../gcc - I/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/include/i386-pc- sco3.2v5.0.5 -I/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++- v3/include -I/usr/hjs/gcc-3.4.2/libstdc++-v3/libsupc++ -O2 -g -O2 -g -O2 - fPIC -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual - fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c -o eh_alloc.lo ../../../../../gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc /usr/hjs/gcc-3.4.2-obj/gcc/xgcc -shared-libgcc -B/usr/hjs/gcc-3.4.2-obj/gcc/ - nostdinc++ -L/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/src - L/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/src/.libs - B/usr/local/i386-pc-sco3.2v5.0.5/bin/ -B/usr/local/i386-pc-sco3.2v5.0.5/lib/ - isystem /usr/local/i386-pc-sco3.2v5.0.5/include -isystem /usr/local/i386-pc- sco3.2v5.0.5/sys-include -fPIC -I/usr/hjs/gcc-3.4.2/libstdc++-v3/../gcc - I/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/include/i386-pc- sco3.2v5.0.5 -I/usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++- v3/include -I/usr/hjs/gcc-3.4.2/libstdc++-v3/libsupc++ -O2 -g -O2 -g -O2 - fPIC -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual - fdiagnostics-show-location=once -ffunction-sections -fdata-sections - c ../../../../../gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o In file included from ../../../../../gcc-3.4.2/libstdc++- v3/libsupc++/eh_alloc.cc:34: /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/include/cstring: In function `void* std::memchr(void*, int, size_t)': /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++- v3/include/cstring:101: error: `void* std::memchr(void*, int, size_t)' conflicts with previous using declaration `void* memchr(void*, int, size_t)' /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/include/cstring: In function `char* std::strchr(char*, int)': /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++- v3/include/cstring:107: error: `char* std::strchr(char*, int)' conflicts with previous using declaration `char* strchr(char*, int)' /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/include/cstring: In function `char* std::strpbrk(char*, const char*)': /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++- v3/include/cstring:113: error: `char* std::strpbrk(char*, const char*)' conflicts with previous using declaration `char* strpbrk(char*, const char*)' /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/include/cstring: In function `char* std::strrchr(char*, int)': /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++- v3/include/cstring:119: error: `char* std::strrchr(char*, int)' conflicts with previous using declaration `char* strrchr(char*, int)' /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++-v3/include/cstring: In function `char* std::strstr(char*, const char*)': /usr/hjs/gcc-3.4.2-obj/i386-pc-sco3.2v5.0.5/pic/libstdc++- v3/include/cstring:125: error: `char* std::strstr(char*, const char*)' conflicts with previous using declaration `char* strstr(char*, const char*)' make[7]: *** [eh_alloc.lo] Error 1 make[7]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/i386-pc- sco3.2v5.0.5/pic/libstdc++-v3/libsupc++' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/i386-pc- sco3.2v5.0.5/pic/libstdc++-v3' make[5]: *** [all] Error 2 make[5]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/i386-pc- sco3.2v5.0.5/pic/libstdc++-v3' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/i386-pc- sco3.2v5.0.5/libstdc++-v3' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/i386-pc- sco3.2v5.0.5/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/i386-pc- sco3.2v5.0.5/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/usr/hjs/gcc-3.4.2-obj' make: *** [bootstrap] Error 2 -- Summary: gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34 Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: critical Priority: P2
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-14 08:58 --- Needs a configury maintainer. Bruce Korb said he's fine with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Additional Comments From realsong at hotmail dot com 2004-10-14 09:15 --- Created an attachment (id=7347) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7347action=view) original name is math.h gcc-3.4.2 ../gcc-3.4.2/configure --with-gnu-as --enable-languages=c,c++,objc make bootstrap === stage1/xgcc -Bstage1/ -B/usr/local/i386-pc-sco3.2v5.0.5/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -I. -I../../gcc-3.4.2/gcc -I../../gcc-3.4.2/gcc/. -I../../gcc-3.4.2/gcc/../include ../../gcc-3.4.2/gcc/genautomata.c -o genautomata.o In file included from ../../gcc-3.4.2/gcc/genautomata.c:112: include/math.h:10:1: unterminated #ifndef make[2]: *** [genautomata.o] Error 1 make[2]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/usr/hjs/gcc-3.4.2-obj/gcc' make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-14 09:17 --- I think fixincludes is very close to building on Windows, and so probably should not be disabled after all for this target, since its needed in some configurations. Presumably the other targets still should be disabled. All that is needed to make it build is resolution to PR 17991, a patch to enable two-process fixincludes for i?86-*-mingw32*, and a patch that does the equivilent of http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01393.html. I will probably resubmit a version of the latter tomorrow that addresses the comments here http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01045.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Additional Comments From realsong at hotmail dot com 2004-10-14 09:18 --- Created an attachment (id=7348) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7348action=view) original name is math.h compare with http://gcc.gnu.org/bugzilla/attachment.cgi?id=7347action=view -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Additional Comments From realsong at hotmail dot com 2004-10-14 09:21 --- Created an attachment (id=7349) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7349action=view) nohup output command output. the command was nohup make bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug tree-optimization/17522] ICE with -tree-vectorize
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-14 10:04 --- Seems to be fixed since I cannot reproduce the problem any more. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17522
[Bug fortran/17987] multidimensional array problem
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-10-14 10:08 --- if the example is compiled with: [EMAIL PROTECTED] ~]$ g77 x.f -fno-automatic [EMAIL PROTECTED] ~]$ ./a.out ==1st time= first time is=: 1 1 1 0.200031 2 1 1. 2 1 1 0.400062 2 1 2. 1 1 2 0.200031 2 2 1. 2 1 2 0.400062 2 2 2. ZZZ are=: 1 0.20003 1. 0.20003 1. 2 0.40006 2. 0.40006 2. ===2nd time ZZZ are=: 1 0.20003 1. 0.20003 1. 2 0.40006 2. 0.40006 2. This is a common difference between g77 and some other fortran compilers. HTH, bud davis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17987
[Bug c++/17996] New: [3.4/4.0 regression] Destructor run twice
The following testcase is miscompiled on the 3.4 branch and mainline:
=
extern int printf(const char *restrict, ...) throw ();
struct A
{
A() { printf(Ctor\n); }
~A() { printf(Dtor\n); }
};
A a;
extern A a;
int main()
{
return 0;
}
=
The output is:
Ctor
Dtor
Dtor
i.e. the destructor of A is run twice.
If I exchange line 9 and 10, the bug goes away.
Btw, the bug was reported at Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260747
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265961
The bug affects gcc 3.4.0 and later.
It was introduced somewhere in Mid August 2003.
Mark, your patch
http://gcc.gnu.org/ml/gcc-cvs/2003-08/msg00621.html
might have caused the regression. Could you please have a look?
--
Summary: [3.4/4.0 regression] Destructor run twice
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17996
[Bug c++/17996] [3.4/4.0 regression] Destructor run twice
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-14 11:25 --- Mark, I just checked, the regression indeed appears with your patch http://gcc.gnu.org/ml/gcc-cvs/2003-08/msg00621.html -- What|Removed |Added Severity|normal |critical Known to fail||3.4.0 3.4.3 4.0.0 Known to work||3.3.5 Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17996
[Bug c++/17997] New: C++ ostringstream const char * interpreted as void *(?)
The test program below produces the following output below.
I tested this with Visual C++ and it does outputs abcdef for both cases.
=
$ g++ -v
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-
prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --
mandir=/usr/share/man --infodir=/usr/share/info --enable-
languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls --without-included-
gettext --enable-libgcj --with-system-zlib --enable-interpreter --enable-
threads=posix --enable-java-gc=boehm --enable-sjlj-exceptions --disable-version-
specific-runtime-libs --disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
$ g++ test.cc
[EMAIL PROTECTED] ~
$ ./a.exe
0x434004def
abcdef
=
#include sstream
#include iostream
#include sstream
#include fstream
#include iostream
#include string
using namespace std;
void executeBuffer(const ostream cmd)
{
string t=static_castconst ostringstream (cmd).str();
printf(%s\n, t.c_str());
}
int main(char **argv, int argc)
{
executeBuffer(ostringstream() abc def\n);
ostringstream t;
tabc def\n ;
executeBuffer(t);
return 0;
}
--
Summary: C++ ostringstream const char * interpreted as void *(?)
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oyvind dot harboe at zylin dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17997
[Bug bootstrap/14316] collect2 doesnt build on windows hosts
--- Additional Comments From dannysmith at users dot sourceforge dot net 2004-10-14 11:28 --- Refreshed patch (with missing files) here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01172.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14316
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-14 11:46 --- http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01173.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug middle-end/17973] [4.0 Regression] tree dumps are cluttered and mixed with RTL dumps
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-14 11:48 --- First hunk of the attached patch was applied; the second is not related and the behavior it disables was intended. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17973
[Bug c/10735] ICE on correct type conversion with vector
--- Additional Comments From bonzini at gcc dot gnu dot org 2004-10-14 11:51 --- http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02540.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10735
[Bug middle-end/17746] [4.0 Regression] ICE when building the shared Ada RTS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 11:55 --- Recategorizing. -- What|Removed |Added Component|ada |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17746
[Bug ada/17794] [4.0 Regression] Bootstrap error building ada runtime
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 11:56 --- *** This bug has been marked as a duplicate of 17746 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17794
[Bug middle-end/17746] [4.0 Regression] ICE when building the shared Ada RTS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 11:56 --- *** Bug 17794 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17746
[Bug other/17900] [4.0 Regression] GCC's source path in ICE is wrong
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 12:21 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17900
[Bug c++/17996] [3.4/4.0 regression] Destructor run twice
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 12:28 --- *** This bug has been marked as a duplicate of 17976 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17996
[Bug c++/17976] [3.4/4.0 Regression] Calls the dtor twice
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 12:28 --- *** Bug 17996 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17976
[Bug c++/17976] [3.4/4.0 Regression] Calls the dtor twice
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 12:28 --- From the dup: Mark, I just checked, the regression indeed appears with your patch http://gcc.gnu.org/ml/gcc-cvs/2003-08/msg00621.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17976
[Bug c++/17998] New: Pointer reference optimized into register is not used when referenced through type cast.
void test(int *p) {
p+= 1; // modifies p in register
(char*)p+= 8; // modifies p in memory
// finally the value from register wins
}
This prints 4 (BAD):
g++ -O2 -march=athlon bug.cc -o bug; ./bug; echo $?
This prints 12 (CORRECT):
g++ -O1 -march=athlon bug.cc -o bug; ./bug; echo $?
This prints 12, but works by chance (assembly code is incorrect):
g++ -O2 bug.cc -o bug; ./bug; echo $?
# gcc -v
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041006 (Red Hat 3.4.2-5)
--
Summary: Pointer reference optimized into register is not used
when referenced through type cast.
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zybi at talex dot pl
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17998
[Bug c++/17998] Pointer reference optimized into register is not used when referenced through type cast.
--- Additional Comments From zybi at talex dot pl 2004-10-14 12:35 --- Created an attachment (id=7350) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7350action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17998
[Bug target/17990] unaligned xmm movaps on the stack
-- What|Removed |Added Summary|segfault in c++ code|unaligned xmm movaps on the |(unaligned movaps on the|stack |stack) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990
[Bug libstdc++/17997] C++ ostringstream const char * interpreted as void *(?)
--- Additional Comments From bangerth at dealii dot org 2004-10-14 12:58 --- This has been reported many times. In essence, you cannot use a temporary as a stringstream object as in ostringstream() something; The standard doesn't allow this. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17997
[Bug c++/17998] Pointer reference optimized into register is not used when referenced through type cast.
--- Additional Comments From bangerth at dealii dot org 2004-10-14 13:01 --- You can't do that -- your code violates aliasing rules. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17998
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
-- What|Removed |Added Severity|critical|normal Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 13:22 --- The second one looks like a bug in SCO's math.h. -- What|Removed |Added Severity|critical|normal Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug target/17993] Error in dwarf2 debug output of bitfield members
-- What|Removed |Added Component|debug |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
-- What|Removed |Added Component|debug |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug target/17989] Add a warning for more than one -march option on command line
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 13:29 --- This bug report was a response to PR 17990 where we thought that -march=pentium was coming after the other march but I just tested that and it works. With -march=pentium we don't output mmx/sse instructions at all. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17989
[Bug target/17990] unaligned xmm movaps on the stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 13:31 --- Note the options needed to reproduce this is -O2 -march=athlon-xp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990
[Bug middle-end/17961] ICE for operation on small vector with altivec enabled
-- What|Removed |Added Component|c |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug middle-end/17961] ICE for operation on small vector with altivec enabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 13:37 --- Hmm this works on ppc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug target/17990] unaligned xmm movaps on the stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:01
---
Confirmed reduced testcase:
extern double sin (double __x) throw ();
float hmag[128],hphase[128];
void prepare(float *oscilFFTfreqs)
{
int i;
for (i=0;i128;i++)
*oscilFFTfreqs=-hmag[i]*sin(hphase[i])/2.0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-10-14 14:01:07
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990
[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:04 --- And this is a regression. Only -O2 -msse is needed to reproduce the problem. -- What|Removed |Added Known to work||3.3.3 Summary|unaligned xmm movaps on the |[3.4/4.0 Regression] |stack |unaligned xmm movaps on the ||stack with -O2 -msse Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990
[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:07 --- Unless someone can prove that eh part of remove_useless_stmt does not matter any more because of the lowering of eh, I think the patch is wrong. Maybe we can move the eh part into the lowering of the eh and then we don't have to worry about that if we don't do it alreay. Doing CFG already does the some parts of remove_useless_stmt and cfg_remove_useless_stmt does the conditional part already. I think eh lowering does the rest so maybe we can remove this compile time problem. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-14 14:07:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967
[Bug libfortran/17992] reading empty line does not return 0
-- What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug target/17962] [4.0 Regression] small fp vector uses sse/mmx vectors and is not aligned
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:10 --- Confirmed, this is a regression from 3.4. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Known to fail||4.0.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2004-10-14 14:10:24 date|| Summary|small fp vector uses sse/mmx|[4.0 Regression] small fp |vectors and is not aligned |vector uses sse/mmx vectors ||and is not aligned Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17962
[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:14 --- Related to bug 17962. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:16 --- New error message on the mainline: A.java: In class `A': A.java: In method `A.main(java.lang.String[])': A.java:8: error: stack underflow -- What|Removed |Added Last reconfirmed|2004-06-06 01:37:12 |2004-10-14 14:16:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
[Bug libfortran/17748] libgfortran contains undefined references to _environ
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:26 --- If I get some time, I will look into getting this done correctly, aka autoconf that we cannot use _environ and try to use _NSGetEnviron instead. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17748
[Bug libfortran/17999] New: libfortran: uses some C99 functions (snprintf)
The most ovbious fix here is to link in libiberty.a which has snprintf. -- Summary: libfortran: uses some C99 functions (snprintf) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: *-*-solaris2.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17999
[Bug libfortran/16135] libfortran doesn't build, use of C99 types
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:29 --- Note I filed PR 17999 for the snprintf issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135
[Bug c/17946] wanted: warning for a MASK when a MASK was probably intended
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:31 --- I still say that people do have a 4 in their code meaning a != 0 4 !=0. Also a 1 should be caught too but that would just give too many false postives so there is no way for GCC to warn about this. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c++/17910] wrong order of static initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:33 --- Even though the testcase in PR 10112 is fixed (or is it), the problem is the same, the order in this case is undefined. *** This bug has been marked as a duplicate of 10112 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17910
[Bug c++/10112] static data member is not correctly initialised
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:33 --- *** Bug 17910 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10112
[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined
--- Additional Comments From pavenis at latnet dot lv 2004-10-14 14:41 --- For DJGPP I created one more .c file in fixincludes directory: #include fixlib.h #define _ENV_(v,m,n,t) tCC* v = NULL; ENV_TABLE #undef _ENV_ and added corresponding obj file to FIXOBJ in Makefile.in. That fixed the problem Andris -- What|Removed |Added CC||pavenis at latnet dot lv http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
[Bug c++/17053] [4.0 Regression] Repo functionality partially broken on AIX
--- Additional Comments From dje at gcc dot gnu dot org 2004-10-14 14:49 --- reducing priority -- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 14:55 --- Well I just provided to my self that lowering eh actually does the same job as the old remove_useless_stmts. I will submit a patch after class and getting home to remove remove_useless_stmts and change it to cfg_ remove_useless_stmts. -- 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=17967
[Bug c++/18000] New: g++ interprets a variable declaration as a function prototype when the arguments to the constructor are temporaries
Platform: x86 (Pentium 4 2.8 GHz with MT)
The following code does not compile, it appears that g++ is interpreting the
declaration of myvar to be a function prototype:
[EMAIL PROTECTED]:~ g++3.4.2 -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.2/specs
Configured with: ./configure --program-suffix=3.4.2
Thread model: posix
gcc version 3.4.2
[EMAIL PROTECTED]:~ g++3.4.2 -Wall -o testcpp testcpp.cpp
testcpp.cpp: In function `int main(int, char**)':
testcpp.cpp:19: error: request for member `m' in `myvar', which is of non-class
type `x ()(y)'
testcpp.cpp:17: warning: unused variable 'v'
testcpp.cpp:19: warning: unused variable 'v2'
[EMAIL PROTECTED]:~
The code:
class y
{
public:
y(int n) : n(n) {}
int n;
};
class x
{
public:
x(y m) : m(m) {}
y m;
};
int main(int argc, char *argv[])
{
int v = 1;
x myvar(y(v));
int v2 = myvar.m.n;
}
--
Summary: g++ interprets a variable declaration as a function
prototype when the arguments to the constructor are
temporaries
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schveiguy at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18000
[Bug c++/18000] g++ interprets a variable declaration as a function prototype when the arguments to the constructor are temporaries
--- Additional Comments From nathan at gcc dot gnu dot org 2004-10-14 15:48 --- This is correct behaviour. [8.2] -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18000
[Bug c/17946] wanted: warning for a MASK when a MASK was probably intended
--- Additional Comments From trt at acm dot org 2004-10-14 15:54 --- a 4 in their code meaning a != 0 4 !=0 That happens, but when it does `a' is not integer type. I use a gcc with this warning on a 35Mloc code base. There are currently 4 warnings, all pointing to real bugs. This is an excellent warning, it just doesn't fit neatly into the gcc front end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c++/17976] [3.4/4.0 Regression] Calls the dtor twice
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17976
[Bug other/17437] [4.0 Regression] obscure GC problem
--- Additional Comments From stevenb at novell dot com 2004-10-14 16:09 --- Subject: Re: [4.0 Regression] obscure GC problem On Tuesday 12 October 2004 15:03, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 13:03 --- Can you try this again? Can't reproduce it -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437
[Bug other/17464] The newly built gcc shared libraries aren't used for bootstap and check
--- Additional Comments From hjl at lucon dot org 2004-10-14 16:16 --- Shouldn't we also revert libgcc_s.so patch? The problem is nothing new. It existed from day one when libgcc_s.so was introduced. If there is no system libgcc_s.so, gcc won't boostrap nor pass make check. Let's fix this long standing bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures
--- Additional Comments From ericw at evcohs dot com 2004-10-14 16:21 --- See related bug #17462. -- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832
[Bug other/17437] [4.0 Regression] obscure GC problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 16:30 --- So closing as fixed. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437
[Bug other/17464] The newly built gcc shared libraries aren't used for bootstap and check
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 16:34 --- This is not true at all because I used to bootstrap on linux right after gcc added libgcc_s, In fact I still bootstrap on targets where libgcc_s don't exist on the machine but is built now on the mainline (ppc- darwin is the one which I am talking about). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
[Bug c++/18001] New: [4.0 regression] Badly formatted error message (quotation problem)
From a rather big program I get this error message: include/lac/sparse_matrix.templates.h:356: error: non-lvalue in unary %$ I don't have the time to reduce this right now, but the problem seems obvious enough: I guess that this error is generated in cp/tree.c, in lvalue_or_else. This probably needs the exact same change that jsm did in the C frontend (or better: these codes should be merged). The call to lvalue_or_else, btw, comes from typeck.c, and the quotation signs are misspelled there indeed (note $ instead of % in the output). W. -- Summary: [4.0 regression] Badly formatted error message (quotation problem) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bangerth at dealii dot org CC: gcc-bugs at gcc dot gnu dot org,jsm at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18001
[Bug c++/18001] [4.0 regression] Badly formatted error message (quotation problem)
--- Additional Comments From bangerth at dealii dot org 2004-10-14 16:35 ---
Thinking about it, finding a testcase wasn't all that hard:
--
int main ()
{
1;
}
--
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18001
[Bug target/17993] Error in dwarf2 debug output of bitfield members
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug c++/18001] [4.0 regression] Badly formatted error message (quotation problem)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 16:40 --- Confirmed, related to PR 17852. -- What|Removed |Added CC||gdr at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2004-10-14 16:40:11 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18001
[Bug target/17822] avr: Hard-coded XXX_FOR_TARGET
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17822
[Bug other/17464] The newly built gcc shared libraries aren't used for bootstap and check
--- Additional Comments From hjl at lucon dot org 2004-10-14 17:10 --- Have you looked at http://gcc.gnu.org/ml/gcc/2004-09/msg00209.html We get lucky that only Ada compiler is linked with libgcc_s.so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
[Bug c/17946] wanted: warning for a MASK when a MASK was probably intended
--- Additional Comments From bangerth at dealii dot org 2004-10-14 17:33 --- Andrew, I'm getting angry when you selfishly close PRs that other people think are useful to be kept open. The submitter of this PR has shown that the cases you claim exist are not frequent, and that they often enough point to real bugs. What more proof do you want that you argument is wrong? This is, after all, an enhancement request, not a bug report. If your code wrongly triggers this warning, just switch it off. I would also like to remind you that we work based on consensus. If you disagree with decisions by others, then that's fine, but you may not put your opinions over those of others. If you close a PR and I reopen it, don't close it again or we will have to discuss this on the bugmaster mailing list. I consider your behavior disrespectful and rude. Thanks Wolfgang -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/17023] [3.3/3.4/4.0 Regression] ICE with nested functions in parameter declaration
--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-14 18:25
---
Subject: Re: [3.3/3.4/4.0 Regression] ICE with nested functions
in parameter declaration
On Thu, 14 Oct 2004, rth at gcc dot gnu dot org wrote:
Looks to me as if the nested function has nothing to do with it. Rather,
it's the statement expression. Just int b[({ 1; })] is enough to crash.
I think the plain statement expression case is actually valid code (the
statement expression should be evaluated on function entry just like the
other array size expressions in the parameters).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17023
[Bug debug/7241] DWARF encoding for char incorrect in gcc
--- Additional Comments From ericw at evcohs dot com 2004-10-14 18:37 --- Would someone comment if the fix in comment #6 is correct? And could it be applied to mainline to close out this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7241
[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 18:38 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01202.html. I was convenced by RTH that removing r_u_s actually can slow it down but he also helped me to figure out where the problem is. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967
[Bug tree-optimization/17635] [4.0 regression] ICE in verify_ssa: type mismatch
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 18:40 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17635
[Bug middle-end/17746] [4.0 Regression] ICE when building the shared Ada RTS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 18:57 --- Quick summary of my investigation so far: - ICE on g-awk.adb at -O0: pb in the RTL expander relating to ADDR_EXPR - ICE on g-socket.adb at -O0: consistency check, again ADDR_EXPR - infinite loop on make.adb at -O2: PHI nodes sharing pb (ok at -O1) After quick fix for both ICE + workaround for infinite loop: === acats tests === FAIL: c330001 FAIL: c380004 FAIL: c391002 FAIL: c43214c FAIL: c45273a FAIL: c45347a FAIL: c45347b FAIL: c45347c FAIL: c74004a FAIL: c940006 FAIL: c951001 FAIL: c954023 FAIL: c97114a FAIL: c97117a FAIL: ca11005 FAIL: cc1221d FAIL: cd10002 FAIL: cd2a21e FAIL: cd2a22i FAIL: cd2a31a FAIL: cxaa010 FAIL: cxaa017 FAIL: cxb4004 FAIL: cxh3002 === acats Summary === # of expected passes2298 # of unexpected failures24 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17746
[Bug tree-optimization/17986] [4.0 Regression] Compile error for make.adb breaks bootstrap
-- What|Removed |Added Component|ada |tree-optimization Keywords||build, ice-on-valid-code Summary|Compile error for make.adb |[4.0 Regression] Compile |breaks bootstrap|error for make.adb breaks ||bootstrap Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17986
[Bug middle-end/17746] [4.0 Regression] ICE when building the shared Ada RTS
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-14 19:03 --- - ICE on g-socket.adb at -O0: consistency check, again ADDR_EXPR is PR 17793 (I filed it) - infinite loop on make.adb at -O2: PHI nodes sharing pb (ok at -O1) is PR 17986 (someone else filed it) And there is target (PPC) bug see PR 17956 after working around PR 17793. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17746
[Bug target/17889] gcc 3.4 branch does not build for arc-elf32
-- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17889
[Bug target/17317] Match Constraints for *movdf_insn fails
-- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17317
[Bug middle-end/17793] [4.0 Regression] Ada bootstrap failure
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 19:18
---
The integer_type's are not compatible by defined by the front-end, why?
The front-end generates a correct tree (with a NOP_EXPR) but it is stripped by
the gimplifier:
/* Strip away as many useless type conversions as possible
at the toplevel. */
STRIP_USELESS_TYPE_CONVERSION (*expr_p);
A quick fix is therefore the following:
Index: gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.82
diff -u -p -r2.82 gimplify.c
--- gimplify.c 30 Sep 2004 01:22:05 - 2.82
+++ gimplify.c 14 Oct 2004 15:24:57 -
@@ -4156,7 +4156,7 @@ gimplify_one_sizepos (tree *expr_p, tree
static bool
cpt_same_type (tree a, tree b)
{
- if (lang_hooks.types_compatible_p (a, b))
+ if (a == b || lang_hooks.types_compatible_p (a, b))
return true;
/* ??? The C++ FE decomposes METHOD_TYPES to FUNCTION_TYPES and doesn't
@@ -4179,7 +4179,8 @@ cpt_same_type (tree a, tree b)
if (POINTER_TYPE_P (a) POINTER_TYPE_P (b))
return cpt_same_type (TREE_TYPE (a), TREE_TYPE (b));
- return false;
+ /* STRIP_USELESS_TYPE_CONVERSION uses this predicate. */
+ return tree_ssa_useless_type_conversion_1 (a, b);
}
/* Check for some cases of the front end missing cast expressions.
However I'm not sure it is not papering over something else.
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
Component|ada |middle-end
GCC target triplet|powerpc-darwin, powerpc-|powerpc-*, sparc-*
|linux |
Summary|[4.0 Regression] Ada front- |[4.0 Regression] Ada
|end causing bootstrap |bootstrap failure
|failure |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17793
[Bug tree-optimization/17986] [4.0 Regression] Compile error for make.adb breaks bootstrap
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-14 19:22 --- Present on sparc-sun-solaris2.8, with same workaround. Preliminary investigation suggests a PHI nodes sharing problem. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-14 19:22:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17986
[Bug target/18002] New: [3.4/4.0 Regression] 'while' loop performace regression on avr target
Hello,
when I compile(avr-gcc -c -Os -mmcu=atmega8 test.c) this code:
int main (void)
{
while (((*(volatile unsigned char *)((0x0B) + 0x20)) (15)) == 0) {
;
}
return (0);
}
with gcc 3.3.1 I get this asm loop:
8: 5d 9b sbis0x0b, 5 ; 11
a: fe cf rjmp.-4 ; 0x8
with gcc 3.4.2 or 4.0.0 I get this:
8: 41 e0 ldi r20, 0x01 ; 1
a: 50 e0 ldi r21, 0x00 ; 0
c: 8b b1 in r24, 0x0b ; 11
e: 99 27 eor r25, r25
10: 25 e0 ldi r18, 0x05 ; 5
12: 96 95 lsr r25
14: 87 95 ror r24
16: 2a 95 dec r18
18: e1 f7 brne.-8 ; 0x12
1a: 84 27 eor r24, r20
1c: 95 27 eor r25, r21
1e: 9c 01 movwr18, r24
20: 21 70 andir18, 0x01 ; 1
22: 30 70 andir19, 0x00 ; 0
24: 80 fd sbrcr24, 0
26: f2 cf rjmp.-28; 0xc
--
Summary: [3.4/4.0 Regression] 'while' loop performace regression
on avr target
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: berndtrog at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18002
[Bug c++/18000] g++ interprets a variable declaration as a function prototype when the arguments to the constructor are temporaries
--- Additional Comments From schveiguy at yahoo dot com 2004-10-14 19:51 --- (In reply to comment #1) This is correct behaviour. [8.2] whoops! I'll be damned. It doesn't seem like it should be proper behavior :) sorry. Thanks for the quick reply. If anyone reads this bug, and has a similar problem, the fix for the code above is to change the line to: x myvar = x(y(v)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18000
[Bug c/17023] [3.3/3.4/4.0 Regression] ICE with nested functions in parameter declaration
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-14 19:55 ---
You do? Hm, in which case I may need to persue a different solution than
the one I'm currently testing. Also, if true, I don't see why a nested
function wouldn't be acceptable there:
int b[({ int h() { return 1; } h(); })]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17023
