[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures

--- Comment #10 from dominiq at lps dot ens dot fr 2008-12-07 10:35 --- > Those 3 still aren't fixed: > > FAIL: gcc.dg/vect/vect-67.c scan-tree-dump-times vect "vectorized 1 loops" 1 see pr37853#2 for the output of -ftree-vectorizer-verbose=6. > FAIL: gcc.dg/vect/no-scevccp-outer-13.c

[Bug rtl-optimization/38434] New: [4.4 Regression] speed regression with hand-unrolled matmul

$ gfortran-4.3 -O3 -funroll-all-loops -ffast-math foo-2.f90 $ ./a.out subroutine with explicit interface and unroll(1):2.3321450 s $ gfortran -O3 -funroll-all-loops -ffast-math foo-2.f90 $ ./a.out subroutine with explicit interface and unroll(1):3.0121880 s $ gfortran -v Using b

[Bug rtl-optimization/38434] [4.4 Regression] speed regression with hand-unrolled matmul

--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-07 11:34 --- I forgot: $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2600+ stepping: 1 cpu MHz : 2083.200 cache

[Bug rtl-optimization/38434] [4.4 Regression] speed regression with hand-unrolled matmul

--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-12-07 11:55 --- On x86_64: With 4.3.3: $ ./a.out subroutine with explicit interface and unroll(1):1.5400960 s With 4.4.0: $ ./a.out subroutine with explicit interface and unroll(1):1.5480961 s Probably targe

[Bug middle-end/23401] Gimplifier produces too many temporaries

--- Comment #7 from rguenth at gcc dot gnu dot org 2008-12-07 12:03 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned

[Bug tree-optimization/27810] inefficient gimplification of function calls

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-07 12:07 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned

[Bug tree-optimization/27798] gimplifying "return CONSTANT" creates unneeded temporaties

--- Comment #7 from rguenth at gcc dot gnu dot org 2008-12-07 12:13 --- Note that I think it is good that we always have a return decl. So this PR is IMHO invalid (or at least we wont fix it for a reason). There is PR27800 which is IMHO valid. -- rguenth at gcc dot gnu dot org chan

[Bug tree-optimization/33237] [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.

--- Comment #16 from rguenth at gcc dot gnu dot org 2008-12-07 12:22 --- In 4.5 all the memory partitioning code will be gone (hopefully). Have a look into the alias-improvements branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237

[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite

--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-07 12:25 --- *** This bug has been marked as a duplicate of 36792 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures

--- Comment #11 from rguenth at gcc dot gnu dot org 2008-12-07 12:25 --- *** Bug 37853 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug rtl-optimization/38434] [4.4 Regression] speed regression with hand-unrolled matmul

--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-07 12:40 --- There is one thing that is on my list to investigate. This is how the following impacts hardware prefetchers: : pretmp.34_33 = (*b_13(D))[6]; pretmp.34_62 = (*b_13(D))[7]; pretmp.34_88 = (*b_13(D))[8]; pret

[Bug tree-optimization/33928] [4.3/4.4 Regression] 22% performance slowdown from 4.2.2 to 4.3/4.4.0 in floating-point code

--- Comment #41 from rguenth at gcc dot gnu dot org 2008-12-07 13:00 --- There's not much to be done for aliasing - everything points to global memory and thus aliases. There may be some opportunities for offset-based disambiguations via pointers, but I didn't investigate in detail. W

[Bug rtl-optimization/38434] [4.4 Regression] speed regression with hand-unrolled matmul

--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-12-07 12:25 --- I'll upgrade to current trunk and run another test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38434

[Bug tree-optimization/27809] inefficient gimplification of globals

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-07 12:08 --- I agree. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug tree-optimization/33237] [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.

--- Comment #15 from steven at gcc dot gnu dot org 2008-12-07 11:55 --- Diego, in comment #7 you said you will work on this... So? Have you worked on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237

[Bug c/38435] New: bug or no bug ?!

It is following little loop: - #include #include int m,a,n; /* m and n are reserved for later; a is for counting */ int main(void) { for (a=0;a<=32;a++) { man=true; } return(0); } -- Now, the thing is, this loop is wrong, bec

[Bug c/38435] bug or no bug ?!

--- Comment #1 from steven at gcc dot gnu dot org 2008-12-07 15:28 --- Learn C, then try again. -- steven at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/38410] g++.dg/eh/crossjump1.C (internal compiler error)

--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-07 16:01 --- Confirmed. This is a regression (it should appear in the subject otherwise it would be missed). The batch of failures is: FAIL: g++.dg/eh/crossjump1.C (internal compiler error) FAIL: g++.dg/eh/crossjump1.C (test for

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #7 from hjl dot tools at gmail dot com 2008-12-07 16:17 --- This bug disappeared between revision 142341 and revision 142508. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405

[Bug fortran/32626] Run-time check for recursive functions

--- Comment #2 from domob at gcc dot gnu dot org 2008-12-07 16:17 --- Unassigning myself, Tobias has a working patch posted for 4.5. -- domob at gcc dot gnu dot org changed: What|Removed |Added --

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #8 from rguenth at gcc dot gnu dot org 2008-12-07 16:29 --- Maybe it's just gone latent ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #9 from hjl at gcc dot gnu dot org 2008-12-07 16:44 --- Subject: Bug 38405 Author: hjl Date: Sun Dec 7 16:43:15 2008 New Revision: 142538 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142538 Log: 2008-12-07 H.J. Lu <[EMAIL PROTECTED]> PR tree-optimizatio

[Bug fortran/37423] Fortran 2003: DEFERRED bindings not yet implemented

--- Comment #1 from domob at gcc dot gnu dot org 2008-12-07 17:12 --- A proposed patch for 4.5 can be found at: http://gcc.gnu.org/ml/fortran/2008-12/msg00109.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37423

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #10 from hjl dot tools at gmail dot com 2008-12-07 17:17 --- It is fixed by revision 142483: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00341.html -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #11 from hjl dot tools at gmail dot com 2008-12-07 17:39 --- Oops. It is revision 142484: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00340.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405

[Bug fortran/38137] MERGE: -fbounds-check runtime check for same string length

-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #12 from rguenth at gcc dot gnu dot org 2008-12-07 18:52 --- We now get D.1254 = BIT_FIELD_REF <*rfp, 8, 0>; D.1255 = D.1254 & 1; D.1253 = D.1255 != 0; which causes missed optimizations. Jakub - can you disable the bit-field-ref folding for single tests like this?

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #13 from rguenth at gcc dot gnu dot org 2008-12-07 19:20 --- It's not fixed. Jakub just made it latent. I am testing a real fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug libgomp/38436] New: libgomp does not respect --disable-werror

the --disable-werror flag is very useful for distributions and dealing with a myriad of build systems / versions / etc... unfortunately, libgomp doesnt respect this flag. from libgomp/configure.ac: # Add -Wall -Werror if we are using GCC. if test "x$GCC" = "xyes"; then XCFLAGS="$XCFLAGS -Wall -

[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files

--- Comment #6 from dfranke at gcc dot gnu dot org 2008-12-07 19:38 --- Since libcpp integration, default search paths (i.e. /usr/local/ etc.) are used for #include'd files. To add the default paths defined in gcc/cppdefault.c (cpp_include_defaults) to the module/INCLUDE search path, on

[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475

--- Comment #42 from lucier at math dot purdue dot edu 2008-12-07 19:39 --- Just a comment that -fforward-propagate isn't enabled at -O1 (the main optimization option in the test) while the cse code it replaces was enabled at -O1. This is presumably why adding -fno-forward-propagate to

[Bug fortran/38437] New: truncation error in endfile

Hello, I’ve got this problem… * endfile: truncation failed in endfile apparent state: unit 1 named fort.1 last format: list io lately writing direct formatted external IO * On the file fort.1 I first open it, then read, then close, then write, then close again…. But this happens randomly a

[Bug fortran/38437] truncation error in endfile

--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-12-07 20:20 --- The g77 compiler is no longer supported on any platform. Gfortran will compile the code and works on linux, so you can get a windows version of gfortran at http://gcc.gnu.org/wiki/GFortranBinaries and it should w

[Bug fortran/38437] truncation error in endfile

--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-07 20:21 --- g77 was removed from GCC more than 3.5 years ago and is no longer support. However, ask yourself does it make sense to "first open it, then read, then close, then write, then close again". Either re-open the file bef

[Bug target/35424] deallocate_local_thread-5.cc and deallocate_local_thread-7.cc fails on darwin

-- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfi

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #15 from rguenth at gcc dot gnu dot org 2008-12-07 20:34 --- Subject: Bug 38405 Author: rguenth Date: Sun Dec 7 20:33:07 2008 New Revision: 142539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142539 Log: 2008-12-07 Richard Guenther <[EMAIL PROTECTED]>

[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary

--- Comment #14 from rguenth at gcc dot gnu dot org 2008-12-07 20:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENE

[Bug testsuite/38165] g++.dg/pubtypes.C fails at -m32/-m64 on i686-apple-darwin9

-- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfi

[Bug libgcj/38438] New: build error in x86_64-unknown-linux-gnu/32/libjava

I have had this error for months now. When I try to build the current svn HEAD I get this compile error: make[5]: Entering directory `/home/leitner/tmp/gcc/build/x86_64-unknown-linux-gnu/32/libjava' /bin/sh ./libtool --tag=GCJ --mode=link /home/leitner/tmp/gcc/build/gcc/gcj -B/home/leitner/tmp/gc

[Bug target/38110] gcc.dg/pr30286.c fails on i686-apple-darwin9

-- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfi

[Bug target/34587] gcc.dg/initpri1.c fails on *-apple-darwin

--- Comment #10 from danglin at gcc dot gnu dot org 2008-12-07 21:18 --- g++.dg/special/initpri1.C also aborts in the same way: Starting program: /Users/dave/gnu/gcc/objdir/gcc/testsuite/g++/initpri1.xg Reading symbols for shared libraries +++. done Program received signal SIGABRT, A

[Bug fortran/38439] New: I/O PD edit descriptor inconsistency

Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/2fc107eda65d9065 The following code WRITE (*,'(1PD24.15E4)') 1.0d0 end is rejected in gfortran 4.2 to 4.4 with: Error: Period required in format specifier at (1) (and ifort, NAG f95 and g95 also reject it)

[Bug rtl-optimization/38440] New: auto-increment generation does not work

While gcc 4.2 could generate auto-incremnt addressing at least for simple code as in the libgcc bcmp, gcc 4.4 fails utterly there. -- Summary: auto-increment generation does not work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords:

[Bug target/38441] New: FAIL: g++.dg/special/conpr-3.C execution test

Executing on host: /Users/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/Use rs/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ /Users/dave/gnu/gcc/gcc/gcc/test suite/g++.dg/special/conpr-3.C -nostdinc++ -I/Users/dave/gnu/gcc/objdir/i686-ap ple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/U

[Bug rtl-optimization/38440] auto-increment generation does not work

--- Comment #1 from amylaar at gcc dot gnu dot org 2008-12-07 21:38 --- Created an attachment (id=16845) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16845&action=view) test case This is the test case, the preprocessed libgcc2 bcmp code. I've used the version from gcc 4.4, but h

[Bug rtl-optimization/38440] auto-increment generation does not work

--- Comment #2 from amylaar at gcc dot gnu dot org 2008-12-07 21:41 --- Created an attachment (id=16846) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16846&action=view) gcc 4.2.1 compiled code This is the testcase compiled with the options -O2 -mA7, using gcc 4.2.1 with our local

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

--- Comment #6 from hp at gcc dot gnu dot org 2008-12-07 21:42 --- I noticed something odd while looking at simulator traces: running the test-case streamio_1 at -O1 (passing) yielded a different execution path than at -O0 (failing) *in the library*. At -O0, no write system calls were d

[Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava

--- Comment #1 from felix-gcc at fefe dot de 2008-12-07 21:46 --- I tried building gcc with --disable-multilib but fails at the same location in the 64-bit libjava build as well: /bin/sh ./libtool --tag=GCJ --mode=link /home/leitner/tmp/gcc/build/gcc/gcj -B/home/leitner/tmp/gcc/build/x8

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

--- Comment #7 from hp at gcc dot gnu dot org 2008-12-07 21:51 --- Created an attachment (id=16847) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16847&action=view) valgrind -v output from streamio_1 compiled "-O2 -static" on i686-unknown-linux-gnu (freshly updated F 9) Ignore the

[Bug rtl-optimization/38440] auto-increment generation does not work

--- Comment #3 from amylaar at gcc dot gnu dot org 2008-12-07 21:51 --- Created an attachment (id=16848) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16848&action=view) gcc 4.4.0 compiled code This is the testcase compiled using the options -O2 -mA7 with gcc 4.4.0 20081205 (revis

[Bug target/38442] New: Multi-line description used in config/picochip/picochip.opt

According to bug 34352 comment 1, it is incorrect for descriptions in .opt files to span multiple lines. In version 4.4-20081121 there is such a case in config/picochip/picochip.opt: msymbol-as-address Target Mask(SYMBOL_AS_ADDRESS) Allow a symbol value to be used as an immediate value i

[Bug debug/38390] Missing DW_TAG_imported_module

--- Comment #3 from dodji at gcc dot gnu dot org 2008-12-07 22:19 --- The patch passes regtests. I have posted it to http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00442.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38390

[Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava

--- Comment #2 from brian at dessent dot net 2008-12-07 22:48 --- Subject: Re: New: build error in x86_64-unknown-linux-gnu/32/libjava It looks like somehow a rule is being run that isn't intended to ever actually be built. In libjava/Makefile.am there are these dummy rules copied

[Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava

--- Comment #3 from felix-gcc at fefe dot de 2008-12-07 23:38 --- I have the sources in ~/tmp/gcc, and I build in ~/tmp/gcc/build using ../configure. I can see the .in files you mention in libjava/classpath/tools and I can see some binaries in build/x86_64-unknown-linux-gnu/libjava/clas

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-12-07 23:58 --- This has been seen before and until now I thought it was an artifact of valgrind and that the Front end is suppose to set some values. I will see if we can fix this. -- jvdelisle at gcc dot gnu dot org change

[Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava

--- Comment #4 from felix-gcc at fefe dot de 2008-12-08 00:17 --- This was apparently caused by a conflict with my userland. When I used vanilla coreutils, the build works. This will be horrible to debug. Sorry for the noise. -- felix-gcc at fefe dot de changed: What

[Bug libgcj/38438] build error in x86_64-unknown-linux-gnu/32/libjava

--- Comment #5 from brian at dessent dot net 2008-12-08 00:30 --- Subject: Re: build error in x86_64-unknown-linux-gnu/32/libjava > I have the sources in ~/tmp/gcc, and I build in ~/tmp/gcc/build using > ../configure. Oh, that's definitely not good. To quote

[Bug fortran/38439] I/O PD edit descriptor inconsistency

--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-12-08 00:52 --- After thinking about it some, I think we should accept with -std=legacy since it is accepted by g77 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-12-08 02:03 --- First, thanks for the trace. Please try this patch. In the meantime, I need to make sure I have the backward compatibility with 4.3 runtime OK. I have one other spot to check in the code. Index: transfer.c ===

[Bug target/38294] Enable multilib support for mingw

--- Comment #2 from nightstrike at gmail dot com 2008-12-08 07:48 --- Created an attachment (id=16849) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16849&action=view) Second attempt This gets us further along -- nightstrike at gmail dot com changed: What|Remov