[Bug bootstrap/19818] New: [4.0 Regression] GCC 4.0 cannot bootstrap itself
Warnings in libiberty and libcpp prevent GCC 4.0 from bootstrapping itself, because libcpp's configure uses -Werror. The easiest way to reproduce this is to configure GCC 4.0 with --enable-bootstrap so that libcpp is bootstrapped as well. Severity is normal and not critical because releases do not use -Werror, but the bug ought to be fixed before GCC branches. -- Summary: [4.0 Regression] GCC 4.0 cannot bootstrap itself Product: gcc Version: unknown Status: UNCONFIRMED Keywords: build Severity: normal Priority: P1 Component: bootstrap AssignedTo: bonzini at gcc dot gnu dot org ReportedBy: bonzini 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=19818
[Bug bootstrap/19818] [4.0 Regression] GCC 4.0 cannot bootstrap itself
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-08 09:18 --- Created an attachment (id=8139) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8139&action=view) proposed patch Pretty obvious patch if it weren't for the hunk in macro.c. Patch is in stage2 of a toplevel bootstrap now, will post it once it finishes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19818
[Bug bootstrap/19818] [4.0 Regression] GCC 4.0 cannot bootstrap itself
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-08 09:19 --- CCing Geoff since he wrote the hunk I modify in macro.c. It looks like a pasto, but I am not sure. -- What|Removed |Added CC||geoffk at apple dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-08 09:19:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19818
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 09:24 --- On ia64-unknown-linux-gnu, -O1 produces the same result that -O3 does. Here's a shell script that I currently use for shotgun testing of single optimization options: for a in \ branch-count-reg cprop-registers \ function-cse gcse-lm \ guess-branch-probability if-conversion if-conversion2 \ ivopts keep-static-consts loop-optimize \ loop-optimize2 math-errno \ peephole sched-interblock sched-spec \ sched-stalled-insns-dep split-ivs-in-unroller \ tree-ccp tree-ch tree-copyrename tree-dce tree-dominator-opts \ tree-dse tree-fre tree-loop-im tree-loop-ivcanon \ tree-loop-optimize tree-lrs tree-sra tree-ter do echo $a rm *.o gfortran -c -f$a ../*.f \ && gfortran -g *.o -o xeigtstd \ && xeigtstd < ded.in > $a.out done The directory above contains all the Fortran routines necessary for xeigtstd, namely alahdg.f derrgg.f dget51.f dlaev2.f dlarrb.f dlatms.f dsbev.f dsyevr.f alareq.f derrhs.f dget52.f dlaexc.f dlarre.f dlatrd.f dsbevx.f dsyevx.f alasum.f derrst.f dget53.f dlafts.f dlarrf.f dlatrs.f dsbgst.f dsygs2.f alasvm.f dgbbrd.f dget54.f dlag2.f dlarrv.f dlctes.f dsbgvd.f dsygst.f chkxer.f dgbmv.f dgetc2.f dlagge.f dlartg.f dlctsx.f dsbgv.f dsygvd.f dasum.f dgebak.f dggbak.f dlags2.f dlartv.f dlsets.f dsbgvx.f dsygv.f daxpy.f dgebal.f dggbal.f dlagsy.f dlaruv.f dnrm2.f dsbmv.f dsygvx.f dbdsdc.f dgebd2.f dgges.f dlagtf.f dlas2.f dopbl3.f dsbt21.f dsymm.f dbdsqr.f dgebrd.f dggesx.f dlagts.f dlascl.f dopgtr.f dsbtrd.f dsymv.f dbdt01.f dgecon.f dggev.f dlagv2.f dlasd0.f dopla2.f dscal.f dsyr2.f dbdt02.f dgees.f dggevx.f dlahd2.f dlasd1.f dopla.f dsecnd.f dsyr2k.f dbdt03.f dgeesx.f dggglm.f dlahqr.f dlasd2.f dopmtr.f dsgt01.f dsyr.f dchkbb.f dgeev.f dgghrd.f dlahrd.f dlasd3.f dorg2l.f dslect.f dsyrk.f dchkbd.f dgeevx.f dgglse.f dlakf2.f dlasd4.f dorg2r.f dspevd.f dsyt21.f dchkbk.f dgegs.f dggqrf.f dlaln2.f dlasd5.f dorgbr.f dspev.f dsyt22.f dchkbl.f dgegv.f dggrqf.f dlamch.f dlasd6.f dorghr.f dspevx.f dsytd2.f dchkec.f dgehd2.f dggsvd.f dlamrg.f dlasd7.f dorgl2.f dspgst.f dsytrd.f dchkee.f dgehrd.f dggsvp.f dlangb.f dlasd8.f dorglq.f dspgvd.f dtbmv.f dchkgg.f dgelq2.f dglmts.f dlange.f dlasda.f dorgql.f dspgv.f dtgevc.f dchkgk.f dgelqf.f dgqrts.f dlanhs.f dlasdq.f dorgqr.f dspgvx.f dtgex2.f dchkgl.f dgemm.f dgrqts.f dlansb.f dlasdt.f dorgr2.f dspmv.f dtgexc.f dchkhs.f dgemv.f dgsvts.f dlansp.f dlaset.f dorgrq.f dspr2.f dtgsen.f dchksb.f dgeqpf.f dhgeqz.f dlanst.f dlasq1.f dorgtr.f dspr.fdtgsja.f dchkst.f dgeqr2.f dhsein.f dlansy.f dlasq2.f dorm2l.f dspt21.f dtgsna.f dckglm.f dgeqrf.f dhseqr.f dlanv2.f dlasq3.f dorm2r.f dsptrd.f dtgsy2.f dckgqr.f dger.fdhst01.f dlapll.f dlasq4.f dormbr.f dstebz.f dtgsyl.f dckgsv.f dgerq2.f dlabad.f dlapmt.f dlasq5.f dormhr.f dstech.f dtpmv.f dcklse.f dgerqf.f dlabrd.f dlapy2.f dlasq6.f dorml2.f dstect.f dtpsv.f dcopy.f dgesc2.f dlacon.f dlapy3.f dlasr.f dormlq.f dstedc.f dtrevc.f ddot.fdgesdd.f dlacpy.f dlaqtr.f dlasrt.f dormql.f dstegr.f dtrexc.f ddrges.f dgesvd.f dladiv.f dlar1v.f dlassq.f dormqr.f dstein.f dtrmm.f ddrgev.f dget02.f dlae2.f dlar2v.f dlasum.f dormr2.f dsteqr.f dtrmv.f ddrgsx.f dget10.f dlaebz.f dlaran.f dlasv2.f dormrq.f dsterf.f dtrsen.f ddrgvx.f dget22.f dlaed0.f dlarfb.f dlaswp.f dormtr.f dstevd.f dtrsm.f ddrvbd.f dget23.f dlaed1.f dlarf.f dlasy2.f dort01.f dstev.f dtrsna.f ddrves.f dget24.f dlaed2.f dlarfg.f dlatb9.f dort03.f dstevr.f dtrsv.f ddrvev.f dget31.f dlaed3.f dlarft.f dlatdf.f dpbstf.f dstevx.f dtrsyl.f ddrvgg.f dget32.f dlaed4.f dlarfx.f dlatm1.f dpotf2.f dstt21.f idamax.f ddrvsg.f dget33.f dlaed5.f dlarfy.f dlatm2.f dpotrf.f dstt22.f ieeeck.f ddrvst.f dget34.f dlaed6.f dlarge.f dlatm3.f dpptrf.f dsvdch.f ilaenv.f ddrvsx.f dget35.f dlaed7.f dlargv.f dlatm4.f dpteqr.f dsvdct.f lsame.f ddrvvx.f dget36.f dlaed8.f dlarhs.f dlatm5.f dpttrf.f dswap.f lsamen.f derrbd.f dget37.f dlaed9.f dlarnd.f dlatm6.f drot.fdsxt1.f xerbla.f derrec.f dget38.f dlaeda.f dlarnv.f dlatme.f drscl.f dsyevd.f xlaenv.f derred.f dget39.f dlaein.f dlarot.f dlatmr.f dsbevd.f dsyev.f There is no single optimization option that will cause any failures for xeigtstd for ded.in *sigh*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug c++/19819] New: ICE when compiling aegis 4.20
g++ runs into an ICE when compiling aegis 4.20 on HP 10.20 /software/gcc/3.4.3/HP-UX-B.10/bin/g++ -Iaeget -Ilibaegis -Icommon -I/work/include -O -c \ aeget/get/file/metrics.cc aeget/get/file/metrics.cc: In function `void get_file_metrics(change_ty*, string_ty*, string_list_ty*)': aeget/get/file/metrics.cc:382: error: unrecognizable insn: (insn 2201 2200 2199 114 (set (reg:DF 68 %fr22) (mem/s/j:DF (plus:SI (reg:SI 21 %r21) (reg:SI 1 %r1)) [0 .data S8 A64])) -1 (nil) (nil)) aeget/get/file/metrics.cc:382: internal compiler error: in extract_insn, at recog.c:2083 Now how to attach the preprocessed source file...? -- Summary: ICE when compiling aegis 4.20 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ralfixx at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa2.0-hp-hpux10.20 GCC host triplet: hppa2.0-hp-hpux10.20 GCC target triplet: hppa2.0-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19819
[Bug c++/19819] ICE when compiling aegis 4.20
--- Additional Comments From ralfixx at gmx dot de 2005-02-08 09:59 --- Created an attachment (id=8140) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8140&action=view) preprocessed source file preprocessed source with commandline: /software/gcc/3.4.3/HP-UX-B.10/bin/g++ -v -save-temps -Iaeget -Ilibaegis -Icommon -I/work/include -O -caeget/get/file/metrics.cc Reading specs from /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/specs Configured with: /tmp_mnt/hosts/jupiter/disk4/tmp/ralf/Software/gcc-3.4.3/configure --prefix=/software/gcc/3.4.3 --exec-prefix=/software/gcc/3.4.3/HP-UX-B.10 --with-local-prefix=/work --enable-languages=c,c++ --enable-shared --with-gnu-as --with-as=/work/bin/as Thread model: single gcc version 3.4.3 /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/libexec/gcc/hppa2.0-hp-hpux10.20/3.4.3/cc1plus -E -quiet -v -Iaeget -Ilibaegis -Icommon -I/work/include -iprefix /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/bin/../lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/ aeget/get/file/metrics.cc -O -o metrics.ii ignoring nonexistent directory "/tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/bin/../lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/../../../../hppa2.0-hp-hpux10.20/include" ignoring duplicate directory "/software/gcc/3.4.3/include/c++/3.4.3" ignoring duplicate directory "/software/gcc/3.4.3/include/c++/3.4.3/hppa2.0-hp-hpux10.20" ignoring duplicate directory "/software/gcc/3.4.3/include/c++/3.4.3/backward" ignoring duplicate directory "/software/gcc/3.4.3/HP-UX-B.10/lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/include" ignoring nonexistent directory "/software/gcc/3.4.3/HP-UX-B.10/hppa2.0-hp-hpux10.20/include" ignoring duplicate directory "/work/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: aeget libaegis common /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/bin/../lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/../../../../../include/c++/3.4.3 /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/bin/../lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/../../../../../include/c++/3.4.3/hppa2.0-hp-hpux10.20 /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/bin/../lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/../../../../../include/c++/3.4.3/backward /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/bin/../lib/gcc/hppa2.0-hp-hpux10.20/3.4.3/include /work/include /software/gcc/3.4.3/include /usr/include End of search list. /tmp_mnt/software/software/gcc/3.4.3/HP-UX-B.10/libexec/gcc/hppa2.0-hp-hpux10.20/3.4.3/cc1plus -fpreprocessed metrics.ii -quiet -dumpbase metrics.cc -auxbase metrics -O -version -o metrics.s GNU C++ version 3.4.3 (hppa2.0-hp-hpux10.20) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32768 aeget/get/file/metrics.cc: In function `void get_file_metrics(change_ty*, string_ty*, string_list_ty*)': aeget/get/file/metrics.cc:382: error: unrecognizable insn: (insn 2201 2200 2199 114 (set (reg:DF 68 %fr22) (mem/s/j:DF (plus:SI (reg:SI 21 %r21) (reg:SI 1 %r1)) [0 .data S8 A64])) -1 (nil) (nil)) aeget/get/file/metrics.cc:382: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19819
[Bug c++/19819] ICE when compiling aegis 4.20
--- Additional Comments From ralfixx at gmx dot de 2005-02-08 10:01 --- Created an attachment (id=8141) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8141&action=view) preprocessed assembly source assembly source (same commandline as .ii attachment) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19819
[Bug target/17548] -march=pentium4 slows down Ada code
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 10:04 --- For me -march=pentium4 or -march=pentium3 does not make a difference. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17548
[Bug target/19133] march=athlon can produce slower code than march=i686
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 10:09 --- -march=athlon should optimize for the K7 yes. What you probably run into is a simple backend problem where the code generated for the K7 can, for whatever reason, not be optimized as well as the i686 code. Can you try mainline and see what happens there? I think very few people think this is important enough to fix for already-released compilers. But if the problem exists on mainline as well, we can look into it. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-08 10:09:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19133
[Bug middle-end/19779] IBM 128bit long double format is not constant folded.
-- What|Removed |Added Summary|IBM 128bit long double |IBM 128bit long double |format is not constant |format is not constant |foldded.|folded. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 10:13 --- rth hacked the constraints recently to have better ra for some fp cases. Can you see if the bug is still there today on mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug tree-optimization/17863] [4.0 Regression] threefold performance loss, not inlining as much
--- Additional Comments From kunert at physik dot tu-dresden dot de 2005-02-08 10:13 --- Subject: Re: [4.0 Regression] threefold performance loss, not inlining as much Good idea. However, this provides just another knob to tune the inlining and it is not obvious where to apply that attribute for the best performance. I played with the present dozen or so parameters for some hours to come close to the old (aka 3.4) performance, and I definitely can't handle even more. Thank you Thomas Kunert bonzini at gcc dot gnu dot org wrote: > --- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-03 > 16:49 --- > To the reporter: in this case you probably want __attribute__ ((leafify)), > just > in case, though you are right in expecting the compiler to inline it. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug tree-optimization/1046] gcc less efficient than jdk for recursion!
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 10:14 --- Honza, this is one we should catch on the tree-profiling branch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1046
[Bug middle-end/14060] An unused register is saved to the stack.
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 10:19 --- Kazu, is this still a problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14060
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From giovannibajo at libero dot it 2005-02-08 10:42 --- Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and see if you find out something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug c/19820] New: How to get results from a V2SF ?
This is probably not really a bug, just a hole in the documentation. While
google can demonstrate how to get values into vectors, and the info pages the
names of the manipulation functions avaliable, there seems to be no
documentation on how to get at the results of the manipulation.
How do you get at the results?
typedef float V2SF __attribute__((vector_size(8)));
int main()
{
V2SF a = { 2.0, 3.0 };
V2SF b = { 4.0, 5.0 };
V2SF c;
c = __builtin_ia32_pfmul(a,b);
/* how to get at the values in c? */
return 0;
};
--
Summary: How to get results from a V2SF ?
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: plm at netspace dot net dot au
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19820
[Bug java/18281] Backslashes in CLASSPATH cause jc1 to hang
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-08 12:00 --- (In reply to comment #0) > If gcj is called while the environment variable CLASSPATH contains > backslashes > instead of slashes, jc1 (called by gcj) hangs without any error message. > Could > gcj/jc1 be made "backslash tolerant"? You'll have to provide more details than this. What platform are you trying this on? What was the value of CLASSPATH when you saw this? Et cetera. FWIW, when I checked the current mainline on Linux with a CLASSPATH containing backslashes it did not hang. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18281
[Bug preprocessor/19821] New: Preprocessor oom with nested vector operations
With 4 nested vec_add()'s gcc goes out of memory on my 512MB+1GBswap ppc box.
With 3 adds it consumes about 150MB of memory and eventually succeeds. The
preprocessor expands the y=... line into an exagerately huge expression. fftw3
fails to compile because of this.
Tested on gcc 3.4.1 and 3.4.3, stable versions. They were configured with the
following options:
./configure --prefix=/usr/ --enable-shared --enable-threads=posix --with-system-
zlib --enable-__cxa_atexit --disable-checking --enable-altivec --with-cpu=7450 -
-enable-languages=c,c++,objc
#include
main() {
vector float y, a, b;
y = vec_add(a, vec_add(a, vec_add(a, vec_add(a, b;
}
# gcc -maltivec c.c
--
Summary: Preprocessor oom with nested vector operations
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pochini at shiny dot it
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19821
[Bug target/19819] ICE when compiling aegis 4.20
-- What|Removed |Added Component|c++ |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19819
[Bug other/18961] Large output causes testsuite failure
--- Additional Comments From chris at bubblescope dot net 2005-02-08 13:24 --- Yep, that fixed it. Marking it as a dup. *** This bug has been marked as a duplicate of 12096 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18961
[Bug other/12096] dejagnu truncates output from spawned commands randomly, causing intermittant failed tests
--- Additional Comments From chris at bubblescope dot net 2005-02-08 13:24 --- *** Bug 18961 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12096
[Bug preprocessor/19821] Preprocessor oom with nested vector operations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 13:27 --- *** This bug has been marked as a duplicate of 19411 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19821
[Bug preprocessor/19411] Simple program causes gcc to run out of memory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 13:27 --- *** Bug 19821 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||pochini at shiny dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19411
[Bug c/19820] How to get results from a V2SF ?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 13:37 --- Hmm, I thought this was documented but you use an union. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19820
[Bug target/19822] New: [avr] Unable to find a register to spill in class `POINTER_REGS'
Hi,
I get an ICE compiling arpcache.i with avr-gcc-3.4.3+:
avr-gcc -c -Os arpcache.i
arpcache.c: In function `NutArpCacheQuery':
arpcache.c:481: error: unable to find a register to spill in class
`POINTER_REGS'
arpcache.c:481: error: this is the insn:
(insn 90 207 206 5 (parallel [
(set (mem:BLK (reg/v/f:HI 44 [ mac ]) [0 A8])
(mem:BLK (reg/v/f:HI 28 r28 [orig:46 entry ] [46]) [0 A8]))
(use (reg:QI 24 r24 [60]))
(use (const_int 1 [0x1]))
(clobber (scratch:HI))
(clobber (scratch:HI))
(clobber (scratch:QI))
]) 16 {*movstrqi_insn} (insn_list 87 (insn_list 89 (nil)))
(expr_list:REG_DEAD (reg:QI 24 r24 [60])
(expr_list:REG_DEAD (reg/v/f:HI 44 [ mac ])
(expr_list:REG_UNUSED (scratch:QI)
(expr_list:REG_UNUSED (scratch:HI)
(expr_list:REG_UNUSED (scratch:HI)
(nil)))
arpcache.c:481: confused by earlier errors, bailing out
This works on 3.4.2!
It fails on 3.4.3, 3.4.4 20050202 (prerelease), and 4.0.0 20050203
(experimental)
--
Summary: [avr] Unable to find a register to spill in class
`POINTER_REGS'
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dieterbmeier at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19822
[Bug target/19822] [avr] Unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From dieterbmeier at yahoo dot com 2005-02-08 13:45 --- Created an attachment (id=8143) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8143&action=view) arpcache.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19822
[Bug middle-end/16802] PowerPC - Unnecessary extsw
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
13:49 ---
Fixed on the mainline.
We now combine the following RTL to fix the problem:
(insn 16 15 17 0 (set (reg:SI 126)
(lt:SI (reg:CC 127)
(const_int 0 [0x0]))) 382 {*rs6000.md:11380}
(insn_list:REG_DEP_TRUE 15 (nil))
(expr_list:REG_DEAD (reg:CC 127)
(nil)))
(insn 17 16 21 0 (set (reg:DI 128)
(sign_extend:DI (reg:SI 126))) 43 {*rs6000.md:446}
(insn_list:REG_DEP_TRUE 16 (nil))
(expr_list:REG_DEAD (reg:SI 126)
(nil)))
(insn 24 21 30 0 (set (reg/i:DI 3 r3 [ ])
(reg:DI 128)) 312 {*movdi_internal64} (insn_list:REG_DEP_TRUE 17 (nil))
(expr_list:REG_DEAD (reg:DI 128)
(nil)))
Into:
(insn 24 21 30 0 (set (reg/i:DI 3 r3 [ ])
(lt:DI (reg:CC 127)
(const_int 0 [0x0]))) 383 {*rs6000.md:11412}
(insn_list:REG_DEP_TRUE 15 (nil))
(expr_list:REG_DEAD (reg:CC 127)
(nil)))
--
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16802
[Bug fortran/16943] doubly defined function type causes error, even when types are the same
-- What|Removed |Added Keywords||diagnostic Last reconfirmed|2004-11-08 03:03:11 |2005-02-08 13:54:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16943
[Bug target/19822] [avr] Unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 13:55 --- *** This bug has been marked as a duplicate of 18251 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19822
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 13:55 --- *** Bug 19822 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dieterbmeier at yahoo dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug tree-optimization/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From amacleod at redhat dot com 2005-02-08 14:02 --- (In reply to comment #30) > Subject: Re: [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3 > > On Mon, Feb 07, 2005 at 11:13:27PM -, steven at gcc dot gnu dot org wrote: > > x = a + b; > > x = x * a; > > x = x * b; > ... > > After Coalescing: > ... > > Partition 2 (x_3 - 3 ) > > Partition 3 (x_4 - 4 ) > > Partition 4 (x_5 - 5 ) > > That is curious. Certainly not the way I'd have expected things to work. > Why are we not coalescing here? Do we think that x_4 as an input to the > same insn that creates x_5 means that the two conflict? Unless someone > can convince me otherwise, I'd call this a bug. > No we dont think that, but they are disjoint live ranges, so we want to keep them seperate. we do live range splitting on the way out of SSA. there is no conflict, just reason NOT to coalesce them. if there was a copy between them, then we consider coalescing them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug preprocessor/19821] Preprocessor oom with nested vector operations
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-08 14:02 --- Subject: Re: New: Preprocessor oom with nested vector operations pochini at shiny dot it wrote:- > With 4 nested vec_add()'s gcc goes out of memory on my 512MB+1GBswap ppc box. > With 3 adds it consumes about 150MB of memory and eventually succeeds. The > preprocessor expands the y=... line into an exagerately huge expression. > fftw3 > fails to compile because of this. But it is ridiculously big. If you think it's expanding it wrong then please elaborate. Otherwise don't use brain-dead macros 8-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19821
[Bug bootstrap/19818] [4.0 Regression] GCC 4.0 cannot bootstrap itself
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.0 Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19818
[Bug tree-optimization/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From amacleod at redhat dot com 2005-02-08 14:26 --- (In reply to comment #28) > Using var_to_partition does not help. The reason is that the SSA names with > the same root var are not in the same partition, e.g. > > _7 --> > x_3 --> x > x_4 not coalesced with x --> New temp: 'x.0' > x_5 not coalesced with x.0 --> New temp: 'x.1' <...> > > Partition 0 (a - 1 ) > Partition 1 (b - 2 ) > Partition 2 (x - 3 ) > Partition 3 (x.0 - 4 ) > Partition 4 (x.1 - 5 ) > Partition 5 ( - 7 ) > > So if you replace the root var comparison in my hack with a check to make > sure > def and def2 are not in the same partition, that whole check will always be > false and you still get crap code. > of course. doh. Accumulation will result in live range splitting, so they will all be different variables. Stick with checking the root variable, its probably our simplest measure I guess. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug java/19823] New: java fails with non-executable memory
Newer linux kernels (2.6.11 in this case) check the executable for a PT_GNU_STACK program header, and if it exists default to provide non-executable memory (for stack _and_ malloced memory) on CPUs which support this (all x86-64 CPUs and newer x86 ones). It seems that gij is not prepared to handle this. This can be seen in some testresults, e.g. here: http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg00223.html This is the autovect branch, but it's the same on all GCC versions (3.3 through 4.0). This is with such a new kernel, with an older kernel which didn't do this yet all those testcases work. Currently Andi Kleen proposed again to switch this off on the kernel side as a hot fix, because too much software currently breaks. But somewhen it will be activated for sure, and then GCC should be able to cope with this. My guess is, that there only are missing some mprotect calls at the right places. -- Summary: java fails with non-executable memory Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at suse dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 14:41 --- I think this is a libffi problem in that it creates a closure but does not make it exutable. -- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1
--- Additional Comments From hundertmarck at boehme-weihs dot de 2005-02-08 15:02 --- The Problem was using gcc-3.2 as bootstrap compiler. After using the system cc the bootstrap finished successfully. Now my g++ supports wstring :-D Thanks to all! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005
[Bug bootstrap/19824] New: genattrtab allocates over 4GB memory and fails!
Hello I want to compile gcc 4.0.0 20050202 on ibm aix 4.3.3. Bootstrap fails if genattrtab runs: build/genattrtab /soft/gnu/packages/gcc_cvs/gcc/gcc/config/rs6000/rs6000.md > tmp-attrtab.c out of memory allocating 80016 bytes after a total of 4161650636 bytes I have not found an existing bug for it. It is a bug or do I something wrong? Tanks Joerg Hundertmarck -- Summary: genattrtab allocates over 4GB memory and fails! Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hundertmarck at boehme-weihs dot de CC: gcc-bugs at gcc dot gnu dot org,hundertmarck at boehme- weihs dot de GCC build triplet: powerpc-ibm-aix4.3.3.0 GCC host triplet: powerpc-ibm-aix4.3.3.0 GCC target triplet: powerpc-ibm-aix4.3.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19824
[Bug preprocessor/19801] [4.0 Regression] cppinternals.texi references old file names
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-08 15:09 --- Subject: Bug 19801 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-08 15:08:53 Modified files: gcc/doc: cppinternals.texi gcc: ChangeLog Log message: 2005-02-08 Paolo Bonzini <[EMAIL PROTECTED]> PR preprocessor/19801 * doc/cppinternals.texi (Conventions, Lexer, Files): Adjust filenames that changed when libcpp was moved to the toplevel. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/cppinternals.texi.diff?cvsroot=gcc&r1=1.20&r2=1.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7417&r2=2.7418 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19801
[Bug preprocessor/19801] [4.0 Regression] cppinternals.texi references old file names
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-08 15:09 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19801
[Bug preprocessor/19801] [4.0 Regression] cppinternals.texi references old file names
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19801
[Bug other/19082] [4.0 Regression] build/genattrtab: out of memory allocating 151568 bytes after a total of 4161651196 bytes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 15:13 --- *** Bug 19824 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hundertmarck at boehme-weihs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19082
[Bug bootstrap/19824] genattrtab allocates over 4GB memory and fails!
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 15:13 --- This is one, see PR 19082. You have to change your limits. *** This bug has been marked as a duplicate of 19082 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19824
[Bug target/19806] [4.0 regression] cris-axis-elf testsuite failure: gcc.c-torture/execute/20001130-1.c compilation, -O0
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-08 15:35 --- Subject: Bug 19806 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-08 15:35:12 Modified files: gcc: ChangeLog gcc/config/cris: cris-protos.h cris.c cris.h Log message: PR target/19806 * config/cris/cris.c (in_code): New variable. (cris_output_addr_const): Now a static function, a wrapper for output_addr_const. (cris_asm_output_symbol_ref): New function, broken out SYMBOL_REF case from old cris_output_addr_const. (cris_asm_output_label_ref): Similar for LABEL_REF. (cris_output_addr_const_extra): Similar for UNSPEC. * config/cris/cris.h (OUTPUT_ADDR_CONST_EXTRA) (ASM_OUTPUT_SYMBOL_REF, ASM_OUTPUT_LABEL_REF): Define. * config/cris/cris-protos.h (cris_output_addr_const): Remove declaration. (cris_asm_output_symbol_ref, cris_output_addr_const_extra) (cris_asm_output_label_ref): Declare. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7418&r2=2.7419 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris-protos.h.diff?cvsroot=gcc&r1=1.13&r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris.c.diff?cvsroot=gcc&r1=1.62&r2=1.63 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris.h.diff?cvsroot=gcc&r1=1.83&r2=1.84 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19806
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 15:36 --- (In reply to comment #34) > Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and > see if you find out something. Still the same four failures with #! /bin/sh for a in \ verbose-asm \ cprop-registers defer-pop \ guess-branch-probability if-conversion if-conversion2 \ loop-optimize \ loop-optimize2 merge-constants omit-frame-pointer \ split-ivs-in-unroller trapping-math \ tree-ccp tree-ch tree-copyrename tree-dce tree-dominator-opts \ tree-dse tree-fre tree-loop-im tree-loop-ivcanon \ tree-loop-optimize tree-lrs tree-sra tree-ter do echo $a rm *.o gfortran -c -g -O1 -fno-$a ../*.f \ && gfortran -c -g -O0 ../dlasy2.f \ && gfortran -g *.o -o xeigtstd \ && xeigtstd < ded.in > $a.out done The separate compilation of dlasy2.f is to get around the segfault in PR 18977. Any important optimization options that I've missed? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug target/19806] [4.0 regression] cris-axis-elf testsuite failure: gcc.c-torture/execute/20001130-1.c compilation, -O0
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-08 16:04 --- See http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00306.html>. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19806
[Bug target/19745] meta: cris-elf gcc, g++, objc testsuite failures as of "Tue Feb 1 22:03:59 UTC 2005"
-- Bug 19745 depends on bug 19806, which changed state. Bug 19806 Summary: [4.0 regression] cris-axis-elf testsuite failure: gcc.c-torture/execute/20001130-1.c compilation, -O0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19806 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
[Bug target/19133] march=athlon can produce slower code than march=i686
--- Additional Comments From ornati at fastwebnet dot it 2005-02-08 16:13 --- gcc -v Using built-in specs. Configured with: /var/tmp/portage/gcc-4.0.0_alpha20050130/work/gcc-4.0-20050130/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.0.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.0 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.0/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.0.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.0.0/include/g++-v4 --host=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-shared --enable-threads=posix --disable-multilib --disable-libgcj --enable-languages=c,c++ Thread model: posix gcc version 4.0.0 alpha20050130 (Gentoo Linux 4.0.0_alpha20050130) [EMAIL PROTECTED] gcc_test $ time ./test-i686 real0m8.539s user0m8.376s sys 0m0.001s [EMAIL PROTECTED] gcc_test $ time ./test-athlon real0m6.168s user0m6.031s sys 0m0.005s As the numbers show, the problem go away for "-march=athlon"... but now "-march=i686" version is MUCH slower than before (with GCC 3.3.x). Seems like I've found a very strange test-case... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19133
[Bug driver/19825] New: -fno-loop-optimize2 does not work
Apparently, the compiler likes -floop-optimize2 very much and does not want it to be switched off: $ gcc -O1 -fno-loop-optimize -fno-loop-optimize2 -S -fverbose-asm example.c $ cat example.s .file "example.c" .pred.safe_across_calls p1-p5,p16-p63 // GNU C version 4.0.0 20050130 (experimental) (ia64-unknown-linux-gnu) // compiled by GNU C version 4.0.0 20050130 (experimental). // GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 // options passed: -auxbase -O1 -fno-loop-optimize -fno-loop-optimize2 // -fverbose-asm // options enabled: -falign-loops -fargument-alias -fbranch-count-reg // -fcommon -fcprop-registers -fdefer-pop -feliminate-unused-debug-types // -ffunction-cse -fgcse-lm -fguess-branch-probability -fident // -fif-conversion -fif-conversion2 -fivopts -fkeep-static-consts // -fleading-underscore -floop-optimize2 -fmath-errno -fmerge-constants // -fomit-frame-pointer -fpeephole -freg-struct-return -fsched-interblock // -fsched-spec -fsched-stalled-insns-dep -fsplit-ivs-in-unroller // -ftrapping-math -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce // -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im // -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-sra // -ftree-ter -funwind-tables -fverbose-asm -fzero-initialized-in-bss // -mgnu-as -mgnu-ld -minline-float-divide-max-throughput -mdwarf2-asm // -mtune=itanium2 .text .align 16 .global main# .proc main# main: .prologue .body mov r8 = r0 // , br.ret.sptk.many b0 // ;; .endp main# .ident "GCC: (GNU) 4.0.0 20050130 (experimental)" $ gcc -dumpmachine ia64-unknown-linux-gnu -- Summary: -fno-loop-optimize2 does not work Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug AWT/17952] Windows don't show with window manager that supports _NET_REQUEST_FRAME_EXTENTS
--- Additional Comments From fitzsim at redhat dot com 2005-02-08 16:30 --- Fixed on java-gui-branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17952
[Bug driver/19825] -fno-loop-optimize2 does not work
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 16:36 --- This blocks testing of compiler options in PR 5900. -- What|Removed |Added OtherBugsDependingO||5900 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 16:36 --- I am not sure which of my tests of compiler options were actually testing anything. There appears to be a bug in passing at least one -fno - switch (see PR 19825). Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug tree-optimization/18687] [4.0 Regression] ~50% compile time regression
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-02-08 16:43 --- Patch (improving ivopts performance on the testcase by some 40%): http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00307.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug c++/19826] New: More array bounds rejected as non-constant in template...
This one *may* be related to c++/18470 but does *not* involve using... FWIW,
Icc accepts it, same for 3.4.3. Maybe a regression, fall out of recent work
in close areas... ?!?
template
class basic_string
{
typedef typename _Alloc::size_type size_type;
static const size_type _S_max_local = 16;
char _M_data[_S_max_local];
};
--
Summary: More array bounds rejected as non-constant in
template...
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,mmitchel at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19826
[Bug c++/19826] More array bounds rejected as non-constant in template...
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-08
16:56 ---
Even shorter example:
template struct A
{
static const T i = 1;
char a[i];
};
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19826
[Bug c++/19826] [4.0 Regression] More array bounds rejected as non-constant in template...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 17:09 --- This is at least a 4.0 regression and it looks like it is going to effect libstdc++ also which is really bad. -- What|Removed |Added Severity|normal |critical Keywords||rejects-valid Priority|P2 |P1 Summary|More array bounds rejected |[4.0 Regression] More array |as non-constant in |bounds rejected as non- |template... |constant in template... Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19826
[Bug c++/19826] [4.0 Regression] More array bounds rejected as non-constant in template...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 17:10 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-08 17:10:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19826
[Bug target/19745] [meta-bug]: cris-elf gcc, g++, objc testsuite failures as of "Tue Feb 1 22:03:59 UTC 2005"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 17:16 --- XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times link_error 0 is xfailed because it fails on most targets (except for ppc, and a couple of others). FAIL: gcc.dg/tree-ssa/loop-1.c scan-assembler-times foo 5 could be just the way calls are done on cris (there are examples of other targets fail in the test and how to fix this one). FAIL: gcc.c-torture/execute/920501-8.c execution, -O0 Means var_arg does not work correctly or sprintf is not working as we expected it to. -- What|Removed |Added Summary|meta: cris-elf gcc, g++,|[meta-bug]: cris-elf gcc, |objc testsuite failures as |g++, objc testsuite failures |of "Tue Feb 1 22:03:59 UTC |as of "Tue Feb 1 22:03:59 |2005" |UTC 2005" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 17:26 --- Shouldn't the warning killer for system header errors apply to this sort of thing? Apparently it doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug driver/19825] -fno-loop-optimize2 does not work
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 17:33 --- There is a section in the source which does this: /* Enable new loop optimizer pass if any of its optimizations is called. */ if (flag_move_loop_invariants || flag_unswitch_loops || flag_peel_loops || flag_unroll_loops || flag_branch_on_count_reg) flag_loop_optimize2 = 1; And -fbranch-count-reg is always enabled. The documention says: -floop-optimize2 Perform loop optimizations using the new loop optimizer. The optimizations (loop unrolling, peeling and unswitching, loop invariant motion) are enabled by separate flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug driver/19825] -fno-loop-optimize2 does not work
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 17:34 --- In fact the only thing which -floop-optimize2 does without enabling something else at -O1 is to enable -fbranch-count-reg which has no effect on ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:30 --- >Is a fix likely to get into 4.0? Yes, the hackish fix is in. I hope to get the cleaner fix in, but who knows. >FYI Once I am able to build, the next issue is that the Ada libraries >do not look into newlib's headers and do not have a way to let a >target add specific include directories. See gcc/config/t-rtems for >the OS specific newlib include directory we need. With that resolved, >I think it could build in a single pass. I wouldn't want to touch this until substantially more of the branch went in, so that's probably a 4.1 issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug tree-optimization/19827] New: Missed pure/const optimization
The following two function should produce the same asm because we can skip the
second call to f:
int f(void) __attribute__((const,pure));
int g(int i, int j)
{
int k = 0;
if(i)
k = f();
if (j)
k = f();
return k;
}
int h(int i, int j)
{
int k = 0;
if(i)
k = f();
else if (j)
k = f();
return k;
}
--
Summary: Missed pure/const optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19827
[Bug preprocessor/19821] Preprocessor oom with nested vector operations
--- Additional Comments From pochini at shiny dot it 2005-02-08 18:48 --- Sorry for the noise, I didn't find #19411 while browsing the database. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19821
[Bug bootstrap/19420] make install fails if not preceded by make all
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:51 --- This has never worked. It is recommended by the GNU coding standards, but it also requires truly substantial work to get right without forcing rebuilds if 'make all' is followed by 'make install'. Reducing priority and severity. -- What|Removed |Added Severity|normal |enhancement Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19420
[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:53 --- I have considered doing this in the truly parallel way: namely, introducing HOST_SUBDIR to go along with BUILD_SUBDIR and TARGET_SUBDIR. It requires mangling of '..'s in many subdirectories, which is why I haven't done it. But if it's done it allows some genuine, major simplifications. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17383
[Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining??
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:58 --- Isn't this most likely to be an out-of-memory issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
[Bug tree-optimization/19828] New: [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
Take the following program, it should run and work correct and not call abort
but with -O1/-O2 on the
mainline we call abort because LIM pulls out the call to f of the loop but
should not because f1 can
modify the global memory (and does). If I uncomment the store to the global
memory in the function
containing the loop we get the correct code as LIM sees that the call to f has
a VUSE and call to f1 has a
V_MAY_DEF.
int f(void) __attribute__((pure));
int lll;
int f() { return lll; }
int f1() { lll++; return lll % 2;}
int g(void)
{
int k, l;
k=0;
//lll = 0;
for(l =0;l<10;l++)
if (f1 ())
k = f();
return k;
}
void abort ();
int main(void)
{
if (g() != 9)
abort ();
}
--
Summary: [4.0 Regression] LIM is pulling out a pure function even
though there is something which can modify global memory
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: dnovillo at gcc dot gnu dot org,drow at gcc dot gnu dot
org,gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
-- What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Additional Comments From joseph at codesourcery dot com 2005-02-08 19:07 --- Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL constants On Tue, 8 Feb 2005, neroden at gcc dot gnu dot org wrote: > Shouldn't the warning killer for system header errors apply to this sort of > thing? Apparently it doesn't. The problem is that macros are defined in system headers and expanded outside them. Getting the system header treatment to apply to macros defined in system headers so that #define _Complex_I 1.0iF or #define INTMAX_C(c) c ## LL can be defined in system headers, and then expanded in user source files without -pedantic diagnostics, would suffice. (Both cases are relevant, the former for , the latter for if used in C90 mode.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug tree-optimization/18178] Missed opportunity for removing bounds checking
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-13 02:03:16 |2005-02-08 19:15:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-08 19:16 --- Subject: Re: gnat tools not buildable cross neroden at gcc dot gnu dot org wrote: > --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 > 18:30 --- > >>Is a fix likely to get into 4.0? > > Yes, the hackish fix is in. I hope to get the cleaner fix in, but who knows. > > >>FYI Once I am able to build, the next issue is that the Ada libraries >>do not look into newlib's headers and do not have a way to let a >>target add specific include directories. See gcc/config/t-rtems for >>the OS specific newlib include directory we need. With that resolved, >>I think it could build in a single pass. > > I wouldn't want to touch this until substantially more of the branch went in, > so that's probably a 4.1 issue. I need to get to test this first but I think the mistake in the gcc/ada/Makefile.in is actually quite simple. It has this: GNATLIBCFLAGS_FOR_C = $(GNATLIBCFLAGS) $(TARGET_LIBGCC2_CFLAGS) -fexceptions \ -DIN_RTS $(TARGET_LIBGCC2_CFLAGS) is not sufficient to find all the newlib headers. But the gcc/Makefile.in also uses $(LIBGCC2_INCLUDES) which is target specific when compiling libgcc2. LIBGCC2_INCLUDES is primarily set by RTEMS, VxWorks, and Cygwin. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug c++/19826] [4.0 Regression] More array bounds rejected as non-constant in template...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 19:21 --- : Search converges between 2004-11-12-161002-trunk (#631) and 2004-11-13-014001-trunk (#632). Mark, I suspect your patch for PR 18429 is responsible for the regression. Could you please have a look? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19826
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-08 19:25 --- I don't think this is a libffi problem. gcj allocates trampolines on the heap, not the stack. I think this is a multilib problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-08 19:27
---
Here's another related testcase. If you uncomment the store to global_int,
LIM will move only func_const out of the loop. With them both commented
out, however, the pure call gets moved out of the loop. func_other may
modify global memory, though, so the pure call can not be moved.
int func_pure (void) __attribute__ ((pure));
int func_const (void) __attribute__ ((const));
void func_other (int);
int global_int;
int
func_loop (int arg)
{
while (arg--)
{
// global_int = arg;
func_other (func_pure ());
}
}
int
func_loop_2 (int arg)
{
while (arg--)
{
// global_int = arg;
func_other (func_const ());
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-08 19:36
---
Here's another one. This may be a different bug. Suppose we have two pure
functions, one which checks whether a library is present and one which fetches
some piece of data from the library. Code looks like this:
int
func_loop_3 (int arg)
{
int var = 0;
while (arg--)
{
if (func_pure ())
var = func_pure_2 ();
}
return var;
}
LIM will move _both_ pure calls out of the loop. I think that it is valid
for a pure call to segfault in a condition when it would not normally have
been called; if the implementation of func_pure always returns zero, I don't
think that func_pure_2 should ever be called in the above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug regression/19829] New: [4.0 regression] cris-elf testsuite failure: 21_strings/basic_string/find/char/3.cc execution test
Between LAST_UPDATED: Mon Feb 7 13:27:26 UTC 2005 and Tue Feb 8 17:55:17 UTC 2005 the following regression was introduced for cris-axis-elf: FAIL: 21_strings/basic_string/find/char/3.cc execution test The message in libstdc++.log is: PASS: 21_strings/basic_string/find/char/3.cc (test for excess errors) assertion "csz01 == 8" failed: file "/home/hp/cvs_areas/combined/combined/libstdc++-v3/testsuite/21_strings/basic_string/find/char/3.cc", line 67^M program stopped with signal 6.^M FAIL: 21_strings/basic_string/find/char/3.cc execution test -- Summary: [4.0 regression] cris-elf testsuite failure: 21_strings/basic_string/find/char/3.cc execution test Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19829
[Bug c++/19826] [4.0 Regression] More array bounds rejected as non-constant in template...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
19:50 ---
Is the problem here (in sematics.c):
/* Since this name was dependent, the expression isn't
constant -- yet. No error is issued because it might be
constant when things are instantiated. */
if (integral_constant_expression_p)
*non_integral_constant_expression_p = true;
Can someone help me if this really should be false because that fixes both this
bug and PR 18470.
With that change we still reject the following testcase:
template struct A
{
static const T i = 1;
char a[i];
};
A a;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19826
[Bug regression/19813] [4.0 Regression] gcc 4.0 regression: bad code generation?? due to inlining??
--- Additional Comments From bangerth at dealii dot org 2005-02-08 19:58 --- I can confirm this: tmp/xxx> c++ x.cc tmp/xxx> ./a.out tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=604 tmp/xxx> ./a.out Segmentation fault tmp/xxx> c++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --enable-languages=c,c++ --prefix=/ticam/bangerth/tmp/build-gcc/gcc-install --enable-checking Thread model: posix gcc version 4.0.0 20050203 (experimental) I'll try to find a shorter testcase. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
20:02 ---
(In reply to comment #2)
> Here's another one. This may be a different bug.
Yes that is a different (but related) bug. The problem is now, what is
definition of pure functions (for
that testcase).
Take the following:
int *a;
int *func_pure () __attribute__((pure));
int func_pure_2 () __attribute__((pure));
int *func_pure() { return a; }
int func_pure_2() { return *a;}
int i;
int
func_loop_3 (int arg)
{
int var = 0;
i = 1;
while (arg--)
{
if (func_pure ())
var = func_pure_2 ();
}
return var;
}
void abort (void);
int main()
{
int i;
i = func_loop_3 (10);
if (i)
abort ();
}
Is func_pure_2 really pure and if it is, then we should change it so we can
trap on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit
--- Additional Comments From bangerth at dealii dot org 2005-02-08 20:13
---
This is somewhat shorter, though maybe not much:
#include
#include
struct ltstr {
bool operator()(const char* s1, const char* s2) const
{ return strcmp(s1, s2) < 0; }
};
int main(){
char* tab_tmp[2] = { "1", "2"};
const static std::set
codon_table1 (tab_tmp, tab_tmp+2);
*codon_table1.find("1");
}
---
tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=603 && ./a.out
tmp/xxx> c++ x.cc -O2 -finline-functions -finline-limit=604 && ./a.out
Segmentation fault
W.
--
What|Removed |Added
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||4.0.0
Last reconfirmed|-00-00 00:00:00 |2005-02-08 20:13:47
date||
Summary|[4.0 Regression] gcc 4.0|[4.0 Regression] wrong code
|regression: bad code|with -finline-limit
|generation?? due to |
|inlining?? |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From snyder at fnal dot gov 2005-02-08 20:18
---
(In reply to comment #24)
> (In reply to comment #23)
> > This does not seem to be fixed so reopening.
> I opened another PR because it is related but not fully the same problem. (PR
19699).
We still (as of CVS from Feb 8) get the warning if the throw-specifier is
not empty.
This example still gives the warning with -Wall -O1:
struct E{};
inline int bar() throw(E)
{
return 0;
}
void foo ()
{
bar();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug target/19806] [4.0 regression] cris-axis-elf testsuite failure: gcc.c-torture/execute/20001130-1.c compilation, -O0
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-08 21:05 --- Judging from the similarity of the frv-elf test-results and a brief look at frv_print_operand_address, it has the same flaw as was fixed in this PR; making sure there's a call to mark_decl_referenced for SYMBOL_REF output. (See frv_print_operand_address.) FRV maintainers complimentary CC:ed. -- What|Removed |Added CC||aoliva at gcc dot gnu dot ||org, aldyh at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19806
[Bug tree-optimization/18178] Missed opportunity for removing bounds checking
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 21:07 --- We have this hunk in the .vrp dump: # BLOCK 1 # PRED: 4 (true,exec) :; iD.1901_30 = iD.1901_1; D.1909_31 = D.1909_4; i.0D.1911_5 = (unsigned intD.6) iD.1901_30; D.1909_6 = D.1909_31; D.1912_7 = (unsigned intD.6) D.1909_6; if (i.0D.1911_5 >= D.1912_7) goto ; else goto ; # SUCC: 2 (true,exec) 3 (false,exec) # BLOCK 2 # PRED: 1 (true,exec) :; # TMT.3D.1926_25 = V_MAY_DEF ; # TMT.2D.1925_26 = V_MAY_DEF ; # VUSE <_ZTIiD.1905_14>; D.1904_16 = __cxa_allocate_exception (4); D.1914_18 = (intD.2 *) D.1904_16; # TMT.3D.1926_27 = V_MAY_DEF ; *D.1914_18 = 5; D.1914_2 = D.1914_18; # VUSE <_ZTIiD.1905_14>; # VUSE ; # VUSE ; __cxa_throw (D.1904_16, &_ZTIiD.1905, 0B); # SUCC: # BLOCK 3 # PRED: 1 (false,exec) :; and: i.0_5: VARYING D.1909_6: [-2147483648, i_30 - 1] D.1912_7: VARYING If WORK_WORK_WORK is defined, we have: # BLOCK 1 # PRED: 4 (true,exec) :; iD.1901_30 = iD.1901_1; D.1909_31 = D.1909_4; D.1909_5 = D.1909_31; if (iD.1901_30 >= D.1909_5) goto ; else goto ; # SUCC: 2 (true,exec) 3 (false,exec) # BLOCK 2 # PRED: 1 (true,exec) :; # TMT.2D.1925_24 = V_MAY_DEF ; # TMT.1D.1924_25 = V_MAY_DEF ; # VUSE <_ZTIiD.1905_13>; D.1904_15 = __cxa_allocate_exception (4); D.1912_17 = (intD.2 *) D.1904_15; # TMT.2D.1925_26 = V_MAY_DEF ; *D.1912_17 = 5; D.1912_2 = D.1912_17; # VUSE <_ZTIiD.1905_13>; # VUSE ; # VUSE ; __cxa_throw (D.1904_15, &_ZTIiD.1905, 0B); # SUCC: # BLOCK 3 # PRED: 1 (false,exec) :; and i_30: [0, D.1909_4 - 1] D.1909_5: [0, i_30 - 1] Note that even though (i_30 >= D.1909_5), VRP does not clean this up. The exception stays there until DOM1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178
[Bug target/19745] [meta-bug]: cris-elf gcc, g++, objc testsuite failures as of "Tue Feb 1 22:03:59 UTC 2005"
-- What|Removed |Added BugsThisDependsOn||19830 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
[Bug target/19830] New: cris-elf testsuite failure: gcc.c-torture/execute/920501-8.c execute tests.
Regarding gcc.c-torture/execute/920501-8.c, there's an extra "0" in the "1.00" part. Comparing to results for other targets (mmix, frv), it seems the core sprintf function is miscompiled! -- Summary: cris-elf testsuite failure: gcc.c- torture/execute/920501-8.c execute tests. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: cris-elf OtherBugsDependingO 19745 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19830
[Bug tree-optimization/19831] New: Missing DSE/malloc/free optimization
The following function really should be compiled to an empty function (DSE
should first remove the
store and then free of a malloc with no change inbetween and we should remove
both calls).
void *malloc(__SIZE_TYPE__);
void free(void*);
int f(void)
{
char *i = malloc(1);
*i = 1;
free (i);
}
This is something which is useful when we want to much higer level
optimizations.
--
Summary: Missing DSE/malloc/free optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
[Bug target/19745] [meta-bug]: cris-elf gcc, g++, objc testsuite failures as of "Tue Feb 1 22:03:59 UTC 2005"
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
21:45 ---
WARNING: gcc.dg/20010912-1.c compilation failed to produce executable
as the following is in the testcase:
/* { dg-warning "not supported" "PIC unsupported" { target cris-*-elf*
cris-*-aout* mmix-*-* } 0 } */
FAIL: gcc.dg/20020430-1.c (test for excess errors)
FAIL: gcc.dg/20021018-1.c (test for excess errors)
FAIL: gcc.dg/20021023-1.c (test for excess errors)
FAIL: gcc.dg/20021029-1.c (test for excess errors)
FAIL: gcc.dg/20030702-1.c (test for excess errors)
FAIL: gcc.dg/20030708-1.c (test for excess errors)
uses -fpic just like gcc.dg/20010912-1.c
I am starting to think there should be a require-pic in the testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
[Bug fortran/19479] UBOUND causes ICE
--- Additional Comments From craig dot powers at gmail dot com 2005-02-08 21:53 --- Further testing indicates that the bug is caused by an array in a derived type -- the pointer is not necessary. program test implicit none type test_type integer, dimension(5) :: a end type test_type type (test_type) :: tt integer i i = ubound(tt%a) end program test In this case, as originally takes on a non-null value (I presume because the type member is now an array rather than a pointer), but in the component walk, it is set to NULL via ref->u.c.sym->as. I think this may be instructive about the precise nature of the bug as originally reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19479
[Bug c/19832] New: Missed optimisation
According to Andrew Pinski , the following patch is useless because gcc should be able to find the optimisation by itself. Description : function preferable in cse.c can be simplified if we notice that, at the end of the function : if (regcost_a != regcost_b) return regcost_a - regcost_b; return 0; So, if regcost_a == regcost_b, we return 0, but in this case (regcost_a - regcost_b) is also = 0. There is no need for the test, and (return regcost_a - regcost_b;) wins in all cases. This patch remove 3 572 566 useless tests (if regcost_a != regcost_b) when doing a full bootstrap. Bootstrap on a cygwin machine based on snapshot from 20050130. 2005-02-08 Christophe Jaillet <[EMAIL PROTECTED]> * cse.c (preferable): simplify last test to speed up *** gcc-4.0-20050130/gcc/cse.c Tue Feb 8 23:39:30 2005 --- my_patch/cse.c Tue Feb 8 23:55:02 2005 *** preferable (int cost_a, int regcost_a, i *** 836,845 /* Normal operation costs take precedence. */ if (cost_a != cost_b) return cost_a - cost_b; /* Only if these are identical consider effects on register pressure. */ ! if (regcost_a != regcost_b) ! return regcost_a - regcost_b; ! return 0; } /* Internal function, to compute cost when X is not a register; called --- 836,844 /* Normal operation costs take precedence. */ if (cost_a != cost_b) return cost_a - cost_b; + /* Only if these are identical consider effects on register pressure. */ ! return regcost_a - regcost_b; } /* Internal function, to compute cost when X is not a register; called -- Summary: Missed optimisation Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe dot jaillet at wanadoo dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08
23:34 ---
Confirmed, here is the full testcase by the way:
int f(int i, int j)
{
if (i!=j)
return i - j;
return 0;
}
Note I did not say the patch is useless but I just wantted to say that it would
be useful if gcc did this for
us instead of changing the code. Anyways this can be done with PHI-OPT, I will
try to look into this
doing this for 4.1. Your patch should be still considered.
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed||1
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2005-02-08 23:34:07
date||
Summary|Missed optimisation |don't remove an if when we
||know the value is the same
||as with the if (subtraction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832
[Bug tree-optimization/19833] New: bogus uninitialized variable warning for powerpc64
Test gcc.dg/uninit-4.c has failed on powerpc64-unknown-linux-gnu with -m64
since 2004-12-17 for a bogus uninitialized variable warning. No other target
for which test results have been reported for the last few days gets this
failure. The change is with this patch:
2004-12-17 Diego Novillo <[EMAIL PROTECTED]>
tree-optimization/18501
* tree-optimize.c (init_tree_optimization_passes): Run
pass_late_warn_uninitialized before the last DCE run.
The following testsuite changes were made at the same time:
2004-12-17 Diego Novillo <[EMAIL PROTECTED]>
* gcc.dg/pr18501.c: New test.
* gcc.dg/uninit-5.c: XFAIL.
* gcc.dg/uninit-9.c: XFAIL.
This is probably low priority, but I wanted a PR to reference when I mark
uninit-4.c XFAIL for { powerpc64*-*-* && lp64 }. (The new XFAILs for the
other tests don't have such references to PRs.)
--
Summary: bogus uninitialized variable warning for powerpc64
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19833
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 23:52 --- Jakub, so why not get your patch of comment #11 in first, and worry about the, as you say yourself, unrelated bugs later? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug tree-optimization/19833] bogus uninitialized variable warning for powerpc64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-08 23:57 --- It also fails on powerpc-darwin with -m64 too. So maybe xfailing it for powerpc*-*-* && lp64 would be a better idea. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|powerpc64-unknown-linux-gnu |powerpc64-*-* Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-02-08 23:57:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19833
[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 00:48 --- (In reply to comment #5) > This is somewhat shorter, though maybe not much: Does -fno-strict-aliasing make this compile and run correctly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
[Bug regression/19813] [4.0 Regression] wrong code with -finline-limit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 00:51 --- (In reply to comment #6) > (In reply to comment #5) > > This is somewhat shorter, though maybe not much: > > Does -fno-strict-aliasing make this compile and run correctly? Because if it does then this is not tree optimization problem because the tree dumps look the same with and without -fno-strict-aliasing. This would then either be a RTL, a C++ or a libstdc++ problem, I don't know which yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
[Bug target/19799] sibcall-3.c and sibcall-4.c fail on hppa64-*-hpux*
--- Additional Comments From danglin at gcc dot gnu dot org 2005-02-09 01:22 --- The stub placement issues in GNU ld still haven't been fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19799
[Bug target/19799] sibcall-3.c and sibcall-4.c fail on hppa64-*-hpux*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-09 01:44 --- Subject: Bug 19799 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-09 01:43:51 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg: sibcall-3.c sibcall-4.c Log message: PR target/19799 * gcc.dg/sibcall-3.c, gcc.dg/sibcall-4.c: XFAIL on hppa*64*-*. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5002&r2=1.5003 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/sibcall-3.c.diff?cvsroot=gcc&r1=1.9&r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/sibcall-4.c.diff?cvsroot=gcc&r1=1.9&r2=1.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19799
[Bug c++/19733] [3.4/4.0 regression] ICE on invalid destructor call
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-09 02:21 --- Subject: Bug 19733 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-09 02:21:36 Modified files: gcc/cp : ChangeLog cvt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: crash23.C Log message: PR c++/19733 * cvt.c (convert_to_void): Issue errors about pseudo-destructor expressions. PR c++/19733 * g++.dg/parse/crash23.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.194&r2=1.3892.2.195 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.151.4.2&r2=1.151.4.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.356&r2=1.3389.2.357 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/crash23.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19733
