[Bug rtl-optimization/47299] [4.6 Regression] Widening multiply optimization generates bad code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-01-18 
08:15:02 UTC ---
Fixed.

[Bug c++/47338] New: [4.5 Regression][C++] cc1plus returns exist code 5

[daniel.f.starke at freenet dot de]

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

   Summary: [4.5 Regression][C++] cc1plus returns exist code 5
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de
  Host: mingw32
Target: mingw32
 Build: mingw32


Created attachment 23015
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23015
preprocessed test file .ii

When compiling the attatched code cc1plus returns exit code 5. No warning or
error message is shown. It compiles fine with the same host/target/build and
gcc 4.4.0.

Command:
$ g++ -pass-exit-codes -o XmlResultReader.o -c XmlResultReader.cpp -v
-save-temps || echo "error: $?"
Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw\bin\g++.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --disable-bootstrap
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-nls
--disable-shared --enable-static --enable-libgcj --enable-libgomp --enable-lto
--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw --build=mingw32 --enable-abi=32
Thread model: win32
gcc version 4.5.2 (GCC) 
COLLECT_GCC_OPTIONS='-o' 'XmlResultReader.o' '-c' '-v' '-save-temps'
'-mtune=i386' '-march=i386'
 d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe -E -quiet
-v -iprefix d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/
XmlResultReader.cpp -mtune=i386 -march=i386 -fpch-preprocess -o
XmlResultReader.ii
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include/c++"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include/c++/mingw32"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include/c++/backward"
ignoring nonexistent directory "/mingw/include"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include-fixed"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/mingw32
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/backward
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include-fixed
 D:/Programme/msys/mingw/include
 d:/programme/msys/mingw/lib/gcc/../../mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-o' 'XmlResultReader.o' '-c' '-v' '-save-temps'
'-mtune=i386' '-march=i386'
 d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe
-fpreprocessed XmlResultReader.ii -quiet -dumpbase XmlResultReader.cpp
-mtune=i386 -march=i386 -auxbase-strip XmlResultReader.o -version -o
XmlResultReader.s
error: 5

[Bug bootstrap/46856] [4.6 regression] internal compiler error in final_scan_insn breaks m68k-linux bootstrap

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2011-01-18 
08:29:42 UTC ---
If I hack reload_combine_recognize_const_pattern to bail out early if HAVE_cc0,
then the test case doesn't ICE a cross to m68k-linux, and native bootstrap on
m68k-linux also succeeds (--enable-languages=c,c++; testsuite currently
running).

I'm not suggesting this is the proper fix, but at least it identifies roughly
were the problem lies.

--- gcc-4.6-20110115/gcc/postreload.c.~1~   2010-12-21 15:51:42.0
+0100
+++ gcc-4.6-20110115/gcc/postreload.c   2011-01-16 12:29:44.0 +0100
@@ -944,6 +944,11 @@ reload_combine_recognize_const_pattern (
   int add_moved_after_ruid = 0;
   int clobbered_regno = -1;

+#ifdef HAVE_cc0
+  /* Unbreak m68k, see PR bootstrap/46856. */
+  return false;
+#endif
+
   set = single_set (insn);
   if (set == NULL_RTX)
 return false;

[Bug c++/47291] [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.18 08:59:02
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Dodji Seketeli  2011-01-18 
08:59:02 UTC ---
Mine

[Bug c/47337] [4.6 Regression] memory unsafety bug leading to wrong code generation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.6.0
Summary|memory unsafety bug leading |[4.6 Regression] memory
   |to wrong code generation|unsafety bug leading to
   ||wrong code generation

--- Comment #1 from Jakub Jelinek  2011-01-18 
09:04:46 UTC ---
Confirmed, goes away with -fno-partial-inlining, happens only with -m32.
>From brief look at it it looks like a RTL DCE bug, it removes a __divdi3 call,
but takes away with it also a needed unrelated store:
(insn 203 105 204 6 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S4 A32])
(const_int 10 [0xa])) pr47337.c:14 64 {*movsi_internal}
 (nil))

(insn 204 203 205 6 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [0 S4 A32])
(const_int 0 [0])) pr47337.c:14 64 {*movsi_internal}
 (nil))

(insn 205 204 206 6 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(const_int 0 [0])) pr47337.c:14 64 {*movsi_internal}
 (nil))

(insn 206 205 190 6 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [0 S4 A32])
(const_int 0 [0])) pr47337.c:14 64 {*movsi_internal}
 (nil))

(insn 190 206 110 6 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])) [5 S4 A32])
(reg:SI 2 cx)) pr47337.c:14 64 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 2 cx)
(nil)))

(call_insn/u 110 190 179 6 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI ("__divdi3") [flags 0x41]) [0 S1 A8])
(const_int 16 [0x10]))) pr47337.c:14 927 {*call_value_0}
 (expr_list:REG_UNUSED (reg:DI 0 ax)
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil)))
(expr_list:REG_DEP_TRUE (use (mem:DI (reg/f:SI 7 sp) [0 S8 A8]))
(expr_list:REG_DEP_TRUE (use (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A8]))
(nil

The sp+0x1c store shouldn't be deleted, but it is.

[Bug rtl-optimization/47337] [4.6 Regression] Wrong RTL dce of calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.01.18 09:22:11
  Component|c   |rtl-optimization
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
Summary|[4.6 Regression] memory |[4.6 Regression] Wrong RTL
   |unsafety bug leading to |dce of calls
   |wrong code generation   |
 Ever Confirmed|0   |1

[Bug fortran/47339] New: Fortran 95: Reject namelist objects of non-constant size

[burnus at gcc dot gnu.org]

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

   Summary: Fortran 95: Reject namelist objects of non-constant
size
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Fortran 95 contains at "5.4 NAMELIST statement":

"Constraint: A namelist-group-object shall not be an array dummy argument with
a nonconstant bound, a variable with nonconstant character length, an automatic
object, a pointer, a variable of a type that has an ultimate component that is
a pointer, or an allocatable array."

However, the following programs is not rejected using "gfortran -std=f95
-pedantic":

subroutine test1(n)
  character(len=n) :: str
  namelist /nml/ str
end subroutine test1

Expected: An error as printed by g95:
  Error: Variable 'str' at (1) cannot have a variable length and be in a
NAMELIST
or as with NAG:
  Error: Namelist-group-object STR is an automatic object
or as with PathScale:
  "STR" is a namelist-group-object, therefore it must not be typed as variable
length character.


Note: In Fortran 2003 (and 2008) the restriction has been lifted and only the
following is left, which is properly diagnosed

C574 (R553) A namelist-group-object shall not be an assumed-size array.

[Bug rtl-optimization/47337] [4.6 Regression] Wrong RTL dce of calls

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-01-18 
09:58:04 UTC ---
Created attachment 23016
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23016
gcc46-pr47337.patch

Untested fix.  Thanks for the report.

[Bug c++/47067] [4.6 Regression] [c++0x] ICE in cxx_eval_bare_aggregate, at cp/semantics.c:6352

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-01-18 
10:09:39 UTC ---
Fixed.

[Bug c++/47329] cc1plus segfaults when using variadic function template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Jonathan Wakely  2011-01-18 
10:25:08 UTC ---
I can't reproduce an ICE with FSF 4.4.3, 4.4.5, or 4.5/4.6 from svn, instead I
get a diagnostic as expected because the code is invalid.

Maybe you are hitting a bug in the Ubuntu package, in which case it should be
reported to Ubuntu

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-01-18 
10:31:32 UTC ---
How about

Index: tree-eh.c
===
--- tree-eh.c   (revision 168906)
+++ tree-eh.c   (working copy)
@@ -3710,6 +3710,9 @@ cleanup_empty_eh_unsplit (basic_block bb
 if (find_edge (e->src, e_out->dest))
   return false;

+  if (!single_pred_p (e_out->dest))
+return false;
+
   /* Attempt to move the PHIs into the successor block.  */
   if (cleanup_empty_eh_merge_phis (e_out->dest, bb, e_out, false))
 {

?  The condition before was added by me for another corner-case and
of course could be removed with that patch.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Richard Guenther  2011-01-18 
10:32:06 UTC ---
CCing Honza.  What kind of simplifications did we want to catch here?

[Bug c++/47340] New: [trans-mem] problem with declaration of new operator

[patrick.marlier at gmail dot com]

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

   Summary: [trans-mem] problem with declaration of new operator
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: r...@gcc.gnu.org, al...@gcc.gnu.org


It seems that there is a problem with the declaration of new operator and
related to PR46941.
Attached the testcase.

$ g++ -I . -save-temps -fgnu-tm -c -o incomplete3.o incomplete3.cpp
...
incomplete3.cpp:31:67: error: call to function ‘void* operator new(long
unsigned int)’ which throws incomplete type ‘struct std::bad_alloc’

Patrick Marlier.

[Bug middle-end/47341] New: unnecessary versioning in the vectorizer.

[Joost.VandeVondele at pci dot uzh.ch]

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

   Summary: unnecessary versioning in the vectorizer.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joost.vandevond...@pci.uzh.ch


with current trunk:

> cat test.f90
   SUBROUTINE HARD_NN_4_4_4_5_1_2_4(C,A,B)
  REAL(KIND=8) :: C(4,*)
  REAL(KIND=8) :: B(4,*), A(4,*)
  INTEGER ::i,j,l
  l=   1
  DO j=   1 ,   4 ,   2
  DO i=   1 ,   4 ,   1
C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+0)*B(l+0,j+0)
C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+1)*B(l+1,j+0)
C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+2)*B(l+2,j+0)
C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+3)*B(l+3,j+0)
C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+0)*B(l+0,j+1)
C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+1)*B(l+1,j+1)
C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+2)*B(l+2,j+1)
C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+3)*B(l+3,j+1)
  ENDDO
  ENDDO
END SUBROUTINE

> gfortran-trunk -c -O2 -fno-unroll-loops -ftree-vectorize 
> -ftree-vectorizer-verbose=1 -march=core2 -msse4.2 test.f90

test.f90:7: note: created 1 versioning for alias checks.

test.f90:7: note: LOOP VECTORIZED.
test.f90:1: note: vectorized 1 loops in function.

The compiler should not need to generate various version of these loops. With
the bounds info provided, nothing can alias (I think).

[Bug middle-end/47341] unnecessary versioning in the vectorizer.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.18 11:21:06
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-01-18 
11:21:06 UTC ---
t.f90:7: note: versioning for alias required: can't determine dependence
between *c_18(D)[D.1552_17] and *c_18(D)[D.1603_128]

  pretmp.22_273 = (integer(kind=8)) j_2;

  pretmp.22_274 = pretmp.22_273 * 4;

  pretmp.30_287 = pretmp.22_273 + 1;
  pretmp.30_288 = pretmp.30_287 * 4;

  D.1548_13 = (integer(kind=8)) i_1;
  D.1551_16 = D.1548_13 + pretmp.22_274;
  D.1552_17 = D.1551_16 + -5;

  D.1602_127 = D.1548_13 + pretmp.30_288;
  D.1603_128 = D.1602_127 + -5;

thus we can't determine the dependence between

  *(c_18(D) + (integer(kind=8)) i_1 + ((integer(kind=8)) j_2) * 4)

vs

  *(c_18(D) + (integer(kind=8)) i_1 + (((integer(kind=8)) j_2) + 1) * 4)


(compute_affine_dependence
  (stmt_a = 
D.1553_19 = *c_18(D)[D.1552_17];
)   
  (stmt_b = 
D.1604_129 = *c_18(D)[D.1603_128];
)
(subscript_dependence_tester
(analyze_overlapping_iterations 
  (chrec_a = {pretmp.22_274 + -4, +, 1}_2)
  (chrec_b = {pretmp.30_288 + -4, +, 1}_2)
(analyze_siv_subscript 
siv test failed: unimplemented.
)

the SCEVs cannot be expanded properly because of the casts.

[Bug c++/47338] [4.5 Regression][C++] cc1plus returns exist code 5

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3

--- Comment #1 from Richard Guenther  2011-01-18 
11:30:27 UTC ---
Works on x86_64-linux.  Can you debug it please?

[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.18 11:40:09
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2011-01-18 
11:40:09 UTC ---
Yep, I have it too.

[Bug middle-end/47341] unnecessary versioning in the vectorizer.

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin  2011-01-18 
12:30:09 UTC ---
(In reply to comment #1)
> the SCEVs cannot be expanded properly because of the casts.

Doesn't seem to work better with i,j,l made integer(8), i.e. without the casts.

[Bug c++/46170] [4.4/4.5 Regression] g++ wrongly rejects pointer-to-member in template arguments

[dodji at gcc dot gnu.org]

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

--- Comment #25 from Dodji Seketeli  2011-01-18 
12:44:28 UTC ---
> Hi again, any chance Dodji's patches could be pushed to the 4.5 and/or 4.4
> branches, before it gets too close to release time again?  Thanks.

It's in my TODO list. I'll get to it ASAP.

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[mikael at gcc dot gnu.org]

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

--- Comment #30 from Mikael Morin  2011-01-18 
12:48:41 UTC ---
(In reply to comment #28)
> One way would be to keep for data types all the time the two versions around:
> One with restrict and one without restrict;
makes sense

> thus, if one does type extension,
> one has always a fully restrictless data type.
Why? From my point of view type extension is orthogonal to target. 
If an entity of extended derived type has the target/pointer attribute, one
uses the non-restrict variant for its base type, and if it hasn't one uses the
restrict variant. Do I miss something?

> Unfortunately, that seems to
> cause a missed-optimization for
>   type t
> integer :: a
> integer, pointer :: b
>   end type t
>   type(t) :: x
> as "x%a" cannot alias and only "x%b" can - but is seems that one cannot encode
> this for the ME such that "t" as a whole has to be marked as unrestricted.

How about: 

struct t_restrict {
  int a;
  int * b;
} * restrict

VS

struct t_norestrict {
  int a;
  int * b;
} *

?


> 
> I think the easiest would be to create for derived types sym->backend_decl and
> another backend_decl with "restrict" - and propagate both variants types
> through, when extending the type or including it into another type. As soon as
> it is used as POINTER component, one could drop propagating the
> backend_decl_restricted.

Looks like a plan. :-)

[Bug fortran/47339] Fortran 2003/2008: Valid NAMELIST rejected; Fortran 95: Invalid namelist objects accepted

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid
Summary|Fortran 95: Reject namelist |Fortran 2003/2008: Valid
   |objects of non-constant |NAMELIST rejected; Fortran
   |size|95: Invalid namelist
   ||objects accepted

--- Comment #1 from Tobias Burnus  2011-01-18 
12:50:52 UTC ---
The check is currently done at match.c's gfc_match_namelist and at resolve.c's
resolve_fl_namelist.

MISSING (valid F2003, invalid F95):
- sym->ts.u.cl->length && !gfc_is_constant_expr (sym->ts.u.cl->length)
- sym->attr.pointer || sym->attr.allocatable

Seemingly in gfc_match_namelist already covered -- and is thus REJECTS-VALID
for Fortran 2003:
- Non-constant arrays
- Allocatable/pointer components*
+ Handling of polymorphic objects*

*Note: this requires defined I/O, cf. quote below.


Example for rejects valid:
  subroutine test1(n)
integer:: a(n)
namelist /nml/ a
  end subroutine test1


 * * *

For completeness: F2008 lists additionally the following in "5.6 NAMELIST
statement":

"A namelist group object shall either be accessed by use or host association or
shall have its type, type parameters, and shape specified by previous
specification statements or the procedure heading in the same scoping unit or
by the implicit typing rules in effect for the scoping unit. If a namelist
group object is typed by the implicit typing rules, its appearance in any
subsequent type declaration statement shall conrm the implied type and type
parameters."


And in "9.6.4.7 Namelist formatting" [...]:

"Every allocatable namelist-group-object in the namelist group shall be
allocated and every namelist-group-object that is a pointer shall be associated
with a target. If a namelist-group-object is polymorphic or has an ultimate
component that is allocatable or a pointer, that object shall be processed by a
defined input/output procedure (9.6.4.8)."

[Bug c++/47342] New: misleading diagnostic for member of undeclared class template partial specialization

[redi at gcc dot gnu.org]

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

   Summary: misleading diagnostic for member of undeclared class
template partial specialization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


g++ does not distinguish between invalid uses of an incomplete partial
specialization and an undeclared partial specialization:

template
  struct X : T
  {
void f();
  };

template
  inline void
  X::f()
  { }

template
  struct Y
  { };

#ifdef CORRECT
template
  struct X< Y > : Y
  {
void f();
  };
#endif

template
  inline void
  X< Y >::f()// xxx
  { }


$ g++ ps.cc
ps.cc:26: error: invalid use of incomplete type 'struct X >'
ps.cc:3: error: declaration of 'struct X >'

The diagnostic is rather unhelpful.

The problem is not that the type is incomplete, but that there is not even a
declaration of the class template partial specialization X> (which can be
fixed by defining CORRECT).  The second error referring to line 3 is wrong,
that's the declaration of the primary template, not the partial specialization.

The diagnostic would be almost correct (apart from the line number) if the
class template partial specialization had been declared but not defined, like
so
template struct X< Y >;
but that is not the case here.

This is a regression since 4.1 which correctly states the type is undefined,
not incomplete:
ps.cc:27: error: invalid use of undefined type `struct X >'
ps.cc:3: error: declaration of `struct X >'
ps.cc:27: error: template definition of non-template `void X >::f()'

EDG gives:
"ComeauTest.c", line 26: error: template argument list must match the parameter
list
X< Y >::f()// xxx
^
This isn't very informative but is more accurate, referring to the wording in
[temp.class.spec.mfunc]p1:
The template argument list of a member of a class template partial
specialization shall match the template argument list of the class template
partial specialization.

Clang++ gives a more helpful diagnostic:
ps.cc:26:14: error: nested name specifier 'X >::' for declaration does not
  refer into a class, class template or class template partial
  specialization
  X< Y >::f()// xxx
  ~~~^
1 error generated.

Sun CC gives arguably the best diagnostic:
"ps.cc", line 27: Error: Could not find partial specialization matching
X>.
1 Error(s) detected.

(N.B. clang++ gives a worse diagnostic for the case where the class template
partial specialization has been declared but not defined and CC accepts it
without error)

[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute

[burnus at gcc dot gnu.org]

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

--- Comment #19 from Tobias Burnus  2011-01-18 
12:57:11 UTC ---
Related: PR 47339

[Bug fortran/47339] Fortran 2003/2008: Valid NAMELIST rejected; Fortran 95: Invalid namelist objects accepted

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-01-18 
12:57:20 UTC ---
Related: PR 43062

[Bug c++/47343] New: incorrect location for declaration of class template partial specialization

[redi at gcc dot gnu.org]

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

   Summary: incorrect location for declaration of class template
partial specialization
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


template
  struct X : T
  {
void f();
  };

template
  inline void
  X::f()
  { }

template
  struct Y
  { };

template
  struct X< Y >;  // here

template
  inline void
  X< Y >::f()// xxx
  { }

ps2.cc:21:16: error: invalid use of incomplete type 'struct X >'
ps2.cc:2:10: error: declaration of 'struct X >'

The declaration of the partial specialization is on line 17 not line 2

(related to PR 47342)

[Bug c++/47342] misleading diagnostic for member of undeclared class template partial specialization

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-01-18 
13:00:26 UTC ---
Oops, the g++ diagnostics I showed were from 4.4 not 4.6, but they're the same
except 4.6 adds column numbers

I've created PR 47343 for the incorrect line number in the case where the
partial specialization is declared but incomplete.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-01-18 
13:07:06 UTC ---
Created attachment 23017
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23017
gcc46-pr47290.patch

Another possible untested patch that should handle any number of bbs in empty
infinite loop.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-01-18 
13:10:19 UTC ---
We could also limit the number of iterations:
   int i;

-  for (i = 1; VEC_iterate (eh_landing_pad, cfun->eh->lp_array, i, lp); ++i)
+  int len = VEC_length (eh_landing_pad, cfun->eh->lp_array) * 2;
+  for (i = 1; 
+   VEC_iterate (eh_landing_pad, cfun->eh->lp_array, i, lp) && i < len;
+   i++)
 if (lp)
   changed |= cleanup_empty_eh (lp);

[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute

[zazzou at gmail dot com]

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

--- Comment #20 from Xavier  2011-01-18 13:14:38 UTC 
---
Hi,

so, I am bit lost, "bug" is resolved or not ?
Correction available with next version of gcc ?

Thanks,

Xavier

[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle  2011-01-18 
13:27:48 UTC ---
It is not resolved because we are waiting for an interpretation from the
Fortran standards committee on whether the test case is valid or invalid
Fortran.  If invalid, then we need to give an error, if valid, we need to make
sure it works correctly.  Unfortunately, this PR is in a waiting state.

[Bug fortran/47339] Fortran 2003/2008: Valid NAMELIST rejected; Fortran 95: Invalid namelist objects accepted

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2011-01-18 
13:31:48 UTC ---
Created attachment 23018
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23018
Draft patch

Draft patch; handles most of the items - except that ALLOCATABLEs/POINTERs are
still rejected via symbol.c (cf. PR 43062). In order to enable the support, one
needs to fix the ICE mentioned there. The -std=f95 diagnostic is already
included in this patch. -- As are objects which require defined I/O.

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[rguenther at suse dot de]

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

--- Comment #31 from rguenther at suse dot de  
2011-01-18 13:37:42 UTC ---
On Tue, 18 Jan 2011, mikael at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
> 
> --- Comment #30 from Mikael Morin  2011-01-18 
> 12:48:41 UTC ---
> (In reply to comment #28)
> > One way would be to keep for data types all the time the two versions 
> > around:
> > One with restrict and one without restrict;
> makes sense
> 
> > thus, if one does type extension,
> > one has always a fully restrictless data type.
> Why? From my point of view type extension is orthogonal to target. 
> If an entity of extended derived type has the target/pointer attribute, one
> uses the non-restrict variant for its base type, and if it hasn't one uses the
> restrict variant. Do I miss something?
> 
> > Unfortunately, that seems to
> > cause a missed-optimization for
> >   type t
> > integer :: a
> > integer, pointer :: b
> >   end type t
> >   type(t) :: x
> > as "x%a" cannot alias and only "x%b" can - but is seems that one cannot 
> > encode
> > this for the ME such that "t" as a whole has to be marked as unrestricted.
> 
> How about: 
> 
> struct t_restrict {
>   int a;
>   int * b;
> } * restrict
> 
> VS
> 
> struct t_norestrict {
>   int a;
>   int * b;
> } *
> 
> ?

Yes.  The restrict qualifier on t_restrict * does not apply
to members, so as long as int *b is not restrict qualified
the b's alias.

> > I think the easiest would be to create for derived types sym->backend_decl 
> > and
> > another backend_decl with "restrict" - and propagate both variants types
> > through, when extending the type or including it into another type. As soon 
> > as
> > it is used as POINTER component, one could drop propagating the
> > backend_decl_restricted.
> 
> Looks like a plan. :-)

I think Micha has started working on something.

Richard.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-01-18 
13:39:47 UTC ---
(In reply to comment #7)
> We could also limit the number of iterations:
>int i;
> 
> -  for (i = 1; VEC_iterate (eh_landing_pad, cfun->eh->lp_array, i, lp); ++i)
> +  int len = VEC_length (eh_landing_pad, cfun->eh->lp_array) * 2;
> +  for (i = 1; 
> +   VEC_iterate (eh_landing_pad, cfun->eh->lp_array, i, lp) && i < len;
> +   i++)
>  if (lp)
>changed |= cleanup_empty_eh (lp);

won't it still say "changed" and iterate in the caller?  Note that we could
avoid the above if we'd avoid generating new landing-pads and instead moved
the old ones.

[Bug bootstrap/47230] [4.6 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  2011-01-18 13:43:10 
UTC ---
Why is the comparison marked with SCHED_GROUP_P?  I think that's your
underlying problem as SCHED_GROUP_P indicates the current insn must be
scheduled with the previous insn.  But there is no previous insn in the block.

(gdb) p debug_bb_n (4)
;; basic block 4, loop depth 0, count 0
;; prev block 3, next block 5
;; pred:   2 [50.0%] 
;; succ:   7 [78.4%]  5 [21.6%]  (fallthru)
;; bb 4 artificial_defs: { }
;; bb 4 artificial_uses: { u17(3){ }u18(29){ }u19(34){ }u20(35){ }}
;; lr  in   3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 43 47 48
;; lr  use  3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 43 47
;; lr  def  42 44
;; live  in   3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 43 47 48
;; live  gen  42 44
;; live  kill

(code_label 20 62 21 4 2 "" [1 uses])
(note 21 20 22 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 22 21 23 4 NOTE_INSN_DELETED)
(insn/s 23 22 60 4 (set (reg/v:SI 44 [ c ])
(ne:SI (cc0)
(const_int 0 [0]))) j.c:10 40 {*setcc}
 (nil))
(note 60 23 59 4 NOTE_INSN_DELETED)
(insn 59 60 30 4 (set (reg/v/f:SI 42 [ tmpp ])
(if_then_else:SI (ne (reg:SI 43 [ D.1959 ])
(const_int 1 [0x1]))
(reg/v/f:SI 47 [ op ])
(const_int 0 [0]))) j.c:15 46 {*movsicc_normal}
 (expr_list:REG_DEAD (reg/v/f:SI 47 [ op ])
(expr_list:REG_DEAD (reg:SI 43 [ D.1959 ])
(nil
(insn 30 59 31 4 (set (cc0)
(compare (reg/v/f:SI 42 [ tmpp ])
(const_int 0 [0]))) j.c:16 16 {cmpsi_insn}
 (expr_list:REG_DEAD (reg/v/f:SI 42 [ tmpp ])
(nil)))
(jump_insn 31 30 32 4 (set (pc)
(if_then_else (ne (cc0)
(const_int 0 [0]))
(label_ref:SI 50)
(pc))) j.c:16 53 {*branch_normal}
 (expr_list:REG_BR_PROB (const_int 7837 [0x1e9d])
(nil))
 -> 50)
;; lr  out  3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 44 48
;; live  out  3 [sp] 29 [r29] 34 [.fp] 35 [.ap] 44 48



Note the /s on insn 23.  That's SCHED_GROUP_P.

[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.18 13:46:50
 Ever Confirmed|0   |1

[Bug c++/47340] [trans-mem] problem with declaration of new operator

[patrick.marlier at gmail dot com]

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

--- Comment #1 from Patrick Marlier  
2011-01-18 13:47:21 UTC ---
Created attachment 23019
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23019
testcase

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-01-18 
13:49:18 UTC ---
cleanup_all_empty_eh is called just once per ehcleanup pass, doesn't iterate.
If we don't want to iterate on the new pads, we could just use len = VEC_length
too, but IMHO some iteration is helpful, as we don't recurse on them, and we
probably want to handle cases like moving pads across two empty bbs and with a
resx in the third bb or something similar.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  2011-01-18 
13:50:07 UTC ---
CCing Richard, as he wrote this function...

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[matz at gcc dot gnu.org]

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

--- Comment #32 from Michael Matz  2011-01-18 13:56:01 
UTC ---
Yes, but it's possible I was going up the wrong tree.  My idea was to
build the no-restrict variants of types on demand, as necessary, basically
from gfc_sym_type(), whenever sym->attr.pointer.

This nearly worked, as in, it gives the top-level objects ('x' in question
of the testcase from comment #2) a correct type (a record of only non-restrict
members, recursively).

Unfortunately the fortran frontend uses a peculiar way to expand the actual
'x%r' construct.  The necessary FIELD_DECL is not pulled out from the
type of 'x' (I mean the TREE_TYPE), but rather from the frontend-specific
representation of types, in this case from the r-named-component's
backend_decl.  And that very backend_decl itself doesn't depend on the
context, as in, there's always only one for a given type.

So, yes, adding another backend_decl for one component which would hold
the no-restrict variant would work.  But that feels like a gross hack.

Everything would work iff 'x' had the proper type from the start, in
the frontend representation already.  Then its components also would have
the proper attributes set (target namely), leading to correctly typed
backend_decls automatically.

I quickly tried to implement something like that last paragraph,
but were unsuccessful so far.  My basic idea was to remember if a frontend
decl had attr.pointer set, and then set attr.target for all subcomponents
(via current_attr or otherwise).  I thought this was possible as it seemed
to me that the frontend possibly builds types for declarations anew each
time if necessary.  But I might be wrong.

[Bug c++/47326] [4.4/4.5/4.6 Regression] ICE in tsubst_copy (triggered by dependency of return type on parameter pack size)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Target Milestone|--- |4.4.6
Summary|ICE in tsubst_copy  |[4.4/4.5/4.6 Regression]
   |(triggered by dependency of |ICE in tsubst_copy
   |return type on parameter|(triggered by dependency of
   |pack size)  |return type on parameter
   ||pack size)

--- Comment #4 from H.J. Lu  2011-01-18 14:13:14 
UTC ---
It is caused by revision 145013:

http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00520.html

[Bug c++/47289] [4.4/4.5 Regression] [C++0x] ICE in tsubst_pack_expansion (triggered by decltype)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
   Target Milestone|4.6.0   |4.4.6
Summary|[C++0x] ICE in  |[4.4/4.5 Regression]
   |tsubst_pack_expansion   |[C++0x] ICE in
   |(triggered by decltype) |tsubst_pack_expansion
   ||(triggered by decltype)

--- Comment #6 from H.J. Lu  2011-01-18 14:17:13 
UTC ---
4.4/4.5 regression.

[Bug middle-end/47344] New: [4.3/4.4/4.5/4.6 Regression][meta-bug] GCC gets slower and uses more memory

[rguenth at gcc dot gnu.org]

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

   Summary: [4.3/4.4/4.5/4.6 Regression][meta-bug] GCC gets slower
and uses more memory
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: compile-time-hog, memory-hog
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Depends on: 18687,26854


This is a meta-bug for old(!) compile-time and memory-usage regressions that
we keep not closing for whatever reason and that are present on all active
branches.

Those bugs got their regression markers removed now and instead are liked from
this single regression bug.

[Bug middle-end/47344] [4.3/4.4/4.5/4.6 Regression][meta-bug] GCC gets slower and uses more memory

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.18 14:20:10
   Target Milestone|--- |4.3.6
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-01-18 
14:20:10 UTC ---
Confirmed.

[Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  2011-01-18 14:20:40 
UTC ---
Please note that valgrind also complaints search_line_acc_char
which doesn't use SSE2/SSE4.

[Bug tree-optimization/18687] >200% compile time regression compared to gcc-3.4

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.3.6   |---
Summary|[4.3/4.4/4.5/4.6|>200% compile time
   |Regression] >200% compile   |regression compared to
   |time regression compared to |gcc-3.4
   |gcc-3.4 |
  Known to fail||4.6.0

--- Comment #54 from Richard Guenther  2011-01-18 
14:21:28 UTC ---
PR47344 now tracks the "regression" property of this bug.

[Bug tree-optimization/26854] Inordinate compile times on large routines

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.3.6   |---
Summary|[4.3/4.4/4.5/4.6|Inordinate compile times on
   |Regression] Inordinate  |large routines
   |compile times on large  |
   |routines|
  Known to fail||4.6.0

--- Comment #121 from Richard Guenther  2011-01-18 
14:22:57 UTC ---
PR47344 now tracks the regression property of this bug.

[Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  2011-01-18 
14:23:32 UTC ---
That's because even that routines operates on (aligned) word_type sized chunks.

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Blocks||47344
   Target Milestone|4.3.6   |---
Summary|[4.3/4.4/4.5/4.6|gcc 4.3.1 cannot compile
   |Regression] gcc 4.3.1   |big function
   |cannot compile big function |
  Known to fail||4.6.0

--- Comment #42 from Richard Guenther  2011-01-18 
14:28:00 UTC ---
PR47344 now tracks the regression property of this bug.

[Bug bootstrap/47345] New: [4.6 Regression] LTO failed to bootstrap-profiled

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] LTO failed to bootstrap-profiled
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/Intel64, revision 168948 failed to bootstrap-profiled
with LTO:

http://gcc.gnu.org/ml/gcc-regression/2011-01/msg00279.html

/export/gnu/import/svn/gcc-test-profile/bld/./prev-gcc/xgcc
-B/export/gnu/import/svn/gcc-test-profile/bld/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -g -O2 -flto=jobserver
-frandom-seed=1 -fprofile-use -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 -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H
-static-libstdc++ -static-libgcc  -o gfortran \
  gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o vec.o
ggc-none.o gfortranspec.o version.o prefix.o intl.o driver-i386.o 
../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
../../src-trunk/gcc/config/i386/i386.md: In function 'bypass_p':
../../src-trunk/gcc/config/i386/i386.md:20383:1: error: corrupted profile info:
profile data is not flow-consistent
../../src-trunk/gcc/config/i386/i386.md:20383:1: error: corrupted profile info:
number of executions for edge 715-900 thought to be -2012
../../src-trunk/gcc/config/i386/i386.md:20383:1: error: corrupted profile info:
number of executions for edge 715-716 thought to be 469950
../../src-trunk/gcc/config/i386/i386.md:20383:1: error: corrupted profile info:
number of executions for edge 717-900 thought to be -1190
../../src-trunk/gcc/config/i386/i386.md:20383:1: error: corrupted profile info:
number of executions for edge 717-718 thought to be 353590
../../src-trunk/gcc/config/i386/i386.md:20383:1: error: corrupted profile info:
number of executions for edge 734-900 thought to be -1875
../../src-trunk/gcc/config/i386/i386.md:20383:1: error: corrupted profile info:
number of executions for edge 734-735 thought to be 1875
make[6]: *** [insn-attrtab.o] Error 1

Revision 168944 is OK.  I didn't see checkins between revision 168944
and revision 168948 can cause this.

[Bug bootstrap/47345] [4.6 Regression] LTO failed to bootstrap-profiled

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #1 from Jack Howarth  2011-01-18 
14:42:11 UTC ---
A few weeks back I saw a corrupted profile information bootstrap failure on
x86_64-apple-darwin10  but it was transitory and couldn't be reproduced (at
least in later revisions).

[Bug target/36861] [4.5/4.6 Regression] boost's compressed avl confuses GCC

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||
  Known to fail||

--- Comment #36 from Richard Guenther  2011-01-18 
14:43:50 UTC ---
Trunk is now very fast and segfaults the testcase ;)

[Bug tree-optimization/26854] Inordinate compile times on large routines

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #122 from Jan Hubicka  2011-01-18 
14:48:32 UTC ---
oprofiling shows that 50% of parsing time is in decl_jump_unsafe that is C
frontend thingy to output some sort of warnings on gotos to VLAs.  This can
probably be solved quite easilly.

Later we get (at -O2 all.i)
8341717.0179  cc1  dominated_by_p
7516415.3342  cc1  bitmap_equal_p
38134 7.7797  cc1  bitmap_set_bit
26144 5.3336  cc1  bitmap_ior_into
21031 4.2905  cc1  decl_jump_unsafe
16142 3.2931  cc1  register_new_assert_for.isra.42
12713 2.5936  cc1  bitmap_elt_insert_after
11136 2.2719  cc1  sbitmap_a_or_b
10625 2.1676  cc1  et_splay
10059 2.0521  cc1  walk_dominator_tree
6775  1.3822  cc1  dse_enter_block
5952  1.2143  cc1  bitmap_bit_p

probably callgrinding to work out who is doing so many dominance tests might be
enlightening. I get 5.3GB memory use at that point. 300MB of it seems to be
GGC.

Later in RTL copmilation DCE seems to get stuck...
6281522.8048  cc1  mark_insn
4074814.7934  cc1  rest_of_handle_ud_dce
18558 6.7374  cc1  bitmap_and_into
13046 4.7363  cc1  bitmap_elt_insert_after
9955  3.6141  cc1  bitmap_copy
8812  3.1992  cc1  bitmap_ior_into
7271  2.6397  cc1  bitmap_set_bit
6952  2.5239  cc1  bitmap_ior_and_compl
6718  2.4389  cc1  ira_compress_allocno_live_ranges
6370  2.3126  cc1  create_start_finish_chains
6123  2.2229  cc1  bitmap_and
4627  1.6798  cc1  bitmap_and_compl_into
3688  1.3389  cc1  regstat_compute_ri
3150  1.1436  cc1  record_reg_classes.constprop.9

Finally at IRA time we get stuck in 
168451   33.5060  cc1  ira_build_conflicts
46025 9.1547  cc1  allocno_spill_priority_compare
18558 3.6913  cc1  bitmap_and_into
13046 2.5949  cc1  bitmap_elt_insert_after
12285 2.4436  cc1  color_pass
9955  1.9801  cc1  bitmap_copy
8812  1.7528  cc1  bitmap_ior_into
7689  1.5294  cc1  splay_tree_splay

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[hubicka at gcc dot gnu.org]

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

--- Comment #43 from Jan Hubicka  2011-01-18 
14:53:46 UTC ---
Now at -O2 the main inliner seems to degenerate ;(
168767   78.4974  cc1  cgraph_edge_badness
9426  4.3842  cc1  update_edge_key
3529  1.6414  cc1  update_caller_keys
2498  1.1619  cc1  bitmap_set_bit
1776  0.8261  opreport /usr/bin/opreport
1212  0.5637  cc1  bitmap_elt_insert_after
1166  0.5423  oprofiled/usr/bin/oprofiled
1106  0.5144  libc-2.11.1.so   _IO_vfscanf
965   0.4488  cc1  bitmap_ior_into

[Bug tree-optimization/26854] Inordinate compile times on large routines

[dberlin at gcc dot gnu.org]

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

--- Comment #123 from Daniel Berlin  2011-01-18 
14:54:33 UTC ---
On Tue, Jan 18, 2011 at 9:49 AM, hubicka at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
>
> Jan Hubicka  changed:
>
>           What    |Removed                     |Added
> 
>                 CC|                            |hubicka at gcc dot gnu.org
>
> --- Comment #122 from Jan Hubicka  2011-01-18 
> 14:48:32 UTC ---
> oprofiling shows that 50% of parsing time is in decl_jump_unsafe that is C
> frontend thingy to output some sort of warnings on gotos to VLAs.  This can
> probably be solved quite easilly.
>

> Later we get (at -O2 all.i)
> 83417    17.0179  cc1                      dominated_by_p
> 75164    15.3342  cc1                      bitmap_equal_p
> 38134     7.7797  cc1                      bitmap_set_bit
> 26144     5.3336  cc1                      bitmap_ior_into
> 21031     4.2905  cc1                      decl_jump_unsafe
> 16142     3.2931  cc1                      register_new_assert_for.isra.42
> 12713     2.5936  cc1                      bitmap_elt_insert_after
> 11136     2.2719  cc1                      sbitmap_a_or_b
> 10625     2.1676  cc1                      et_splay
> 10059     2.0521  cc1                      walk_dominator_tree
> 6775      1.3822  cc1                      dse_enter_block
> 5952      1.2143  cc1                      bitmap_bit_p


This looks suspiciously like it's not using the DFS numbers

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[hubicka at gcc dot gnu.org]

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

--- Comment #44 from Jan Hubicka  2011-01-18 
14:58:04 UTC ---
and later IRA
samples  %app name symbol name
2582656.8667  cc1  allocno_spill_priority_compare
6812 14.9994  cc1  ira_build_conflicts
4308  9.4859  cc1  splay_tree_splay
2847  6.2689  cc1  color_pass
1661  3.6574  cc1  push_allocno_to_stack
1336  2.9418  cc1  build_object_conflicts
468   1.0305  cc1  bitmap_bit_p
443   0.9754  cc1  splay_tree_insert

df reaching defs  :   1.65 ( 1%) usr   0.42 (10%) sys   2.10 ( 1%) wall
  0 kB ( 0%) ggc
 df live regs  :   4.27 ( 2%) usr   0.00 ( 0%) sys   4.24 ( 2%) wall   
   0 kB ( 0%) ggc
 df live&initialized regs:   1.31 ( 1%) usr   0.01 ( 0%) sys   1.32 ( 1%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:   0.72 ( 0%) usr   0.00 ( 0%) sys   0.72 ( 0%)
wall   0 kB ( 0%) ggc
 df reg dead/unused notes:   4.32 ( 2%) usr   0.00 ( 0%) sys   4.31 ( 2%) wall 
  8508 kB ( 1%) ggc
 register information  :   2.05 ( 1%) usr   0.00 ( 0%) sys   2.02 ( 1%) wall   
   0 kB ( 0%) ggc

362   0.7971  cc1  splay_tree_remove
193   0.4250  cc1  splay_tree_free
167   0.3677  cc1  add_copies


 inline heuristics :  81.88 (35%) usr   0.04 ( 1%) sys  82.07 (35%) wall  
44238 kB ( 5%) ggc
 CSE   :   4.09 ( 2%) usr   0.00 ( 0%) sys   4.12 ( 2%) wall   
 138 kB ( 0%) ggc
 CSE 2 :   4.13 ( 2%) usr   0.00 ( 0%) sys   4.12 ( 2%) wall   
 125 kB ( 0%) ggc
 integrated RA :  50.18 (22%) usr   0.18 ( 4%) sys  50.48 (21%) wall   
7472 kB ( 1%) ggc
 reload:   9.21 ( 4%) usr   0.00 ( 0%) sys   9.25 ( 4%) wall  
12180 kB ( 1%) ggc
 scheduling 2  :   3.81 ( 2%) usr   0.00 ( 0%) sys   3.79 ( 2%) wall   
 356 kB ( 0%) ggc

So mostly IRA and main inliner.  I am not sure how much I can do for main
inliner except for adding some hard limit on how much work we put into updating
the priority queue and ignoring inconsistencies when it is met...

Honza

[Bug c++/40901] Access qualifiers of embedded templates are discarded

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #3 from Jonathan Wakely  2011-01-18 
15:07:56 UTC ---
access control isn't done for a nested-name-specifier

class C
{
  struct Private { };
};

template
struct exploit
{
typedef T type;
};

exploit::type x2;   // should be an error

[Bug c++/40901] Access qualifiers of embedded templates are discarded

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-01-18 
15:11:05 UTC ---
(In reply to comment #3)
> access control isn't done for a nested-name-specifier

sorry, should be  "... for arguments in a template-id in a
nested-name-specifier"

[Bug c++/47346] New: access control for nested type is ignored in class template

[redi at gcc dot gnu.org]

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

   Summary: access control for nested type is ignored in class
template
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


There are several bugs about failure to do access checking for template
parameters and in function templates (PR 40901, PR 41437, PR 45011, PR 45917)
but I don't think this is a dup of any of them

class C
{
  struct Private { };
};

template
struct exploit1
{
typedef C::Private type;
};

exploit1::type x1;   // error

// similarly for base-specifier
template
struct exploit2 : C::Private
{
};

exploit2 x2;   // error

[Bug tree-optimization/26854] Inordinate compile times on large routines

[hubicka at ucw dot cz]

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

--- Comment #124 from Jan Hubicka  2011-01-18 15:15:01 
UTC ---
> 
> This looks suspiciously like it's not using the DFS numbers
It seems that they are used, just we do a lot of queries from
register_new_assert_for
according to my ^C GDB profiling.

Honza
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.

[Bug tree-optimization/26854] Inordinate compile times on large routines

[dberlin at gcc dot gnu.org]

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

--- Comment #125 from Daniel Berlin  2011-01-18 
15:18:25 UTC ---
>
> --- Comment #124 from Jan Hubicka  2011-01-18 15:15:01 
> UTC ---
>>
>> This looks suspiciously like it's not using the DFS numbers
> It seems that they are used, just we do a lot of queries from
> register_new_assert_for
> according to my ^C GDB profiling.
>

Interesting, i wonder why et_splay shows up at all then.

[Bug target/36861] [4.5/4.6 Regression] boost's compressed avl confuses GCC

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #37 from Richard Guenther  2011-01-18 
15:19:05 UTC ---
Ok, with -O1 -fno-tree-loop-im as basic flags -fno-tree-dse makes the
difference for the segfault when we remove

 static void
boost::intrusive::avltree_algorithms::rebalance_after_i
nsertion(boost::intrusive::avltree_algorithms::node_ptr,
boost::intr
usive::avltree_algorithms::node_ptr) [with NodeTraits =
boost::intru
sive::avltree_node_traits, false>,
boost::
intrusive::avltree_algorithms::node_ptr =
boost::interprocess::offse
t_ptr > >] 
(struct node_ptr & restrict header, struct node_ptr & restrict x)
 {
   long int D.64530;
@@ -8290,7 +7992,6 @@
   p.19_2156 = (long int) D.64522_2154;
   D.64529_2157 = (long int) D.64513_2150;
   D.64530_2158 = p.19_2156 - D.64529_2157;
-  MEM[(struct offset_ptr *)D.64515_2149].m_offset = D.64530_2158;
   if (D.64530_2158 == 1)
 goto ;
   else

this pointer is believed to point to

D.64515_2149, points-to NULL, points-to vars: { D.57715 CAST_RESTRICT.445 }
(includes restrict tags)

computed from

:
  n_2143 = (struct node_ptr & restrict) &D.57715;
  p_2144 = (struct node_ptr & restrict) &D.57716;
  D.64517_2145 = D.57715.m_offset;
  D.64516_2147 = (long unsigned int) D.64517_2145;
  D.64515_2148 = n_2143 + D.64516_2147;

:
  # D.64515_2149 = PHI <0B(739), D.64515_2148(742)>

which confirms the points-to calculation.

But the compressed AVL tree thinks it can represent a pointer to
a global object by using the address of a local variable and
the difference between the address of the global and the local.
Which it of course cannot according to the C++ standard.
D.57715.m_offset is set by

:
  p.19_2139 = (long int) D.64504_2137;
  D.64508_2140 = (long int) &D.57715;
  D.64509_2141 = p.19_2139 - D.64508_2140;
  D.57715.m_offset = D.64509_2141;
  if (D.64509_2141 == 1)
goto ;
  else
goto ;

and we have

:
boost::interprocess::offset_ptr
> >::offset_ptr (&D.57716, &root);
  D.64502_2134 = MEM[(const struct offset_ptr *)header_2(D)].m_offset;
  if (D.64502_2134 != 1)
goto ;
  else
goto ;

:
  D.64503_2136 = (long unsigned int) D.64502_2134;
  D.64504_2137 = header_2(D) + D.64503_2136;

where header_2(D) is a parameter, struct node_ptr & restrict header.  So
Boost AVL expects us to compute whatever header points-to as points-to
set of D.64515_2149 with no backing from the standard that we are required
to do that.

If we were able to "optimize" the code back to base the address on
header it would of course work (by luck).

For

extern void abort (void);
struct X { unsigned long offset; };
void foo (char *p)
{
  struct X a;
  char tmp, *q;
  a.offset = p - &tmp;
  if (a.offset == 1)
abort ();
  q = &tmp + a.offset;
  *q = 0;
}

already early DCE kills the store (the above is what compressed AVL does).

Thus, this testcase is invalid.  Resulting performance is irrelevant.

[Bug bootstrap/47345] [4.6 Regression] LTO failed to bootstrap-profiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug rtl-optimization/47216] [4.6 Regression] gcc.dg/torture/pr43360.c FAILs with -O -fPIC -fgcse -fgcse-sm -fnon-call-exceptions -fno-tree-dse

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-01-18 
15:50:59 UTC ---
Author: rguenth
Date: Tue Jan 18 15:50:55 2011
New Revision: 168951

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168951
Log:
2011-01-18  Richard Guenther  

PR rtl-optimization/47216
* emit-rtl.c: Include tree-flow.h.
(set_mem_attributes_minus_bitpos): Use tree_could_trap_p instead
of replicating it with different semantics.
* Makefile.in (emit-rtl.o): Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/emit-rtl.c

[Bug rtl-optimization/47216] [4.6 Regression] gcc.dg/torture/pr43360.c FAILs with -O -fPIC -fgcse -fgcse-sm -fnon-call-exceptions -fno-tree-dse

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2011-01-18 
15:53:22 UTC ---
Fixed.

[Bug bootstrap/47345] [4.6 Regression] LTO failed to bootstrap-profiled

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth  2011-01-18 
16:16:24 UTC ---
No problems on x86_64-apple-darwin10 with profiledbootstrap BOOT_CFLAGS="-g
-O3" using...

Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.6.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc-4.6-20110118/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--with-build-config=bootstrap-lto --enable-stage1-languages=c,lto
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --enable-build-with-cxx
--with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw
--with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-checking=yes
--enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20110118 (experimental) (GCC) 

at r168947.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rth at gcc dot gnu.org]

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

--- Comment #11 from Richard Henderson  2011-01-18 
16:45:09 UTC ---
Jakub, I'm fine with your second patch to detect infinite loops, with
the proviso that you break out the test into a separate function.

[Bug c++/47347] New: "pragma GCC diagnostic ignored" has no effect sometimes

[gcc at dpinol dot com]

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

   Summary: "pragma GCC diagnostic ignored" has no effect
sometimes
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@dpinol.com


The code below produces warning "warning: unused parameter ‘a’
[-Wunused-parameter]" were it shouldn't, since this diagnostic should be
ignored.
If we remove the final line, the warning does not appear, but I understand that
a pragma should not affect previous lines.

#pragma GCC diagnostic ignored "-Wunused-parameter"

#include 

template 
struct KeyValue
{
public:
  virtual ~KeyValue()
  {
  }

  virtual void serialize(int a) const
  {
  }
};

void f()
{
  std::vector< KeyValue  >  values;
}
#pragma GCC diagnostic warning "-Wunused-parameter"

[Bug tree-optimization/46886] [4.5/4.6 Regression] gfortran.dg/array_constructor_9.f90 FAILs with -ftree-parallelize-loops -fstrict-overflow -fno-tree-ch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu.org,
   ||spop at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-01-18 
17:00:29 UTC ---
Seems one extra incorrect iteration is added after GOMP_parallel_end:
:
  D.1592_69 = D.1591_183 * 4;

:
  # D.1592_15 = PHI <0(15), D.1592_69(16)>
  D.1749_71 = () D.1592_15;
  D.1750_72 = MAX_EXPR ;
  D.1751_73 = __builtin_malloc (D.1750_72);
  D.1594_74 = (void * restrict) D.1751_73;
  D.1898_232 = () D.1591_183;
  D.1899_233 = D.1591_183 >= 0;
  D.1900_234 = D.1898_232 > 199;
  D.1901_235 = D.1899_233 && D.1900_234;
  if (D.1901_235 != 0)
goto ;
  else
goto ;

:
  .paral_data_store.64.D.1910 = D.1578_1;
  .paral_data_store.64.D.1911 = D.1594_74;
  .paral_data_store.64.D.1912 = D.1898_232;
  __builtin_GOMP_parallel_start (build._loopfn.1, &.paral_data_store.64, 2);
  build._loopfn.1 (&.paral_data_store.64);
  __builtin_GOMP_parallel_end ();
  ivtmp.60_247 = D.1898_232;
  S.7_248 = (integer(kind=8)) ivtmp.60_247;
  D.1755_249 = *D.1578_1[S.7_248];
  MEM[(real(kind=4)[0:] *)D.1594_74][S.7_248] = D.1755_249;
  S.7_251 = S.7_248 + 1;
  ivtmp.60_252 = ivtmp.60_247 + 1;
S.7_248 is equal to the number of ints allocated, so stores after the end of
malloced area.  The loop is initially:
loop_4 (header = 18, latch = 19, niter = , upper_bound = 9223372036854775808,
estimate = 9223372036854775808)
{
  bb_18 (preds = {bb_17 bb_19 }, succs = {bb_20 bb_19 })
  {
  :
# S.7_7 = PHI <0(17), S.7_80(19)>
# .MEM_152 = PHI <.MEM_182(17), .MEM_185(19)>
if (S.7_7 > D.1586_64)
  goto ;
else
  goto ;

  }
  bb_19 (preds = {bb_18 }, succs = {bb_18 })
  {
  :
# VUSE <.MEM_152>
D.1755_79 = *D.1578_1[S.7_7];
# .MEM_185 = VDEF <.MEM_152>
MEM[(real(kind=4)[0:] *)D.1594_74][S.7_7] = D.1755_79;
S.7_80 = S.7_7 + 1;
goto ;

  }
}
and try_get_loop_niter computes niter->niter as ()
D.1591_183.  On:
__attribute__((noinline, noclone)) void
foo (int *__restrict__ p, int *__restrict__ q, int n)
{
  int i;
  for (i = 0; i < n; i++)
p[i] = q[i];
}

int
main (void)
{
  int *p = __builtin_calloc (1024, sizeof (int));
  int *q = __builtin_calloc (1024, sizeof (int));
  foo (p, q, 1024);
  return 0;
}
try_get_loop_niter instead computes niter->niter as n - 1 (which is strange to
me), but then it works even with the extra iteration added after
GOMP_parallel_end (as that iteration is done with iv set to n - 1).

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-01-18 
17:20:56 UTC ---
Created attachment 23020
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23020
gcc46-pr47290.patch

Like this (still untested but on this testcase)?

[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[mikael at gcc dot gnu.org]

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

--- Comment #33 from Mikael Morin  2011-01-18 
17:21:54 UTC ---
(In reply to comment #32)
> Yes, but it's possible I was going up the wrong tree.  My idea was to
> build the no-restrict variants of types on demand, as necessary, basically
> from gfc_sym_type(), whenever sym->attr.pointer.
> 
> This nearly worked, as in, it gives the top-level objects ('x' in question
> of the testcase from comment #2) a correct type (a record of only non-restrict
> members, recursively).
> 
> Unfortunately the fortran frontend uses a peculiar way to expand the actual
> 'x%r' construct.  The necessary FIELD_DECL is not pulled out from the
> type of 'x' (I mean the TREE_TYPE), but rather from the frontend-specific
> representation of types, in this case from the r-named-component's
> backend_decl.  And that very backend_decl itself doesn't depend on the
> context, as in, there's always only one for a given type.
> 
> So, yes, adding another backend_decl for one component which would hold
> the no-restrict variant would work.  But that feels like a gross hack.
> 
> Everything would work iff 'x' had the proper type from the start, in
> the frontend representation already.  Then its components also would have
> the proper attributes set (target namely), leading to correctly typed
> backend_decls automatically.
> 
> I quickly tried to implement something like that last paragraph,
> but were unsuccessful so far.  My basic idea was to remember if a frontend
> decl had attr.pointer set, and then set attr.target for all subcomponents
> (via current_attr or otherwise).  I thought this was possible as it seemed
> to me that the frontend possibly builds types for declarations anew each
> time if necessary.  But I might be wrong.
As I said in comment #27, gfc_component structs belonging to the type, they are
shared between target and non-target variants. Thus one cannot set inherited
target attributes on them. 
Consider this :
!
type bar
  integer :: a
end type bar

type(bar), pointer :: b
type(bar)  :: c
end
!
If you want to set the target attribute on b%a, you will set it on the `a'
component of the `bar' type, and will impact `c' as well.

[Bug c++/47338] [4.5 Regression] cc1plus returns exist code 5

[daniel.f.starke at freenet dot de]

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

--- Comment #2 from daniel.f.starke at freenet dot de 2011-01-18 17:30:54 UTC 
---
What do you mean by debug? I can't even compile it because cc1plus exists half
the way.

[Bug c++/47347] "pragma GCC diagnostic ignored" has no effect sometimes

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-01-18 
17:32:39 UTC ---
reduced:

#pragma GCC diagnostic ignored "-Wunused-parameter"

template 
struct KeyValue
{
  virtual void serialize(int a) const
  {
  }
};

void f()
{
  KeyValue  values;
}
#pragma GCC diagnostic warning "-Wunused-parameter"


The template instantiation is at the end of the file, after the warning has
been re-enabled.

There's no warning with 4.6.0

[Bug c++/47338] [4.5 Regression] cc1plus returns exit code 5

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-01-18 
17:35:34 UTC ---
debug cc1plus to see where/why it exits, not debug your application

[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.01.18 17:38:15
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-01-18 
17:38:15 UTC ---
When dwarf2out_abstract_function is called on MAIN__, it doesn't have
DECL_INITIAL set when in lto1 (compared to f951), the BLOCK tree is simply not
present, which both causes incomplete debug information and for Fortran COMMON
blocks ICEs, as it relies on those to be actually present.  P4 as it only
affects Fortran, but if -flto -g is ever meant to be usable, the BLOCK trees
need to be streamed out and preserved.  It seems output_function calls:
  /* Output DECL_INITIAL for the function, which contains the tree of
 lexical scopes.  */
  lto_output_tree (ob, DECL_INITIAL (function), true);
but for inlines output_function isn't called.

[Bug target/47318] _mm256_maskstore_pd has wrong prototype

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from H.J. Lu  2011-01-18 18:00:08 
UTC ---
Fixed.

[Bug fortran/47348] New: substring with len_trim in array constructor

[tkoenig at gcc dot gnu.org]

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

   Summary: substring with len_trim in array constructor
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
Blocks: 19276


This one is strange; it is with recent trunk.

ig25@linux-fd1f:~/Krempel/Char-4> cat foo.f90
program main
  implicit none
  character(len=3) :: c(3)

  c = 'x'

  print '(3(A,"|"))', (/ (/ trim(c(1)), 'a' /)//'c', 'cd' /)
  print '(3(A,"|"))', (/ (/ c(1)(1:len_trim(c(1))), 'a' /)//'c', 'cd' /)
  print '(3(A,"|"))', (/ (/ c(1)(1:1), 'a' /)//'c', 'cd' /)
end program main
ig25@linux-fd1f:~/Krempel/Char-4> gfortran foo.f90
ig25@linux-fd1f:~/Krempel/Char-4> ./a.out
xc|ac|cd|
x |a |cd|
xc|ac|cd|

The second line should be identical to the first and third one.

Modified from nested_array_constructor_2.f90, BTW.

Goes back at least to 4.4.1, so probably not a regression.

[Bug tree-optimization/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop

[rth at gcc dot gnu.org]

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

--- Comment #13 from Richard Henderson  2011-01-18 
18:20:49 UTC ---
Looks good.  Ok if it passes tests.

[Bug fortran/47349] New: missing warning: Actual argument contains too few elements

[janus at gcc dot gnu.org]

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

   Summary: missing warning: Actual argument contains too few
elements
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


Test case:


 implicit none
 type t
integer :: j(3)
 end type t

 type(t) :: tt
 integer :: i(3) = (/ 1,2,3 /)

 tt%j = i

 call sub1 (i) ! Warning: Actual argument contains too few elements
 call sub1 (tt%j)  ! <- XXX (no warning!)
 call sub2 (i) ! Error: Rank mismatch in argument
 call sub2 (tt%j)  ! Error: Rank mismatch in argument

contains

  subroutine sub1(i)
integer, dimension(1:3,1:3) :: i
print *,"sub1:",i
  end subroutine

  subroutine sub2(i)
integer, dimension(:,:) :: i
print *,"sub2:",i
  end subroutine

end



For the line marked "XXX" one should get the same warning as for the line
above. Errors are only mandatory for assumed-size dummies (thrown correctly for
both cases), cf. F08:12.5.2.4.

[Bug fortran/47348] substring with len_trim in array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-01-18 18:42:45 UTC ---
gfortran 4.2.5 tries to grab 4 GB of memory and eventually
I killed the job.  With 4.3.something, I get

troutmask:sgk[211] gfc43 -o z df.f90 
df.f90: In function 'main':
df.f90:5: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.

Definitely, an interesting bug.

[Bug tree-optimization/47271] [4.6 Regression] if-conversion removes a test (if), the function generates invalid outputs

[spop at gcc dot gnu.org]

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

--- Comment #5 from Sebastian Pop  2011-01-18 18:45:27 
UTC ---
In this loop:

  for (i=0, nops=0 ; i= 90) ? 3 : 1))
{
  addrmap[i] = i - nops;
  if (codestr[i] == 9)
nops++;
}

it looks like this part: i += ((codestr[i] >= 90) ? 3 : 1)
is miscompiled into:

  # i_35 = PHI 
  iftmp.0_4 = [cond_expr] D.2702_12 != 9 ? 3 : 1;
  i_19 = iftmp.0_4 + i_35;

the predicate for the increment is wrongly computed.

[Bug libstdc++/36104] [4.3/4.4/4.5/4.6 Regression] gnu-versioned-namespace is broken

[bkoz at gcc dot gnu.org]

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

--- Comment #11 from Benjamin Kosnik  2011-01-18 
19:01:01 UTC ---

yes. debug mode + versioning still in progress. expect to wrap that up asap

[Bug fortran/47349] missing warning: Actual argument contains too few elements

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org 2011-01-18 19:08:00 UTC ---
Here's a first patch, not regtested yet:

Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 168850)
+++ gcc/fortran/interface.c (working copy)
@@ -1915,8 +1915,6 @@ get_expr_storage_size (gfc_expr *e)
- mpz_get_si (ref->u.ar.as->lower[i]->value.integer));
}
 }
-  else
-   return 0;
 }

   if (substrlen)

[Bug target/36861] [4.5/4.6 Regression] boost's compressed avl confuses GCC

[igaztanaga at gmail dot com]

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

--- Comment #38 from Ion Gaztañaga  2011-01-18 
19:15:22 UTC ---
Thanks Richard for the detailed report. The fact is that the next standard is
trying to support relative pointers for container implementations (much like
Boost.Interprocess does), to be able to place containers in shared memory. In
those cases the relative pointers stores the difference between "this" and the
pointee, which is what boost::interprocess::offset_ptr does.

It is certainly outside the standard right now and the standard won't include
such "relative pointer" class, but it will require to container implementations
to support them as allocator::pointer types. It would be important to find a
way to use smart pointers, maybe with some existing annotation/attribute to
avoid optimizing away that relative addressing, so that there is always away to
compute the pointee address based on "this" + this->m_offset. It is also
important to support smart pointers created on the stack pointing to global
objects (temporaries, function arguments, etc.)

I know this is outside the bug, but it will be certainly a common question when
using GCC and next standard containers. Thanks

[Bug fortran/47348] substring with len_trim in array constructor

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Blocks||47065

--- Comment #2 from Thomas Koenig  2011-01-18 
19:39:32 UTC ---
Of course, I can't replace trim(c(1)) with c(1)(1:len_trim(c(1)) until
this is resolved (which is why I found the bug in the first place),
so mark this as blocking PR 47065.

[Bug testsuite/41146] FAIL: gcc.target/powerpc/asm-es-2.c scan-assembler *

[mrs at gcc dot gnu.org]

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

--- Comment #4 from mrs at gcc dot gnu.org  2011-01-18 
20:06:17 UTC ---
Author: mrs
Date: Tue Jan 18 20:06:13 2011
New Revision: 168960

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168960
Log:
2011-01-18  Dominique d'Humieres  

PR testsuite/41146
* gcc.target/powerpc/asm-es-2.c: Adjust regular expression for
powerpc-apple-darwin9.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/asm-es-2.c

[Bug tree-optimization/47179] [4.5/4.6 Regression] SPU: errno misoptimization around malloc call

[uweigand at gcc dot gnu.org]

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

--- Comment #4 from Ulrich Weigand  2011-01-18 
20:13:59 UTC ---
Author: uweigand
Date: Tue Jan 18 20:13:56 2011
New Revision: 168961

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168961
Log:
PR tree-optimization/47179
* config/spu/spu.c (spu_ref_may_alias_errno): New function.
(TARGET_REF_MAY_ALIAS_ERRNO): Define.

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

[Bug tree-optimization/47179] [4.5/4.6 Regression] SPU: errno misoptimization around malloc call

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Ulrich Weigand  2011-01-18 
20:16:10 UTC ---
Fixed.

[Bug fortran/47350] New: Deferred string length: ALLOCATE should allow MOLD=

[burnus at gcc dot gnu.org]

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

   Summary: Deferred string length: ALLOCATE should allow MOLD=
   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


Currently, gfortran allows:

  character(len=:) :: str, str2
  ALLOCATE( str, SOURCE=str2)

but it does not allow for
  ALLOCATE( str, MOLD=str2)
which fails with
  Error: Allocate-object at (1) with a deferred type parameter requires either
a type-spec or SOURCE tag

Expected: MOLD (which is also a source-expr) is also accepted.


>From Fortran 2008 (which added MOLD=, which is already implemented in
gfortran):

C629 (R626) If any allocate-object has a deferred type parameter, is unlimited
polymorphic, or is of abstract type, either type-spec or source-expr shall
appear.

If source-expr is a pointer, it shall be associated with a target. If
source-expr is allocatable, it shall be allocated.
If MOLD= appears and source-expr is a variable, its value need not be defined.

[Bug tree-optimization/43567] linear loop transform

[spop at gcc dot gnu.org]

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

--- Comment #5 from Sebastian Pop  2011-01-18 20:47:10 
UTC ---
*** Bug 43568 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/43568] linear loop transform

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||spop at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #2 from Sebastian Pop  2011-01-18 20:47:10 
UTC ---
Indeed this is a duplicate.

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

[Bug c++/47338] [4.5 Regression] cc1plus returns exit code 5

[daniel.f.starke at freenet dot de]

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

--- Comment #4 from Daniel Starke  
2011-01-18 20:48:34 UTC ---
Here is the debugging output. I can attach the whole back-trace if needed.

GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
...
Reading symbols from
d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe...done.
(gdb) run -fpreprocessed XmlResultReader.ii -quiet -dumpbase XmlResultReader.ii
-mtune=i386 -march=i386 -auxbase-strip XmlResultReader.o -version -o
XmlResultReader.s
Starting program:
d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe
-fpreprocessed XmlResultReader.ii -quiet -dumpbase XmlResultReader.ii
-mtune=i386 -march=i386 -auxbase-strip XmlResultReader.o -version -o
XmlResultReader.s
[New Thread 4016.0x9f4]
GNU C++ (GCC) version 4.5.2 (mingw32)
compiled by GNU C version 4.4.0, GMP version 5.0.1, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.5.2 (mingw32)
compiled by GNU C version 4.4.0, GMP version 5.0.1, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2ec00196c1446cde6554d87cd326f0cd
XmlResultReader.ii: In function 'std::_Resetiosflags
std::resetiosflags(std::ios_base::fmtflags)':
XmlResultReader.ii:70520:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setiosflags
std::setiosflags(std::ios_base::fmtflags)':
XmlResultReader.ii:70542:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setbase std::setbase(int)':
XmlResultReader.ii:70564:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setfill<_CharT> std::setfill(_CharT)':
XmlResultReader.ii:70594:7: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setprecision std::setprecision(int)':
XmlResultReader.ii:70616:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setw std::setw(int)':
XmlResultReader.ii:70638:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x

Program received signal SIGSEGV, Segmentation fault.
0x006266d5 in ggc_set_mark (p=0x1d9fae40) at
../../gcc-4.5.2/gcc/ggc-page.c:1330
1330{
(gdb) #0  0x006266d5 in ggc_set_mark (p=0x1d9fae40) at
../../gcc-4.5.2/gcc/ggc-page.c:1330
#1  0x00495798 in gt_ggc_mx_lang_tree_node (x_p=0x1d9fae40) at
./gt-cp-tree.h:146
#2  0x004963d8 in gt_ggc_mx_lang_tree_node (x_p=0x1d9fc800) at
./gt-cp-tree.h:440

[[[roughly 10 mega bytes of back-trace left out]]]

#136740 0x004961d0 in gt_ggc_mx_lang_tree_node (x_p=0x37f2ba0) at
./gt-cp-tree.h:397
#136741 0x00496668 in gt_ggc_mx_lang_tree_node (x_p=0x3872600) at
./gt-cp-tree.h:373
#136742 0x005e9102 in gt_ggc_mx_cgraph_node (x_p=0x1a129170) at
gtype-desc.c:393
#136743 0x005e929f in gt_ggc_m_P11cgraph_node4htab (x_p=0x56032c0) at
gtype-desc.c:2396
#136744 0x00654f05 in ggc_mark_roots () at ../../gcc-4.5.2/gcc/ggc-common.c:167
#136745 0x00626ed6 in ggc_collect () at ../../gcc-4.5.2/gcc/ggc-page.c:1962
#136746 0x005d34ad in execute_todo (flags=3) at
../../gcc-4.5.2/gcc/passes.c:1309
#136747 0x005d3aba in execute_one_pass (pass=0xb68fa0) at
../../gcc-4.5.2/gcc/passes.c:1591
#136748 0x005d3ca1 in execute_pass_list (pass=0xb68fa0) at
../../gcc-4.5.2/gcc/passes.c:1623
#136749 0x007503ba in tree_rest_of_compilation (fndecl=0x1f9c7f00) at
../../gcc-4.5.2/gcc/tree-optimize.c:413
#136750 0x005d5dd0 in cgraph_expand_function (node=) at
../../gcc-4.5.2/gcc/cgraphunit.c:1574
#136751 0x005d8b3b in cgraph_output_in_order () at
../../gcc-4.5.2/gcc/cgraphunit.c:1747
#136752 cgraph_optimize () at ../../gcc-4.5.2/gcc/cgraphunit.c:1904
#136753 0x005d8d07 in cgraph_finalize_compilation_unit () at
../../gcc-4.5.2/gcc/cgraphunit.c:1122
#136754 0x0044f4a5 in cp_write_global_declarations () at
../../gcc-4.5.2/gcc/cp/decl2.c:3833
#136755 0x006050dd in compile_file (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/toplev.c:1065
#136756 do_compile (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/toplev.c:2417
#136757 toplev_main (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/toplev.c:2459
#136758 0x004e612c in main (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/main.c:35

[Bug tree-optimization/43567] linear loop transform

[spop at gcc dot gnu.org]

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

--- Comment #6 from Sebastian Pop  2011-01-18 20:54:23 
UTC ---
Author: spop
Date: Tue Jan 18 20:54:18 2011
New Revision: 168962

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168962
Log:
Add testcase for PR43567.

2011-01-18  Sebastian Pop  

PR tree-optimization/43567
* gcc.dg/graphite/pr43567.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr43567.c
Modified:
branches/graphite/gcc/ChangeLog.graphite

[Bug tree-optimization/29832] -ftree-loop-linear miscompiles scalarize.f90

[spop at gcc dot gnu.org]

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

--- Comment #8 from Sebastian Pop  2011-01-18 20:54:30 
UTC ---
Author: spop
Date: Tue Jan 18 20:54:26 2011
New Revision: 168963

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168963
Log:
Add testcase for PR29832.

2011-01-18  Sebastian Pop  

PR tree-optimization/29832
* gfortran.dg/graphite/pr29832.f90: New.

Added:
branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr29832.f90
Modified:
branches/graphite/gcc/ChangeLog.graphite

[Bug tree-optimization/43657] [4.3/4.4/4.5/4.6 Regression] -ftree-loop-linear causes FAIL: gcc.dg/vect/vect-cond-5.c execution test

[spop at gcc dot gnu.org]

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

--- Comment #7 from Sebastian Pop  2011-01-18 20:54:38 
UTC ---
Author: spop
Date: Tue Jan 18 20:54:34 2011
New Revision: 168964

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168964
Log:
Add testcase for PR43657.

2011-01-18  Sebastian Pop  

PR tree-optimization/43657
* gcc.dg/graphite/pr43657.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr43657.c
Modified:
branches/graphite/gcc/ChangeLog.graphite

[Bug tree-optimization/46168] [4.3/4.4/4.5/4.6 Regression] ICE: verify_ssa failed: definition in block 6 does not dominate use in block 5 with -ftree-loop-linear

[spop at gcc dot gnu.org]

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

--- Comment #3 from Sebastian Pop  2011-01-18 20:54:43 
UTC ---
Author: spop
Date: Tue Jan 18 20:54:40 2011
New Revision: 168965

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168965
Log:
Add testcase for PR46168.

2011-01-18  Sebastian Pop  

PR tree-optimization/46168
* gcc.dg/graphite/pr46168.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr46168.c
Modified:
branches/graphite/gcc/ChangeLog.graphite

[Bug tree-optimization/46215] ICE: verify_stmts failed: type mismatch in comparison expression with -fstrict-overflow -fno-tree-ch -ftree-loop-linear

[spop at gcc dot gnu.org]

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

--- Comment #1 from Sebastian Pop  2011-01-18 20:54:50 
UTC ---
Author: spop
Date: Tue Jan 18 20:54:46 2011
New Revision: 168966

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168966
Log:
Add testcase for PR46215.

2011-01-18  Sebastian Pop  

PR tree-optimization/46215
* gcc.dg/graphite/pr46215.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr46215.c
Modified:
branches/graphite/gcc/ChangeLog.graphite

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

[spop at gcc dot gnu.org]

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

--- Comment #6 from Sebastian Pop  2011-01-18 20:54:55 
UTC ---
Author: spop
Date: Tue Jan 18 20:54:52 2011
New Revision: 168967

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168967
Log:
Add testcase for PR46970.

2011-01-18  Sebastian Pop  

PR tree-optimization/46970
* gcc.dg/graphite/pr46970.c: New.

Added:
branches/graphite/gcc/testsuite/gcc.dg/graphite/pr46970.c
Modified:
branches/graphite/gcc/ChangeLog.graphite

[Bug tree-optimization/43657] [4.3/4.4/4.5/4.6 Regression] -ftree-loop-linear causes FAIL: gcc.dg/vect/vect-cond-5.c execution test

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 AssignedTo|aoliva at gcc dot gnu.org   |spop at gcc dot gnu.org

--- Comment #8 from Sebastian Pop  2011-01-18 20:55:48 
UTC ---
Fixed on the graphite branch.