[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #22678|0   |1
is obsolete||
  Attachment #22679|0   |1
is obsolete||

--- Comment #66 from Jakub Jelinek  2010-12-08 
07:35:43 UTC ---
Created attachment 22680
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22680
gcc46-pr41082.patch

Another untested fix, which this time should fix both
rs6000_expand_vector_extract patterns and __builtin_altivec_stve*x.
For altivec-4.c it generates identical code before/after the patch for both -O0
and -O2.

[Bug fortran/46842] 465.tonto test run miscompares (even with -O0)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842

--- Comment #5 from Tobias Burnus  2010-12-08 
07:02:49 UTC ---
(In reply to comment #4)
> Yes, a duplicate. A fortran frontend bug?

Maybe - however, in order that we could investigate, it would help if you could
narrow down the failing commit - without SPEC CPU 2006 access that's
impossible. For the revisions you have given one finds
 58 files changed, 13026 insertions(+), 4788 deletions(-)

[Bug middle-end/45231] gcc.c-torture/compile/941014-2.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45231

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.08 06:29:51
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Sebastian Pop  2010-12-08 06:29:51 
UTC ---
Mine.  Thanks Jack for letting me know that the posted patch
also fixes this one.  I added the testcase of this bug to the patch.

[Bug middle-end/46845] -fgraphite-identity causes ICE in gcc.dg/pr43300.c at -m32/-m64

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46845

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.08 06:26:31
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Sebastian Pop  2010-12-08 06:26:31 
UTC ---
Mine.
This ICE occurs on trunk without extra patches.
When I read the first comment, I thought that it was due to the patch that I
posted.

[Bug target/45754] Driver core dump when duplicating -Wall command line option

[davek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45754

Dave Korn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||davek at gcc dot gnu.org
 Resolution||FIXED

--- Comment #3 from Dave Korn  2010-12-08 05:57:07 
UTC ---
(In reply to comment #2)
> Subject: Re:  Driver core dump when duplicating -Wall
>  command line option
> 
> Unless this can be reproduced with trunk I'd guess it was fixed by:
> 
> 2010-06-09  Dave Korn  
> 
> * opts-common.c (prune_options): Ensure replacement argv array
> is correctly terminated by a NULL entry.

  Yes, I confirmed that the bug is fixed on head.  Martin, it is also fixed in
the cygwin gcc-4.5.0-1 test release.

  BTW, use 'g++', not 'gcc', when compiling C++, or you will run into link
errors vs. libstdc!

[Bug fortran/46705] Spurious "Missing '&' in continued character constant" warning occurs twice

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46705

Jerry DeLisle  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |jvdelisle at gcc dot
   |gnu.org |gnu.org

--- Comment #2 from Jerry DeLisle  2010-12-08 
04:40:58 UTC ---
I will work this one.

Elado-Mobil.hu

[Eladó-Mobil]

Szia!
Esetleg szeretnél eladni, venni, elcserélni egy, vagy akár több telefont?
Nem szeretnéd a telefonboltokba jóval áron alul eladni a telefonodat?
Akkor regisztrálj az alábbi honlapon teljesen INGYENESEN!
Minden hónapban tárgynyeremény, a regisztráltak között!
Az oldal linkje: http://elado-mobil.hu/

[Bug middle-end/46845] -fgraphite-identity causes ICE in gcc.dg/pr43300.c at -m32/-m64

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46845

--- Comment #2 from Jack Howarth  2010-12-08 
03:39:46 UTC ---
This same ICE also appears in...

FAIL: gcc.target/i386/pr21101.c (internal compiler error)
FAIL: gcc.target/i386/pr21101.c (test for excess errors)
FAIL: gcc.target/i386/sse2-mmx.c (internal compiler error)
FAIL: gcc.target/i386/sse2-mmx.c (test for excess errors)
WARNING: gcc.target/i386/sse2-mmx.c compilation failed to produce executable
FAIL: gcc.target/i386/sse2-vec-6.c (internal compiler error)
FAIL: gcc.target/i386/sse2-vec-6.c (test for excess errors)
WARNING: gcc.target/i386/sse2-vec-6.c compilation failed to produce executable
FAIL: gcc.target/i386/sse4_1-insertps-1.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-insertps-1.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-insertps-1.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-movntdqa.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-movntdqa.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-movntdqa.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-mpsadbw.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-mpsadbw.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-mpsadbw.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-pinsrd.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-pinsrd.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-pinsrd.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-ptest-3.c (internal compiler error)
FAIL: gcc.target/i386/sse4_1-ptest-3.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-ptest-3.c compilation failed to produce
executable

at both -m32 and -m64.

[Bug middle-end/46845] -fgraphite-identity causes ICE in gcc.dg/pr43300.c at -m32/-m64

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46845

--- Comment #1 from Jack Howarth  2010-12-08 
03:33:33 UTC ---
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc-4.6-20101207/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20101207 (experimental) (GCC)

[Bug middle-end/46845] New: -fgraphite-identity causes ICE in gcc.dg/pr43300.c at -m32/-m64

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46845

   Summary: -fgraphite-identity causes ICE in gcc.dg/pr43300.c at
-m32/-m64
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


Current gcc trunk with http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00629.html
and

Index: opts.c
===
--- opts.c  (revision 167318)
+++ opts.c  (working copy)
@@ -462,6 +462,9 @@
 { OPT_LEVELS_1_PLUS, OPT_fcombine_stack_adjustments, NULL, 1 },

 /* -O2 optimizations.  */
+#ifdef HAVE_cloog
+{ OPT_LEVELS_2_PLUS, OPT_fgraphite_identity, NULL, 1 },
+#endif
 { OPT_LEVELS_2_PLUS, OPT_finline_small_functions, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_findirect_inlining, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fpartial_inlining, NULL, 1 },

causes the regressions...

FAIL: gcc.dg/pr43300.c (internal compiler error)
FAIL: gcc.dg/pr43300.c (test for excess errors)

which are of the form...

Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101207/gcc/testsuite/gcc.dg/pr43300.c
  -Os -w -Wno-psabi -S  -m32 -o pr43300.s(timeout = 300)
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101207/gcc/testsuite/gcc.dg/pr43300.c:
In function 'foo':
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101207/gcc/testsuite/gcc.dg/pr43300.c:8:1:
internal compiler error: in rename_uses, at sese.c:534

on x86_64-apple-darwin10 for both -m32 and -m64. This backtraces as...


gdb /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/cc1
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries  done

(gdb) break fancy_abort
Breakpoint 1 at 0x10039fa0b: file ../../gcc-4.6-20101207/gcc/diagnostic.c, line
893.
(gdb) r  -v -imultilib i386 -iprefix
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/
-isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include -isystem
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include-fixed
-D__DYNAMIC__
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101207/gcc/testsuite/gcc.dg/pr43300.c
-fPIC -quiet -dumpbase pr43300.c -mmacosx-version-min=10.6.5 -m32 -mtune=core2
-auxbase-strip pr43300.s -Os -Wno-psabi -w -version -o pr43300.s
Starting program: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/cc1 -v
-imultilib i386 -iprefix
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/
-isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include -isystem
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include-fixed
-D__DYNAMIC__
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101207/gcc/testsuite/gcc.dg/pr43300.c
-fPIC -quiet -dumpbase pr43300.c -mmacosx-version-min=10.6.5 -m32 -mtune=core2
-auxbase-strip pr43300.s -Os -Wno-psabi -w -version -o pr43300.s
Reading symbols for shared libraries .+++... done
GNU C (GCC) version 4.6.0 20101207 (experimental) (x86_64-apple-darwin10.5.0)
compiled by GNU C version 4.6.0 20101207 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include"
ignoring nonexistent directory
"/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include-fixed"
ignoring nonexistent directory
"/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../../x86_64-apple-darwin10.5.0/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../../x86_64-apple-darwin10.5.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include
 /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/include-fixed
 /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include
 /sw/lib/gcc4.6/include
 /sw/lib/gcc4.6/lib/gcc/x86_64-apple-dar

[Bug middle-end/45231] gcc.c-torture/compile/941014-2.c ICEs with -fgraphite-identity

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45231

--- Comment #2 from Jack Howarth  2010-12-08 
02:23:45 UTC ---
This issue doesn't seem to be present at r167573 with
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00629.html and

Index: opts.c
===
--- opts.c  (revision 167318)
+++ opts.c  (working copy)
@@ -462,6 +462,9 @@
 { OPT_LEVELS_1_PLUS, OPT_fcombine_stack_adjustments, NULL, 1 },

 /* -O2 optimizations.  */
+#ifdef HAVE_cloog
+{ OPT_LEVELS_2_PLUS, OPT_fgraphite_identity, NULL, 1 },
+#endif
 { OPT_LEVELS_2_PLUS, OPT_finline_small_functions, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_findirect_inlining, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fpartial_inlining, NULL, 1 },

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230

--- Comment #21 from Jack Howarth  2010-12-08 
02:15:28 UTC ---
(In reply to comment #20)
> Patch here:
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00629.html

The proposed patch applied to r167573 as well as...

Index: opts.c
===
--- opts.c  (revision 167318)
+++ opts.c  (working copy)
@@ -462,6 +462,9 @@
 { OPT_LEVELS_1_PLUS, OPT_fcombine_stack_adjustments, NULL, 1 },

 /* -O2 optimizations.  */
+#ifdef HAVE_cloog
+{ OPT_LEVELS_2_PLUS, OPT_fgraphite_identity, NULL, 1 },
+#endif
 { OPT_LEVELS_2_PLUS, OPT_finline_small_functions, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_findirect_inlining, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fpartial_inlining, NULL, 1 },

eliminates the ICEs compiling the gcc.c-torture/execute/strncmp-1.c testcase on
x86_64-apple-darwin10.

[Bug other/46840] libgo should link against libm

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46840

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Ian Lance Taylor  2010-12-08 02:09:38 
UTC ---
Fixed.  Thanks.

[Bug other/46840] libgo should link against libm

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46840

--- Comment #1 from ian at gcc dot gnu.org  2010-12-08 
02:09:02 UTC ---
Author: ian
Date: Wed Dec  8 02:08:59 2010
New Revision: 167582

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167582
Log:
PR other/46840
Link libgo against -lm.

Modified:
trunk/libgo/Makefile.am
trunk/libgo/Makefile.in
trunk/libgo/configure
trunk/libgo/configure.ac
trunk/libgo/testsuite/Makefile.in

[Bug middle-end/46844] New: [4.6 Regression] regrename.c:312:22: error: unused parameter 'reg'

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46844

   Summary: [4.6 Regression] regrename.c:312:22: error: unused
parameter 'reg'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa2.0w-hp-hpux11.11
 Build: hppa-unknown-linux-gnu


/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/sys-include-c   -g -O2 -DIN_GCC
  -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-forma
t-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-string
s -Werror -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I.
-I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/
../libcpp/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumb
er/dpd -I../libdecnumber../../gcc/gcc/regrename.c -o regrename.o
../../gcc/gcc/regrename.c: In function 'check_new_reg_p':
../../gcc/gcc/regrename.c:312:22: error: unused parameter 'reg'
[-Werror=unused-
parameter]cc1: all warnings being treated as errors

d...@hiauly6:~/gnu/gcc/objdir/prev-gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa-linux
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--prefix=/home/dave/opt/gnu/gcc/gcc-4.6.0
--with-local-prefix=/home/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu
--enable-java-gc=boehm --enable-java-awt=xlib
--with-host-libstdcxx=/usr/lib/libstdc++.so.6
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
Thread model: posix
gcc version 4.6.0 20101207 (experimental) [trunk revision 167551] (GCC)

[Bug c++/46626] [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46626

--- Comment #5 from Jonathan Wakely  2010-12-08 
02:07:31 UTC ---
Most of the 30_threads tests will abort without -pthread

[Bug target/46685] [4.6 Regression] New stack alignment failures with -fpic

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #14 from John David Anglin  2010-12-08 
01:55:53 UTC ---
Fixed.

[Bug target/46685] [4.6 Regression] New stack alignment failures with -fpic

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46685

--- Comment #13 from John David Anglin  2010-12-08 
01:26:48 UTC ---
Author: danglin
Date: Wed Dec  8 01:26:44 2010
New Revision: 167581

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167581
Log:
PR middle-end/46671
PR target/46685
* config/pa/pa.c (pa_function_section): New function.
(TARGET_ASM_FUNCTION_SECTION): Define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c

[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671

--- Comment #10 from John David Anglin  2010-12-08 
01:26:47 UTC ---
Author: danglin
Date: Wed Dec  8 01:26:44 2010
New Revision: 167581

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167581
Log:
PR middle-end/46671
PR target/46685
* config/pa/pa.c (pa_function_section): New function.
(TARGET_ASM_FUNCTION_SECTION): Define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c

[Bug middle-end/46506] GCC miscompiled 465.tonto in SPEC CPU 2006

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
   Target Milestone|--- |4.6.0

--- Comment #10 from H.J. Lu  2010-12-08 01:09:37 
UTC ---
Tonto always fails with test input. Ignore it.

[Bug middle-end/46506] GCC miscompiled 465.tonto in SPEC CPU 2006

[changpeng.fang at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506

--- Comment #9 from Changpeng Fang  2010-12-08 
00:54:08 UTC ---
This is not a optimization bug because it fails with -O0.
I am seeking a working src_alt. Thanks.

[Bug middle-end/46506] GCC miscompiled 465.tonto in SPEC CPU 2006

[changpeng.fang at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506

Changpeng Fang  changed:

   What|Removed |Added

 CC||changpeng.fang at amd dot
   ||com

--- Comment #8 from Changpeng Fang  2010-12-08 
00:50:31 UTC ---
*** Bug 46842 has been marked as a duplicate of this bug. ***

[Bug fortran/46842] 465.tonto test run miscompares (even with -O0)

[changpeng.fang at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842

Changpeng Fang  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Changpeng Fang  2010-12-08 
00:50:31 UTC ---
Yes, a duplicate. A fortran frontend bug?

*** This bug has been marked as a duplicate of bug 46506 ***

[Bug c++/46626] [4.6 Regression] simple use of virtual methods causes pure virtual method call in c++0x mode

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46626

--- Comment #4 from Zdenek Sojka  2010-12-08 00:43:03 
UTC ---
This seems to cause FAILs in libstdc++ testsuite with -O0, for example:
$ g++ 42819.ii -std=gnu++0x
$ ./a.out
terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error 18446744073709551615
Aborted

(all failures I encountered are from 30_threads)

[Bug middle-end/46837] induct compiled with -ffast-math -fschedule-insns -fsched-pressure -O3 ~30% slower

[steven at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46837

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.08 00:35:39
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Steven Bosscher  2010-12-08 
00:35:39 UTC ---
Re. comment #2: For the i386 backends -fschedule-insns is disabled even at -O2
and -O3. See gcc/config/i386/i386.c:ix86_option_optimization_table:

static const struct default_options ix86_option_optimization_table[] =
  {
/* Turn off -fschedule-insns by default.  It tends to make the
   problem with not enough registers even worse.  */
#ifdef INSN_SCHEDULING
{ OPT_LEVELS_ALL, OPT_fschedule_insns, NULL, 0 },
#endif

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

--- Comment #65 from Jakub Jelinek  2010-12-08 
00:32:47 UTC ---
Created attachment 22679
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22679
gcc46-pr41082.patch

Found that now too.  Anyway, I believe (if there is no performance issue) I can
just tweak rs6000_expand_vector_extract this way, and the stve*x patterns would
need to be fixed anyway, though, because it hardly can have the extra argument,
it couldn't be VEC_SELECT, but I guess a scalar store with =Z or some similar
constraint that forces reg or reg+reg, with source being jus tthe unspec
UNSPEC_STVE with the vector as argument thereof.

[Bug fortran/46842] 465.tonto test run miscompares (even with -O0)

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842

--- Comment #3 from Dominique d'Humieres  2010-12-08 
00:21:22 UTC ---
Could it be a duplicate of PR46506?

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

--- Comment #64 from Andrew Pinski  2010-12-08 
00:15:44 UTC ---
> IMHO we should just get rid of UNSPEC_STVE stuff and store the whole vector, 

No you cannot because there are builtins which create the UNSPEC_STVE.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

--- Comment #63 from Jakub Jelinek  2010-12-08 
00:12:52 UTC ---
Created attachment 22678
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22678
gcc46-pr41082.patch

Totally untested proof of concept patch.
The disadvantage is that as the MEM mode is not altivec-ish, it isn't forced
into reg+reg addressing early.

On the other side, when rs6000_expand_vector_extract always creates a new stack
local (shouldn't it try to share just one such slot for each mode in each
function btw?), is there any reason why a normal stvx insn can't be used
instead of these stve*x insns?  Is it a performance issue?  The difference
between stvx and stve*x I understand is just that stve*x doesn't clobber in the
memory
other bytes, while stvx stores everything in the 16 byte slot.  But we don't
care about those other bytes anyway, so if it is not a performance issue, IMHO
we should just get rid of UNSPEC_STVE stuff and store the whole vector, then
just read the bytes we want.

[Bug rtl-optimization/46829] ICE: in spill_failure, at reload1.c:2105 with -fschedule-insns -fsched-pressure and variadic function

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829

--- Comment #8 from H.J. Lu  2010-12-07 23:54:42 
UTC ---
(In reply to comment #7)
> If you compile with dispatch scheduling enabled (together with -march=bdver1),
> both test cases attached PASS.
> 
> gcc -O2 -fschedule-insns -fsched-pressure -mdispatch-scheduler -march=bdver1

You can turn it on for -march=bdver1.

[Bug c++/40269] ICE during processing class attributes

[davek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40269

Dave Korn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||davek at gcc dot gnu.org
 Resolution||WORKSFORME

--- Comment #1 from Dave Korn  2010-12-07 23:26:26 
UTC ---
Couldn't reproduce this on the released 4.5.0 nor on 4.6.0 current trunk, so I
assume this was a transient thing that got fixed.  Please re-open if you see it
again anytime.

[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

Jakub Jelinek  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #62 from Jakub Jelinek  2010-12-07 
23:18:05 UTC ---
On a closer look, the reason why DSE deletes it is because there is a stvewx
insn in between, and the pattern of the insn is just plain wrong.
rs6000_expand_vector_extract has called assign_stack_temp, which gave for a
V4SImode something that is at r1+256, 16 bytes.
But rs6000_expand_vector_extract adjusts the address by elt * 4 bytes, here for
elt 3, so it is r1+268.  The pattern wrongly says that a V4SImode register is
stored into (mem:V4SI (r1 + 268)), which is not true (the insn stores just
4 bytes, i.e. SImode, into r1 + 268.  The r1+272 address which was given for
one of the spilled CCmode pseudos is then considered to be clobbered by DSE,
because
(mem:V4SI (r1 + 268)) overlaps it, thus the removed (mem:CC (r1 + 272)) store
by DSE.

I think the stve* insns need to be represented as what it really does, i.e.
(set (mem:SI ...) (either vec_select or perhaps unspec with the V4SImode reg
inside of it)).

[Bug fortran/46842] 465.tonto test run miscompares (even with -O0)

[changpeng.fang at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842

--- Comment #2 from Changpeng Fang  2010-12-07 
23:12:23 UTC ---
(In reply to comment #1)
> It does not seem to affect all SPEC testers as Rev. 167317 is already quite
> some old (= 2010-11-30) and I do not have seen any other report. (Cf. for
> instance http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00579.html)

This bug is filed against test data set. train and ref data sets are fine.

> I assume it worked before - can you find out which version caused the
> regression? Or do some other narrowing down of the problem?
The last working re I observed is 162788 (very very old).
The first bad rev I observed   is 166096 ( very old)

[Bug rtl-optimization/46843] New: ICE: in spill_failure, at reload1.c:2157 -fschedule-insns -fsched-pressure when using doubles

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46843

   Summary: ICE: in spill_failure, at reload1.c:2157
-fschedule-insns -fsched-pressure when using doubles
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22677
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22677
reduced testcase

Compiler output:
$ gcc -O -fschedule-insns -fsched-pressure pr46843.c 
pr46843.c: In function 'foo':
pr46843.c:9:1: error: unable to find a register to spill in class 'CREG'
pr46843.c:9:1: error: this is the insn:
(insn 19 50 9 2 (parallel [
(set (reg/v:SI 0 ax [orig:63 n ] [63])
(ashift:SI (reg:SI 0 ax [84])
(reg:QI 37 r8 [ s ])))
(clobber (reg:CC 17 flags))
]) pr46843.c:3 497 {*ashlsi3_1}
 (expr_list:REG_DEAD (reg:SI 0 ax [84])
(expr_list:REG_DEAD (reg:QI 37 r8 [ s ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
pr46843.c:9:1: internal compiler error: in spill_failure, at reload1.c:2105
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-mdispatch-scheduler -march=bdver1 doesn't help in this case (opposing to
PR46829)

Tested revisions:
r167471 - fail
4.5 r166509 - fail

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230

--- Comment #20 from Sebastian Pop  2010-12-07 
23:09:22 UTC ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00629.html

[Bug tree-optimization/45370] [4.6 Regression] gfortran.dg/subref_array_pointer_2.f90 -O2 -fgraphite-identity ICE

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45370

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.07 23:09:01
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Sebastian Pop  2010-12-07 23:09:01 
UTC ---
Mine.
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00629.html

[Bug rtl-optimization/46829] ICE: in spill_failure, at reload1.c:2105 with -fschedule-insns -fsched-pressure and variadic function

[changpeng.fang at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829

--- Comment #7 from Changpeng Fang  2010-12-07 
22:42:26 UTC ---
If you compile with dispatch scheduling enabled (together with -march=bdver1),
both test cases attached PASS.

gcc -O2 -fschedule-insns -fsched-pressure -mdispatch-scheduler -march=bdver1

[Bug fortran/46842] 465.tonto test run miscompares (even with -O0)

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2010-12-07 
22:39:13 UTC ---
It does not seem to affect all SPEC testers as Rev. 167317 is already quite
some old (= 2010-11-30) and I do not have seen any other report. (Cf. for
instance http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00579.html)

I assume it worked before - can you find out which version caused the
regression? Or do some other narrowing down of the problem?

Note: To my knowledge none of the gfortran developers has access to SPEC CPU
2006.
Tonto itself is accessible (GPL) from
http://www.theochem.uwa.edu.au/tonto/download

[Bug libstdc++/46659] std::list iterator debugging (_GLIBCXX_DEBUG) is much slower than stlport's one.

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46659

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug libstdc++/46659] std::list iterator debugging (_GLIBCXX_DEBUG) is much slower than stlport's one.

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46659

Pawel Sikora  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from Pawel Sikora  2010-12-07 22:19:39 
UTC ---
here're the results for current git: 54486c25c3df3bdb314929fe30855f0d3bd2e0b5

20 elements:

$ time ./t-libstdcxx
./t-libstdcxx  0,09s user 0,01s system 98% cpu 0,109 total
$ time ./t-stlport
./t-stlport  170,91s user 0,01s system 99% cpu 2:50,93 total

10 elements:

$ time ./t-libstdcxx
./t-libstdcxx  0,05s user 0,00s system 95% cpu 0,056 total
$ time ./t-stlport
./t-stlport  31,59s user 0,02s system 99% cpu 31,622 total

5 elements:

$ time ./t-libstdcxx
./t-libstdcxx  0,02s user 0,00s system 93% cpu 0,029 total
$ time ./t-stlport
./t-stlport  7,28s user 0,00s system 99% cpu 7,287 total

so... it's fixed.

[Bug libstdc++/46659] std::list iterator debugging (_GLIBCXX_DEBUG) is much slower than stlport's one.

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46659

--- Comment #7 from Paolo Carlini  2010-12-07 
22:10:39 UTC ---
Excellent. If you can confirm that the improvement holds true also for a
smaller number of elements let's close this as fixed for 4.6.0.

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

--- Comment #61 from Jakub Jelinek  2010-12-07 
22:07:59 UTC ---
I've managed to massage both -O3 -m64 -mtune={rs64,power4} darwin assembly into
ppc64-linux assembly.
Before DSE2 we have:
(insn 460 483 925 33 (set (reg:CC 75 cr7)
(compare:CC (reg:SI 11 r11 [orig:866 reduce+32 ] [866])
(const_int 6 [0x6]))) where_2.f90:11 451 {*cmpsi_internal1}
 (nil))

(insn 925 460 926 33 (set (reg:CC 0 r0)
(reg:CC 75 cr7)) where_2.f90:11 358 {*movcc_internal1}
 (nil))

(insn 926 925 467 33 (set (mem/c:CC (plus:DI (reg/f:DI 1 r1)
(const_int 272 [0x110])) [5 %sfp+272 S4 A32])
(reg:CC 0 r0)) where_2.f90:11 358 {*movcc_internal1}
 (nil))

... # %sfp+272 not used anywhere here

(insn 931 415 932 33 (set (reg:CC 19 r19)
(mem/c:CC (plus:DI (reg/f:DI 1 r1)
(const_int 272 [0x110])) [5 %sfp+272 S4 A32])) where_2.f90:11
358 {*movcc_internal1}
 (nil))

(insn 932 931 461 33 (set (reg:CC 74 cr6)
(reg:CC 19 r19)) where_2.f90:11 358 {*movcc_internal1}
 (nil))

(insn 461 932 422 33 (set (reg:SI 27 r27 [712])
(gt:SI (reg:CC 74 cr6)
(const_int 0 [0]))) where_2.f90:11 462 {*rs6000.md:13486}
 (nil))

and DSE2 somehow decides to nuke the insn 926 store.  The error could be also
that RA decides to share %sfp+272 not just for the CCmode stuff, but also
before that for a SImode value.

Looking into it...

[Bug libstdc++/46659] std::list iterator debugging (_GLIBCXX_DEBUG) is much slower than stlport's one.

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46659

--- Comment #6 from Pawel Sikora  2010-12-07 22:05:15 
UTC ---
(In reply to comment #5)
> With current mainline 20 elements finishes in 0.1s on my x86_64 system,
> which is only 5 times slower than non-debug mode.
> 
> That's compared with 5m36s with 4.5's debug mode.
> 
> I think it's safe to say François has fixed it :)

in fact :)
with current git-mirror 54486c25c3df3bdb314929fe30855f0d3bd2e0b5
checkout for 200'000 elemetns i have a fantastic speedup:

$ time ./t-libstdcxx
./t-libstdcxx  0,09s user 0,01s system 98% cpu 0,109 total
$ time ./t-stlport
./t-stlport  170,91s user 0,01s system 99% cpu 2:50,93 total

[Bug fortran/46842] New: 465.tonto test run miscompares (even with -O0)

[changpeng.fang at amd dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842

   Summary: 465.tonto test run miscompares (even with -O0)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: changpeng.f...@amd.com


Tests are performed based 4.6 trunk @ 167317 on a linux64 system. 456.tonto
test run miscompares @ any options. 

train and ref runs are fine.

LINK: gfortran   -O0  -DSPEC_CPU_LP64   -o options
C: LD="gfortran"
O: FOPTIMIZE="-O0"
P: PORTABILITY="-DSPEC_CPU_LP64"
C: LDOUT="-o options"

Build successes: 465.tonto(base)

Setting Up Run Directories
  Setting up 465.tonto test base cfang default: existing
(run_base_test_cfang.)
Running Benchmarks
  Running 465.tonto test base cfang default
/home/chfang/cpu2006/bin/specinvoke -d
/home/chfang/cpu2006/benchspec/CPU2006/465.tonto/run/run_base_test_cfang.
-e speccmds.err -o speccmds.stdout -f speccmds.cmd -r -C
/home/chfang/cpu2006/bin/specinvoke -E -d
/home/chfang/cpu2006/benchspec/CPU2006/465.tonto/run/run_base_test_cfang.
-c 1 -e compare.err -o compare.stdout -f compare.cmd

*** Miscompare of stdout; for details see
   
/home/chfang/cpu2006/benchspec/CPU2006/465.tonto/run/run_base_test_cfang./stdout.mis
Error: 1x465.tonto

[Bug libstdc++/46659] std::list iterator debugging (_GLIBCXX_DEBUG) is much slower than stlport's one.

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46659

--- Comment #5 from Jonathan Wakely  2010-12-07 
21:40:38 UTC ---
With current mainline 20 elements finishes in 0.1s on my x86_64 system,
which is only 5 times slower than non-debug mode.

That's compared with 5m36s with 4.5's debug mode.

I think it's safe to say François has fixed it :)

[Bug bootstrap/46810] [4.6 regression] sparc64-linux bootstrap fails with "C++ preprocessor "/lib/cpp" fails sanity check"

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46810

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Ian Lance Taylor  2010-12-07 21:08:43 
UTC ---
This should be fixed now.  Thanks for reporting it.

Note that we are considering shifting gcc to be built using C++ by default,
which will fail on your system until you install a C++ compiler (e.g., by
installing an earlier version of gcc).

This does not fix PR 40950, which must be fixed in some other way.

[Bug bootstrap/46810] [4.6 regression] sparc64-linux bootstrap fails with "C++ preprocessor "/lib/cpp" fails sanity check"

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46810

--- Comment #6 from ian at gcc dot gnu.org  2010-12-07 
21:04:36 UTC ---
Author: ian
Date: Tue Dec  7 21:04:33 2010
New Revision: 167572

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167572
Log:
PR bootstrap/46810
* configure.ac: Disable AC_MSG_ERROR while looking for the C++
preprocessor.
* configure: Rebuild.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug testsuite/46595] [4.6 Regression] libquadmath.0.dylib image not found

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46595

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from John David Anglin  2010-12-07 
20:35:07 UTC ---
Fixed.

[Bug fortran/46809] [OOP] ICE with -fcheck=pointer for CLASS IS

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.07 20:33:35
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from janus at gcc dot gnu.org 2010-12-07 20:33:35 UTC ---
(In reply to comment #4)
> The issue seems to be the EXTENDS_TYPE_OF call which is generated for CLASS 
> IS;
> the call seems to have an "expr->where" defined - but not a
> where->lb->location.

We fail to set the location of the first argument when generating the
EXTENDS_TYPE_OF call. The following patch fixes it:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 167369)
+++ gcc/fortran/resolve.c(working copy)
@@ -7892,6 +7892,7 @@ resolve_select_type (gfc_code *code, gfc_namespace
   /* Set up arguments.  */
   new_st->expr1->value.function.actual = gfc_get_actual_arglist ();
   new_st->expr1->value.function.actual->expr = gfc_get_variable_expr
(code->expr1->symtree);
+  new_st->expr1->value.function.actual->expr->where = code->loc;
   gfc_add_vptr_component (new_st->expr1->value.function.actual->expr);
   vtab = gfc_find_derived_vtab (body->ext.case_list->ts.u.derived);
   st = gfc_find_symtree (vtab->ns->sym_root, vtab->name);

[Bug fortran/44352] ICE in string_to_single_character

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352

--- Comment #10 from Tobias Burnus  2010-12-07 
20:29:25 UTC ---
Author: burnus
Date: Tue Dec  7 20:29:22 2010
New Revision: 167569

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167569
Log:
2010-12-07  Tobias Burnus  

PR fortran/44352
* trans-expr.c (gfc_string_to_single_character): Return if not
POINTER_TYPE_P.
(gfc_trans_string_copy): gfc_build_addr_expr if src or dest is
not a pointer.
(gfc_trans_string_copy): Make sure the argument string type
has a string length, fix indention, and remove not needed
gfc_build_addr_expr.

2010-12-07  Tobias Burnus  

PR fortran/44352
* gfortran.dg/string_4.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/string_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/35531] Assembler failure while compiling libgcc

[gseanmcg at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35531

Sean McGovern  changed:

   What|Removed |Added

 CC||gseanmcg at gmail dot com

--- Comment #13 from Sean McGovern  2010-12-07 
20:06:27 UTC ---
Since I have had successful builds of both 4.5.x and 4.6.x of gcc using current
GNU binutils (2.20.1.x) and Sun ld, can this bug be closed?

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230

--- Comment #19 from Sebastian Pop  2010-12-07 
19:45:19 UTC ---
With this patch:

diff --git a/gcc/sese.c b/gcc/sese.c
index 65f8556..140b16f 100644
--- a/gcc/sese.c
+++ b/gcc/sese.c
@@ -547,8 +547,8 @@ rename_uses (gimple copy, htab_t rename_map,
gimple_stmt_iterator *gsi_tgt,
   gsi_insert_seq_before (gsi_tgt, stmts, GSI_SAME_STMT);
   replace_exp (use_p, new_expr);

-
-  if (TREE_CODE (new_expr) == INTEGER_CST)
+  if (TREE_CODE (new_expr) == INTEGER_CST
+ && gimple_code (copy) == GIMPLE_ASSIGN)
{
  tree rhs = gimple_assign_rhs1 (copy);

I now see the same error as in comment #12

[Bug fortran/46841] ICE on allocate array of procedure pointers

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46841

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.07 19:44:18
 Ever Confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org 2010-12-07 19:44:18 UTC ---
Confirmed. Slightly reduced test case:



  type vfunc_p
procedure (dum_vfunc), pointer, nopass :: p => null()
  end type vfunc_p

  type(vfunc_p), allocatable, dimension(:) :: vfunc1 

  allocate(vfunc1(10))

contains

  function dum_vfunc ()
real, dimension(2) :: dum_vfunc
dum_vfunc = 0
  end function dum_vfunc

end

[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230

Sebastian Pop  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2010.12.07 19:34:49
 Resolution|FIXED   |
 AssignedTo|unassigned at gcc dot   |spop at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #18 from Sebastian Pop  2010-12-07 
19:34:49 UTC ---
Mine.  On trunk r167554 I see this failing:
./xgcc -B. -fgraphite-identity -Os -m32
gcc/testsuite/gcc.c-torture/execute/strncmp-1.c

in sese.c:

  tree rhs = gimple_assign_rhs1 (copy);

and here copy is a call statement.

[Bug tree-optimization/46833] ICE: SIGSEGV in expand_vector_operations (tree-vect-generic.c:340) with -fno-non-call-exceptions -ftree-vectorize

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46833

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ian at airs dot com
 Resolution||FIXED

--- Comment #3 from Ian Lance Taylor  2010-12-07 19:32:53 
UTC ---
This should work now.

[Bug tree-optimization/46805] ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46805

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ian at airs dot com
 Resolution||FIXED

--- Comment #4 from Ian Lance Taylor  2010-12-07 19:32:31 
UTC ---
This should work now.

[Bug tree-optimization/46805] ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46805

--- Comment #3 from ian at gcc dot gnu.org  2010-12-07 
19:28:49 UTC ---
Author: ian
Date: Tue Dec  7 19:28:44 2010
New Revision: 167563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167563
Log:
PR tree-optimization/46805
PR tree-optimization/46833
* go-lang.c (go_langhook_type_for_mode): Handle vector modes.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-lang.c

[Bug tree-optimization/46833] ICE: SIGSEGV in expand_vector_operations (tree-vect-generic.c:340) with -fno-non-call-exceptions -ftree-vectorize

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46833

--- Comment #2 from ian at gcc dot gnu.org  2010-12-07 
19:28:48 UTC ---
Author: ian
Date: Tue Dec  7 19:28:44 2010
New Revision: 167563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167563
Log:
PR tree-optimization/46805
PR tree-optimization/46833
* go-lang.c (go_langhook_type_for_mode): Handle vector modes.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-lang.c

[Bug middle-end/45406] ICE: in rename_uses, at sese.c:534

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45406

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.12.07 19:22:33
 Ever Confirmed|0   |1

--- Comment #6 from Sebastian Pop  2010-12-07 19:22:33 
UTC ---
I cannot reproduce this.  Is this still a problem or has this been fixed?

[Bug target/46040] crtstuff.c:308:26: error: '__DTOR_LIST__' undeclared

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46040

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #9 from Ulrich Weigand  2010-12-07 
19:17:16 UTC ---
It looks like this was caused by this patch:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01145.html

gcc/
* config.gcc (arm*-*-linux-*eabi) : Add bpabi.h from
libgcc.
(arm*-*-uclinux*eabi) : Likewise.
(arm*-*-eabi*) : Likewise.
(frv-*-elf) : Add frv-abi.h from libgcc.
(frv-*-*linux*) : Likewise.
* config/arm/bpabi.h: Delete DECLARE_LIBRARY_RENAMES stanzas
and associated helper macros.
* config/frv/frv-abi.h: Delete.

libgcc/
* config/arm/bpabi.h: New file.
* config/frv/frv-abi.h: New file.

For more details see:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00608.html

[Bug middle-end/46837] induct compiled with -ffast-math -fschedule-insns -fsched-pressure -O3 ~30% slower

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46837

--- Comment #3 from Dominique d'Humieres  2010-12-07 
19:08:09 UTC ---
See http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00604.html for a possible
explanation.

[Bug fortran/46753] [4.4 Regression] ICE: OpenMP - in extract_omp_for_data, at omp-low.c:335

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753

--- Comment #5 from Jakub Jelinek  2010-12-07 
19:01:38 UTC ---
Author: jakub
Date: Tue Dec  7 19:01:36 2010
New Revision: 167561

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167561
Log:
Backport from mainline
2010-12-02  Jakub Jelinek  

PR fortran/46753
* trans-openmp.c (gfc_trans_omp_do): Use build2_loc instead of
fold_build2_loc for OMP_FOR conditions.

* libgomp.fortran/pr46753.f90: New test.

Added:
branches/gcc-4_4-branch/libgomp/testsuite/libgomp.fortran/pr46753.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/trans-openmp.c
branches/gcc-4_4-branch/libgomp/ChangeLog

[Bug bootstrap/46819] [4.6 Regression] libffi is always built

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46819

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  2010-12-07 19:00:26 
UTC ---
I just did a complete bootstrap with --enable-languages=c and libffi was not
built.  I did various configure runs with various options, and
TARGET_CONFIGDIRS appeared to generally include libffi when appropriate and not
include it when appropriate.

What configure options are you using?

[Bug libgomp/45240] parallel.c: GOMP_parallel_end locks a mutex but fails to unlock it after atomic operation complete

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45240

--- Comment #4 from Jakub Jelinek  2010-12-07 
18:59:06 UTC ---
Author: jakub
Date: Tue Dec  7 18:59:03 2010
New Revision: 167560

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167560
Log:
Backport from mainline
2010-12-02  Jakub Jelinek  

PR libgomp/45240
* parallel.c (GOMP_parallel_end): Unlock gomp_remaining_threads_lock
at the end if sync builtins aren't supported.

Modified:
branches/gcc-4_4-branch/libgomp/ChangeLog
branches/gcc-4_4-branch/libgomp/parallel.c

[Bug c++/46538] [4.3/4.4 Regression] ICE: SIGSEGV in cp_make_fname_decl (decl.c:3690) on invalid code when using __PRETTY_FUNCTION__

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46538

--- Comment #3 from Jakub Jelinek  2010-12-07 
18:58:20 UTC ---
Author: jakub
Date: Tue Dec  7 18:58:18 2010
New Revision: 167559

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167559
Log:
Backport from mainline
2010-11-20  Jakub Jelinek  

PR c++/46538
* decl.c (cp_make_fname_decl): Return error_mark_node if
current_binding_level has already sk_function_parms kind.

* g++.dg/other/error34.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/error34.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/decl.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug middle-end/46534] [4.3/4.4 Regression] ICE optimizing printf ("...>10MBstring\n") into puts

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46534

--- Comment #8 from Jakub Jelinek  2010-12-07 
18:57:00 UTC ---
Author: jakub
Date: Tue Dec  7 18:56:56 2010
New Revision: 167558

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167558
Log:
PR middle-end/46534
* builtins.c (expand_builtin_printf): Don't copy and modify string
before build_string_literal, instead modify what
build_string_literal returned.

Backport from mainline
2010-11-18  Jakub Jelinek  

PR middle-end/46534
* builtins.c (fold_builtin_printf): Don't copy and modify string
before build_string_literal, instead modify what
build_string_literal returned.

* gcc.c-torture/compile/pr46534.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr46534.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/builtins.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug fortran/46841] ICE on allocate array of procedure pointers

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46841

--- Comment #2 from Dominique d'Humieres  2010-12-07 
18:46:31 UTC ---
Confirmed on trunk and 4.5.0. If I replace

procedure (dum_vfunc), pointer, nopass :: p => null()

with


procedure (dum_vfunc), pointer, nopass :: p

the ICE goes away.

[Bug fortran/46841] ICE on allocate array of procedure pointers

[m.a.hulsen at tue dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46841

--- Comment #1 from Martien Hulsen  2010-12-07 
18:28:26 UTC ---
Created attachment 22676
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22676
source file of module

[Bug fortran/46841] New: ICE on allocate array of procedure pointers

[m.a.hulsen at tue dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46841

   Summary: ICE on allocate array of procedure pointers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m.a.hul...@tue.nl


The attached file gives:

gfortran -c  -O2element_defs.f90
element_defs.f90: In function ‘create_coefficients’:
element_defs.f90:20:0: internal compiler error: in
gfc_conv_descriptor_data_get, at fortran/trans-array.c:144
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/42694] Compiler could optimize pow (x, 0.75) into sqrt (x) * sqrt (sqrt (x))

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42694

--- Comment #8 from Michael Meissner  2010-12-07 
17:42:04 UTC ---
Created attachment 22675
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22675
Add check for sqrt optab being present before doing some optimizations

[Bug rtl-optimization/46829] ICE: in spill_failure, at reload1.c:2105 with -fschedule-insns -fsched-pressure and variadic function

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46829

--- Comment #6 from Zdenek Sojka  2010-12-07 17:34:01 
UTC ---
Created attachment 22674
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22674
different testcase

A bit different testcase

$ gcc -O -fschedule-insns -fsched-pressure pr46829-2.c 
pr46829-2.c: In function 'foo':
pr46829-2.c:10:1: error: unable to find a register to spill in class 'AREG'
pr46829-2.c:10:1: error: this is the insn:
(insn 8 13 9 2 (parallel [
(set (reg:SI 37 r8)
(div:SI (reg:SI 2 cx [orig:59 b.0 ] [59])
(reg:SI 38 r9 [orig:60 a.1 ] [60])))
(set (reg:SI 1 dx [66])
(mod:SI (reg:SI 2 cx [orig:59 b.0 ] [59])
(reg:SI 38 r9 [orig:60 a.1 ] [60])))
(clobber (reg:CC 17 flags))
]) pr46829-2.c:8 353 {*divmodsi4}
 (expr_list:REG_UNUSED (reg:SI 1 dx [66])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
pr46829-2.c:10:1: internal compiler error: in spill_failure, at reload1.c:2105
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug other/46840] New: libgo should link against libm

[doko at ubuntu dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46840

   Summary: libgo should link against libm
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ubuntu.com


building libgo, I see:

dpkg-shlibdeps: warning: symbol sqrtl used by
debian/libgo0/usr/lib/libgo.so.0.0.0 found in none of the libraries.

so libgo should linked against libm?

[Bug c++/46839] Parser confuses derived member with std::forward

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46839

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Andrew Pinski  2010-12-07 
17:24:19 UTC ---
See PR 20308 and such.

*** This bug has been marked as a duplicate of bug 20308 ***

[Bug c++/20308] parser thinks something is a start of a template-id when it is just less than

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308

Andrew Pinski  changed:

   What|Removed |Added

 CC||foehst at informatik dot
   ||uni-kl.de

--- Comment #9 from Andrew Pinski  2010-12-07 
17:24:19 UTC ---
*** Bug 46839 has been marked as a duplicate of this bug. ***

[Bug c++/46839] Parser confuses derived member with std::forward

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46839

--- Comment #2 from Paolo Carlini  2010-12-07 
17:19:42 UTC ---
Note that Intel compiler, based on the EDG C++ front-end, also rejects this
code in strict mode. Likewise of course Comeau. This is enough to show the
issue:

template
  void forward(T);

template  struct A
{
  T forward;
};

template  struct B : public A
{
  void Function()
  {
this->forward < 1;
  }
};

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #29 from Anh Vo  2010-12-07 17:13:08 
UTC ---
(In reply to comment #28)
> (In reply to comment #27)
> > No, the build still failed the same way. In fact, when issuing command 'file
> > gcc/tm.texi' on the build directory, gcc/tm.texi: ASCII English text, with 
> > very
> > long lines is outputed.
> Did your Makefile actually get regenerated?
> The idea is that gcc/tm.texi is no longer compared against
> $(srcdir))/doc/tm.texi,
> but against gcc/tmp3-tm.texi, which should have the same line endings as
> gcc/tm.texi .

gcc/tm.texi and gcc/tmp3-tm.texi did not have same same line ending. In fact,
gcc/tm.texi contains 'ASCII English text, with very long lines' while
gcc/tmp3-tm.texi has 'ASCII English text' only when examined with 'file'
command. In addition, gcc/tm.texi is slightly larger in size (507 KB) than
gcc/tmp3-tm.texi (493 KB).

[Bug c++/46839] Parser confuses derived member with std::forward

[foehst at informatik dot uni-kl.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46839

--- Comment #1 from Tobias Föhst  
2010-12-07 17:12:45 UTC ---
I forgot: Line 15 is only there to prove that this->forward with another
successor than '<' can be resolved as the member derived from A.

[Bug fortran/46838] [OOP] Wrong allocation status for polymorphic component INTENT(OUT) dummy

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838

--- Comment #2 from Tobias Burnus  2010-12-07 
17:04:04 UTC ---
The default initializer is obtained via expr.c's gfc_default_initializer.

[Bug c++/46839] New: Parser confuses derived member with std::forward

[foehst at informatik dot uni-kl.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46839

   Summary: Parser confuses derived member with std::forward
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: foe...@informatik.uni-kl.de


Created attachment 22673
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22673
Info about gcc build configuration

01: #include 
02: #include 
03: using namespace std;
04:
05: template  struct A
06: {
07:   T forward;
08:   A() : forward(0) {}
09: };
10:
11: template  struct B : public A
12: {
13:   void Function()
14:   {
15: cout << (this->forward > 1) << endl;
16: cout << (this->forward < 1) << endl;
17:   }
18: };
19:
20: int main(int argc, char **argv)
21: {
22:   return 0;
23: }

g++ -Wall -std=gnu++0x

: In member function ‘void B::Function()’:
:16: error: parse error in template argument list

Used compiler version: gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2)
4.3 and 4.5 versions show the same behavior.

It seems, that in line 16 "forward <" is parsed as the beginning of a template
instantiation. To get this effect, the inclusion of , using namespace
std and using derived members in a template class is necessary. Maybe, using
namespace typically appears after template definition in other h-files, but a
scenario like this might occur. Apart from that: Would
"this->std::forward<...>" be valid C++ code?

Therefore, I think that is a bug in the parsers which neglects the occurrence
of this and starts to interpret forward as the std::forward template.

Regards,
Tobias Föhst

[Bug fortran/46838] [OOP] Wrong allocation status for polymorphic component INTENT(OUT) dummy

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2010-12-07 
17:00:19 UTC ---
Work here as expected - but I get:

==32139== Conditional jump or move depends on uninitialised value(s)
==32139==at 0x400A36: cdall.1593 (oop.f90:139)
==32139==by 0x400CCE: create_matrix.1606 (oop.f90:117)

Line 139 is:
if (allocated(desc%indxmap)) then

>From the dump:

cdall (struct desc_type & restrict desc)
struct desc_type D.1561;
struct desc_type desc_type.0;
desc_type.0.matrix_data = 0B;
D.1561 = *desc;
*desc = desc_type.0;
D.1561.matrix_data = 0B;
D.1561.indxmap._data = 0B;

  if (desc->indxmap._data != 0B)

The way one has to read it is as follows:

  D.1561 = *desc;   // Save pointers
  *dest = desc_type.0;  // Default initialize
  // free allocatables via D.1561

The freeing works OK (except for a missing deep freeing, which is a different
PR). However, the initializing does not work. There is a line missing which
reads:
desc_type.0.indxmap._data = 0B;

The initialization happens via gfc_init_default_dt, which uses sym->value.
Hence, the problem might be in resolve.c.

* * *

Modified version: If one changes indxmap into an array, one gets:

oop.f90:21:0: internal compiler error: in gfc_conv_descriptor_data_get, at
fortran/trans-array.c:144

* * *


Reduced test case:
module descriptor_type
  implicit none
  type  :: indx_map
  end type indx_map
  type desc_type
integer, allocatable  :: matrix_data
class(indx_map), allocatable :: indxmap
  end type desc_type
end module descriptor_type

program bug28
  use descriptor_type
  implicit none
  type(desc_type)   :: desc_a
  call cdall(desc_a)
contains
  subroutine cdall(desc)
type(desc_type), intent(out)  :: desc
if (allocated(desc%indxmap)) stop 'ERROR'
STOP 'OK'
  end subroutine cdall
end program bug28

[Bug c++/46836] reporting locations for names in std namespace could be improved

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46836

--- Comment #3 from Jonathan Wakely  2010-12-07 
16:48:56 UTC ---
(In reply to comment #2)
> On Tue, Dec 07, 2010 at 03:31:22PM +, redi at gcc dot gnu.org wrote:
> > It's not entirely trivial, because e.g. std::tuple_size is declared in more
> > than one place, and we have internal helpers which might be in namespace std
> > but probably don't want to be reported as being part of any standard header,
> > but I'd love to see this.
> 
> Wow, what entirely trivial implementation are you thinking of? :)

My first thought was just fudging it with
#line 1 ""

But it would be nice to do better than that!

[Bug middle-end/46837] induct compiled with -ffast-math -fschedule-insns -fsched-pressure -O3 ~30% slower

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46837

--- Comment #2 from Jack Howarth  2010-12-07 
16:48:11 UTC ---
The runtime performance reduction from...

gfortran -mtune=core2 -fschedule-insns -ffast-math -O3 induct.f90 -o induct

compared to...

gfortran -mtune=core2 -ffast-math -O3 induct.f90 -o induct

...is very confusing. According to the man page...

   -fschedule-insns
   If supported for the target machine, attempt to reorder instructions
to eliminate execution stalls due to required data
   being unavailable.  This helps machines that have slow floating
point or memory load instructions by allowing other
   instructions to be issued until the result of the load or floating
point instruction is required.

   Enabled at levels -O2, -O3.

So shouldn't this already be defaulted on by -O3 in the second case?

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

--- Comment #5 from H.J. Lu  2010-12-07 16:45:11 
UTC ---
(In reply to comment #2)
> Hmm, is it possible to do the change without breaking ABI (i.e. preserving the
> proper relative order for binary built with init_arra/fini_array linked with
> ctors/dtors library and vice versa?
> Honza

[...@gnu-6 46770]$ cat foo.c
#include 

static void
init ()
{
  printf ("init_array\n");
}

static void (*const init_array []) ()
  __attribute__ ((section (".init_array"), aligned (sizeof (void *
  = { init };

static void
fini ()
{
  printf ("fini_array\n");
}

static void (*const fini_array []) ()
  __attribute__ ((section (".fini_array"), aligned (sizeof (void *
  = { fini };

static void
ctor ()
{
  printf ("ctor\n");
}

static void (*const ctors []) ()
  __attribute__ ((section (".ctors"), aligned (sizeof (void *
  = { ctor };

static void
dtor ()
{
  printf ("dtor\n");
}

static void (*const dtors []) ()
  __attribute__ ((section (".dtors"), aligned (sizeof (void *
  = { dtor };

int
main ()
{
  printf ("main\n");
}
[...@gnu-6 46770]$ gcc foo.c
[...@gnu-6 46770]$ ./a.out 
ctor
init_array
main
fini_array
dtor
[...@gnu-6 46770]$

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mikestump at comcast dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749

--- Comment #42 from Mike Stump  2010-12-07 
16:42:04 UTC ---
Oh, one can use -Wl,-dsym in the time being with this patch.

[Bug fortran/46838] New: [OOP] Wrong allocation status for polymorphic component INTENT(OUT) dummy

[sfilippone at uniroma2 dot it]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46838

   Summary: [OOP] Wrong allocation status for polymorphic
component INTENT(OUT) dummy
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sfilipp...@uniroma2.it


Created attachment 22672
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22672
test-case

Hello,
At r167487 the polymorphic component of an INTENT(OUT) dummy starts as
ALLOCATED, which is obviously wrong. 
[sfili...@localhost bug28]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp
--with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc
: (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp
--with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc
: (reconfigured) ../gcc/configure --prefix=/usr/local/gnu46
--with-gmp=/home/travel/GCC/BUILDS/gmp --with-mpfr=/home/travel/GCC/BUILDS/mpfr
--with-mpc=/home/travel/GCC/BUILDS/mpc --enable-languages=c,c++,fortran,lto
--no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20101206 (experimental) (GCC) 
[sfili...@localhost bug28]$ gfortran -o bug28 bug28.f90
[sfili...@localhost bug28]$ ./bug28 
Generating Matrix (size=512)...
 Allocated on an intent(OUT) var?

[Bug tree-optimization/44676] [4.5/4.6 Regression] ICE: in loop_entry_phi_arg, at graphite-sese-to-poly.c:89 with -fgraphite-identity -fprofile-generate

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44676

Sebastian Pop  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Sebastian Pop  2010-12-07 
16:34:44 UTC ---
Fixed.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749

--- Comment #41 from mrs at gcc dot gnu.org  2010-12-07 
16:34:34 UTC ---
Yeah, I was thinking of letting them bake just a little bit.  -dsym would be
the only driver option, if we make it one.  Testing of the C languages and
fortran seems to have gone well on x86_64-darwin10.  java/ada/go weren't
tested, though, don't expect any issues with them.

[Bug debug/46796] debug info missing builtin type names with lto

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46796

--- Comment #8 from rguenther at suse dot de  
2010-12-07 16:32:57 UTC ---
On Tue, 7 Dec 2010, mrs at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46796
> 
> --- Comment #7 from mrs at gcc dot gnu.org  
> 2010-12-07 16:17:09 UTC ---
> Ok, I can confirm that ptype i is better, now, the next problem:
> 
> (gdb) ptype a1
> type = volatile __unknown__
> 
> :-(

Yeah, I saw that but didn't yet debug why it happens.

[Bug tree-optimization/44676] [4.5/4.6 Regression] ICE: in loop_entry_phi_arg, at graphite-sese-to-poly.c:89 with -fgraphite-identity -fprofile-generate

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44676

--- Comment #10 from Sebastian Pop  2010-12-07 
16:33:03 UTC ---
Author: spop
Date: Tue Dec  7 16:32:59 2010
New Revision: 167555

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167555
Log:
Add missing testcase for PR44676.

2010-12-07  Sebastian Pop  

PR tree-optimization/44676
* gcc.dg/graphite/id-pr44676.c: New.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/graphite/id-pr44676.c
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/44676] [4.5/4.6 Regression] ICE: in loop_entry_phi_arg, at graphite-sese-to-poly.c:89 with -fgraphite-identity -fprofile-generate

[spop at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44676

--- Comment #9 from Sebastian Pop  2010-12-07 16:27:33 
UTC ---
Author: spop
Date: Tue Dec  7 16:27:28 2010
New Revision: 167554

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167554
Log:
Add missing testcase for PR44676.

2010-12-07  Sebastian Pop  

PR tree-optimization/44676
* gcc.dg/graphite/id-pr44676.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/id-pr44676.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/46837] induct compiled with -ffast-math -fschedule-insns -fsched-pressure -O3 ~30% slower

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46837

--- Comment #1 from Jack Howarth  2010-12-07 
16:22:55 UTC ---
The -fschedule-insns option alone is sufficient to regress the induct
benchmark...

gfortran -mtune=core2 -fschedule-insns -ffast-math -O3 induct.f90 -o induct
15.57s
gfortran -mtune=core2 -ffast-math -O3 induct.f90 -o induct
12.42s

[Bug debug/46796] debug info missing builtin type names with lto

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46796

--- Comment #7 from mrs at gcc dot gnu.org  2010-12-07 
16:17:09 UTC ---
Ok, I can confirm that ptype i is better, now, the next problem:

(gdb) ptype a1
type = volatile __unknown__

:-(

[Bug tree-optimization/44676] [4.5/4.6 Regression] ICE: in loop_entry_phi_arg, at graphite-sese-to-poly.c:89 with -fgraphite-identity -fprofile-generate

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44676

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #8 from H.J. Lu  2010-12-07 16:00:37 
UTC ---
Missing testcases for both trunk and 4.5 branch.

[Bug rtl-optimization/46777] [4.5 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2164 with -O -fgcse -fno-tree-dominator-opts -funroll-loops

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46777

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2010-12-07 
15:55:12 UTC ---
Fixed.

[Bug c++/46836] reporting locations for names in std namespace could be improved

[froydnj at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46836

--- Comment #2 from froydnj at codesourcery dot com  2010-12-07 15:49:15 UTC ---
On Tue, Dec 07, 2010 at 03:31:22PM +, redi at gcc dot gnu.org wrote:
> It's not entirely trivial, because e.g. std::tuple_size is declared in more
> than one place, and we have internal helpers which might be in namespace std
> but probably don't want to be reported as being part of any standard header,
> but I'd love to see this.

Wow, what entirely trivial implementation are you thinking of? :)  I
guess you could augment the compiler to maintain an identifier->header
mapping, but I was thinking about doing it entirely on-the-fly, which
already strikes me as non-trivial.  (Identifiers declared in more that
one place and/or not in their intended header, etc.)

> If there's anything we can add to the libstdc++ headers to help this please 
> let
> us know, I'd be happy to work on that.

I'll do that, though I'm not planning on working on this right now.  The
only thing that comes to mind is something like:

#pragma GCC canonical_header [header-name] [identifier]

but that's just one idea from two minutes of thinking about it.

[Bug libgomp/45240] parallel.c: GOMP_parallel_end locks a mutex but fails to unlock it after atomic operation complete

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45240

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jakub Jelinek  2010-12-07 
15:45:53 UTC ---
Fixed.

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

H.J. Lu  changed:

   What|Removed |Added

Version|unknown |4.6.0
   Target Milestone|--- |4.6.0

[Bug rtl-optimization/46614] [4.5 Regression] gcc.dg/vect/vect-strided-u8-i8-gap4.c FAILs with -fno-rename-registers -fsched2-use-superblocks

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46614

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #12 from Jakub Jelinek  2010-12-07 
15:45:08 UTC ---
Fixed.

[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.07 15:44:50
 AssignedTo|unassigned at gcc dot   |hjl.tools at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #4 from H.J. Lu  2010-12-07 15:44:50 
UTC ---
Created attachment 22671
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22671
A patch

I am testing this patch.

[Bug middle-end/46499] [4.5 Regression] gcc.c-torture/execute/20051021-1.c FAILs with -fno-tree-dominator-opts -fno-tree-ccp

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46499

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jakub Jelinek  2010-12-07 
15:44:22 UTC ---
Fixed.