[Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2010-12-17 
08:55:06 UTC ---
Ah, the trick is that you keep the artificial PARM_DECL out of DECL_ARGUMENTS
as it was and manually add it in var-tracking.
To avoid dropping the DECL_NAME test you could perhaps give some artificial
name to this PARM_DECL and make it DECL_NAMELESS.

[Bug middle-end/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

[steven at gcc dot gnu.org]

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

--- Comment #5 from Steven Bosscher  2010-12-17 
09:19:51 UTC ---
The verification error happens after the 'phiprop' pass, and disappears with
-fno-tree-phiprop. Focusing on that pass now...

[Bug middle-end/45310] ICE: verify_stmts failed: Dead STMT in EH table with -O1 -fnon-call-exceptions

[steven at gcc dot gnu.org]

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

--- Comment #6 from Steven Bosscher  2010-12-17 
09:31:46 UTC ---
It seems to me that we should remove all traces of the deleted statements,
including EH info. Like so:

Index: tree-ssa-phiprop.c
===
--- tree-ssa-phiprop.c  (revision 167956)
+++ tree-ssa-phiprop.c  (working copy)
@@ -352,7 +352,7 @@ propagate_with_phi (basic_block bb, gimp
 want to delete it here we also have to delete all intermediate
 copies.  */
  gsi = gsi_for_stmt (use_stmt);
- gsi_remove (&gsi, false);
+ gsi_remove (&gsi, true);

  phi_inserted = true;
}

[Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2010-12-17 
09:44:03 UTC ---
Created attachment 22794
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22794
gcc46-pr46724-incremental.patch

Incremental patch for that.

BTW, the reason why a location list is used is because it is needed - it
doesn't cover the whole function, when inside of the abort call r2 might be
clobbered within the abort call.  Therefore the range ends at .LVL1 - 1 instead
of .LVL1 (end of function).

[Bug c++/46989] New: Mixing "-fprofile-arcs -ftest-coverage" and OpenMP triggers a bug

[sylvestre.ledru at inria dot fr]

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

   Summary: Mixing "-fprofile-arcs -ftest-coverage" and OpenMP
triggers a bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sylvestre.le...@inria.fr


With:
$ g++-4.5 -v
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-12'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold
--enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 20101210 (prerelease) (Debian 4.5.1-12) 

Create the following error
In file included from sci_gateway/cpp/sci_parallel_run.cpp:44:0:
./src/cpp/parallel_run.hxx: In function '':
./src/cpp/parallel_run.hxx:314:21: internal compiler error: in change_scope, at
cfglayout.c:429
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Note that using -v or -save-temps fixes the issue.

If it helps, the result with the verbose mode:
$ make CXX="g++-4.5" CXXFLAGS="-v"
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++-4.5 -DHAVE_CONFIG_H -I.
-I../../modules/core/includes  -fopenmp -I../../libs/MALLOC/includes/
-I./includes/ -I../../modules/core/includes -I./src/cpp/
-I../../modules/api_scilab/includes -I../../modules/output_stream/includes
-I../../modules/parameters/includes -I../../modules/dynamic_link/includes
-fprofile-arcs -ftest-coverage -DNDEBUG -fno-stack-protector
-I../../modules/core/includes/ -I../../libs/MALLOC/includes/
-I../../modules/localization/includes/  -v -MT
libsciparallel_la-sci_parallel_run.lo -MD -MP -MF
.deps/libsciparallel_la-sci_parallel_run.Tpo -c -o
libsciparallel_la-sci_parallel_run.lo `test -f
'sci_gateway/cpp/sci_parallel_run.cpp' || echo
'./'`sci_gateway/cpp/sci_parallel_run.cpp
libtool: compile:  g++-4.5 -DHAVE_CONFIG_H -I. -I../../modules/core/includes
-fopenmp -I../../libs/MALLOC/includes/ -I./includes/
-I../../modules/core/includes -I./src/cpp/ -I../../modules/api_scilab/includes
-I../../modules/output_stream/includes -I../../modules/parameters/includes
-I../../modules/dynamic_link/includes -fprofile-arcs -ftest-coverage -DNDEBUG
-fno-stack-protector -I../../modules/core/includes/
-I../../libs/MALLOC/includes/ -I../../modules/localization/includes/ -v -MT
libsciparallel_la-sci_parallel_run.lo -MD -MP -MF
.deps/libsciparallel_la-sci_parallel_run.Tpo -c
sci_gateway/cpp/sci_parallel_run.cpp  -fPIC -DPIC -o
.libs/libsciparallel_la-sci_parallel_run.o
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-12'
--with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold
--enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 20101210 (prerelease) (Debian 4.5.1-12) 
COLLECT_GCC_OPTIONS='-DHAVE_CONFIG_H' '-I.' '-I../../modules/core/includes'
'-fopenmp' '-I../../libs/MALLOC/includes/' '-I./includes/'
'-I../../modules/core/includes' '-I./src/cpp/'
'-I../../modules/api_scilab/includes' '-I../../modules/output_stream/includes'
'-I../../modules/parameters/includes' '-I../../modules/dynamic_link/includes'
'-fprofile-arcs' '-ftest-coverage' '-DNDEBUG' '-fno-stack-protector'
'-I../../modules/core/includes/' '-I../../libs/MALLOC/includes/'
'-I../../modules/localization/includes/' '-v' '-MT'
'libsciparallel_la-sci_parallel_run.lo' '-MD' '-MP' '-MF'
'.deps/libsciparallel_la-sci_parallel_run.Tpo' '-c' '-fPIC' '-DPIC' '-o'
'.libs/libsciparallel_la-sci_parallel_run.o' '-shared-libgcc' '-mtune=generic'
'-march=x86-6

[Bug fortran/46990] New: [OOP] gfortran rejects passing a CLASS variable to TYPE

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] gfortran rejects passing a CLASS variable to
TYPE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


In the following program a polymorphic dummy is passed as actual argument to a
non-polymorphic dummy of the declared type.

The program compiles with the ifort 11.1 and nagf95 5.1, but gfortran rejects
it with:
call two(x)
 1
Error: Type mismatch in argument 'x' at (1); passed CLASS(t) to TYPE(t)


Both compiler reject passing a CLASS(t2) variable to TYPE(t) or CLASS(t) to
TYPE(t2). (Where "t2" extends type "t".)

 * * *

>From the standard.

"The dummy argument shall be type compatible with the actual argument. If the
actual argument is a polymorphic coindexed object, the dummy argument shall not
be polymorphic." (F2008, 12.5.2.4)

"A nonpolymorphic entity is type compatible only with entities of the same
declared type." (4.3.1.3)

Thus, the dummy argument (a nonpolymorphic entitiy) is type compatible with
entities (i.e. actual actual arguments) of the same declared type.

 * * *

module m
  type t
integer :: i
  end type t
contains
  subroutine one(x)
class(t) :: x
call two(x)
  end subroutine one
  subroutine two(x)
type(t) :: x
  end subroutine two
end module m

[Bug debug/45088] pointer type information lost in debuginfo

[dodji at gcc dot gnu.org]

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

--- Comment #8 from Dodji Seketeli  2010-12-17 
10:39:23 UTC ---
Author: dodji
Date: Fri Dec 17 10:39:21 2010
New Revision: 167976

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167976
Log:
Fix for PR debug/45088

gcc/

* dwarf2out.c (gen_type_die_with_usage): Do not try to emit debug
info for a redundant typedef that has DECL_ORIGINAL_TYPE set. Use
that underlying type instead.

gcc/testsuite/

* g++.dg/debug/dwarf2/self-ref-1.C: New test.
* g++.dg/debug/dwarf2/self-ref-2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-1.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46991] New: [OOP] polymorphic assumed-size actual arguments

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] polymorphic assumed-size actual arguments
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Found at http://j3-fortran.org/pipermail/j3/2010-December/004084.html

Currently, it is unclear whether the following program is valid, but Robert
Corbett of Oracle (formerly Sun) thinks it is (but does not seem to like it.)

[100% guessing, 90% wrongly]: The main issue he sees is seemingly that SUB2
does not need to have an explicit interface - which only works if the $data of
a CLASS and a TYPE object start at the same offset of the passed pointer
address.

I think that part is OK in gfortran, but gfortran has other issues:


Gfortran rejects the program with:

CALL SUB2(A, N)
  1
Warning: Type mismatch in argument 'a' at (1); passed CLASS(rec) to TYPE(rec)

[That's PR 46990.] I also tried SELECT TYPE but with limited success.


Using
CLASS(REC) A(*)
one gets:
PRINT *, A(:N)%A
   1
Error: Syntax error in argument list at (1)


 * * *

   MODULE TYPES
 PRIVATE
 PUBLIC REC, REC2

 TYPE REC
   INTEGER A
 END TYPE

 TYPE, EXTENDS(REC) :: REC2
   INTEGER B
 END TYPE
   END

   SUBROUTINE SUB1(A, N)
 USE TYPES
 CLASS(REC), INTENT(IN) :: A(*)

 CALL SUB2(A, N)
   END

   SUBROUTINE SUB2(A, N)
 USE TYPES
 TYPE(REC) A(*)

 PRINT *, A(:N)%A
   END

   PROGRAM MAIN
 USE TYPES
 CLASS(REC), ALLOCATABLE :: A(:)
 INTERFACE
   SUBROUTINE SUB1(A, N)
 USE TYPES
 CLASS(REC), INTENT(IN) :: A(*)
   END SUBROUTINE
 END INTERFACE

 A = [ (REC2(I, I+1), I = 1, 10) ]
 CALL SUB1(A, 10)
   END

[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2010-12-17 
10:46:09 UTC ---
Created attachment 22795
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22795
gcc46-pr39213.patch

I wonder if this wouldn't fix it (at least, that's similar to how lex.c guards
calling of _cpp_process_line_notes).  I can't reproduce it myself, so have to
guess...

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[bitti at iki dot fi]

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

Matti Rintala  changed:

   What|Removed |Added

 CC||bitti at iki dot fi

--- Comment #12 from Matti Rintala  2010-12-17 11:21:06 
UTC ---
Has there been any progress with this bug/problem? The latest C++0x draft still
explicitly allows "array a = { initializer-list };" (23.3.1/2), but at
least gcc 4.5.1 still gives a warning with -Wall enabled.

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
   |com |gnu.org

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2010-12-17 
11:33:48 UTC ---
GCC allows it too, otherwise it would be an error not a warning.

But no, there hasn't been any progress I know of, the warning is still given
for std::array in C++0x mode as well as tr1::array

[Bug tree-optimization/46985] [4.4/4.5/4.6 Regression] ICE: SIGSEGV in is_gimple_min_invariant (gimple.c:2742) with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.17 12:05:09
 CC||jakub at gcc dot gnu.org,
   ||spop at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2010-12-17 
12:05:09 UTC ---
instantiate_scev_r is called on:
{&tar[ptr$dim$0$lbound_81 + -1].i, +, 4}_3
and the problem is with that COMPONENT_REF inside of it.  COMPONENT_REF has 3
operands, but the last one is optional (there are lots of other trees like
that),
but instantiate_scev_r/instantiate_scev_[123] assume all operands must be
non-NULL.

So, one possible fix would be to:
   if (automatically_generated_chrec_p (chrec)
+  || chrec == NULL
   || is_gimple_min_invariant (chrec))
 return chrec;
at the beginning of instantiate_scev_r.  Or maybe it is just wrong to call
instantiate_scev_r with such arguments and the bug is earlier.

[Bug middle-end/46900] [4.6 Regression] 50% slowdown when linking with LTO in a single step

[d.g.gorbachev at gmail dot com]

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

--- Comment #7 from Dmitry Gorbachev  
2010-12-17 12:13:54 UTC ---
> Thus, the "-march=native" somehow gets
> lost in the single-step compile.

PR42445 ?

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

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

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.5.2

--- Comment #5 from Hin-Tak Leung  
2010-12-17 12:22:08 UTC ---
(In reply to comment #4)
> GCC 4.5.2 is being released, adjusting target milestone.

same problem with 4.5.2:

CONFIG_SHELL=/usr/local/bin/bash ../gcc-4.5.2/configure &&
CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make
...
make[2]: Entering directory `/home/htl10/tmp-build/gcc-452-obj'
make[3]: Entering directory `/home/htl10/tmp-build/gcc-452-obj'
rm -f stage_current
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-452-obj'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/java/win32-host.o differs
gcc/build/min-insn-modes.o differs
gcc/dummy-checksum.o differs
gcc/insn-peep.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/graphite-dependences.o differs
gcc/graphite-interchange.o differs
gcc/graphite-poly.o differs
gcc/graphite-ppl.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-sese-to-poly.o differs
gcc/loop-doloop.o differs
gcc/version.o differs
gcc/vmsdbgout.o differs
gcc/xcoffout.o differs
gcc/host-default.o differs
gcc/gcc-options.o differs
gcc/collect2-aix.o differs
intl/osdep.o differs
libiberty/safe-ctype.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-452-obj'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-452-obj'
make: *** [all] Error 2
bash-2.05a#

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  2010-12-17 
12:22:50 UTC ---
I'm sorry I don't mean to wrk on this over the next weeks, maybe sombody will
ne interested in picking my patch in this thread and completing it (both for C
and C++): http://gcc.gnu.org/ml/gcc/2009-11/msg00430.html
http://gcc.gnu.org/ml/gcc/2009-11/msg00468.html

[Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2010-12-17 12:31:57 UTC ---
Author: janus
Date: Fri Dec 17 12:31:54 2010
New Revision: 167978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167978
Log:
2010-12-17  Janus Weil  
Tobias Burnus 

PR fortran/46849
* resolve.c (resolve_symbol): Remove symbols that wrongly ended up
in a local BLOCK namespace.

2010-12-17  Janus Weil  

PR fortran/46849
* gfortran.dg/block_9.f08: New.

Added:
trunk/gcc/testsuite/gfortran.dg/block_9.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46849] [OOP] MODULE PROCEDURE resolution does not work in BLOCK or SELECT TYPE

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2010-12-17 12:34:11 UTC ---
r167978 fixes the rejects-valid part, i.e. comment #3.

ToDo: ICE-on-invalid in comment #2.

[Bug middle-end/46500] target.h includes tm.h

[amylaar at gcc dot gnu.org]

wise.
* config/s390/s390.c (s390_call_saved_register_used): Likewise.
* config/sh/sh.c (sh_output_mi_thunk): Likewise.
* config/microblaze/microblaze.c (microblaze_expand_prologue): Likewise.
* config/m32r/m32r.c (m32r_return_in_memory): Adjust for changed
m32r_pass_by_reference.
* config/spu/spu.c (spu_gimplify_va_arg_expr): Adjust for changed
spu_pass_by_reference.
gcc/c-family:
* c-opts.c: Include "tm.h" .
gcc/java:
* expr.c: Include "tm.h" .
gcc/fortran:
* trans-types.c: Include "tm.h" .

Modified:
branches/pr46489-20101217-branch/gcc/ChangeLog.46489
branches/pr46489-20101217-branch/gcc/c-family/c-opts.c
branches/pr46489-20101217-branch/gcc/calls.c
branches/pr46489-20101217-branch/gcc/config/alpha/alpha.c
branches/pr46489-20101217-branch/gcc/config/arc/arc.c
branches/pr46489-20101217-branch/gcc/config/arm/arm.c
branches/pr46489-20101217-branch/gcc/config/avr/avr.c
branches/pr46489-20101217-branch/gcc/config/bfin/bfin.c
branches/pr46489-20101217-branch/gcc/config/cris/cris.c
branches/pr46489-20101217-branch/gcc/config/crx/crx.c
branches/pr46489-20101217-branch/gcc/config/fr30/fr30.c
branches/pr46489-20101217-branch/gcc/config/frv/frv.c
branches/pr46489-20101217-branch/gcc/config/h8300/h8300.c
branches/pr46489-20101217-branch/gcc/config/i386/i386.c
branches/pr46489-20101217-branch/gcc/config/ia64/ia64.c
branches/pr46489-20101217-branch/gcc/config/iq2000/iq2000.c
branches/pr46489-20101217-branch/gcc/config/lm32/lm32.c
branches/pr46489-20101217-branch/gcc/config/m32c/m32c.c
branches/pr46489-20101217-branch/gcc/config/m32r/m32r.c
branches/pr46489-20101217-branch/gcc/config/m68hc11/m68hc11.c
branches/pr46489-20101217-branch/gcc/config/m68k/m68k.c
branches/pr46489-20101217-branch/gcc/config/mcore/mcore.c
branches/pr46489-20101217-branch/gcc/config/mep/mep.c
branches/pr46489-20101217-branch/gcc/config/microblaze/microblaze.c
branches/pr46489-20101217-branch/gcc/config/mips/mips.c
branches/pr46489-20101217-branch/gcc/config/mmix/mmix.c
branches/pr46489-20101217-branch/gcc/config/mn10300/mn10300.c
branches/pr46489-20101217-branch/gcc/config/moxie/moxie.c
branches/pr46489-20101217-branch/gcc/config/pa/pa.c
branches/pr46489-20101217-branch/gcc/config/pdp11/pdp11.c
branches/pr46489-20101217-branch/gcc/config/picochip/picochip.c
branches/pr46489-20101217-branch/gcc/config/rs6000/rs6000.c
branches/pr46489-20101217-branch/gcc/config/rx/rx.c
branches/pr46489-20101217-branch/gcc/config/s390/s390.c
branches/pr46489-20101217-branch/gcc/config/score/score-protos.h
branches/pr46489-20101217-branch/gcc/config/score/score.c
branches/pr46489-20101217-branch/gcc/config/sh/sh.c
branches/pr46489-20101217-branch/gcc/config/sparc/sparc.c
branches/pr46489-20101217-branch/gcc/config/spu/spu-protos.h
branches/pr46489-20101217-branch/gcc/config/spu/spu.c
branches/pr46489-20101217-branch/gcc/config/stormy16/stormy16.c
branches/pr46489-20101217-branch/gcc/config/v850/v850.c
branches/pr46489-20101217-branch/gcc/config/vax/vax.c
branches/pr46489-20101217-branch/gcc/config/xtensa/xtensa.c
branches/pr46489-20101217-branch/gcc/doc/tm.texi
branches/pr46489-20101217-branch/gcc/dse.c
branches/pr46489-20101217-branch/gcc/expr.c
branches/pr46489-20101217-branch/gcc/fortran/trans-types.c
branches/pr46489-20101217-branch/gcc/function.c
branches/pr46489-20101217-branch/gcc/java/expr.c
branches/pr46489-20101217-branch/gcc/target.def
branches/pr46489-20101217-branch/gcc/target.h
branches/pr46489-20101217-branch/gcc/targhooks.c
branches/pr46489-20101217-branch/gcc/targhooks.h

[Bug tree-optimization/46985] [4.4/4.5/4.6 Regression] ICE: SIGSEGV in is_gimple_min_invariant (gimple.c:2742) with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2010-12-17 
12:53:28 UTC ---
This is called when constant_after_peeling is called on:
D.1682_40 = &tar[0].i + D.1683_39;
(&tar[0].i is is_gimple_min_invariant).  Folding folds
&tar[0].i p+ () ((ptr$dim$0$lbound_81 + -1) * 4)
into the COMPONENT_REF's operand.

[Bug middle-end/46761] [4.6 Regression] -fgraphite-identity produces wrong code for array initialization arr[i] = i

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  2010-12-17 
12:55:03 UTC ---
Author: amonakov
Date: Fri Dec 17 12:54:59 2010
New Revision: 167980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167980
Log:
PR middle-end/46761
* graphite-clast-to-gimple.c (graphite_create_new_loop_guard): Prefer
to use unadjusted UB.

testsuite:
* gcc.dg/graphite/pr46761.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr46761.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-clast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/46761] [4.6 Regression] -fgraphite-identity produces wrong code for array initialization arr[i] = i

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Alexander Monakov  2010-12-17 
12:57:27 UTC ---
A different patch was committed after the review.  Closing as fixed.

[Bug tree-optimization/46985] [4.4/4.5/4.6 Regression] ICE: SIGSEGV in is_gimple_min_invariant (gimple.c:2742) with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Jakub Jelinek  2010-12-17 
13:01:51 UTC ---
Created attachment 22796
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22796
gcc46-pr46985.patch

Untested fix.

[Bug tree-optimization/46987] [4.6 Regression] g++.dg/torture/covariant-1.C ICE: double free or corruption with -fno-inline

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.17 13:27:32
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-12-17 13:27:32 
UTC ---
It is caused by revision 167855:

http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00537.html

I got

*** glibc detected ***
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus:
double free or corruption (!prev): 0x01bd6490 ***
=== Backtrace: =
/lib64/libc.so.6(+0x78db3)[0x77482db3]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus[0xd69312]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus[0xd71f26]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(execute_one_pass+0x1da)[0xb741a2]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(execute_pass_list+0x41)[0xb74391]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(execute_pass_list+0x62)[0xb743b2]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(tree_rest_of_compilation+0x10a)[0xcfc7a8]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus[0xf9b0f5]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus[0xf9b2b4]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(cgraph_optimize+0x1bb)[0xf9b8e9]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(cgraph_finalize_compilation_unit+0x63)[0xf99433]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(cp_write_global_declarations+0x146f)[0x60ed22]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus[0xc6a1ee]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus[0xc6c2e9]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(toplev_main+0x121)[0xc6c436]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus(main+0x20)[0x808b98]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x77428dfd]
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus[0x48cbd9]
=== Memory map: 
0040-01841000 r-xp  08:21 7538315   
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus
01a4-01a4b000 rw-p 0144 08:21 7538315   
/export/gnu/import/rrs/167895/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus
01a4b000-01c23000 rw-p  00:00 0  [heap]
3f4ac0-3f4acba000 r-xp  08:07 27630 
/usr/lib64/libppl.so.7.1.0
3f4acba000-3f4aeb9000 ---p 000ba000 08:07 27630 
/usr/lib64/libppl.so.7.1.0
3f4aeb9000-3f4aebc000 rw-p 000b9000 08:07 27630 
/usr/lib64/libppl.so.7.1.0
3f4b00-3f4b003000 r-xp  08:07 26888 
/usr/lib64/libgmpxx.so.4.1.2
3f4b003000-3f4b203000 ---p 3000 08:07 26888 
/usr/lib64/libgmpxx.so.4.1.2
3f4b203000-3f4b204000 rw-p 3000 08:07 26888 
/usr/lib64/libgmpxx.so.4.1.2
3f4b40-3f4b42 r-xp  08:07 26584 
/usr/lib64/libcloog.so.0.0.0
3f4b42-3f4b61f000 ---p 0002 08:07 26584 
/usr/lib64/libcloog.so.0.0.0
3f4b61f000-3f4b62 rw-p 0001f000 08:07 26584 
/usr/lib64/libcloog.so.0.0.0
3f4b62-3f4b622000 rw-p  00:00 0 
3f4c00-3f4c366000 r-xp  08:07 16831 
/usr/lib64/libppl_c.so.2.1.0
3f4c366000-3f4c565000 ---p 00366000 08:07 16831 
/usr/lib64/libppl_c.so.2.1.0
3f4c565000-3f4c569000 rw-p 00365000 08:07 16831 
/usr/lib64/libppl_c.so.2.1.0
3f4c569000-3f4c56a000 rw-p  00:00 0 
3f4cc0-3f4cc4d000 r-xp  08:07 27185 
/usr/lib64/libmpfr.so.1.2.2
3f4cc4d000-3f4ce4c000 ---p 0004d000 08:07 27185 
/usr/lib64/libmpfr.so.1.2.2
3f4ce4c000-3f4ce4e000 rw-p 0004c000 08:07 27185 
/usr/lib64/libmpfr.so.1.2.2
3f5480-3f54857000 r-xp  08:07 27019 
/usr/lib64/libgmp.so.3.5.2
3f54857000-3f54a57000 ---p 00057000 08:07 27019 
/usr/lib64/libgmp.so.3.5.2
3f54a57000-3f54a59000 rw-p 00057000 08:07 27019 
/usr/lib64/libgmp.so.3.5.2
70c94000-70ddd000 rw-p 

[Bug tree-optimization/46984] [4.6 Regression] g++.dg/torture/pr45699.C FAILs with -fno-early-inlining -flto

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.17 13:48:15
 CC||hubicka at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Martin Jambor  2010-12-17 
13:48:15 UTC ---
I added thunk_delta streaming to analysis streaming and not decision
streaming, which of course cannot work.  Serves me right for not
testing lto.

I'll move the delta to struct cgraph_edge as a HOST_WIDE_INT.
Mine.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[howarth at nitro dot med.uc.edu]

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

--- Comment #88 from Jack Howarth  2010-12-17 
13:50:40 UTC ---
(In reply to comment #85)
> Created attachment 22787 [details]
> updated #2 darwin candidate function sect. patch
> 
> 
>   o  I think that the "no debug symbols" is down to missing pub sections
> investigating.
> 
...
> 
>   o .. so at the moment Darwin10 fails on partition2.C ... for the reasons
> above.
> 

Iain,
   Do you think the "no debug symbols" warnings in the partition2.C test case
on darwin10 are the caused by the same issue (lack of pub symbols) as those
additional instances caused by honza'a patch? Also, do we see any additional
failures beyond those warnings when honza'a patch is added onto this current
darwin patch?

[Bug tree-optimization/46987] [4.6 Regression] g++.dg/torture/covariant-1.C ICE: double free or corruption with -fno-inline

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Martin Jambor  2010-12-17 
13:58:21 UTC ---
Yes, I know.  Mine.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[dominiq at lps dot ens.fr]

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

--- Comment #89 from Dominique d'Humieres  
2010-12-17 14:08:12 UTC ---
(In reply to comment #88)
> Iain,
>Do you think the "no debug symbols" warnings in the partition2.C test case
> on darwin10 are the caused by the same issue (lack of pub symbols) as those
> additional instances caused by honza'a patch? Also, do we see any additional
> failures beyond those warnings when honza'a patch is added onto this current
> darwin patch?

I think you should analyse comment #42. If I did not do any mistake, the
partition2.C test is unsupported with current trunk, but becomes supported with
any of the patches in this PR. If this is correct, it means that these patches
change something in the testsuite machinery (e.g., a failing test becomes
successful).
In this case one should find what is this change, then assess if the test has
to be supported or not. For the former case, the failure will have to be fixed,
but in the later case only some test(s) in some *.exp file will have to be
fixed.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #90 from Iain Sandoe  2010-12-17 14:21:00 
UTC ---
(In reply to comment #89)
> (In reply to comment #88)
> > Iain,
> >Do you think the "no debug symbols" warnings in the partition2.C test 
> > case
> > on darwin10 are the caused by the same issue (lack of pub symbols) as those
> > additional instances caused by honza'a patch? Also, do we see any additional
> > failures beyond those warnings when honza'a patch is added onto this current
> > darwin patch?
> 
> I think you should analyse comment #42. If I did not do any mistake, the
> partition2.C test is unsupported with current trunk, but becomes supported 
> with
> any of the patches in this PR. If this is correct, it means that these patches
> change something in the testsuite machinery (e.g., a failing test becomes
> successful).

well, this change is the likely difference:

+  if (opts->x_flag_reorder_blocks_and_partition
+  && !opts_set->x_flag_reorder_functions)
+opts->x_flag_reorder_functions = 1;

as far as whether Darwin10 supports -freorder-blocks-and-partition
- there should be no difference before/after the patch (darwin < 10 should not
support at present).

It would be interesting to know why the test claims to be 'unsupported' for
current trunk (except that it would fail because of this bug).

// { dg-require-effective-target freorder }
// { dg-options "-fnon-call-exceptions -freorder-blocks-and-partition" }

you would have to back out of the patches and the change that causes the fault
.. if the test still claims to be unsupported - that implies something
different (again, not related to the current bug).

In any event the two remaining issues need resolution -- I suspect they are
causing fallout elsewhere.
... I just don't see the point in swelling this patch to solve those .. 

the intention of this patch is to get correct function section selection for
Darwin.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[dominiq at lps dot ens.fr]

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

--- Comment #91 from Dominique d'Humieres  
2010-12-17 14:31:18 UTC ---
(In reply to comment #90)
> ... In any event the two remaining issues need resolution -- I suspect they 
> are
> causing fallout elsewhere.
> ... I just don't see the point in swelling this patch to solve those .. 

I agree that it is likely an other issue for which a new PR should be opened
and that this PR has now grown out of proportion ans should be closed ASAP (BTW
x86_64-darwin10, full test, and powerpc-apple-darwin9, c++ and libstdc++-v3,
regtested fine).

> the intention of this patch is to get correct function section selection for
> Darwin.

[Bug c++/46989] Mixing "-fprofile-arcs -ftest-coverage" and OpenMP triggers a bug

[sylvestre.ledru at inria dot fr]

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

--- Comment #1 from Sylvestre Ledru  
2010-12-17 14:40:30 UTC ---
Created attachment 22797
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22797
sci_parallel_run.ii


I have been able to reproduce this issue with -v or -save-temps

[Bug c++/46989] Mixing "-fprofile-arcs -ftest-coverage" and OpenMP triggers a bug

[sylvestre.ledru at inria dot fr]

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

--- Comment #2 from Sylvestre Ledru  
2010-12-17 14:41:11 UTC ---
Created attachment 22798
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22798
sci_parallel_run.s

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[howarth at nitro dot med.uc.edu]

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

--- Comment #92 from Jack Howarth  2010-12-17 
14:47:01 UTC ---
  Don't forget about PR45646 where we used to fail
g++.dg/tree-prof/partition2.C with a linker error of...

ld: in /var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccVrX7dM.o, section
not found for address 0x696765625F617863

This disappeared between r166079 and r166156 for unknown reasons. The bug may
have went latent and could be related.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[howarth at nitro dot med.uc.edu]

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

--- Comment #93 from Jack Howarth  2010-12-17 
14:59:30 UTC ---
(In reply to comment #90)

> as far as whether Darwin10 supports -freorder-blocks-and-partition
> - there should be no difference before/after the patch (darwin < 10 should not
> support at present).
> 

Are you sure that we still need to disable -freorder-blocks-and-partition on
darwin <10? I thought the only reason we did that was because of the duplicate
eh label symbols emitted from darwin_emit_unwind_label. Now that you have those
properly renamed for the hot and cold partitions, this issue should be solved.

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #94 from Iain Sandoe  2010-12-17 15:03:38 
UTC ---
(In reply to comment #93)
> (In reply to comment #90)
> 
> > as far as whether Darwin10 supports -freorder-blocks-and-partition
> > - there should be no difference before/after the patch (darwin < 10 should 
> > not
> > support at present).
> > 
> 
> Are you sure that we still need to disable -freorder-blocks-and-partition on
> darwin <10? I thought the only reason we did that was because of the duplicate
> eh label symbols emitted from darwin_emit_unwind_label. Now that you have 
> those
> properly renamed for the hot and cold partitions, this issue should be solved.

I decided to maintain the status quo (modulo external changes).  

-- Some partitioning will fail on D9 for the same reasons as D10
-- once we've sorted out the other two problems 
(I agree with Dominique, they should be two additional separate PRs)
-- then it is a one-line patch to enable for D9.

[Bug c++/46852] [4.6 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in cp_parser_class_specifier, at cp/parser.c:16947

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Nathan Froyd  2010-12-17 
15:14:03 UTC ---
Fixed.

[Bug fortran/46794] ICE on valid code involving power of small integer kinds

[domob at gcc dot gnu.org]

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

--- Comment #7 from Daniel Kraft  2010-12-17 15:30:02 
UTC ---
Author: domob
Date: Fri Dec 17 15:29:55 2010
New Revision: 167990

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167990
Log:
2010-12-17  Daniel Kraft  

PR fortran/46794
* gfortran.dg/power2.f90: Initialize variables.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/power2.f90

[Bug fortran/46794] ICE on valid code involving power of small integer kinds

[domob at gcc dot gnu.org]

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

Daniel Kraft  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Daniel Kraft  2010-12-17 15:32:32 
UTC ---
Fixed on 4.5 and 4.4, also.

[Bug c++/46992] New: [4.6 Regression] [C++0x] ICE: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2452

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] [C++0x] ICE: tree check: expected
record_type or union_type or qual_union_type, have
template_type_parm in lookup_conversions, at
cp/search.c:2452
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


-- testcase.C --
extern int array[];

template < typename T > 
void foo (T t)
{
  array[(unsigned)t];
}


Compiler output:
$ gcc -std=c++0x testcase.C
testcase.C: In function 'void foo(T)':
testcase.C:6:21: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2452
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r167954 - crash
r167898 - crash
r165699 - OK
4.5 r166509 - OK

[Bug c++/46992] [4.6 Regression] [C++0x] ICE: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2452

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.17 15:54:53
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2010-12-17 
15:54:53 UTC ---
Let's add Jason in CC.

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-12-17 16:09:09 UTC ---
> --- Comment #6 from Benjamin Kosnik  2010-12-16 
> 22:49:23 UTC ---
>
> Does this still happen if -g is removed? (Via -g0)

I've manually checked for

FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not
_ZNSt23enable_shared_from_thisIiEC2Ev
FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not
_ZN7derivedC2Ev

Both symbols only occur in stabs, but are gone with -g0.  I've found no
easy way to compile the tests with -g0 from runtest, though.  Setting
DEFAULT_CXXFLAGS=-g0 either on the runtest command line or in site.exp
seems to have no effect.

Rainer

[Bug c++/46992] [4.6 Regression] [C++0x] ICE: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2452

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2010-12-17 16:09:44 
UTC ---
It is caused by revision 166167:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html

[Bug tree-optimization/46987] [4.6 Regression] g++.dg/torture/covariant-1.C ICE: double free or corruption with -fno-inline

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  2010-12-17 
16:12:25 UTC ---
I've nailed this down to

  gimple_call_set_arg (call_stmt, 0, tmp);

in gimple_adjust_this_by_delta.  When I comment it out, the corruption
goes away (though the produced code is of course wrong).  Otherwise it
all blows up later in tree-ssa-ccp.  (The new parameter is a result of
a new PTR_PLUS with a thunk delta which is a constant).

But I don't see anything wrong with gimple_adjust_this_by_delta, at
least not at the moment...

[Bug target/44332] ICE: in copy_to_mode_reg, at explow.c:623 with -mno-sse2

[serowk at yandex dot ru]

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

serowk at yandex dot ru changed:

   What|Removed |Added

 CC||serowk at yandex dot ru

--- Comment #3 from serowk at yandex dot ru 2010-12-17 16:13:45 UTC ---
Appears with arm-iwmmx-linux-uclibcgnueabi-gcc 4.4.5

1.c:
#include 
#include 
#include 

__m64  do_some(__m64 a, int64_t count)
{
return _mm_srli_pi16(a, count);
}

int main()
{
__m64 a=(__m64)222LL;
int64_t b=8;

b=(int64_t)do_some(a, b);
printf("%lli\n", b);

return 0;
}

$ arm-iwmmx-linux-uclibcgnueabi-gcc 1.c -flax-vector-conversions
In file included from 1.c:1:
/opt/arm-iwmmx-linux-uclibcgnueabi/lib/gcc/arm-iwmmx-linux-uclibcgnueabi/4.4.5/include/mmintrin.h:
In function '_mm_srli_pi16':
/opt/arm-iwmmx-linux-uclibcgnueabi/lib/gcc/arm-iwmmx-linux-uclibcgnueabi/4.4.5/include/mmintrin.h:526:
internal compiler error: in copy_to_mode_reg, at explow.c:623
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[serowk at yandex dot ru]

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

--- Comment #11 from serowk at yandex dot ru 2010-12-17 16:16:28 UTC ---
Created attachment 22799
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22799
gcc 35294 possible Fix

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[serowk at yandex dot ru]

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

--- Comment #12 from serowk at yandex dot ru 2010-12-17 16:17:07 UTC ---
Created attachment 22800
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22800
gcc 4.4.5 possible fix

[Bug tree-optimization/46970] [4.3/4.4/4.5/4.6 Regression] wrong code with -Os -ftree-loop-linear

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2010-12-17 
16:17:39 UTC ---
I think the bug is in that gcc_loop_to_lambda_loop doesn't record whether the
SSA_NAME compared in the exit condition was the induction var or incremented
induction var.
E.g. on ltrans-3.c testcase we have
:
  # j_25 = PHI 
...
  j_15 = j_25 + 1;
  if (N.2_3 > j_15)
goto ;
  else
goto ;
and thus the exit condition tests the incremented iv (gcc_loop_to_lambda_loop
btw. doesn't bother to check whether the def stmt of the rhs of exit condition
here actually increments by step, and doesn't bother to check that step fits
into int (so I guess step like 0x10001ULL would cause trouble).
It just records lower bound 0, upper bound N.2_3 - 1 here and step 1.
But with -Os -ftree-loop-linear on this testcase we have before ltrans:
  j_12 = j_2 + 1;

:
  # j_2 = PHI <0(7), j_12(3)>
  if (j_2 < n_5(D))
goto ;
  else
goto ;
Here similarly it records lower bound 0, upper bound n_5 - 1 and step 1.
But there is an important difference in between the two.
In the former case we correctly use
  gimple_cond_set_condition (exitcond, testtype, newupperbound, ivvarinced);
but we use it in the second case too, which is wrong.

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[serowk at yandex dot ru]

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

--- Comment #13 from serowk at yandex dot ru 2010-12-17 16:22:36 UTC ---
I have attached two versions of the patch (gcc 4.2.4 and gcc 4.4.5). Patched
gcc 4.2.4 seems to work. With the patched gcc 4.4.5, I ran into bug 44332, and
can not check. For arm platform newer versions of gcc seems more completely
ubusabled.

[Bug c++/46890] [4.6 Regression] Failed to compile scummvm's player_v4a.cpp

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||froydnj at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |froydnj at gcc dot gnu.org
   |gnu.org |

[Bug target/46993] New: Optimization on i386 lead to user-visible traps during floating-point operations

[arseny.klimovsky at gmail dot com]

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

   Summary: Optimization on i386 lead to user-visible traps during
floating-point operations
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arseny.klimov...@gmail.com


Version:
$ g++-4.5.2 -v
Using built-in specs.
COLLECT_GCC=g++-4.5.2
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.2/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5.2/configure --prefix /opt/gcc-4.5.2/
Thread model: posix
gcc version 4.5.2 (GCC)

Command:
$ g++ -m32 -fsignaling-nans -O1 -c -S -o simple.s simple.cpp 

Consider a simple function, which copies one value from double array c to
double array a.

#include 
void copy (double * a, double * c)
{
  double b[100];
  memcpy (b, c, sizeof (double));
  memcpy (a, b, sizeof (double));
}

This will generate code
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
movl%esp, %ebp
.cfi_offset 5, -8
.cfi_def_cfa_register 5
movl12(%ebp), %eax
fldl(%eax)
movl8(%ebp), %eax
fstpl   (%eax)
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc

Here, if c[0] is a NaN, and FPU exception mask is set, an FPE will occur.
In gcc 4.4 and earlier I could use memcpy instead of operator= to be sure, that
no floating point operations will be generated.
Now I don't know how to safely copy values from local double buffer (or a
single variable) to some address without floating point operations.

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2010-12-17 
17:00:59 UTC ---
Maybe I'm missing something: can't we just add -g0 to the dg-options string?

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-12-17 17:02:53 UTC ---
> --- Comment #9 from Paolo Carlini  
> 2010-12-17 17:00:59 UTC ---
> Maybe I'm missing something: can't we just add -g0 to the dg-options string?

Sure, I just wanted to check the effect of -g0 without modifying the
testcases yet.

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2010-12-17 
17:06:47 UTC ---
I see. I think you want to change libstdc++.exp then.

[Bug tree-optimization/46939] http://blog.regehr.org/archives/320 example 6

[regehr at cs dot utah.edu]

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

--- Comment #8 from John Regehr  2010-12-17 17:11:05 
UTC ---
Here is the current performance that we measure, in cycles:

gcc-head: 43
icc: 41
clang-head: 41
suncc: 42

[Bug tree-optimization/46970] [4.3/4.4/4.5/4.6 Regression] wrong code with -Os -ftree-loop-linear

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2010-12-17 
17:14:01 UTC ---
Created attachment 22801
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22801
gcc46-pr46970.patch

Untested patch that fixes this and keeps ltrans-3.c working.

I don't feel very good about the +-1 * stepint extra adjustments the code did
and still does though, I'm afraid there could be problems with that if there is
an overflow, but it would be much more work to adjust lambda-code.c so that it
deals with this properly.

[Bug c++/46778] More SFINAE issues?

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2010-12-17 
17:40:46 UTC ---
Jason, sorry for bothering: I would be interested in knowing in particular your
opinion about t4, where is_constructible_mini "returns" true, that is, isn't
just that errors are not suppressed (ie, more than just tsubst_flags_t
arguments not propagated)

[Bug c++/46670] [4.6 Regression] ICE in dependent_type_p, at cp/pt.c:17553

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2010-12-17 
17:47:32 UTC ---
Author: jason
Date: Fri Dec 17 17:47:27 2010
New Revision: 167993

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167993
Log:
PR c++/46670
* pt.c (value_dependent_expression_p) [ARRAY_REF]: Handle
properly.

Added:
trunk/gcc/testsuite/g++.dg/constexpr-null1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  2010-12-17 
17:51:23 UTC ---
or CXXFLAGS_default in scripts/testsuite_flags ?

[Bug tree-optimization/46994] New: [4.6 Regression] ICE: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:422 with -fgraphite-identity -fno-tree-dce -ffast-math

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:422 with -fgraphite-identity
-fno-tree-dce -ffast-math
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22802
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22802
reduced testcase (from pr42180.f90)

Compiler output:
$ gcc -O -ffast-math -fgraphite-identity -fno-tree-dce pr46994.f90 
pr46994.f90: In function 'foo':
pr46994.f90:1:0: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:422
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r167954 - crash
r165699 - OK
4.5 r166509 - OK

[Bug fortran/46978] [4.6 Regression] TRANSPOSE with RESHAPE and ALLOCATE: Segfault

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin  2010-12-17 
19:28:36 UTC ---
(In reply to comment #4)
> Thus, a good candidate would be the TRANSFER rewriting patch for PR 45648.
> 
You mean the TRANSPOSE rewriting patch.
I was hoping not to be the culprit before I looked at the ChangeLog myself. :-(


Thanks for reducing, I'm taking a look.

[Bug tree-optimization/46994] [4.6 Regression] ICE: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:422 with -fgraphite-identity -fno-tree-dce -ffast-math

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.17 19:44:44
 CC||matz at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-12-17 19:44:44 
UTC ---
It is caused by revision 167184:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg01074.html

[Bug tree-optimization/46995] New: [4.6 Regression] ICE: verify_ssa failed: definition in block 11 does not dominate use in block 16 with -fgraphite-identity -fno-tree-dce -ffast-math

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: verify_ssa failed: definition in
block 11 does not dominate use in block 16 with
-fgraphite-identity -fno-tree-dce -ffast-math
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: s...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22803
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22803
reduced testcase (from pr42180.f90)

Testcase is very similiar to PR46994, and flags are the same.

Compiler output:
$ gcc -O -ffast-math -fgraphite-identity -fno-tree-dce pr46995.f90 
pr46995.f90: In function 'foo':
pr46995.f90:1:0: error: definition in block 11 does not dominate use in block
16
for SSA_NAME: s_10 in statement:
s_7 = s_10;
pr46995.f90:1:0: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r167954 - crash
r165699 - OK
4.5 r166509 - OK

[Bug tree-optimization/46995] [4.6 Regression] ICE: verify_ssa failed: definition in block 11 does not dominate use in block 16 with -fgraphite-identity -fno-tree-dce -ffast-math

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.17 19:55:27
 CC||matz at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-12-17 19:55:27 
UTC ---
It is caused by revision 167184:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg01074.html

[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse  2010-12-17 
20:04:18 UTC ---
Note that if I change the function to:

template,
void
>::value
>::type
>
A(U&&...u) ;

I get:

sorry, unimplemented: use of 'type_pack_expansion' in template

[Bug c++/46394] [C++0X] [4.6 Regression] no matching function with default template parameter

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||dseketel at redhat dot com

--- Comment #3 from H.J. Lu  2010-12-17 20:10:12 
UTC ---
It is caused by revision 166179:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00065.html

[Bug tree-optimization/46465] ICE: in calc_dfs_tree, at dominance.c:394 with -Os -fno-rerun-cse-after-loop -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Steven Bosscher  2010-12-17 
20:40:20 UTC ---
This is a dup of bug 46755.

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

[Bug rtl-optimization/46755] ICE: in calc_dfs_tree, at dominance.c:395 with -O

[steven at gcc dot gnu.org]

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

--- Comment #4 from Steven Bosscher  2010-12-17 
20:40:20 UTC ---
*** Bug 46465 has been marked as a duplicate of this bug. ***

[Bug middle-end/43672] Not compiled Qt library

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution||INVALID

--- Comment #3 from Kai Tietz  2010-12-17 20:42:35 
UTC ---
Sorry, I assume as you didn't reported any updates for this bug, that your
issue is already solved. Without gcc version and at least preprocessed source
of the file producing the ICE you mentioned, there is no chance to investigate
this bug.
So I close this bug as invalid.

[Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.17 20:43:55
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2010-12-17 20:43:55 UTC ---
Good point. I was assuming we got the polymorphic type compatibility right by
now, but this case I missed completely.

[Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  2010-12-17 
21:21:17 UTC ---
I don't see the point here.
Since one calls two (which expects a type(t)) x in one (of type class(t)) is
forced to be a type(t) entity actually. Why not make it a type(t) then ?

[Bug c/20385] Lame parse error message for undefined type

[bonzini at gnu dot org]

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

--- Comment #10 from Paolo Bonzini  2010-12-17 21:23:38 
UTC ---
Author: bonzini
Date: Fri Dec 17 21:23:36 2010
New Revision: 167999

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167999
Log:
gcc:
2010-12-17  Paolo Bonzini  

PR c/20385
* function.c (used_types_insert): Handle ERROR_MARK.
* c-decl.c (grokdeclarator): Handle ERROR_MARK.
(declspecs_add_type): Leave error_mark_node in specs->type.
(finish_declspecs): Change it to integer_type_node here.
* c-parser.c (c_parser_peek_2nd_token): Move earlier.
(enum c_lookahead_kind): New.
(c_parser_next_token_starts_typename): New name of
c_parser_next_tokens_start_typename.  Accept lookahead enum
and handle it here instead of...
(c_parser_next_tokens_start_declaration): ... here.  Call it.
(c_parser_declspecs): Accept another argument.  Do not exit
on C_ID_ID if it is guessed to be an unknown typename.
(c_parser_parms_declarator): Use 2nd token to distinguish a K&R
declaration from an ANSI declaration starting with an unknown
typename.
(c_parser_struct_declaration, c_parser_objc_type_name,
c_parser_typeof_specifier, c_parser_declarator,
c_parser_direct_declarator_inner): Adjust calls.
(c_parser_parameter_declaration): Likewise.
(c_parser_type_name): Pass back an error_mark_node to the caller.
(c_parser_postfix_expression): Do error recovery when 
c_parser_type_name returns NULL.

testsuite:
2010-12-17  Paolo Bonzini  

PR c/20385
* objc.dg/tls/init-2.m: Adjust.
* gcc.dg/noncompile/920923-1.c: Adjust.
* gcc.dg/noncompile/pr44517.c: Adjust.
* gcc.dg/declspec-18.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/declspec-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/c-parser.c
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/noncompile/920923-1.c
trunk/gcc/testsuite/gcc.dg/noncompile/pr44517.c
trunk/gcc/testsuite/objc.dg/tls/init-2.m

[Bug c/46996] New: xgcc: Internal error: Illegal instruction (program cc1)

[cryintothebluesky at googlemail dot com]

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

   Summary: xgcc: Internal error: Illegal instruction (program
cc1)
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cryintotheblue...@googlemail.com
  Host: x86_64--netbsd
Target: x86_64--netbsd
 Build: x86_64--netbsd


Building gcc on NetBSD-5.1 x86_64 results in the following:

/bin/ksh ../../gcc-4.5.2/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
echo timestamp > s-attrtab
/home/roman/gcc_build/build/gcc.build/./prev-gcc/xgcc
-B/home/roman/gcc_build/build/gcc.build/./prev-gcc/
-B/opt/gcc4/x86_64--netbsd/bin/ -B/opt/gcc4/x86_64--netbsd/bin/
-B/opt/gcc4/x86_64--netbsd/lib/ -isystem /opt/gcc4/x86_64--netbsd/include
-isystem /opt/gcc4/x86_64--netbsd/sys-include-c  -g -O2 -gtoggle -DIN_GCC  
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H
-I. -I. -I../../gcc-4.5.2/gcc -I../../gcc-4.5.2/gcc/.
-I../../gcc-4.5.2/gcc/../include -I../../gcc-4.5.2/gcc/../libcpp/include
-I/opt/gcc4/include -I/opt/gcc4/include -I/opt/gcc4/include 
-I../../gcc-4.5.2/gcc/../libdecnumber -I../../gcc-4.5.2/gcc/../libdecnumber/dpd
-I../libdecnumber insn-attrtab.c -o insn-attrtab.o
xgcc: Internal error: Illegal instruction (program cc1)
Please submit a full bug report.
See  for instructions.
gmake[3]: *** [insn-attrtab.o] Error 1
rm gcc.pod
gmake[3]: Leaving directory `/home/roman/gcc_build/build/gcc.build/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/home/roman/gcc_build/build/gcc.build'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/home/roman/gcc_build/build/gcc.build'
gmake: *** [all] Error 2

Output of xgcc -v -save-temps

Reading specs from /home/roman/gcc_build/build/gcc.build/./prev-gcc/specs
COLLECT_GCC=/home/roman/gcc_build/build/gcc.build/./prev-gcc/xgcc
COLLECT_LTO_WRAPPER=/home/roman/gcc_build/build/gcc.build/./prev-gcc/lto-wrapper
Target: x86_64--netbsd
Configured with: ../gcc-4.5.2/configure --prefix=/opt/gcc4
--build=x86_64--netbsd --host=x86_64--netbsd --target=x86_64--netbsd
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--enable-__cxa_atexit --disable-nls 
--disable-multilib --with-gmp=/opt/gcc4 --with-mpfr=/opt/gcc4
--with-mpc=/opt/gcc4
Thread model: posix
gcc version 4.5.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps'
'-B/home/roman/gcc_build/build/gcc.build/./prev-gcc/'
'-B/opt/gcc4/x86_64--netbsd/bin/' '-B/opt/gcc4/x86_64--netbsd/bin/'
'-B/opt/gcc4/x86_64--netbsd/lib/' '-isystem' '/opt/gcc4/x86_64--net
bsd/include' '-isystem' '/opt/gcc4/x86_64--netbsd/sys-include' '-c' '-g' '-O2'
'-gtoggle' '-DIN_GCC' '-W' '-Wall' '-Wwrite-strings' '-Wcast-qual'
'-Wstrict-prototypes' '-Wmissing-prototypes' '-Wmissing-format-attribute'
'-pedant
ic' '-Wno-long-long' '-Wno-variadic-macros' '-Wno-overlength-strings'
'-Wold-style-definition' '-Wc++-compat' '-DHAVE_CONFIG_H' '-I.' '-I.'
'-I../../gcc-4.5.2/gcc' '-I../../gcc-4.5.2/gcc/.'
'-I../../gcc-4.5.2/gcc/../include' '-I
../../gcc-4.5.2/gcc/../libcpp/include' '-I/opt/gcc4/include'
'-I/opt/gcc4/include' '-I/opt/gcc4/include'
'-I../../gcc-4.5.2/gcc/../libdecnumber'
'-I../../gcc-4.5.2/gcc/../libdecnumber/dpd' '-I../libdecnumber' '-o'
'insn-attrtab.
o' '-mtune=generic' '-march=x86-64'
 /home/roman/gcc_build/build/gcc.build/./prev-gcc/cc1 -E -quiet -v -I. -I.
-I../../gcc-4.5.2/gcc -I../../gcc-4.5.2/gcc/. -I../../gcc-4.5.2/gcc/../include
-I../../gcc-4.5.2/gcc/../libcpp/include -I/opt/gcc4/include -I/opt/gcc4/in
clude -I/opt/gcc4/include -I../../gcc-4.5.2/gcc/../libdecnumber
-I../../gcc-4.5.2/gcc/../libdecnumber/dpd -I../libdecnumber -iprefix
/home/roman/gcc_build/build/gcc.build/prev-gcc/../lib/gcc/x86_64--netbsd/4.5.2/
-isystem /home/
roman/gcc_build/build/gcc.build/./prev-gcc/include -isystem
/home/roman/gcc_build/build/gcc.build/./prev-gcc/include-fixed -DIN_GCC
-DHAVE_CONFIG_H -isystem /opt/gcc4/x86_64--netbsd/include -isystem
/opt/gcc4/x86_64--netbsd/sys-
include insn-attrtab.c -mtune=generic -march=x86-64 -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -
Wold-style-definition -Wc++-compat -g -gtoggle -fworking-directory -O2
-fpch-preprocess -o insn-attrtab.i
ignoring nonexistent directory "/opt/gcc4/x86_64--netbsd/include"
ignoring nonexistent directory "/opt/gcc4/x86_64--netbsd/sys-include"
ignoring nonexistent directory
"/home/roman/gcc_build/build/gcc.build/prev-gcc/../lib/gcc/x86_64--netbsd/4.5.2/include"
ignoring nonexistent directory
"/home/roman/gcc_build/build/gcc.build/prev-gcc/../lib/gcc/

[Bug middle-end/44982] [4.3/4.4/4.5/4.6 Regression] ICE in get_narrower, at tree.c:7832

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Steven Bosscher  2010-12-17 
21:26:45 UTC ---
I see no reason to cgraph_finalize_compilation_unit if there were parse errors.
Richi, what do you think?


Index: toplev.c
===
--- toplev.c(revision 167996)
+++ toplev.c(working copy)
@@ -582,7 +582,12 @@
  what's left of the symbol table output.  */
   timevar_pop (TV_PARSE);

-  if (flag_syntax_only || flag_wpa)
+  /* If all we have to do is syntax checking, or if there were parse
+ errors, stop here.  */
+  if (flag_syntax_only || seen_error)
+return;
+
+  if (flag_wpa)
 return;

   ggc_protect_identifiers = false;
@@ -590,9 +595,6 @@
   /* This must also call cgraph_finalize_compilation_unit.  */
   lang_hooks.decls.final_write_globals ();

-  if (seen_error ())
-return;
-
   varpool_assemble_pending_decls ();
   finish_aliases_2 ();

[Bug c/46996] xgcc: Internal error: Illegal instruction (program cc1)

[cryintothebluesky at googlemail dot com]

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

--- Comment #1 from cryintothebluesky at googlemail dot com 2010-12-17 21:30:32 
UTC ---
Created attachment 22804
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22804
gzipped gcc/insn-attrtab.i file

[Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever Confirmed|1   |0

--- Comment #3 from janus at gcc dot gnu.org 2010-12-17 21:37:44 UTC ---
(In reply to comment #2)
> I don't see the point here.
> Since one calls two (which expects a type(t)) x in one (of type class(t)) is
> forced to be a type(t) entity actually. Why not make it a type(t) then ?

Of course this small example does not make very much sense. But in general
there might be situations where it's more useful to pass a CLASS to a TYPE.

[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

[steven at gcc dot gnu.org]

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

--- Comment #2 from Steven Bosscher  2010-12-17 
21:43:13 UTC ---
Jakub, ping?

[Bug c/46996] xgcc: Internal error: Illegal instruction (program cc1)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.12.17 21:44:10
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-12-17 21:44:10 
UTC ---
Please run cc1 under gdb and show us the "Illegal instruction".

[Bug target/46997] New: new ia64 vector instructions are broken on HP-UX (big-endian)

[sje at cup dot hp.com]

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

   Summary: new ia64 vector instructions are broken on HP-UX
(big-endian)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com


The new IA64 vector instructions added in version r167136 don't work on
HP-UX.  This is probably because HP-UX is big-endian while Linux is
little-endian.

Some of the failing tests include:

FAIL: gcc.dg/vect/fast-math-vect-complex-3.c execution test
FAIL: gcc.dg/vect/fast-math-vect-complex-3.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10a.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10a.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10b.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-10b.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-18.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-18.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-20.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-20.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-21.c execution test
FAIL: gcc.dg/vect/no-scevccp-outer-21.c execution test
FAIL: gcc.dg/vect/pr37539.c execution test
FAIL: gcc.dg/vect/pr37539.c execution test
FAIL: gcc.dg/vect/slp-11.c execution test
FAIL: gcc.dg/vect/slp-11.c execution test
FAIL: gcc.dg/vect/slp-12a.c execution test
FAIL: gcc.dg/vect/slp-12a.c execution test
FAIL: gcc.dg/vect/slp-13.c execution test
FAIL: gcc.dg/vect/slp-13.c execution test
FAIL: gcc.dg/vect/slp-19.c execution test
FAIL: gcc.dg/vect/slp-19.c execution test
FAIL: gcc.dg/vect/slp-21.c execution test
FAIL: gcc.dg/vect/slp-21.c execution test
FAIL: gcc.dg/vect/slp-23.c execution test
FAIL: gcc.dg/vect/slp-23.c execution test
FAIL: gcc.dg/vect/slp-multitypes-10.c execution test
FAIL: gcc.dg/vect/slp-multitypes-10.c execution test
FAIL: gcc.dg/vect/slp-multitypes-6.c execution test
FAIL: gcc.dg/vect/slp-multitypes-6.c execution test
FAIL: gcc.dg/vect/slp-multitypes-9.c execution test
FAIL: gcc.dg/vect/slp-multitypes-9.c execution test
FAIL: gcc.dg/vect/slp-perm-2.c execution test
FAIL: gcc.dg/vect/slp-perm-2.c execution test
FAIL: gcc.dg/vect/slp-perm-3.c execution test
FAIL: gcc.dg/vect/slp-perm-3.c execution test
FAIL: gcc.dg/vect/slp-reduc-3.c execution test
FAIL: gcc.dg/vect/slp-reduc-3.c execution test
FAIL: gcc.dg/vect/slp-reduc-6.c execution test
FAIL: gcc.dg/vect/slp-reduc-6.c execution test
FAIL: gcc.dg/vect/vect-107.c execution test
FAIL: gcc.dg/vect/vect-107.c execution test
FAIL: gcc.dg/vect/vect-116.c execution test
FAIL: gcc.dg/vect/vect-116.c execution test
FAIL: gcc.dg/vect/vect-35.c execution test
FAIL: gcc.dg/vect/vect-35.c execution test
FAIL: gcc.dg/vect/vect-double-reduc-5.c execution test
FAIL: gcc.dg/vect/vect-double-reduc-5.c execution test
FAIL: gcc.dg/vect/vect-iv-4.c execution test
FAIL: gcc.dg/vect/vect-iv-4.c execution test
FAIL: gcc.dg/vect/vect-iv-8.c execution test
FAIL: gcc.dg/vect/vect-iv-8.c execution test
FAIL: gcc.dg/vect/vect-iv-8a.c execution test
FAIL: gcc.dg/vect/vect-iv-8a.c execution test
FAIL: gcc.dg/vect/vect-multitypes-14.c execution test
FAIL: gcc.dg/vect/vect-multitypes-14.c execution test
FAIL: gcc.dg/vect/vect-multitypes-8.c execution test
FAIL: gcc.dg/vect/vect-multitypes-8.c execution test
FAIL: gcc.dg/vect/vect-shift-2.c execution test
FAIL: gcc.dg/vect/vect-shift-2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-i4.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u16-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u32-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i2-gap.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i2-gap.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap2.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c execution test
FAIL: gcc.dg/vect/vect-strided-a-u8-i8-gap7.c execution test
FAIL: gcc.dg/vect/vect-strided-float.c execution test
FAIL: gcc.dg/vect/vect-strided-float.c execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c execution test
FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c execution test
FAIL: gcc.dg/vect/vect-strided-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-mult.c execution test
FAIL: gcc.dg/vect/vect-strided-same-dr.c execution test
FAIL: gcc.dg/vect/vect-strided-same-dr.c execution test
FAIL: gcc.dg/vect/vect-strided-store-a-u8-i2.c execution test
FAIL: gcc.dg/vect/vect-strided-store-a-u8-i2.c execution tes

[Bug other/43977] Patches from oldlto branch to be salvaged

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #10 from Steven Bosscher  2010-12-17 
21:44:38 UTC ---
I believe there is nothing more to salvage. Most patches don't apply anymore
anyway.

[Bug fortran/46990] [OOP] gfortran rejects passing a CLASS variable to TYPE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2010-12-17 20:43:55 |2010.12.17 22:04:35
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #4 from janus at gcc dot gnu.org 2010-12-17 22:04:35 UTC ---
Here is a preliminary patch. Hope I got the logic right ...


Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 167977)
+++ gcc/fortran/symbol.c(working copy)
@@ -4770,21 +4770,24 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typesp
   bool is_class2 = (ts2->type == BT_CLASS);
   bool is_derived1 = (ts1->type == BT_DERIVED);
   bool is_derived2 = (ts2->type == BT_DERIVED);
+  gfc_symbol *t1,*t2;

-  if (!is_derived1 && !is_derived2 && !is_class1 && !is_class2)
+  if (!(is_derived1 || is_class1) || !(is_derived2 || is_class2))
 return (ts1->type == ts2->type);

-  if (is_derived1 && is_derived2)
-return gfc_compare_derived_types (ts1->u.derived, ts2->u.derived);
+  t1 = ts1->u.derived;
+  t2 = ts2->u.derived;
+  
+  if (is_class2)
+t2 = t2->components->ts.u.derived;

-  if (is_class1 && is_derived2)
-return gfc_type_is_extension_of (ts1->u.derived->components->ts.u.derived,
- ts2->u.derived);
-  else if (is_class1 && is_class2)
-return gfc_type_is_extension_of (ts1->u.derived->components->ts.u.derived,
- ts2->u.derived->components->ts.u.derived);
+  if (is_derived1)
+return gfc_compare_derived_types (t1, t2);
   else
-return 0;
+{
+  t1 = t1->components->ts.u.derived;
+  return gfc_type_is_extension_of (t1, t2);
+}
 }

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[dominiq at lps dot ens.fr]

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

--- Comment #95 from Dominique d'Humieres  
2010-12-17 22:07:55 UTC ---
For the reasons given below, I have reached the conclusion that the failures
for g++.dg/tree-prof/partition2.C are not caused by the above patches, but
exposed by any patch fixing this pr.

Looking at gcc/testsuite/lib/target-supports.exp, I see

proc check_effective_target_freorder {} {
return [check_no_compiler_messages freorder object {
void foo (void) { }
} "-freorder-blocks-and-partition"]
}

Then I did the following tests:

[macbook] f90/bug% cat > order.c
void foo (void) { }
[macbook] f90/bug% /opt/gcc/gcc4.6p/bin/gcc -c -freorder-blocks-and-partition
order.c
gcc: internal compiler error: Segmentation fault (program cc1)

The backtrace

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x7fff5bc00ffc
htab_find_slot_with_hash (htab=0x142420d90, element=0x7fff5bc01050, hash=2086,
insert=INSERT) at ../../p_work/libiberty/hashtab.c:644
644{
(gdb) bt
#0  htab_find_slot_with_hash (htab=0x142420d90, element=0x7fff5bc01050,
hash=2086, insert=INSERT) at ../../p_work/libiberty/hashtab.c:644
#1  0x0001007eb558 in cgraph_node (decl=0x142591200) at
../../p_work/gcc/cgraph.c:502

is exactly the one reported in comment #0. So if the segmentation fault is
fixed, it is also fixed for the freorder test and the tests that were
UNSUPPORTED are then executed.

So the partition2.C failures are due to another bug of the generation of
debugging information on darwin. If nobody is faster, I'll open a new pr for it
when this pr will have been fixed. For the record note that the failure for -O3
-g is slightly different from the one reported in comment #12:

ld: warning: can't add line info to anonymous symbol anon-func-0x0 from
/var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//cc5PMZA6.o
ld: warning: can't add line info to anonymous symbol anon-func-0x0 from
/var/folders/LW/LW1oufkMGIqlLpjYn45fBU+++TI/-Tmp-//cc5PMZA6.o
warning: no debug symbols in executable (-arch i386)

[Bug tree-optimization/45552] [graphite] ICE in sese_loop_depth, at sese.h:172

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Sebastian Pop  2010-12-17 22:23:21 
UTC ---
This is a duplicate of PR45758 that has been fixed on trunk.
I backported this change to the 4.5 branch and that fixes the
testcase.  I will commit the fix after regstrap.

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

[Bug middle-end/45758] [4.6 Regression] ICE in expr_invariant_in_loop_p

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||tolkiendili at gmail dot
   ||com

--- Comment #11 from Sebastian Pop  2010-12-17 
22:23:21 UTC ---
*** Bug 45552 has been marked as a duplicate of this bug. ***

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu  2010-12-17 22:25:56 
UTC ---
(In reply to comment #19)
> Filled in the GNU LD bug as
> http://sourceware.org/bugzilla/show_bug.cgi?id=12323

It should have been fixed on hjl/lto-mixed branch at

http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary

[Bug c++/46807] internal compiler error: in synthesized_method_walk

[rwgk at yahoo dot com]

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

--- Comment #2 from rwgk at yahoo dot com 2010-12-17 22:34:16 UTC ---
Using a binary search I found that svn rev. 161579 introduced the ICE.

(Note that I had to replace gcc/config/i386/i386.md with rev. 161594
since gcc doesn't build otherwise.)

% svn log -v -r 161579

r161579 | jason | 2010-06-29 17:50:57 -0700 (Tue, 29 Jun 2010) | 40 lines
Changed paths:
   M /trunk/gcc/cp/ChangeLog
   M /trunk/gcc/cp/call.c
   M /trunk/gcc/cp/class.c
   M /trunk/gcc/cp/cp-tree.h
   M /trunk/gcc/cp/decl.c
   M /trunk/gcc/cp/method.c
   M /trunk/gcc/cp/search.c
   M /trunk/gcc/cp/semantics.c
   M /trunk/gcc/cp/tree.c

Machinery to support implicit delete/move.
* cp-tree.h: (struct lang_type_class): Add lazy_move_assign,
has_complex_move_ctor, has_complex_move_assign bitfields.
(CLASSTYPE_LAZY_MOVE_ASSIGN): New.
(TYPE_HAS_COMPLEX_MOVE_ASSIGN): New.
(TYPE_HAS_COMPLEX_MOVE_CTOR): New.
(enum special_function_kind): Add sfk_move_assignment.
(LOOKUP_SPECULATIVE): New.
* call.c (build_over_call): Return early if it's set.
(build_over_call): Use trivial_fn_p.
* class.c (check_bases): If the base has no default constructor,
the derived one is non-trivial.  Handle move ctor/op=.
(check_field_decl): Likewise.
(check_bases_and_members): Handle move ctor/op=.
(add_implicitly_declared_members): Handle CLASSTYPE_LAZY_MOVE_ASSIGN.
(type_has_move_constructor, type_has_move_assign): New.
* decl.c (grok_special_member_properties): Handle move ctor/op=.
* method.c (type_has_trivial_fn, type_set_nontrivial_flag): New.
(trivial_fn_p): New.
(do_build_copy_constructor): Use it.
(do_build_assign_ref): Likewise.  Handle move assignment.
(build_stub_type, build_stub_object, locate_fn_flags): New.
(locate_ctor): Use locate_fn_flags.
(locate_copy, locate_dtor): Remove.
(get_dtor, get_default_ctor, get_copy_ctor, get_copy_assign): New.
(process_subob_fn, synthesized_method_walk): New.
(maybe_explain_implicit_delete): New.
(implicitly_declare_fn): Use synthesized_method_walk,
type_has_trivial_fn, and type_set_nontrivial_flag.
(defaulted_late_check): Set DECL_DELETED_FN.
(defaultable_fn_check): Handle sfk_move_assignment.
(lazily_declare_fn): Clear CLASSTYPE_LAZY_* early.  Don't declare
implicitly deleted move ctor/op=.
* search.c (lookup_fnfields_1): Handle sfk_move_assignment.
(lookup_fnfields_slot): New.
* semantics.c (omp_clause_info_fndecl): Remove.
(cxx_omp_create_clause_info): Use get_default_ctor, get_copy_ctor,
get_copy_assign, trivial_fn_p.
(trait_expr_value): Adjust call to locate_ctor.
* tree.c (special_function_p): Handle sfk_move_assignment.

[Bug c++/46807] internal compiler error: in synthesized_method_walk

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2010-12-17 
22:37:56 UTC ---
Can you provide the preprocessed source?

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2010-12-17 23:15:27 UTC ---
The issues appears to have come into gfortran with pault's
initial commit of Brook's gfc_simplify_transfer.  This
is revision 124759.

Consider 

program z
  use iso_c_binding
  type(c_ptr) m
  m = transfer(12345, m)
end program z

The culprit is the second test in 

  if (!gfc_is_constant_expr (source)
|| (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
|| !gfc_is_constant_expr (size))
return NULL;

Here, gfc_init_expr_flag = 0 and mold is EXPR_VARIABLE, which
yields !gfc_is_constant_expr (mold) = 1.  Clearly (0 && anything)
is going to be 0. So, gfortran tries to simplify the expression.

If gfc_init_expr_flag is removed, the code compiles.

Anyone know why this flag is needed?

[Bug testsuite/46998] New: [4.6 Regression] FAIL: objc.dg/exceptions-4.m

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] FAIL: objc.dg/exceptions-4.m
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: bonz...@gnu.org


On Linux/ia32, revision 167999 gave

FAIL: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 42)
FAIL: objc.dg/exceptions-4.m -fgnu-runtime (test for excess errors)

Revision 167996 is OK. It may be caused by revision 167999:

http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00683.html

[Bug testsuite/46998] [4.6 Regression] FAIL: objc.dg/exceptions-4.m

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2010-12-17 23:48:36 
UTC ---
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:
In function 'test':^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:35:5:
error: expected '(' before '{' token^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:38:11:
error: expected declaration specifiers or '...' before ')' token^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:42:11:
error: unknown type name 'i'^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:46:26:
error: expected '>' before 'x'^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:46:26:
error: @catch parameter can not be protocol-qualified^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:50:10:
error: expected '(' before 'MyObject'^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:54:10:
error: expected '(' before 'MyObject2'^M
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:61:3:
error: expected '{' before 'catch'^M

PASS: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 35)
PASS: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 38)
FAIL: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 42)
PASS: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 46)
PASS: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 46)
PASS: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 50)
PASS: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 54)
PASS: objc.dg/exceptions-4.m -fgnu-runtime  (test for errors, line 61)
FAIL: objc.dg/exceptions-4.m -fgnu-runtime (test for excess errors)
Excess errors:
/export/gnu/import/svn/gcc-test-intel64/src-trunk/gcc/testsuite/objc.dg/exceptions-4.m:42:11:
error: unknown type name 'i'

[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler due to r167727

[iains at gcc dot gnu.org]

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

--- Comment #96 from Iain Sandoe  2010-12-17 23:56:16 
UTC ---
(In reply to comment #95)
> For the reasons given below, I have reached the conclusion that the failures
> for g++.dg/tree-prof/partition2.C are not caused by the above patches, but
> exposed by any patch fixing this pr.

In which case, I propose that we close this PR with 

http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01359.html  (still needs review, I
think)

and deal with "anonymous code atoms" and "missing pubnames sections" as two
different PRs.

thanks, Iain

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  
2010-12-18 00:01:03 UTC ---
On Fri, Dec 17, 2010 at 11:15:44PM +, kargl at gcc dot gnu.org wrote:
> 
> Anyone know why this flag is needed?
> 

Well, the answer is to let simplify_transfer_[34].f90
in the testsuite to compile!  :-)

Given 

   program z
   use iso_c_binding
   type(c_ptr) m
   m = transfer(32512, m)
   m = transfer(32512, C_NULL_PTR)
   end program z

This patch compiles the above.

Index: simplify.c
===
--- simplify.c  (revision 167949)
+++ simplify.c  (working copy)
@@ -5954,6 +5954,11 @@ gfc_simplify_transfer (gfc_expr *source,
   if (source->expr_type == EXPR_FUNCTION)
 return NULL;

+  if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
+  && mold->ts.type == BT_DERIVED && mold->ts.u.derived
+  && strcmp(mold->ts.u.derived->name, "c_ptr") == 0)
+return NULL;
+
   /* Calculate the size of the source.  */
   if (source->expr_type == EXPR_ARRAY
   && gfc_array_size (source, &tmp) == FAILURE)

The tree dump looks like

z ()
--More--(74%){
  void * m;

  {
void * transfer.0;
integer(kind=8) D.1524;
integer(kind=8) D.1523;
static integer(kind=4) C.1522 = 32512;
integer(kind=8) D.1521;

D.1521 = 4;
D.1523 = 8;
__builtin_memcpy ((void *) &transfer.0, (void *) &C.1522,
   MAX_EXPR , 0>);
m = transfer.0;
  }
  {
void * transfer.1;
integer(kind=8) D.1530;
integer(kind=8) D.1529;
static void * C.1528 = 0B;
static integer(kind=4) C.1527 = 32512;
integer(kind=8) D.1526;

D.1526 = 4;
D.1529 = 8;
__builtin_memcpy ((void *) &transfer.1, (void *) &C.1527,
   MAX_EXPR , 0>);
m = transfer.1;
  }
}

So we are assigning a void * pointer to a void * pointer.  Not
sure this is the desired result.

[Bug c/46996] xgcc: Internal error: Illegal instruction (program cc1)

[cryintothebluesky at googlemail dot com]

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

--- Comment #3 from cryintothebluesky at googlemail dot com 2010-12-18 00:16:48 
UTC ---
(In reply to comment #2)
> Please run cc1 under gdb and show us the "Illegal instruction".

I think the illegal instruction is caused by stack overflow:

gdb prev-gcc/cc1 gcc/cc1.core

Core was generated by `cc1'.
Program terminated with signal 4, Illegal instruction.
#0  0x00cde521 in gimplify_expr (expr_p=0x7f7ffba88df0, 
pre_p=0x7f7fffe04730, post_p=0x7f7fffe00c08, 
gimple_test_f=0xc1c425 , fallback=2)
at /usr/include/stdio.h:442
442 if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c !=
'\n'))

... Many other frames

#1667 0x00cd371a in gimplify_stmt (stmt_p=0x7f7ffc2d1598, 
seq_p=0x7f7fa8a8) at /usr/include/stdio.h:442
#1668 0x00ce51d1 in gimplify_body (body_p=0x7f7ffc2d1598, 
fndecl=0x7f7ffc2d1500, do_parms=1 '\001') at /usr/include/stdio.h:442
#1669 0x00ce5872 in gimplify_function_tree (fndecl=0x7f7ffc2d1500)
at /usr/include/stdio.h:442
#1670 0x01f3d4d3 in cgraph_analyze_function (node=0x7f7ffbc6b4e0)
at /usr/include/stdio.h:442
#1671 0x01f3da3a in cgraph_analyze_functions ()
at /usr/include/stdio.h:442
#1672 0x01f3dea5 in cgraph_finalize_compilation_unit ()
at /usr/include/stdio.h:442
#1673 0x004fa8c7 in c_write_global_declarations ()
at /usr/include/stdio.h:442
#1674 0x0128b201 in compile_file () at /usr/include/stdio.h:442
#1675 0x0128d37c in do_compile () at /usr/include/stdio.h:442
#1676 0x0128d443 in toplev_main (argc=52, argv=0x7f7fabe0)
at /usr/include/stdio.h:442
#1677 0x006c5be3 in main (argc=52, argv=0x7f7fabe0)
at /usr/include/stdio.h:442
(gdb)

[Bug testsuite/46998] [4.6 Regression] FAIL: objc.dg/exceptions-4.m

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

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

--- Comment #2 from Nicola Pero  2010-12-18 00:23:04 
UTC ---
I fixed it in trunk.

Thanks

[Bug libgcj/46999] New: Problem compiling gcc 4.5.2

[pierre42d at 9online dot fr]

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

   Summary: Problem compiling gcc 4.5.2
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pierre...@9online.fr


[...]
Making all in testsuite
make[3]: Entering directory
`/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava/testsuite'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava/testsuite'
make[3]: Entering directory `/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava'
/bin/sh ./libtool --tag=GCJ  --mode=link
/tmp/gcc-4.5.2/host-i686-pc-linux-gnu/gcc/gcj
-B/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava/
-B/tmp/gcc-4.5.2/host-i686-pc-linux-gnu/gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include   
-L/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava -ffloat-store -fomit-frame-pointer
-Usun -g -O2  -o jv-convert --main=gnu.gcj.convert.Convert -rpath
/usr/local/lib -shared-libgcc   
-L/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava/.libs libgcj.la 
libtool: link: /tmp/gcc-4.5.2/host-i686-pc-linux-gnu/gcc/gcj
-B/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava/
-B/tmp/gcc-4.5.2/host-i686-pc-linux-gnu/gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -ffloat-store -fomit-frame-pointer
-Usun -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc 
-L/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava/.libs
-L/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava ./.libs/libgcj.so -lpthread -lrt
-ldl -Wl,-rpath -Wl,/usr/local/lib
/usr/local/i686-pc-linux-gnu/bin/ld: unrecognized option '-Wl,-rpath'
/usr/local/i686-pc-linux-gnu/bin/ld: use the --help option for usage
information
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1
make[3]: Leaving directory `/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/gcc-4.5.2/i686-pc-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/tmp/gcc-4.5.2'
make: *** [all] Error 2

[Bug c++/46992] [4.6 Regression] [C++0x] ICE: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2452

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Jason Merrill  2010-12-18 
04:08:10 UTC ---
Fixed by the patch for 46670.

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

[Bug c++/46670] [4.6 Regression] ICE in dependent_type_p, at cp/pt.c:17553

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #6 from Jason Merrill  2010-12-18 
04:08:10 UTC ---
*** Bug 46992 has been marked as a duplicate of this bug. ***

[Bug debug/46782] -fcompare-debug failure (length) with -fvar-tracking

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  2010-12-18 
06:24:55 UTC ---
Author: aoliva
Date: Sat Dec 18 06:24:52 2010
New Revision: 168013

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168013
Log:
gcc/ChangeLog:
PR debug/46782
* cfgcleanup.c (try_forward_edges): Skip debug insns.
gcc/testsuite/ChangeLog:
PR debug/46782
* gcc.dg/debug/pr46782.c: New.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/debug/pr46782.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/cfgcleanup.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug debug/46756] -fcompare-debug failure (length) with ASSIGN

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  2010-12-18 
06:25:12 UTC ---
Author: aoliva
Date: Sat Dec 18 06:25:09 2010
New Revision: 168014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168014
Log:
gcc/ChangeLog:
PR debug/46756
* jump.c (mark_all_labels): Skip debug insns.
gcc/testsuite/ChangeLog:
PR debug/46756
* gfortran.dg/debug/pr46756.f: New.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/debug/pr46756.f
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/jump.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug debug/46756] -fcompare-debug failure (length) with ASSIGN

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Alexandre Oliva  2010-12-18 
06:27:14 UTC ---
Fixed, trunk (see bug 46576, oops) and 4.5 branch.

[Bug debug/46782] -fcompare-debug failure (length) with -fvar-tracking

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Alexandre Oliva  2010-12-18 
06:27:40 UTC ---
Fixed, trunk and 4.5 branch.