[Bug middle-end/40026] [4.5 Regression] ICE during gimplify_init_constructor

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-05-11 07:02 ---
I have a patch.  It's just that TREE_OPERAND (*expr, 1) must be changed to
new_ctor.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-09 18:09:03 |2009-05-11 07:02:26
   date||


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

[Bug fortran/40089] Public type with public component which has a private type

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-05-11 08:07 ---
Without heavily thinking about it:

> print *,public_var_with_private_type%i

Seems to be valid in Fortran 2003 (but not in 2003). The components are not
PRIVATE and thus accessibly, even if the TYPE declaration is not accessible. (I
think one only needs the TYPE to declare new variables of this type not to
access components of existing entities of that type.)

> j = x%ppc()

Seems to be valid: The PPC has an explicit interface and thus there is no need
for implicit typing.

Thus I would reason that g95, ifort and NAG (assuming Juergen Reuter is using
it) are correct in accepting it. -- I can try to find it in the standard, but
it is not a simple constraint which one can find but it is rather written
between the lines.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug fortran/40089] Public type with public component which has a private type

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-05-11 08:23 ---

> Thus I would reason that g95, ifort and NAG (assuming Juergen Reuter is using
> it) are correct in accepting it.

NAG indeed accepts it with -f2003. With -f95 it reports

Extension: c0.f90, line 32: Dummy ARG of PUBLIC_SUB exposes PRIVATE type
PRIVATE_T detected at M@
Extension: c0.f90, line 32: Variable PUBLIC_VAR_WITH_PRIVATE_TYPE exposes
PRIVATE type PRIVATE_T detected at M@
Extension: c0.f90, line 32: Component PUBLIC_COMP_WITH_PRIVATE_TYPE of type
PUBLIC_T exposes PRIVATE type PRIVATE_T detected at M@

Probably it is really valid in F2003, and my common sense just failed. I will
try to fix gfortran's bogus error.


-- 


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

[Bug middle-end/40026] [4.5 Regression] ICE during gimplify_init_constructor

[bonzini at gnu dot org]

--- Comment #6 from bonzini at gnu dot org  2009-05-11 09:04 ---
Created an attachment (id=17850)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17850&action=view)
patch to fix the bug


-- 


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

[Bug fortran/39791] [4.3 Regression] Bad Dwarf debug information from gfortran for a character string.

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-05-11 09:17 ---
The patch caused a regression, see PR 40061


-- 


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

[Bug c++/40100] New: verify_flow_info failed with -O2

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package djvulibre-3.5.21-1.85
with the GNU g++ version 4.5 snapshot 20090507.

The compiler said

DjVuDocEditor.cpp:596: error: EH edge 283->1258 is missing
DjVuDocEditor.cpp:596: error: unnecessary EH edge 283->982
DjVuDocEditor.cpp:596: error: EH edge 285->1258 is missing
DjVuDocEditor.cpp:596: error: unnecessary EH edge 285->986
DjVuDocEditor.cpp:596: error: EH edge 287->1258 is missing
DjVuDocEditor.cpp:596: error: unnecessary EH edge 287->991
DjVuDocEditor.cpp:596: error: EH edge 289->1258 is missing
DjVuDocEditor.cpp:596: error: unnecessary EH edge 289->997
...
DjVuDocEditor.cpp:596: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Preprocessed source code attached. Flag -O2 required.


-- 
   Summary: verify_flow_info failed with -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/40100] verify_flow_info failed with -O2

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-05-11 09:23 ---
Created an attachment (id=17851)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17851&action=view)
C++ source code


-- 


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

[Bug fortran/40089] Public type with public component which has a private type

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-05-11 09:55 ---
Actually gfortran even has the same check as NAG that rejects a private type as
component of a public type with -std=f95. And it happens that the bug which
leads to the bogus error message lies just in this check. Thus the fix is easy:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 147349)
+++ gcc/fortran/resolve.c   (working copy)
@@ -9088,11 +9088,11 @@ resolve_fl_derived (gfc_symbol *sym)
  && !gfc_check_access (c->ts.derived->attr.access,
c->ts.derived->ns->default_access))
{
- gfc_notify_std (GFC_STD_F2003, "Fortran 2003: the component '%s' "
+ if (gfc_notify_std (GFC_STD_F2003, "Fortran 2003: the component '%s'
"
  "is a PRIVATE type and cannot be a component of "
  "'%s', which is PUBLIC at %L", c->name,
- sym->name, &sym->declared_at);
- return FAILURE;
+ sym->name, &sym->declared_at) == FAILURE)
+   return FAILURE;
}

   if (sym->attr.sequence)


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-11 09:55:35
   date||


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

[Bug middle-end/40100] [4.5 Regression] verify_flow_info failed with -O2

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
  Component|c++ |middle-end
Summary|verify_flow_info failed with|[4.5 Regression]
   |-O2 |verify_flow_info failed with
   ||-O2
   Target Milestone|--- |4.5.0


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2009-05-11 10:15 ---
I meant my fwprop patch. :-)


-- 


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

[Bug fortran/40089] Public type with public component which has a private type

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-05-11 10:20 ---
>   && !gfc_check_access (c->ts.derived->attr.access,
> c->ts.derived->ns->default_access))
> {
> - gfc_notify_std (GFC_STD_F2003, "Fortran 2003: the component '%s' "
> + if (gfc_notify_std (GFC_STD_F2003, "Fortran 2003: the component '%s'
> "

Or shorter:

 if (
 && !gfc_check_access
 && gfc_notify_std (...) == FAILURE)
   return FAILURE;

saves a { } pair and some indentation


-- 


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2009-05-11 11:15 
---
I can reproduce this on x86_64-unknown-linux-gnu at -O2 with 4.3.2 and
4.5-20090402 snapshot, and at -O3 with 4.2.2

I can't reproduce it with 4.1.2


-- 

jwakely dot gcc at gmail dot com changed:

   What|Removed |Added

 CC||jwakely dot gcc at gmail dot
   ||com


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[jwakely dot gcc at gmail dot com]

--- Comment #6 from jwakely dot gcc at gmail dot com  2009-05-11 11:23 
---
I was using Boost 1.37.0 with:

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20090402/configure
--prefix=/dev/shm/wakelyjo/insroot/4.5-20090402 --enable-languages=c,c++
--disable-bootstrap --disable-checking --with-gmp=/dev/shm/wakelyjo/stage
--with-mpfr=/dev/shm/wakelyjo/stage
Thread model: posix
gcc version 4.5.0 20090402 (experimental) (GCC)

and

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.2/configure --prefix=/opt/gcc/32-bit/4.3.2
--enable-languages=c,c++,fortran,objc,obj-c++ --with-gnu-as
--with-as=/opt/binutils/32-bit/2.18/bin/as --with-gnu-ld
--with-ld=/opt/binutils/32-bit/2.18/bin/ld --with-gmp=/var/tmp/stage
--with-mpfr=/var/tmp/stage --build=i686-pc-linux-gnu --with-arch=pentium4
--enable-shared --enable-threads=posix --enable-nls --enable-libstdcxx-debug
--enable-__cxa_atexit
Thread model: posix
gcc version 4.3.2 (GCC)


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[irar at gcc dot gnu dot org]

--- Comment #16 from irar at gcc dot gnu dot org  2009-05-11 11:54 ---
Subject: Bug 40074

Author: irar
Date: Mon May 11 11:54:02 2009
New Revision: 147370

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147370
Log:
PR tree-optimization/40074
* tree-vect-analyze.c (vect_analyze_group_access): Take gaps into
account in group size and step comparison.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr40074.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-vect-analyze.c


-- 


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-11 12:03 ---
Created an attachment (id=17852)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17852&action=view)
unincluded testcase


-- 


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-05-11 12:04 ---
4.1 and 4.2 cannot compile the testcase.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.3
   Last reconfirmed|-00-00 00:00:00 |2009-05-11 12:04:41
   date||


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

[Bug tree-optimization/40081] verify_stmts failed with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-05-11 12:23 ---
Ok, I simply consider this fixed for 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/40081] verify_stmts failed with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-05-11 12:23 
---
Did I say fixed?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-05-11 12:28 ---
It's a latent bug somewhere, possibly in delayed branch scheduling?  fwprop1
does a single copy propagation which is trivially valid.

Analyzing -O1 -fno-delayed-branch vs. -O1 -fno-delayed-branch
-fno-forward-propagate, I'm pretty sure that every change remains valid up to
the dbr pass.  In particular, as i said, the effect of fwprop is trivial:

 L154:
   155 NOTE_INSN_BASIC_BLOCK
   156 r94:SI=r97:SI+0x1
-  157 r92:SI=r94:SI
   158 r126:SI=r8:SI-0xa
   159 cc0=[r126:SI+r97:SI]
   160 pc={(cc0==0x0)?L165:pc}
@@ -913,7 +906,7 @@
   161 NOTE_INSN_BASIC_BLOCK
   162 r127:SI=r8:SI-0x41
   163 r128:SI=r97:SI<<0x2
-  164 [r127:SI+r128:SI]=r92:SI
+  164 [r127:SI+r128:SI]=r94:SI
 L165:
   166 NOTE_INSN_BASIC_BLOCK
   168 cc0=cmp(r94:SI,0xa)

Also after register allocation there is no major difference, except that
without fwprop r92 is allocated to the (special?) register $srp, giving:

 L154:
   155 NOTE_INSN_BASIC_BLOCK
-  265 r9:SI=r13:SI
-  156 r9:SI=r9:SI+0x1
-  157 srp:SI=r9:SI
+  265 r13:SI=r9:SI
+  156 r13:SI=r13:SI+0x1
   266 r12:SI=r8:SI
   158 r12:SI=r12:SI-0xa
   REG_EQUIV: r8:SI-0xa
-  159 cc0=[r12:SI+r13:SI]
+  159 cc0=[r12:SI+r9:SI]
   160 pc={(cc0==0x0)?L165:pc}
   REG_BR_PROB: 0x1388
   161 NOTE_INSN_BASIC_BLOCK
@@ -1025,14 +1009,14 @@
   267 r12:SI=r8:SI
   243 r12:SI=r12:SI-0x41
   REG_EQUIV: r8:SI-0x41
-  164 [r13:SI*0x4+r12:SI]=srp:SI
+  164 [r9:SI*0x4+r12:SI]=r13:SI
 L165:
   166 NOTE_INSN_BASIC_BLOCK
-  168 cc0=cmp(r9:SI,0xa)
+  168 cc0=cmp(r13:SI,0xa)
   169 pc={(cc0==0x0)?L167:pc}
   REG_BR_PROB: 0x38d
   172 NOTE_INSN_BASIC_BLOCK
-   55 r13:SI=r9:SI
+   55 r9:SI=r13:SI
   237 pc=L154


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[irar at gcc dot gnu dot org]

--- Comment #17 from irar at gcc dot gnu dot org  2009-05-11 12:33 ---
Subject: Bug 40074

Author: irar
Date: Mon May 11 12:33:13 2009
New Revision: 147372

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147372
Log:
PR tree-optimization/40074
* tree-vect-data-refs.c (vect_analyze_group_access): Take gaps into
account in group size and step comparison.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr40074.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c


-- 


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[jwakely dot gcc at gmail dot com]

--- Comment #9 from jwakely dot gcc at gmail dot com  2009-05-11 12:42 
---
The testcase will have included lots of code from Boost headers conditionally
based on __GNUC__ etc. so it's not surprising it doesn't compile with 4.1 or
4.2

If wanted I can produce an unincluded version using 4.1 and 4.2, but I assume
there's no point as those branches are closed.


-- 


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2009-05-11 12:44 ---
Subject: Re:  bad optimization(?) pure virtual function
 call with -O2

On Mon, 11 May 2009, jwakely dot gcc at gmail dot com wrote:

> --- Comment #9 from jwakely dot gcc at gmail dot com  2009-05-11 12:42 
> ---
> The testcase will have included lots of code from Boost headers conditionally
> based on __GNUC__ etc. so it's not surprising it doesn't compile with 4.1 or
> 4.2
> 
> If wanted I can produce an unincluded version using 4.1 and 4.2, but I assume
> there's no point as those branches are closed.

Right.  I was trying to check if this is a regression or not.

Richard.


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[irar at il dot ibm dot com]

--- Comment #18 from irar at il dot ibm dot com  2009-05-11 12:45 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[jwakely dot gcc at gmail dot com]

--- Comment #11 from jwakely dot gcc at gmail dot com  2009-05-11 13:09 
---
It does seem to be a regression.  I preprocessed the program in comment 4 with
GCC version 4.1.2 20071124 (Red Hat 4.1.2-42), then ran uninclude to produce a
standalone testcase and compiled it with different versions of GCC

GCC 4.1.1 (FSF) at -O3 doesn't call the pure virtual.
GCC 4.1.2 (Red Hat) at -O3 doesn't call the pure virtual.
GCC 4.2.2 (FSF) at -O3 calls the pure virtual.
GCC 4.3.2 (FSF) can't compile the program (again, due to Boost's heavy use of
preprocessor checks)

Do you want that unincluded testcase attached?


-- 


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

[Bug middle-end/39509] bad optimization(?) pure virtual function call with -O2

[rguenther at suse dot de]

--- Comment #12 from rguenther at suse dot de  2009-05-11 13:10 ---
Subject: Re:  bad optimization(?) pure virtual function
 call with -O2

On Mon, 11 May 2009, jwakely dot gcc at gmail dot com wrote:

> --- Comment #11 from jwakely dot gcc at gmail dot com  2009-05-11 13:09 
> ---
> It does seem to be a regression.  I preprocessed the program in comment 4 with
> GCC version 4.1.2 20071124 (Red Hat 4.1.2-42), then ran uninclude to produce a
> standalone testcase and compiled it with different versions of GCC
> 
> GCC 4.1.1 (FSF) at -O3 doesn't call the pure virtual.
> GCC 4.1.2 (Red Hat) at -O3 doesn't call the pure virtual.
> GCC 4.2.2 (FSF) at -O3 calls the pure virtual.
> GCC 4.3.2 (FSF) can't compile the program (again, due to Boost's heavy use of
> preprocessor checks)
> 
> Do you want that unincluded testcase attached?

No, that's enough info.

Richard.


-- 


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

[Bug middle-end/39509] [4.3/4.4/4.5 Regression] bad optimization(?) pure virtual function call with -O2

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.3   |4.2.4 4.3.3 4.4.0
  Known to work||4.1.1
Summary|bad optimization(?) pure|[4.3/4.4/4.5 Regression] bad
   |virtual function call with -|optimization(?) pure virtual
   |O2  |function call with -O2
   Target Milestone|--- |4.3.4


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

[Bug rtl-optimization/40101] New: [4.5 Regression] 200.sixtrack ICEs in get_seqno_by_preds, at sel-sched-ir.c:3752

[rguenth at gcc dot gnu dot org]

/gcc/spec/sb-terbium-head-64/ia64/install-200905081754/bin/gfortran -c -o
daten.o  -O3  daten.f
daten.f: In function 'daten':
daten.f:1850: internal compiler error: in get_seqno_by_preds, at
sel-sched-ir.c:3752
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

rev 147259 is good, rev 147290 is bad.


-- 
   Summary: [4.5 Regression] 200.sixtrack ICEs in
get_seqno_by_preds, at sel-sched-ir.c:3752
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: ia64-*-*


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

[Bug rtl-optimization/40101] [4.5 Regression] 200.sixtrack ICEs in get_seqno_by_preds, at sel-sched-ir.c:3752

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug fortran/40089] Public type with public component which has a private type

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-05-11 14:14 ---
Subject: Bug 40089

Author: janus
Date: Mon May 11 14:14:38 2009
New Revision: 147379

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147379
Log:
2009-05-11  Janus Weil  

PR fortran/40089
* resolve.c (resolve_fl_derived): Only return FAILURE if
gfc_notify_std fails.


2009-05-11  Janus Weil  

PR fortran/40089
* gfortran.dg/proc_ptr_comp_7.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40089] Public type with public component which has a private type

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-05-11 14:19 ---
Fixed with r147379. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40102] New: [4.5 Regression] ICE: verify_cgraph_node

[reichelt at gcc dot gnu dot org]

The following testcase triggers an ICE on trunk when compiled with "-O2":


bool foo0(int) { return true; }

bool foo1();

void foo2(bool);

template inline void bar1(T f)
{
  if (f(0))
foo1();
}

template void bar2(T f)
{
  while (foo1())
  {
foo2(foo1());
if (foo1())
  bar1(f);
  }

  if (foo1())
bar1(f);
}

void baz()
{
  bar2(foo0);
}


bug.cc:29: error: missing callgraph edge for call stmt:
retval.3_1 = foo0 (0);

void bar1(T) [with T = bool (*)(int)]/10(-1) [0x2a95725000]: (inline copy in
void bar2(T) [with T = bool (*)(int)]/2) (clone of void bar1(T) [with T = bool
(*)(int)]/6) availability:local 27 insns body local finalized inlinable
  called by: void bar2(T) [with T = bool (*)(int)]/2 (0.39 per call) (inlined)
(can throw external)
  calls: bool foo1()/4 (0.15 per call) (can throw external)
bug.cc:29: internal compiler error: verify_cgraph_node failed
Please submit a full bug report, [etc.]

This might be caused by the patch for PR40080.


-- 
   Summary: [4.5 Regression] ICE: verify_cgraph_node
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/40102] [4.5 Regression] ICE: verify_cgraph_node

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/40026] [4.5 Regression] ICE during gimplify_init_constructor

[bonzini at gcc dot gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2009-05-11 16:06 ---
Subject: Bug 40026

Author: bonzini
Date: Mon May 11 16:05:45 2009
New Revision: 147386

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147386
Log:
2009-05-11  Paolo Bonzini  

PR tree-optimization/40026
* gimplify.c (gimplify_init_constructor): Change initial conditional
to assertion.  Rewrite TREE_OPERAND (*expr_p, 1) after
optimize_compound_literals_in_ctor.

testsuite:
2009-05-11  Paolo Bonzini  

* gcc.c-torture/compile/pr40026.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr40026.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40075] deprecated("xxx") doesn't work on function parameter

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-05-11 16:27 ---
This patch:

--- cp/decl.c.foo   2009-05-08 13:54:31.0 -0700
+++ cp/decl.c   2009-05-11 09:26:21.0 -0700
@@ -8065,6 +8065,9 @@ grokdeclarator (const cp_declarator *dec
   type = cp_build_qualified_type_real
 (type, type_quals, ((typedef_decl && !DECL_ARTIFICIAL (typedef_decl)
 ? tf_ignore_bad_quals : 0) | tf_warning_or_error));
+  /* FIXME: We need TYPE_STUB_DECL to get attributes on TYPE.  */
+  if (TYPE_STUB_DECL (type) == NULL_TREE)
+TYPE_STUB_DECL (type) = typedef_decl;
   /* We might have ignored or rejected some of the qualifiers.  */
   type_quals = cp_type_quals (type);

seems to work.


-- 


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

[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-05-11 16:37 ---
Subject: Bug 40080

Author: hjl
Date: Mon May 11 16:37:07 2009
New Revision: 147389

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147389
Log:
2009-05-11  H.J. Lu  

PR middle-end/40080
* gcc.c-torture/compile/pr40080.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr40080.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40083] [4.5 Regression] Revision 147294 failed 403.gcc in SPEC CPU 2006 at -O3

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-05-11 16:39 ---
Fixed by revision 147320:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00294.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  BugsThisDependsOn||40080
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-05-11 16:40 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40043] [4.5 Regression] ICE with nested try/catch

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2009-05-11 16:49 ---
Subject: Bug 40043

Author: hjl
Date: Mon May 11 16:49:17 2009
New Revision: 147390

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147390
Log:
2009-05-11  H.J. Lu  

Backport from mainline:
2009-05-11  H.J. Lu  

PR middle-end/40080
* gcc.c-torture/compile/pr40080.c: New.

2009-05-11  Paolo Bonzini  

* gcc.c-torture/compile/pr40026.c: New testcase.

2009-05-09  Jan Hubicka  

PR middle-end/40043
* g++.dg/eh/nested-try.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/eh/nested-try.C
  - copied unchanged from r147389,
trunk/gcc/testsuite/g++.dg/eh/nested-try.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40026.c
  - copied unchanged from r147389,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40026.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40080.c
  - copied unchanged from r147389,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40080.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2009-05-11 16:49 ---
Subject: Bug 40080

Author: hjl
Date: Mon May 11 16:49:17 2009
New Revision: 147390

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147390
Log:
2009-05-11  H.J. Lu  

Backport from mainline:
2009-05-11  H.J. Lu  

PR middle-end/40080
* gcc.c-torture/compile/pr40080.c: New.

2009-05-11  Paolo Bonzini  

* gcc.c-torture/compile/pr40026.c: New testcase.

2009-05-09  Jan Hubicka  

PR middle-end/40043
* g++.dg/eh/nested-try.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/eh/nested-try.C
  - copied unchanged from r147389,
trunk/gcc/testsuite/g++.dg/eh/nested-try.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40026.c
  - copied unchanged from r147389,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40026.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40080.c
  - copied unchanged from r147389,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40080.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40102] [4.5 Regression] Revision 147294 caused ICE: verify_cgraph_node

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-05-11 16:56 ---
It is caused by revision 147294:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.5 Regression] ICE:   |[4.5 Regression] Revision
   |verify_cgraph_node  |147294 caused ICE:
   ||verify_cgraph_node


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

[Bug bootstrap/40103] New: [4.5 Regression] error: enum constant defined in struct or union is not visible in C++

[dominiq at lps dot ens dot fr]

Bootstrap is broken again at revision 147380 (147349 worked):

...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -c  -g -O2 -fomit-frame-pointer
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5-work/gcc
-I../../gcc-4.5-work/gcc/. -I../../gcc-4.5-work/gcc/../include -I./../intl
-I../../gcc-4.5-work/gcc/../libcpp/include -I/sw/include 
-I../../gcc-4.5-work/gcc/../libdecnumber
-I../../gcc-4.5-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include 
-I/sw/include -DCLOOG_PPL_BACKEND   ../../gcc-4.5-work/gcc/graphite.c -o
graphite.o
cc1: warnings being treated as errors
../../gcc-4.5-work/gcc/graphite.c: In function
'loop_iv_stack_patch_for_consts':
../../gcc-4.5-work/gcc/graphite.c:500: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c: In function 'clast_to_gcc_expression':
../../gcc-4.5-work/gcc/graphite.c:3844: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3874: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3895: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c: In function 'gcc_type_for_clast_expr':
../../gcc-4.5-work/gcc/graphite.c:3937: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3947: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3966: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c: In function 'find_cloog_iv_in_expr':
../../gcc-4.5-work/gcc/graphite.c:5327: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:5331: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:5334: error: enum constant defined in struct
or union is not visible in C++
/sw/include/cloog/clast.h:9: note: enum constant defined here


-- 
   Summary: [4.5 Regression] error: enum constant defined in struct
or union is not visible in C++
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr


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

[Bug c/40104] New: ARG_MAX erroneously used in upc-4.2.3.6/gcc/upc/upc-cmd.c

[nmm1 at cam dot ac dot uk]

upc-4.2.3.6/gcc/upc/upc-cmd.c contains the line:

char *all_exec_args[ARG_MAX];

That is erroneous, because ARG_MAX is not set on a system where it is variable
and exceeds the maximum, as under SUSE 11.1.  But the failure is generic to all
POSIX systems.


-- 
   Summary: ARG_MAX erroneously used in upc-4.2.3.6/gcc/upc/upc-
cmd.c
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nmm1 at cam dot ac dot uk
 GCC build triplet: All
  GCC host triplet: All
GCC target triplet: All


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

[Bug other/40104] ARG_MAX erroneously used in upc-4.2.3.6/gcc/upc/upc-cmd.c

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-11 17:12 ---
UPC is not part of the FSF GCC at all, report this issue to the UPC folks.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |other
 Resolution||INVALID


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

[Bug bootstrap/40103] [4.5 Regression] error: enum constant defined in struct or union is not visible in C++

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ian at gcc dot gnu dot org
   Severity|normal  |blocker
   Keywords||build
   Target Milestone|--- |4.5.0


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

[Bug middle-end/40100] [4.5 Regression] verify_flow_info failed with -O2

[hubicka at gcc dot gnu dot org]

--- Comment #2 from hubicka at gcc dot gnu dot org  2009-05-11 17:16 ---
It compiles for me at -O2 and x86_64-linux.  I fixed bug with similar symptoms
last week, does it still reproduce?

Honza


-- 


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

[Bug other/40104] ARG_MAX erroneously used in upc-4.2.3.6/gcc/upc/upc-cmd.c

[nmm1 at cam dot ac dot uk]

--- Comment #2 from nmm1 at cam dot ac dot uk  2009-05-11 17:17 ---
I have now found a SECOND set of instructions on how to report a bug in gcc
upc.
I will copy this to http://www.intrepid.com/upc/bugs.html.  Please just cancel
this report if this is the wrong place.


-- 


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

[Bug middle-end/40100] [4.5 Regression] verify_flow_info failed with -O2

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-05-11 17:22 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/40043] [4.5 Regression] ICE with nested try/catch

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-05-11 17:22 ---
*** Bug 40100 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com


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

[Bug middle-end/40043] [4.5 Regression] ICE with nested try/catch

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-05-11 17:23 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/40105] New: [4.3/4.4 Regression] SH: segfault when recompiling itself

[armin76 at gentoo dot org]

Since gcc-4.3 I'm unable to rebuild gcc, please check the downstream bug:
http://bugs.gentoo.org/show_bug.cgi?id=267247

As pointed out there, it compiles with gcc-4.1.2, but after upgrading to
gcc-4.3, switching to that compiler, and recompiling itself, it segfaults.

sh4-unknown-linux-gnu-gcc   -O -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros   
  -Wno-overlength-strings -fno-common   -DHAVE_CONFIG_H
-Wl,-O1 -o xgcc gcc.o opts-common.o gcc-options.o gccspec.o \
  intl.o prefix.o version.o  ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/
-B/usr/sh4-unknown-linux-gnu/bin/ -B/usr/sh4-unknown-linux-gnu/lib/ -isystem
/usr/sh4-unknown-linux-gnu/include -isystem
/usr/sh4-unknown-linux-gnu/sys-include -dumpspecs > tmp-specs
/bin/sh: line 1:  9859 Segmentation fault 
/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/
-B/usr/sh4-unknown-linux-gnu/bin/ -B/usr/sh4-unknown-linux-gnu/lib/ -isystem
/usr/sh4-unknown-linux-gnu/include -isystem
/usr/sh4-unknown-linux-gnu/sys-include -dumpspecs > tmp-specs
make[3]: *** [specs] Error 139
make[3]: Leaving directory

Let me know if you need more info


-- 
   Summary: [4.3/4.4 Regression] SH: segfault when recompiling
itself
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: armin76 at gentoo dot org
 GCC build triplet: sh4-unknown-linux-gnu
  GCC host triplet: sh4-unknown-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu


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

[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)

[luisgpm at linux dot vnet dot ibm dot com]

--- Comment #1 from luisgpm at linux dot vnet dot ibm dot com  2009-05-11 
18:04 ---
Good asm code for a hot loop in swim's "calc1" function

10001e10:   lfd f12,-10672(r11)
10001e14:   lfd f9,-10672(r9)
10001e18:   addir21,r21,16
10001e1c:   lfd f7,-10680(r11)
10001e20:   lfd f6,-10672(r6)
10001e24:   fmulf3,f9,f9
10001e28:   cmpwr21,r0
10001e2c:   faddf4,f7,f12
10001e30:   lfd f22,-10680(r9)
10001e34:   lfd f10,-10664(r9)
10001e38:   addir9,r9,16
10001e3c:   lfd f23,-10672(r5)
10001e40:   lfd f13,-10664(r5)
10001e44:   addir5,r5,16
10001e48:   lfd f5,-10664(r11)
10001e4c:   fsubf28,f23,f9
10001e50:   fsubf25,f13,f10
10001e54:   lfd f13,-10672(r4)
10001e58:   addir11,r11,16
10001e5c:   faddf5,f12,f5
10001e60:   fsubf20,f13,f0
10001e64:   fmulf9,f11,f9
10001e68:   fmadd   f27,f22,f22,f3
10001e6c:   fmadd   f30,f10,f10,f3
10001e70:   lfd f3,-10680(r8)
10001e74:   faddf26,f4,f6
10001e78:   fmulf10,f11,f10
10001e7c:   fmulf24,f28,f2
10001e80:   fmulf21,f25,f2
10001e84:   fmulf4,f9,f4
10001e88:   fmadd   f22,f0,f0,f27
10001e8c:   faddf27,f8,f7
10001e90:   faddf23,f26,f8
10001e94:   fmulf26,f0,f11
10001e98:   lfd f8,-10664(r6)
10001e9c:   lfd f0,-10664(r4)
10001ea0:   addir6,r6,16
10001ea4:   faddf29,f5,f8
10001ea8:   fsubf25,f0,f13
10001eac:   addir4,r4,16
10001eb0:   fmsub   f28,f20,f1,f24
10001eb4:   lfd f20,-10672(r8)
10001eb8:   fmulf5,f10,f5
10001ebc:   addir8,r8,16
10001ec0:   stfdf4,-10672(r22)
10001ec4:   stfdf5,-10664(r22)
10001ec8:   addir22,r22,16
10001ecc:   fmulf27,f26,f27
10001ed0:   faddf24,f6,f29
10001ed4:   fmsub   f29,f25,f1,f21
10001ed8:   fdivf28,f28,f23
10001edc:   fmadd   f25,f13,f13,f30
10001ee0:   faddf6,f6,f12
10001ee4:   fmadd   f30,f3,f3,f22
10001ee8:   stfdf27,-10680(r3)
10001eec:   fdivf29,f29,f24
10001ef0:   fmadd   f3,f20,f20,f25
10001ef4:   fmulf20,f13,f11
10001ef8:   fmadd   f7,f30,f31,f7
10001efc:   stfdf7,-10680(r10)
10001f00:   fmadd   f12,f3,f31,f12
10001f04:   fmulf13,f20,f6
10001f08:   stfdf12,-10672(r10)
10001f0c:   stfdf13,-10672(r3)
10001f10:   addir10,r10,16
10001f14:   addir3,r3,16
10001f18:   stfdf28,-10672(r7)
10001f1c:   stfdf29,-10664(r7)
10001f20:   addir7,r7,16
10001f24:   bne 10001e10 

--
Bad asm code for the same loop

10001a60:   addis   r27,r9,-435
10001a64:   addis   r12,r11,-2176
10001a68:   lfd f13,-7440(r27)
10001a6c:   lfd f10,28344(r12)
10001a70:   addis   r8,r11,-1958
10001a74:   addis   r10,r11,-1740
10001a78:   fsubf7,f10,f13
10001a7c:   lfd f8,-704(r8)
10001a80:   lfd f10,0(r9)
10001a84:   addis   r7,r9,-218
10001a88:   addis   r28,r9,1523
10001a8c:   lfd f9,-29752(r10)
10001a90:   faddf6,f12,f10
10001a94:   fsubf2,f8,f0
10001a98:   addis   r12,r11,218
10001a9c:   addis   r27,r9,2176
10001aa0:   faddf5,f11,f9
10001aa4:   faddf11,f11,f12
10001aa8:   addir9,r9,8
10001aac:   cmpwr6,r9
10001ab0:   fmulf1,f7,f30
10001ab4:   fmulf7,f13,f13
10001ab8:   fmulf13,f13,f3
10001abc:   faddf31,f5,f6
10001ac0:   lfd f5,29040(r7)
10001ac4:   fmsub   f2,f2,f29,f1
10001ac8:   fmadd   f1,f0,f0,f7
10001acc:   fmulf0,f0,f3
10001ad0:   fmulf6,f13,f6
10001ad4:   stfdf6,-6728(r28)
10001ad8:   fdivf2,f2,f31
10001adc:   fmadd   f5,f5,f5,f1
10001ae0:   fmulf31,f0,f11
10001ae4:   fmr f0,f8
10001ae8:   stfdf31,0(r11)
10001aec:   fmr f11,f9
10001af0:   addir11,r11,8
10001af4:   faddf1,f5,f4
10001af8:   fmr f4,f7
10001afc:   fmadd   f5,f1,f28,f12
10001b00:   fmr f12,f10
10001b04:   stfdf5,-28344(r27)
10001b08:   stfdf2,-29040(r12)
10001b0c:   bne+10001a60 

--

Looking into the differences for both cases, the good code seems to be
traversing the loop in a different way than the bad one, using smaller
displacements for each load/store. The bad case uses bigger displacements.

Also, it looks like we have a bigger unrolling factor on the good case (longer
code, more loads) compared to the bad case.


-- 


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

[Bug middle-end/40106] New: Time increase with inlining for the Polyhedron test air.f90

[dominiq at lps dot ens dot fr]

The run time of air.f90 of the Polyhedron test suite takes ~15% more time when
compiled with -fwhole-file than without the option.  I have checked that the
subroutines DERIV(X|Y) are inlined with -finline-limit=100, but not with
-finline-limit=50 (for the later I recover the timing without -fwhole-file).
What I have found very odd is that if I manually inline only a single call (see
below) I get the same timing that with all of them (2*14) inlined. This is the
case for trunk and gfortran 4.4.0, but not for 4.3.3 which gives a slower
executable.


I have inlined 

  SUBROUTINE DERIVX(D,U,Ux,Al,Np,Nd,M)
  IMPLICIT REAL*8(A-H,O-Z)
  PARAMETER (NX=150,NY=150)
  DIMENSION D(NX,33) , U(NX,NY) , Ux(NX,NY) , Al(30) , Np(30)
  DO jm = 1 , M
 jmax = 0
 jmin = 1
 DO i = 1 , Nd
jmax = jmax + Np(i) + 1
DO j = jmin , jmax
   uxt = 0.
   DO k = 0 , Np(i)
  uxt = uxt + D(j,k+1)*U(jmin+k,jm)
   ENDDO
   Ux(j,jm) = uxt*Al(i)
ENDDO
!
jmin = jmin + Np(i) + 1
 ENDDO
  ENDDO
  CONTINUE
  END

at line 793 as

!   CALL DERIVX(DX,f4,f4x,ALX,NPX,NDX,MXPy)
  DO jm = 1 , MXPy
 jmax = 0
 jmin = 1
 DO i = 1 , NDX
jmax = jmax + NPX(i) + 1
DO j = jmin , jmax
   uxt = 0.
   DO k = 0 , NPX(i)
  uxt = uxt + DX(j,k+1)*f4(jmin+k,jm)
   ENDDO
   f4x(j,jm) = uxt*ALX(i)
ENDDO
jmin = jmin + NPX(i) + 1
 ENDDO
  ENDDO


-- 
   Summary: Time increase with inlining for the Polyhedron test
air.f90
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug rtl-optimization/40107] New: [4.5 Regression] gcc.c-torture/execute/builtins/memmove.c and gcc.c-torture/execute/builtins/memmove-chk.c fail at -O1 on spu-elf

[pinskia at gcc dot gnu dot org]

+FAIL: gcc.c-torture/execute/builtins/memmove-chk.c execution,  -O1 
+FAIL: gcc.c-torture/execute/builtins/memmove.c execution,  -O1 


These testcases used to work in 4.4.0.


-- 
   Summary: [4.5 Regression] gcc.c-
torture/execute/builtins/memmove.c and gcc.c-
torture/execute/builtins/memmove-chk.c fail at -O1 on
spu-elf
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: spu-elf


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

[Bug fortran/39865] ICE in gfc_conv_scalarized_array_ref

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2009-05-11 17:30 ---
Testcase:

subroutine f1 (a)
  character(len=1) :: a(7:)
  character(len=12) :: b
  character(len=1) :: c(2:10)
  write (b, a) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
  write (b, a(:)) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
  write (b, a(8:)) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
  c(2) = ' '
  c(3) = '('
  c(4) = '3'
  c(5) = 'A'
  c(6) = '4'
  c(7) = ')'
  write (b, c) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
  write (b, c(:)) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
  write (b, c(3:)) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
end subroutine f1

subroutine f2 (a)
  character(len=1) :: a(10:,20:)
  character(len=12) :: b
  write (b, a) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
  write (b, a) 'Hell', 'o wo', 'rld!'
  if (b .ne. 'Hello world!') call abort
end subroutine f2

  interface
subroutine f1 (a)
  character(len=1) :: a(:)
end
  end interface
  interface
subroutine f2 (a)
  character(len=1) :: a(:,:)
end
  end interface
  integer :: i, j
  character(len=1) :: e (6, 7:9), f (3,2), g (10)
  e = 'X'
  e(2,8) = ' '
  e(3,8) = '('
  e(4,8) = '3'
  e(2,9) = 'A'
  e(3,9) = '4'
  e(4,9) = ')'
  f = e(2:4,8:9)
  g = 'X'
  g(2) = ' '
  g(3) = '('
  g(4) = '3'
  g(5) = 'A'
  g(6) = '4'
  g(7) = ')'
  call f1 (g(2:7))
  call f2 (f)
  call f2 (e(2:4,8:9))
end


-- 


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

[Bug c/40108] New: gcc.dg/torture/complex-* tests fail on spu-elf

[pinskia at gcc dot gnu dot org]

Most of the gcc.dg/torture/complex-* tests fail on spu-elf.  This is due to
signed zeros are never produced except when doing a negation so the tests most
likely should be disabled for spu-elf.


-- 
   Summary: gcc.dg/torture/complex-* tests fail on spu-elf
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: spu-elf


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

[Bug rtl-optimization/40107] [4.5 Regression] gcc.c-torture/execute/builtins/memmove.c and gcc.c-torture/execute/builtins/memmove-chk.c fail at -O1 on spu-elf

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-11 18:10 ---
I forgot to say this fails with:
LAST_UPDATED: Fri May  8 15:49:15 UTC 2009 (revision 147292)

But passed with:
LAST_UPDATED: Wed Feb 11 17:03:51 UTC 2009 (revision 144107)


-- 


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

[Bug c++/40099] 64bit constants

[Andrey dot Martchovsky at gmail dot com]

--- Comment #3 from Andrey dot Martchovsky at gmail dot com  2009-05-11 
18:22 ---
(In reply to comment #2)
> Why is that a problem? C and C++ are different languages.  Compiling with g++
> means you are compiling the C code as C++ (see documentation).
> 

My problem is that the error for 64bit ints in C++ shows up only under the x86
implementation of g++,
compiling the same code under x86_64 does not result in any errors.

Btw, the documentation for C++ suggests to use either int64_t or long long, for
64bit integers, and with either, I cannot define a constant that is greater
than 2^31-1. Therefore this is a bug, as the compiler DOES recognize the
declared variable to be 64 bit wide, and DOES all the 64bit arithmetic properly
(add,sub,mul,div,mod,shift ...), but DOES NOT recognize the variable to be
64bits in the initial parsing.


-- 

Andrey dot Martchovsky at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug debug/40109] New: Incorrect debug info nesting for typedef statements within namespaces

[dodji at gcc dot gnu dot org]

The following program:

namespace A{

  class B{
  };

  typedef A::B AB;
}

int main(){
  A::AB ab;
  return 0;
}

compiled with gcc generates the following debug info:
 ...
 <1><43>: Abbrev Number: 5 (DW_TAG_subprogram)
<44>   DW_AT_external: 1
<45>   DW_AT_name: (indirect string, offset: 0x4c): main
<49>   DW_AT_decl_file   : 1
<4a>   DW_AT_decl_line   : 10   
<4b>   DW_AT_type: <0x91>   
<4f>   DW_AT_low_pc  : 0x40053c 
<57>   DW_AT_high_pc : 0x400547 
<5f>   DW_AT_frame_base  : 0x0  (location list)
<63>   DW_AT_sibling : <0x91>   
 <2><67>: Abbrev Number: 6 (DW_TAG_lexical_block)
<68>   DW_AT_low_pc  : 0x400540 
<70>   DW_AT_high_pc : 0x400545 
 <3><78>: Abbrev Number: 7 (DW_TAG_typedef)
<79>   DW_AT_name: AB   
<7c>   DW_AT_decl_file   : 1
<7d>   DW_AT_decl_line   : 7
<7e>   DW_AT_type: <0x3b>   
...

The typedef tag <78> is a child of subprogram main instead of
namespace A.


-- 
   Summary:  Incorrect debug info nesting for typedef statements
within namespaces
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dodji at gcc dot gnu dot org


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

[Bug c++/40099] 64bit constants

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-05-11 18:27 ---
For C++98 and C90, integer constants can only fit into the long type. You need
to use LL if you want a 64bit integer constant.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug debug/40109] Incorrect debug info nesting for typedef statements within namespaces

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2009-05-11 18:29 ---
Created an attachment (id=17853)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17853&action=view)
Candidate fix

I have tested this patch. It bootstraps and passes regtest on trunk.

I need to test it on the branches.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug c++/40099] 64bit constants

[Andrey dot Martchovsky at gmail dot com]

--- Comment #5 from Andrey dot Martchovsky at gmail dot com  2009-05-11 
19:04 ---
(In reply to comment #4)
> For C++98 and C90, integer constants can only fit into the long type. You need
> to use LL if you want a 64bit integer constant.
> 

Thank you for clarifying this.


-- 


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2009-05-11 19:40 ---
(In reply to comment #4)
> I meant my fwprop patch. :-)

That's the patch in that revision range, yes... (FWIW, $SRP is the subroutine
return pointer, valid to use as data storage if saved.)

It's a bit unclear whether L154 is fall-through && R9 live and holding "r97"
before your second dump snippet, and the first diff (both reversed, I believe?)
doesn't tell whether *all* uses of r92 have been replaced.

I'll have a look myself.


-- 


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2009-05-11 20:47 ---
(In reply to comment #5)
> It's a latent bug somewhere, possibly in delayed branch scheduling?

With vs. without -fno-delayed-branch at 147274 seems to justify this blame.
Ugh.
I'll see if I can nail it.  But, for the record, having said that, still your
exposure, your bug. ;)


-- 


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

[Bug bootstrap/40103] [4.5 Regression] error: enum constant defined in struct or union is not visible in C++

[ian at airs dot com]

--- Comment #1 from ian at airs dot com  2009-05-11 20:53 ---
I have posted a patch here:

http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00587.html

The patch is to CLooG.


-- 

ian at airs dot com changed:

   What|Removed |Added

 CC|ian at gcc dot gnu dot org  |ian at airs dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-11 20:53:24
   date||


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

[Bug tree-optimization/38632] ICE with try/catch and -ftree-parallelize-loops

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2009-05-11 20:57 
---
The bug disappeared on the trunk between 2009-04-24 and 2009-05-04.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug tree-optimization/38632] ICE with try/catch and -ftree-parallelize-loops

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-05-11 21:07 ---
We shouldn't close a bug without a testcase. Otherwise, it may
come back again.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2009-05-11 21:14 ---
I see at least one invalid dbr transformation.  Assuming you can read m68k
assembler, I'm sure you'll have no problem gripping the important parts of:

subq 25,$r13
test.b [$r13+$r9.b]
-   beq .L6
-   nop
+   beq .L33
+   addq 1,$r9
+
subu.b 100,$r13
clear.d [$r13+$r9.d]
-.L6:
addq 1,$r9
+.L33:

That's right, dbr moves an increment of $r9 *over a use* (the "clear.d
[$r13+$r9.d]" is like "[r9:SI*0x4+r13:SI]=0").  Bah.  Over to gdb...


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-11 21:14:13
   date||


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

--- Comment #9 from hp at gcc dot gnu dot org  2009-05-11 21:19 ---
(In reply to comment #8)
> dbr moves an increment of $r9 *over a use*

Actually, "copies", not "moves", which is even worse (sort of; like "how could
it be worse").  I'll take it.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-11 21:14:13 |2009-05-11 21:19:04
   date||


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

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-05-11 22:56 ---
Now tracked as official Interpretation Request.

Request: http://www.j3-fortran.org/doc/year/09/09-236.txt (answer = proposed
answer by me).

Submitted for: J3 MEETING 189 LAS VEGAS, NEVADA, August 10 - 14, 2009
http://www.j3-fortran.org/doc/year/09/paper189.txt


-- 


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

[Bug tree-optimization/38632] ICE with try/catch and -ftree-parallelize-loops

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-05-12 00:00 ---
It is fixed by revision 146776:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01418.html


-- 


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

[Bug tree-optimization/38632] ICE with try/catch and -ftree-parallelize-loops

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-05-12 00:09 ---
Subject: Bug 38632

Author: hjl
Date: Tue May 12 00:09:17 2009
New Revision: 147401

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147401
Log:
2009-05-11  H.J. Lu  

PR tree-optimization/38632
* g++.dg/tree-ssa/pr38632.C: New.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr38632.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/38632] ICE with try/catch and -ftree-parallelize-loops

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-05-12 00:10 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/40105] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system

[kkojima at gcc dot gnu dot org]

--- Comment #1 from kkojima at gcc dot gnu dot org  2009-05-12 00:43 ---
Your compilers are the gentoo special versions, aren't they?
If so, you should try the original FSF compiler sources for both
build/target compilers.  See http://gcc.gnu.org/bugs.html#dontwant.
FSF 4.3/4.4 release compilers are bootstraped without problems
on sh4-unknown-linux-gnu for me. 
Only I can say from the log in #1 is that your xgcc driver looks
to segfault with -dumpspecs option.  Since it doesn't happen with
your gcc-4.1.2, it seems that your 4.3 compiler miscompiles something
for xgcc.  If it's the case, you can bisect the problem with
replacing objects and libraries for xgcc with those compiled by
your 4.1.2 compiler.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Priority|P3  |P4
Summary|[4.3/4.4 Regression] SH:|SH: 4.3/4.4 compilers
   |segfault when recompiling   |segfault when recompiling
   |itself  |itself on gentoo system


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

[Bug bootstrap/40103] [4.5 Regression] error: enum constant defined in struct or union is not visible in C++

[ian at gcc dot gnu dot org]

--- Comment #2 from ian at gcc dot gnu dot org  2009-05-12 01:26 ---
Subject: Bug 40103

Author: ian
Date: Tue May 12 01:26:45 2009
New Revision: 147407

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147407
Log:
PR bootstrap/40103
* graphite.c: Force -Wc++-compat to only be a warning before
#including "cloog/cloog.h".

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c


-- 


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

[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready

[ian at airs dot com]

--- Comment #3 from ian at airs dot com  2009-05-12 01:30 ---
The bootstrap problem has been fixed by adding a #pragma.  When and if the
CLooG header files are made -Wc++-compat compatible, that #pragma should be
removed.


-- 

ian at airs dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ian at airs dot com
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-11 20:53:24 |2009-05-12 01:30:52
   date||
Summary|[4.5 Regression] error: enum|CLooG header files are not -
   |constant defined in struct  |Wc++-compat ready
   |or union is not visible in  |
   |C++ |


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

[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready

[ian at airs dot com]

--- Comment #4 from ian at airs dot com  2009-05-12 01:31 ---
Suspending until CLooG is fixed.


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED
   Keywords|build   |


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

[Bug target/37137] [4.4 Regression] unrecognized command line option "-minterlink-mips16"

[aoliva at gcc dot gnu dot org]

--- Comment #7 from aoliva at gcc dot gnu dot org  2009-05-12 05:49 ---
Subject: Bug 37137

Author: aoliva
Date: Tue May 12 05:49:28 2009
New Revision: 147415

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147415
Log:
ChangeLog:
PR target/37137
* Makefile.def (flags_to_pass): Remove redundant and incomplete
STAGE1_CFLAGS, STAGE2_CFLAGS, STAGE3_CFLAGS, and STAGE4_CFLAGS.
Add FLAGS_FOR_TARGET and BUILD_CONFIG.
(bootstrap_stage): Remove bootstrap-debug custom stages.  Turn
stage_configureflags, stage_cflags and stage_libcflags into
explicit Makefile macros.
* Makefile.tpl (HOST_EXPORTS, EXTRA_HOST_FLAGS): Pass GCJ and
GFORTRAN.
(POSTSTAGE1_HOST_EXPORTS): Add XGCC_FLAGS_FOR_TARGET and TFLAGS to
CC.  Set CC_FOR_BUILD from CC.
(BASE_TARGET_EXPORTS, RAW_CXX_TARGET_EXPORTS,
NORMAL_TARGET_EXPORTS): Move SYSROOT_CFLAGS_FOR_TARGET and
DEBUG_PREFIX_CFLAGS_FOR_TARGET from CFLAGS and CXXFLAGS to
XGCC_FLAGS_FOR_TARGET.  Add it along with TFLAGS to CC, CXX, GCJ,
and GFORTRAN.
(TFLAGS, STAGE_CFLAGS, STAGE_TFLAGS, STAGE_CONFIGURE_FLAGS): New.
(_LIBCFLAGS): Renamed to _TFLAGS.
(do-compare-debug, do-compare3-debug): Drop.
(CC, GCC_FOR_TARGET, CXX_FOR_TARGET, RAW_CXX_FOR_TARGET,
GCJ_FOR_TARGET, GFORTRAN_FOR_TARGET): Remove FLAGS_FOR_TARGET.
(FLAGS_FOR_TARGET, SYSROOT_CFLAGS_FOR_TARGET,
DEBUG_PREFIX_CFLAGS_FOR_TARGET): Move down.
(XGCC_FLAGS_FOR_TARGET): New.
(BASE_FLAGS_TO_PASS): Pass STAGEid_CFLAGS, STAGEid_TFLAGS and TFLAGS.
(EXTRA_HOST_FLAGS): Pass GCJ and GFORTRAN.
(POSTSTAGE1_FLAGS_TO_PASS): Move SYSROOT_CFLAGS_FOR_TARGET and
DEBUG_PREFIX_CFLAGS_FOR_TARGET from CFLAGS, CXXFLAGS, LIBCFLAGS,
LIBCXXFLAGS to XGCC_FLAGS_FOR_TARGET.Add it along with TFLAGS
to CC, CXX, GCJ, and GFORTRAN.  Pass XGCC_FLAGS_FOR_TARGET and
TFLAGS.
(BUILD_CONFIG): Include if requested.
(all): Set TFLAGS on bootstrap.
(configure-stageid-prefixmodule): Pass TFLAGS, adjust FLAGS.
(all-stageid-prefixmodule): Likewise.
(do-clean, distclean-stageid): Set TFLAGS.
(restrap): Fix whitespace.
* Makefile.in: Rebuilt.
config/ChangeLog:
* multi.m4: Save CXX, GFORTRAN and GCJ in config.status.
* mt-gnu (CXXFLAGS_FOR_TARGET): Adjust.
* bootstrap-O1.mk: New.
* bootstrap-O3.mk: New.
* bootstrap-debug.mk: New.
gcc/ChangeLog:
PR target/37137
* doc/install.texi (STAGE1_TFLAGS, BUILD_CONFIG): Document.
gcc/java/ChangeLog:
* Make-lang.in (GCJ): Renamed to...
(XGCJ): ... this.
libjava/ChangeLog:
* configure.ac: Insert libgcjdir in the GCJ passed in the
environment, rather than overriding completely.
* configure: Rebuilt.

Added:
trunk/config/bootstrap-O1.mk
trunk/config/bootstrap-O3.mk
trunk/config/bootstrap-debug.mk
Modified:
trunk/ChangeLog
trunk/Makefile.def
trunk/Makefile.in
trunk/Makefile.tpl
trunk/config/ChangeLog
trunk/config/mt-gnu
trunk/config/multi.m4
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi
trunk/gcc/java/ChangeLog
trunk/gcc/java/Make-lang.in
trunk/libjava/ChangeLog
trunk/libjava/configure
trunk/libjava/configure.ac


-- 


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[bonzini at gnu dot org]

--- Comment #10 from bonzini at gnu dot org  2009-05-12 05:58 ---
Thanks H-P.


-- 


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

[Bug fortran/40006] allow type cheating for procedures with an implicit interface

[pault at gcc dot gnu dot org]

--- Comment #9 from pault at gcc dot gnu dot org  2009-05-12 06:07 ---
Since I am working on it, I had better take it :-)

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-12 06:07:43
   date||


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

[Bug fortran/40110] New: Bind(C): gfortran rejects the questionable but formally correct INTEGER(C_CHAR)

[burnus at gcc dot gnu dot org]

The following program is formally valid though the use of of C_CHAR as INTEGER
kind is doubtful and will not work on all systems. (C_CHAR is for CHARACTERS;
there is C_SIGNED_CHAR for INTEGERS, which may or may not have the same kind
number; in gfortran is has.)

However, it is simply a PARAMETER (of value 1) and as an integer of kind=1
exists, it may not be rejected according to the standard. gfortran currently
rejects it. It should print a big warning but it is formally correct.

See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/026a820711ab1e70


  use iso_c_binding
  implicit none

  Character(kind=c_char):: OK_1
  Integer(  kind=c_signed_char) :: OK_2
  Integer(  kind=c_char):: doubtful ! Formally OK, but bad usage

  print *, 'c_char = ', c_char ! is 1
  print *, 'c_signed_char = ', c_signed_char   ! is 1
  end


-- 
   Summary: Bind(C): gfortran rejects the questionable but formally
correct INTEGER(C_CHAR)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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