[Bug fortran/41242] [4.5 Regression] procedure pointer rejected (related to user-defined assignment?)

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2009-09-06 07:04 ---
(In reply to comment #2)

Why there is a dependence on the preceding statement, I have no idea.  However,
expr_type is not being set to EXPR_PPC, as the following shows (causes lots of
failures by the way :-()

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 151449)
+++ gcc/fortran/resolve.c   (working copy)
@@ -5101,6 +5101,7 @@
 gfc_resolve_expr (gfc_expr *e)
 {
   gfc_try t;
+  gfc_component *comp;

   if (e == NULL)
 return SUCCESS;
@@ -5113,6 +5114,9 @@

 case EXPR_FUNCTION:
 case EXPR_VARIABLE:
+  if (gfc_is_proc_ptr_comp (e, &comp)
+   && (resolve_expr_ppc (e) == SUCCESS))
+   return SUCCESS;

   if (check_host_association (e))
t = resolve_function (e);

I strongly suspect the patch of code in primary.c (gfc_match_varspec) that
deals with these things but I cannot quite see why at the present.

Paul


-- 


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

[Bug bootstrap/39686] ./gcc/xgcc crashes on mingw

[ktietz at gcc dot gnu dot org]

--- Comment #2 from ktietz at gcc dot gnu dot org  2009-09-06 08:52 ---
I tested a i686 mingw bootstrap for 4.4.x and it works for me.


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug fortran/41283] New: Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)

[sschwarzer at sschwarzer dot net]

$ gfortran --version
GNU Fortran (Ubuntu 4.3.3-5ubuntu4) 4.3.3
...
$ cat crash.f90
program crash_random_number

implicit none

integer, parameter :: dp = kind(1.0d0)
integer, parameter :: size = 1
real(kind=dp), dimension(size) :: x, y

! call random_seed() ! doesn't seem to change anything
! if I have only this statement, it seems to succeed
call random_number(x)
! with this one present, the process is killed _immediately_
call random_number(y)

end program crash_random_number
$ gfortran -o crash_random_number -std=f95 -Wall -O0 crash.f90
$ ./crash_random_number
Killed
$

_Any_ of the following changes seems to let the program succeed on my machine:

* changing the real type to default real
* changing the array size from 1 (1e8) to 1000 (1e7)
* commenting out the second call to random_number; however, if the second call
is present, as above, the program crashes immediately

The default integer size is 4 bytes with maximum 2147483647 (2.147483647e9), so
1e8 fits into the integer range.


-- 
   Summary: Generated program gets killed on subsequent calls to
random_number on "double precision" arrays of size
1 (1e8)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sschwarzer at sschwarzer dot net
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu


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

[Bug libstdc++/41280] [4.5 Regression] Revision 151352 breaks 32bit libstdc++

[rwild at gcc dot gnu dot org]

--- Comment #6 from rwild at gcc dot gnu dot org  2009-09-06 09:28 ---
Thanks for the report, analysis, and patch.  I'll look into this later today
(would like to know where I failed when testing my earlier patch, and whether
your patch doesn't do more than desired).  For reference, was this a native
build?  Was it in a fresh build tree or an updated one?  Did you run parallel
make?


-- 


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

[Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-06 09:40 ---
You use too much memory and your operating system kills your program for that.
Read on ulimit(8).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/41280] [4.5 Regression] Revision 151352 breaks 32bit libstdc++

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-09-06 09:43 
---
I reproduced it yesterday with a native, fresh, build, and make -j8 on a quad
core (I bet it happens also with -j1, I'll try it later today and I'll report
back in case of surprises).


-- 


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

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

[dominiq at lps dot ens dot fr]

--- Comment #25 from dominiq at lps dot ens dot fr  2009-09-06 09:56 ---
> Dominique,
> Also if you are bothering to run the test suite on i686-apple-darwin9
> periodically, you might as well shoot the results over to the gcc-testresults
> mailing list (since Apple has never set up a i686-apple-darwin9 regress
> server).

See

http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00494.html
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00495.html
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00502.html

I am curious to see how much it helps!-(


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-09-06 10:13 
---
Created an attachment (id=18516)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18516&action=view)
patch

here it is


-- 


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

[Bug target/41279] [4.5 Regression] 252.eon performance regression

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-06 10:17 ---
Most of the eon regression was due to the SRA patch.  Other changes weren't
affected by the SRA patch and so have to be attributed to VTA.

See http://gcc.opensuse.org/SPEC/CFP/sb-terbium-head-64/recent.html
and http://gcc.opensuse.org/SPEC/CINT/sb-terbium-head-64/recent.html

and the bumps around Sep 3rd.  I guess VTA wasn't supposed to change code
generation at all.


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-09-06 12:38 
---
We again have ANTIC_IN/OUT oscillation

ANTIC_OUT[] := { x_2 (0001), y_3 (0002), {pointer_plus_expr,x_2,4} (0011) }
ANTIC_IN[] := { x_2 (0001), y_3 (0002), {pointer_plus_expr,x_2,4} (0011) }
ANTIC_OUT[] := { x_2 (0001), y_3 (0002), {pointer_plus_expr,y_3,4} (0025) }
ANTIC_IN[] := { x_2 (0001), y_3 (0002), {pointer_plus_expr,y_3,4} (0025) }

for blocks 3, 9 and 6 which form a conditionally infinite loop.

:

:
  # x_2 = PHI 
  # y_3 = PHI 
  if (N_7(D) != 0)
goto ;
  else
goto ;

:
  goto ;

:

:
  # i_10 = PHI 
  D.1986_8 = i_10 * 4;
  D.1987_9 = y_3 + D.1986_8;
  D.1988_11 = x_2 + D.1986_8;
  D.1989_12 = *D.1988_11;
  D.1990_13 = x_2 + 4;
  D.1991_14 = *D.1990_13;
  D.1992_15 = D.1989_12 - D.1991_14;
  D.1993_16 = func (D.1992_15);
  *D.1987_9 = D.1993_16;
  if (D.1993_16 != 0)
goto ;
  else
goto ;

:
  i_20 = i_10 + 1;
  if (N_7(D) >= i_20)
goto ;
  else
goto ;

:
  goto ;

:

:
  goto ;

:
  return;

The maximal set has only {pointer_plus_expr,x_2,4} (0011),
{pointer_plus_expr,y_3,4} (0025) is the result of phi translating
{pointer_plus_expr,y_3,D.1986_8} (0007).

Injecting that pair into the cycle via BB3 -> BB8 yields to the oscillation
as from BB9 we get oscillating 11 which will mask out the other.

It seems to me that whenever we encounter such a cycle as 3 -> 9 -> 6 -> 3
we may not inject the maximal set there as it may not really be the
maximal set (which we can't really enlarge during phi translation, can we?
It does fix this case obviously though).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-09-06 12:41 
---
This is what I am thinking of:

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 151458)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -1802,7 +1802,10 @@ phi_translate_set (bitmap_set_t dest, bi
phi_trans_add (expr, translated, pred);

   if (translated != NULL)
-   bitmap_value_insert_into_set (dest, translated);
+   {
+ bitmap_value_insert_into_set (dest, translated);
+ bitmap_value_insert_into_set (maximal_set, translated);
+   }
 }
   VEC_free (pre_expr, heap, exprs);
 }


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2009-09-06 12:50 
---
Equivalent to that would be to clean ANTIC_IN using the maximal set - that is,
do not allow expressions in ANTIC_IN that are not in the maximal set.


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #13 from t7 at gmail dot com  2009-09-06 12:55 ---
(In reply to comment #12)
> Created an attachment (id=18516)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18516&action=view) [edit]
> patch
> 
> here it is
> 


Confirm fixed.


-- 


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

[Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)

[sschwarzer at sschwarzer dot net]

--- Comment #2 from sschwarzer at sschwarzer dot net  2009-09-06 13:22 
---
Richard, thanks for the quick answer. :-)

I hadn't gotten the idea of the limits because I can, from the same shell,
allocate three lists with Python which have the same size (1e8) and contain
floating point values of the same precision (i. e. 8-byte floats), and in
addition some memory overhead for each number. Inspecting limits with bash's
ulimit and settings in /etc/security/limits.conf doesn't seem to imply any
size/memory limits either.

Running the Fortran program under valgrind gives:

valgrind: mmap(0x804b000, 16) failed in UME with error 22 (Invalid
argument).
valgrind: this can be caused by executables with very large text, data or bss
segments.

Taking valgrind's message into account, it's probably reasonable to check
mmap's return value and give a more helpful error message when the compiled
Fortran program is run and fails. On the other hand, perhaps the mmap call with
its arguments is actually based on wrong assumptions and it's a real bug.

Another thought: Even if the mmap call's length argument was just too big,
would it be possible to access the memory in several chunks (mmap calls) to
work around the argument issue and thus be able to use as much total memory as
the operating system provides for the process?


-- 

sschwarzer at sschwarzer dot net changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[vmakarov at redhat dot com]

--- Comment #50 from vmakarov at redhat dot com  2009-09-06 13:46 ---
  I tried several times to reproduce it without success.  It is suspicious that
only gnat generated files are different.  May be the bug is in gnat specific
files.

  I found that gnat1 generated by a system compiler (gcc 4.3) gives valgrind
warnings.  So at least this bug is in ada sources.

valgrind /home/cygnus/vmakarov/build/lrs/build-p4/gcc/gnat1-O2 -g
-march=i586 -gtoggle  -gnatpg -gnata -nostdinc -I- -I. -Iada
-I/home/cygnus/vmakarov/build/lrs/gcc/gcc/ada
-I/home/cygnus/vmakarov/build/lrs/gcc/gcc/ada/gcc-interface
/home/cygnus/vmakarov/build/lrs/gcc/gcc/ada/lib-xref.adb
==28336== Memcheck, a memory error detector.
==28336== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==28336== Using LibVEX rev 1804, a library for dynamic binary translation.
==28336== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==28336== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==28336== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==28336== For more details, rerun with: -v
==28336== 
 Lib.Xref.Xrefs.Append Lib.Xref.Xrefs.Append_All Lib.Xref.Xrefs.Decrement_Last
Lib.Xref.Xrefs.Free Lib.Xref.Xrefs.Increment_Last Lib.Xref.Xrefs.Init
Lib.Xref.Xrefs.Last Lib.Xref.Xrefs.Reallocate Lib.Xref.Xrefs.Release
Lib.Xref.Xrefs.Restore Lib.Xref.Xrefs.Save Lib.Xref.Xrefs.Set_Item
Lib.Xref.Xrefs.Set_Last Lib.Xref.Xrefs.Tree_Get_Table_Address
Lib.Xref.Xrefs.Tree_Read Lib.Xref.Xrefs.Tree_Write Lib.Xref.Xref_Entryip
Lib.Xref.Xrefs.Table_Typeip Lib.Xref.Xrefs.Saved_Tableip
Lib.Xref.Generate_Definition Lib.Xref.Generate_Operator_Reference
Lib.Xref.Generate_Prim_Op_References Lib.Xref.Generate_Reference
Lib.Xref.Generate_Reference.Is_On_Lhs
Lib.Xref.Generate_Reference.Ok_To_Set_Referenced
Lib.Xref.Generate_Reference_To_Formals
Lib.Xref.Generate_Reference_To_Generic_Formals Lib.Xref.Initialize
Lib.Xref.Output_References Lib.Xref.Output_References.Get_Type_Reference
Lib.Xref.Output_References.Output_Import_Export_Info
Lib.Xref.Output_References.Handle_Orphan_Type_References.New_Entry
Lib.Xref.Output_References.Handle_Orphan_Type_References.B_17.Parent_Op
LIB.XREF.OUTPUT_REFERENCES.OUTPUT_REFS.SORTING.SORT
LIB.XREF.OUTPUT_REFERENCES.OUTPUT_REFS.SORTING.SORT.SIFT
Lib.Xref.Output_References.Output_Refs.Lt
Lib.Xref.Output_References.Output_Refs.Move
Lib.Xref.Output_References.Output_Refs.Name_Change
Lib.Xref.Output_References.Output_Refs.Output_One_Ref.Check_Type_Reference
Lib.Xref.Output_References.Output_Refs.Output_One_Ref.Output_Instantiation_Refs
Lib.Xref.Output_References.Output_Refs.Output_One_Ref.Output_Overridden_Op
Lib.Xref.Output_References.Output_Refs.Output_One_Ref.Write_Level_Info.Is_Private_Record_Component
Lib.Xref.Output_References.Output_Refs.Output_One_Ref.Write_Level_Info.Is_Visible_Generic_Entity
Lib.Xref==28336== Conditional jump or move depends on uninitialised value(s)
==28336==at 0x82D866C: lib__xref__output_references (lib-xref.adb:1504)
==28336==by 0x82DB89B: lib__writ__write_ali (lib-writ.adb:1235)
==28336==by 0x8440E4C: _ada_gnat1drv (gnat1drv.adb:957)
==28336==by 0x816D606: gnat_parse_file (misc.c:176)
==28336==by 0x86E1D81: toplev_main (toplev.c:1038)
==28336==by 0x84413A1: main (main.c:35)
==28336== 
==28336== Conditional jump or move depends on uninitialised value(s)
==28336==at 0x82D8BE5: lib__xref__output_references (lib-xref.adb:1753)
==28336==by 0x82DB89B: lib__writ__write_ali (lib-writ.adb:1235)
==28336==by 0x8440E4C: _ada_gnat1drv (gnat1drv.adb:957)
==28336==by 0x816D606: gnat_parse_file (misc.c:176)
==28336==by 0x86E1D81: toplev_main (toplev.c:1038)
==28336==by 0x84413A1: main (main.c:35)

Analyzing compilation unit
Performing interprocedural optimizations
 
 Assembling functions:
 Lib.Xref.Output_References.Output_Refs.Lt
LIB.XREF.OUTPUT_REFERENCES.OUTPUT_REFS.SORTING.SORT.SIFT
Lib.Xref.Generate_Reference.Is_On_Lhs
Lib.Xref.Output_References.Get_Type_Reference {GC 5332k -> 4189k}
Lib.Xref.Output_References.Output_Refs.Output_One_Ref.Output_Instantiation_Refs
Lib.Xref.Output_References.Output_Refs.Output_One_Ref.Check_Type_Reference
Lib.Xref.Xrefs.Decrement_Last Lib.Xref.Xrefs.Free Lib.Xref.Xrefs.Last
Lib.Xref.Xrefs.Reallocate Lib.Xref.Xrefs.Init Lib.Xref.Xrefs.Increment_Last
Lib.Xref.Output_References.Handle_Orphan_Type_References.New_Entry
Lib.Xref.Xrefs.Release Lib.Xref.Xrefs.Restore Lib.Xref.Xrefs.Save
Lib.Xref.Xrefs.Set_Last Lib.Xref.Xrefs.Set_Item Lib.Xref.Xrefs.Append
Lib.Xref.Xrefs.Append_All Lib.Xref.Xrefs.Tree_Get_Table_Address
Lib.Xref.Xrefs.Tree_Read Lib.Xref.Xrefs.Tree_Write Lib.Xref.Xref_Entryip
Lib.Xref.Xrefs.Table_Typeip Lib.Xref.Xrefs.Saved_Tableip
Lib.Xref.Generate_Definition Lib.Xref.Generate_Reference
Lib.Xref.Generate_Operator_Reference Lib.Xref.Generate_Reference_To_Formals
Lib.Xref.Generate_Reference_To_Generic_Formals Lib.Xref.Initialize
Lib.Xref.Output_References {GC 5486k -> 3997k} Lib.X

[Bug tree-optimization/41284] New: [4.5 regression] gcc fails to inline simple function

[schwab at linux-m68k dot org]

gcc fails to inline a simple function if it is first declared non-inline. 
There is no warning with -Winline.

$ gcc -S -O2 -Winline -fpic inline.c
$ grep fxstatat64 inline.s
$ gcc -S -O2 -Winline -fpic inline.c -DNO_DECL
$ grep fxstatat64 inline.s
bl __gi___fxstata...@local


-- 
   Summary: [4.5 regression] gcc fails to inline simple function
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at linux-m68k dot org


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[dberlin at dberlin dot org]

--- Comment #14 from dberlin at gcc dot gnu dot org  2009-09-06 14:15 
---
Subject: Re:  [4.4/4.5 Regression] ICE in 
compute_antic, at tree-ssa-pre.c:2419

On Sun, Sep 6, 2009 at 8:41 AM, rguenth at gcc dot gnu dot
org wrote:
>
>
> --- Comment #12 from rguenth at gcc dot gnu dot org  2009-09-06 12:41 
> ---
> This is what I am thinking of:

Think harder ;)

The maximal set is the initialization vector for this problem.
If we were using sbitmaps, it would be the equivalent of all ones.

Adding more things to it in the middle of the problem can't possibly be right.


-- 


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

[Bug tree-optimization/41284] [4.5 regression] gcc fails to inline simple function

[schwab at linux-m68k dot org]

--- Comment #1 from schwab at linux-m68k dot org  2009-09-06 14:15 ---
Created an attachment (id=18517)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18517&action=view)
Testcase


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenther at suse dot de]

--- Comment #15 from rguenther at suse dot de  2009-09-06 14:17 ---
Subject: Re:  [4.4/4.5 Regression] ICE in
 compute_antic, at tree-ssa-pre.c:2419

On Sun, 6 Sep 2009, dberlin at dberlin dot org wrote:

> 
> 
> --- Comment #14 from dberlin at gcc dot gnu dot org  2009-09-06 14:15 
> ---
> Subject: Re:  [4.4/4.5 Regression] ICE in 
> compute_antic, at tree-ssa-pre.c:2419
> 
> On Sun, Sep 6, 2009 at 8:41 AM, rguenth at gcc dot gnu dot
> org wrote:
> >
> >
> > --- Comment #12 from rguenth at gcc dot gnu dot org ?2009-09-06 12:41 
> > ---
> > This is what I am thinking of:
> 
> Think harder ;)
> 
> The maximal set is the initialization vector for this problem.
> If we were using sbitmaps, it would be the equivalent of all ones.
> 
> Adding more things to it in the middle of the problem can't possibly be right.

Of course ;)  It was just to illustrate the problem that
maximal_set U ANTIC_IN != maximal_set, thus maximal_set isn't all ones
but there are zeros for some expressions in ANTIC_IN.

Richard.


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[dberlin at dberlin dot org]

--- Comment #16 from dberlin at gcc dot gnu dot org  2009-09-06 14:19 
---
Subject: Re:  [4.4/4.5 Regression] ICE in 
compute_antic, at tree-ssa-pre.c:2419

On Sun, Sep 6, 2009 at 8:50 AM, rguenth at gcc dot gnu dot
org wrote:
>
>
> --- Comment #13 from rguenth at gcc dot gnu dot org  2009-09-06 12:50 
> ---
> Equivalent to that would be to clean ANTIC_IN using the maximal set - that is,
> do not allow expressions in ANTIC_IN that are not in the maximal set.
>

It might be easier to go the other way around, and just special case
the maximal set everywhere again.


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenther at suse dot de]

--- Comment #17 from rguenther at suse dot de  2009-09-06 14:20 ---
Subject: Re:  [4.4/4.5 Regression] ICE in
 compute_antic, at tree-ssa-pre.c:2419

On Sun, 6 Sep 2009, dberlin at dberlin dot org wrote:

> --- Comment #16 from dberlin at gcc dot gnu dot org  2009-09-06 14:19 
> ---
> Subject: Re:  [4.4/4.5 Regression] ICE in 
> compute_antic, at tree-ssa-pre.c:2419
> 
> On Sun, Sep 6, 2009 at 8:50 AM, rguenth at gcc dot gnu dot
> org wrote:
> >
> >
> > --- Comment #13 from rguenth at gcc dot gnu dot org ?2009-09-06 12:50 
> > ---
> > Equivalent to that would be to clean ANTIC_IN using the maximal set - that 
> > is,
> > do not allow expressions in ANTIC_IN that are not in the maximal set.
> >
> 
> It might be easier to go the other way around, and just special case
> the maximal set everywhere again.

Can you elaborate on that a bit?

Thanks,
Richard.


-- 


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

[Bug c++/41144] [4.5 Regression] ice for legal code with -O2 in get_alias_set

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-06 14:04 ---
The future canonical type with structual equality set is built from

#0  0x089afcf4 in build_array_type (elt_type=0xb7d75620, index_type=0xb7d734d0)
at /home/richard/src/trunk/gcc/tree.c:6906
#1  0x082ecaa7 in build_cplus_array_type_1 (elt_type=0xb7d75620, 
index_type=0xb7d734d0) at /home/richard/src/trunk/gcc/cp/tree.c:649
#2  0x082ecd0b in build_cplus_array_type (elt_type=0xb7d75620, 
index_type=0xb7d734d0) at /home/richard/src/trunk/gcc/cp/tree.c:669
#3  0x0818fa4a in tsubst (t=0xb7d73540, args=0xb7d62d58, complain=3, 
in_decl=0xb7d68540) at /home/richard/src/trunk/gcc/cp/pt.c:9909
#4  0x08188473 in tsubst_decl (t=0xb7d68540, args=0xb7d62d58, complain=3)
at /home/richard/src/trunk/gcc/cp/pt.c:8859
#5  0x0818affd in tsubst (t=0xb7d68540, args=0xb7d62d58, complain=3, 
in_decl=0x0) at /home/richard/src/trunk/gcc/cp/pt.c:9382
#6  0x0817bce9 in instantiate_class_template (type=0xb7d75460)
at /home/richard/src/trunk/gcc/cp/pt.c:7523
#7  0x0826dea8 in complete_type (type=0xb7d75460)
at /home/richard/src/trunk/gcc/cp/typeck.c:130
#8  0x0826dec4 in complete_type_or_else (type=0xb7d75460, value=0x0)
at /home/richard/src/trunk/gcc/cp/typeck.c:142
#9  0x081313c8 in xref_basetypes (ref=0xb7d752a0, base_list=0xb7d62dac)
at /home/richard/src/trunk/gcc/cp/decl.c:10770
#10 0x0817aeeb in instantiate_class_template (type=0xb7d752a0)
at /home/richard/src/trunk/gcc/cp/pt.c:7411
#11 0x0826dea8 in complete_type (type=0xb7d753f0)
at /home/richard/src/trunk/gcc/cp/typeck.c:130
#12 0x08109ed7 in start_decl_1 (decl=0xb7d68600, initialized=0 '\0')
at /home/richard/src/trunk/gcc/cp/decl.c:4299
#13 0x08109c8a in start_decl (declarator=0x8ff42d8, declspecs=0xbfffef28, 
initialized=0, attributes=0x0, prefix_attributes=0x0, 
pushed_scope_p=0xbfffee90) at /home/richard/src/trunk/gcc/cp/decl.c:4262
#14 0x082503a1 in cp_parser_init_declarator (parser=0xb7fde6b4, 
...

with element type

 
full-name "struct span_gouraud::coord_type"
no-binfo use_template=1 interface-unknown
chain >

thus layout_type() re-sets the original TYPE_CANONICAL (t) == t to NULL.

Later the frontend completes that coord_type and thus following array
types using that element type are no longer falling back to structural
equality by default:

#0  finalize_record_size (rli=0x8fdbf98)
at /home/richard/src/trunk/gcc/stor-layout.c:1482
#1  0x087a4005 in finish_record_layout (rli=0x8fdbf98, free_p=1)
at /home/richard/src/trunk/gcc/stor-layout.c:1707
#2  0x081ff0ef in layout_class_type (t=0xb7d75620, virtuals_p=0xbfffdb00)
at /home/richard/src/trunk/gcc/cp/class.c:5192
#3  0x08200198 in finish_struct_1 (t=0xb7d75620)
at /home/richard/src/trunk/gcc/cp/class.c:5297
#4  0x0817c5cb in instantiate_class_template (type=0xb7d75620)
at /home/richard/src/trunk/gcc/cp/pt.c:7704
#5  0x0826dea8 in complete_type (type=0xb7d75620)
at /home/richard/src/trunk/gcc/cp/typeck.c:130
#6  0x0826da29 in complete_type (type=0xb7d75700)
at /home/richard/src/trunk/gcc/cp/typeck.c:115
#7  0x0817be9f in instantiate_class_template (type=0xb7d75460)
at /home/richard/src/trunk/gcc/cp/pt.c:7556
#8  0x0826dea8 in complete_type (type=0xb7d75460)
at /home/richard/src/trunk/gcc/cp/typeck.c:130
#9  0x0826dec4 in complete_type_or_else (type=0xb7d75460, value=0x0)
at /home/richard/src/trunk/gcc/cp/typeck.c:142
#10 0x081313c8 in xref_basetypes (ref=0xb7d752a0, base_list=0xb7d62dac)
at /home/richard/src/trunk/gcc/cp/decl.c:10770
#11 0x0817aeeb in instantiate_class_template (type=0xb7d752a0)
at /home/richard/src/trunk/gcc/cp/pt.c:7411
#12 0x0826dea8 in complete_type (type=0xb7d753f0)
at /home/richard/src/trunk/gcc/cp/typeck.c:130
#13 0x08109ed7 in start_decl_1 (decl=0xb7d68600, initialized=0 '\0')
at /home/richard/src/trunk/gcc/cp/decl.c:4299

So either the C++ frontend should be more careful and completing the element
type first before building an array type or we need to not look up the
structual equality marked array type when building the canonical type for
our second array type we build (where the element type is not the canonical
type).  This 2nd version is easy enough to implement.


-- 


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

[Bug fortran/41219] libgfortran build warnings

[jb at gcc dot gnu dot org]

--- Comment #6 from jb at gcc dot gnu dot org  2009-09-06 13:55 ---
(In reply to comment #2)
> Janne, I think the warning about "unix.c:750:15: warning: ‘statbuf.st_mode’ 
> may
> be used uninitialized" is spurious, but can you have a look?

Yes, it's spurious, and I submitted a patch
(http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00419.html), but maybe the
middle-end shouldn't warn about it anyway (see the reply by Richard Guenther).

> Jerry, there is some inconsistency regarding st_parameter_dt's "saved_type".
> One finds both "bt" and "dtype" assignments, which does not make sense. Does
> one need both types in a union? Or can one consolidate them?
> 
> list_read.c:  dtp->u.p.saved_type = BT_LOGICAL;
> list_read.c:  dtp->u.p.saved_type = GFC_DTYPE_UNKNOWN;
> etc.

I looked into this when I redid the lower layer I/O library, and I gave up in
exasperation. This dichotomy between BT_* and GFC_DTYPE_* extends into the
frontend, and would require lots of tedious work and an ABI change to fix.
Perhaps at the same time we change the array descriptor we could fix this too
(the descriptor also needs some form of type tag, and if we adopt the TR29113
descriptor that then also influences the type tag). I added a note about this
to http://gcc.gnu.org/wiki/LibgfortranAbiCleanup . As an additional bonus, note
that the bt enum is different in the frontend and the library, and some of the
library entry points take bt enums as arguments, which makes one one wonder how
the heck all this works.. :)

> In write_a_char4, one has:
>   const char crlf[] = "\r\n";
>   write_default_char4 (dtp, crlf, 2, 0);
> but the second argument should be  gfc_char4_t*

Right. So what is "\r\n" in terms of gfc_char4_t? 


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #14 from t7 at gmail dot com  2009-09-06 13:57 ---
(In reply to comment #12)
> Created an attachment (id=18516)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18516&action=view) [edit]
> patch
> 
> here it is
> 

For some reason this leads to :
Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: qmake.exe
  Application Version:  0.0.0.0
  Application Timestamp:4aa3bdce
  Fault Module Name:qmake.exe
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp:   4aa3bdce
  Exception Code:   c005
  Exception Offset: 0040e132

Program received signal SIGSEGV, Segmentation fault.
0x0080e132 in QString::at ()
(gdb) bt
#0  0x0080e132 in QString::at ()
#1  0x in ?? ()
(gdb) info register
srax0x0 0
rcx0x22f000 2289664
rdx0x34dc60 3464288
rbx0x22f000 2289664
rsp0x22ef80 2289536
rbp0x6  6
rsi0x34dc60 3464288
rdi0x34dae0 3463904
r8 0x0  0
r9 0x22f230 2290224
r100x6c0073005c0065 30399791412019301
r110x34dcfa 3464442
r120x342310 3416848
r130xa  10
r140x0  0
r150x0  0
rip0x80e132 0x80e132 
eflags 0x10206  [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43

disass $pc-30 $pc+30
Dump of assembler code from 0x80e114 to 0x80e150:
0x0080e114 <_ZNK7QScript9CFunction4typeEv+12>:  or %al,%bl
0x0080e116 <_ZNK7QScript9CFunction4typeEv+14>:  nop
0x0080e117 <_ZNK7QScript9CFunction4typeEv+15>:  nop
0x0080e118 <_ZNK7QString2atEi+0>:   sub$0x38,%rsp
0x0080e11c <_ZNK7QString2atEi+4>:   mov%rbx,0x28(%rsp)
0x0080e121 <_ZNK7QString2atEi+9>:   mov%rsi,0x30(%rsp)
0x0080e126 <_ZNK7QString2atEi+14>:  mov%rcx,%rbx
0x0080e129 <_ZNK7QString2atEi+17>:  mov%edx,%esi
0x0080e12b <_ZNK7QString2atEi+19>:  test   %edx,%edx
0x0080e12d <_ZNK7QString2atEi+21>:  js 0x80e137
<_ZNK7QString2atEi+31>
0x0080e12f <_ZNK7QString2atEi+23>:  mov(%rcx),%rax
0x0080e132 <_ZNK7QString2atEi+26>:  cmp0x8(%rax),%edx
0x0080e135 <_ZNK7QString2atEi+29>:  jl 0x80e150
<_ZNK7QString2atEi+56>
0x0080e137 <_ZNK7QString2atEi+31>:  mov$0x2ad,%r8d
0x0080e13d <_ZNK7QString2atEi+37>:  lea0x18f0c(%rip),%rdx  
 # 0x827050 <_data_end__+1936>
0x0080e144 <_ZNK7QString2atEi+44>:  lea0x18f7e(%rip),%rcx  
 # 0x8270c9 <_data_end__+2057>
0x0080e14b <_ZNK7QString2atEi+51>:  callq  0x640d37
<_Z9qt_assertPKcS0_i>


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-09-06 14:07 
---
Try building without the patch but with unlimited stack (ulimit -s unlimited)
and see if the same error appears.


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #15 from t7 at gmail dot com  2009-09-06 13:59 ---
(gdb) print $pc
$1 = (void (*)()) 0x80e132 


-- 


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

[Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-06 14:46 ---
Well you are allocating an 1.5gb bss segment.  There is no room for this
amount of contiguous memory on i?86.

You might want to use allocatable arrays instead.

Anyway, this is not a gcc bug.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/41284] [4.5 regression] gcc fails to inline simple function

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-06 14:49 ---
Works for me on i?86.  Maybe m86k is somehow oddly confused about the extra
restrict qualification in the prototype?


-- 


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

[Bug tree-optimization/41284] [4.5 regression] gcc fails to inline simple function

[schwab at linux-m68k dot org]

--- Comment #3 from schwab at linux-m68k dot org  2009-09-06 14:55 ---
I don't know what m86k is, but this is obviously ppc assembler.


-- 


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

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

[howarth at nitro dot med dot uc dot edu]

--- Comment #26 from howarth at nitro dot med dot uc dot edu  2009-09-06 
15:07 ---
It duplicates my observations that this bug is only triggered on
*-apple-darwin10 at -m64.


-- 


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

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

[hjl dot tools at gmail dot com]

--- Comment #27 from hjl dot tools at gmail dot com  2009-09-06 15:37 
---
EH has been problematic on Darwin/x86, see PR 37012.


-- 


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

[Bug libstdc++/41267] vector<>::resize() from an empty vector calls memmove for 0 bytes (twice), wasting a lot of cpu time in a production PowerDNS

[paolo at gcc dot gnu dot org]

--- Comment #2 from paolo at gcc dot gnu dot org  2009-09-06 15:41 ---
Subject: Bug 41267

Author: paolo
Date: Sun Sep  6 15:41:38 2009
New Revision: 151459

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151459
Log:
2009-09-06  Paolo Carlini  

PR libstdc++/41267
* include/bits/stl_algobase.h (__copy_move::__copy_m,
__copy_move_backward::__copy_move_b): Don't call __builtin_memmove
with a null third argument.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algobase.h


-- 


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

[Bug libstdc++/41267] vector<>::resize() from an empty vector calls memmove for 0 bytes (twice), wasting a lot of cpu time in a production PowerDNS

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-09-06 15:43 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

[howarth at nitro dot med dot uc dot edu]

--- Comment #28 from howarth at nitro dot med dot uc dot edu  2009-09-06 
16:01 ---
Hopefully we can still use Apple's gdb to debug these EH issues on darwin10. If
I am reading...

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00074.html

correctly, the VTA merge may break the ability to debug optimized code but we
should be okay
debugging test cases that compile at -O0, right?


-- 


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

[Bug tree-optimization/41271] [4.5 Regression] FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times matrix-reorg "Flattened 2 dimensions" 1

[schwab at linux-m68k dot org]

--- Comment #11 from schwab at linux-m68k dot org  2009-09-06 16:08 ---
*** Bug 41284 has been marked as a duplicate of this bug. ***


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 CC||schwab at linux-m68k dot org


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

[Bug tree-optimization/41284] [4.5 regression] gcc fails to inline simple function

[schwab at linux-m68k dot org]

--- Comment #4 from schwab at linux-m68k dot org  2009-09-06 16:08 ---


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


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 GCC target triplet|ppc-*-* |
 Resolution||DUPLICATE


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

[Bug fortran/41258] [4.4/4.5 Regression] internal compiler error: in find_typebound_proc_uop, at fortran/symbol.c:4575

[domob at gcc dot gnu dot org]

--- Comment #7 from domob at gcc dot gnu dot org  2009-09-06 16:16 ---
Thanks for fixing this, I guess this was my fault (without looking further)... 
I was away over the weekend, but should be able to do some hacking again now ;)


-- 


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

[Bug fortran/41283] Generated program gets killed on subsequent calls to random_number on "double precision" arrays of size 100000000 (1e8)

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-09-06 16:25 ---

> 
> ! call random_seed() ! doesn't seem to change anything

It changes the seeds to the default settings.  Please see
the manual that came with gfortran.  

As to the other problem, follow Richard's advice and
use a dynamic array.


-- 


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

[Bug middle-end/41261] ice with -O2 -fprofile-arcs when compiling Linux kernel

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-06 16:49 ---
Subject: Bug 41261

Author: rguenth
Date: Sun Sep  6 16:48:41 2009
New Revision: 151460

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151460
Log:
2009-09-06  Richard Guenther  

PR middle-end/41261
* tree-ssa-alias.c (refs_may_alias_p_1): Bail out for function decls.

* gcc.dg/torture/pr41261.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr41261.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c


-- 


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

[Bug c++/41144] [4.5 Regression] ice for legal code with -O2 in get_alias_set

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-09-06 16:50 ---
Subject: Bug 41144

Author: rguenth
Date: Sun Sep  6 16:49:48 2009
New Revision: 151461

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151461
Log:
2009-09-06  Richard Guenther  

PR middle-end/41144
* tree.c (build_array_type): Do not record types marked
with structural equality in the canonical type hashtable.

* g++.dg/torture/pr41144.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr41144.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug middle-end/41261] ice with -O2 -fprofile-arcs when compiling Linux kernel

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-09-06 16:50 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/41144] [4.5 Regression] ice for legal code with -O2 in get_alias_set

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-06 16:50 ---
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=41144

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2009-09-06 16:51 
---
The patch bootstrapped and tested ok but I'm holding off until you confirm it's
not the reason for the issue you see.


-- 


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

[Bug fortran/41197] ICE with ALLOCATE and nonscalar STAT= variable

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2009-09-06 17:38 ---
I have a patch.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-06 17:38:45
   date||


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2009-09-06 17:41 
---
Do you mean sth like the following?  Simply assuming that the maximal-set is
all ones and obviously translating all ones also results in all ones.

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 151459)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -2201,49 +2201,45 @@ compute_antic_aux (basic_block block, bo
 {
   VEC(basic_block, heap) * worklist;
   size_t i;
-  basic_block bprime, first;
+  basic_block bprime, first = NULL;

   worklist = VEC_alloc (basic_block, heap, EDGE_COUNT (block->succs));
   FOR_EACH_EDGE (e, ei, block->succs)
-   VEC_quick_push (basic_block, worklist, e->dest);
-  first = VEC_index (basic_block, worklist, 0);
-
-  if (phi_nodes (first))
{
- bitmap_set_t from = ANTIC_IN (first);
-
- if (!BB_VISITED (first))
-   from = maximal_set;
- phi_translate_set (ANTIC_OUT, from, block, first);
+ if (!first
+ && BB_VISITED (e->dest))
+   first = e->dest;
+ else if (BB_VISITED (e->dest))
+   VEC_quick_push (basic_block, worklist, e->dest);
+   }
+
+  /* Of multiple successors we have to have visited one already.  */
+  if (!first)
+   {
+ SET_BIT (changed_blocks, block->index);
+ BB_VISITED (block) = 0;
+ BB_DEFERRED (block) = 1;
+ changed = true;
+ VEC_free (basic_block, heap, worklist);
+ goto maybe_dump_sets;
}
+
+  if (phi_nodes (first))
+   phi_translate_set (ANTIC_OUT, ANTIC_IN (first), block, first);
   else
-   {
- if (!BB_VISITED (first))
-   bitmap_set_copy (ANTIC_OUT, maximal_set);
- else
-   bitmap_set_copy (ANTIC_OUT, ANTIC_IN (first));
-   }
+   bitmap_set_copy (ANTIC_OUT, ANTIC_IN (first));

-  for (i = 1; VEC_iterate (basic_block, worklist, i, bprime); i++)
+  for (i = 0; VEC_iterate (basic_block, worklist, i, bprime); i++)
{
  if (phi_nodes (bprime))
{
  bitmap_set_t tmp = bitmap_set_new ();
- bitmap_set_t from = ANTIC_IN (bprime);
-
- if (!BB_VISITED (bprime))
-   from = maximal_set;
- phi_translate_set (tmp, from, block, bprime);
+ phi_translate_set (tmp, ANTIC_IN (bprime), block, bprime);
  bitmap_set_and (ANTIC_OUT, tmp);
  bitmap_set_free (tmp);
}
  else
-   {
- if (!BB_VISITED (bprime))
-   bitmap_set_and (ANTIC_OUT, maximal_set);
- else
-   bitmap_set_and (ANTIC_OUT, ANTIC_IN (bprime));
-   }
+   bitmap_set_and (ANTIC_OUT, ANTIC_IN (bprime));
}
   VEC_free (basic_block, heap, worklist);
 }


Now obviously I'm not convinced we'll not defer blocks forever because
we can't seed one with the maximal set ...

Minimally tested with this testcase and tree-ssa.exp.


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2009-09-06 17:48 
---
Err... I wonder how this works at all ;)


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2009-09-06 17:53 
---
Ah, we start from the exit block with ANTIC_IN {} and go to its predecessors
getting just EXP_GEN - TMP_GEN there.  Not unsound.


-- 


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

[Bug c/41285] New: ICE: builtin function to __builtin_bswap16 already processed.

[marcus at jet dot franken dot de]

lto on powerpc does not work at all.

(system is openSUSE 11.1 / PowerPC 32bit. glibc 2.9) 

$ cat xx.c 
int main(int argc,char **argv) { return 1; }
$ /abuild/meissner/lto/BIN/bin/gcc -flto -O2 xx.c -o xx
lto1: fatal error: internal error: builtin function to __builtin_bswap16
already processed.
compilation terminated.
lto-wrapper: /abuild/meissner/lto/BIN/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: ICE: builtin function to __builtin_bswap16 already
processed.
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at jet dot franken dot de
 GCC build triplet: powerpc-unknown-linux-gnu
  GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug libstdc++/41280] [4.5 Regression] Revision 151352 breaks 32bit libstdc++

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2009-09-06 16:56 ---
Darn.  An intermediate version of the r151352 patch was correct and I failed
to do the installation test properly on the final version of the patch.
Awfully sorry about the breakage.

Updated patch at .


-- 


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

[Bug lto/41173] [LTO] internal error: builtin function to __builtin_spe_mtspefscr already processed

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-06 17:02 ---
*** Bug 41285 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||marcus at jet dot franken
   ||dot de


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

[Bug lto/41173] [LTO] internal error: builtin function to __builtin_spe_mtspefscr already processed

[rguenth at gcc dot gnu dot org]

-- 

rguenth 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-09-06 17:03:13
   date||
Version|4.5.0   |lto


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

[Bug c/41285] ICE: builtin function to __builtin_bswap16 already processed.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-06 17:02 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[ktietz at gcc dot gnu dot org]

--- Comment #6 from ktietz at gcc dot gnu dot org  2009-09-06 18:07 ---
I think I found the issue within gfortran for mingw. The issue is that off_t is
for mingw defined as 'long' (like _off_t). There is a 64-bit off64_t, which
holds in fact 64-bits and can be used with the ftello64, and fseeko64
functions.

Cheers,
Kai


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu dot
   ||org


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

[Bug fortran/41219] libgfortran build warnings

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2009-09-06 18:17 
---
Let me fix this.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-09-03 06:55:42 |2009-09-06 18:17:58
   date||


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[ebotcazou at gcc dot gnu dot org]

--- Comment #51 from ebotcazou at gcc dot gnu dot org  2009-09-06 18:20 
---
>   I tried several times to reproduce it without success.  It is suspicious 
> that
> only gnat generated files are different.  May be the bug is in gnat specific
> files.

No, it's again CSA, I'm testing a patch on top of Jakub's.


-- 


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[jakub at gcc dot gnu dot org]

--- Comment #52 from jakub at gcc dot gnu dot org  2009-09-06 18:38 ---
Created an attachment (id=18518)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18518&action=view)
gcc45-pr41241.patch

FYI, here is the updated patch that I've already bootstrapped on x86_64-linux
and i686-linux and am regtesting ATM.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #18497|0   |1
is obsolete||


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[kargl at gcc dot gnu dot org]

--- Comment #7 from kargl at gcc dot gnu dot org  2009-09-06 18:45 ---
(In reply to comment #6)
> I think I found the issue within gfortran for mingw.

I think you have this backwards.  "the issue within mingw
for gfortran" would be a better description of the issue.
It is afterall mingw that defines off_t.

-- 
steve


-- 


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[ktietz at gcc dot gnu dot org]

--- Comment #8 from ktietz at gcc dot gnu dot org  2009-09-06 18:52 ---
(In reply to comment #7)
> (In reply to comment #6)
> > I think I found the issue within gfortran for mingw.
> 
> I think you have this backwards.  "the issue within mingw
> for gfortran" would be a better description of the issue.
> It is afterall mingw that defines off_t.
> 
> -- 
> steve
> 

Well, in fact it is MS here. But we on mingw-w64 think at the moment about to
add an override option for this by defining _LARGE_FILES. But we have to plan
this in more detail. Would this be an option for you?


-- 


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[ebotcazou at gcc dot gnu dot org]

--- Comment #53 from ebotcazou at gcc dot gnu dot org  2009-09-06 19:08 
---
> FYI, here is the updated patch that I've already bootstrapped on x86_64-linux
> and i686-linux and am regtesting ATM.

This is fine, thanks (missing "records" after "This structure").


-- 


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[kargl at gcc dot gnu dot org]

--- Comment #9 from kargl at gcc dot gnu dot org  2009-09-06 19:09 ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > I think I found the issue within gfortran for mingw.
> > 
> > I think you have this backwards.  "the issue within mingw
> > for gfortran" would be a better description of the issue.
> > It is afterall mingw that defines off_t.
> > 
> 
> Well, in fact it is MS here. But we on mingw-w64 think at the moment about to
> add an override option for this by defining _LARGE_FILES. But we have to plan
> this in more detail. Would this be an option for you?
> 

If the changes are confined to libgfortran, then I suspect that the
above would be acceptable (although I haven't worked on libgfortran
recently); as long as the changes can be wrapped in '#define __MINGW__'
(or an equivalent).  If front-end changes are required, then that would
be much more difficult to accommodate.


-- 


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

[Bug ada/40805] verify_gimple failure preceded by "non-trivial conversion at assignment" errors

[oliver dot kellogg at eads dot com]

--- Comment #4 from oliver dot kellogg at eads dot com  2009-09-06 19:21 
---
I don't know what fixed it but it doesn't happen with trunk 20090819 and newer.


-- 

oliver dot kellogg at eads dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[jakub at gcc dot gnu dot org]

--- Comment #54 from jakub at gcc dot gnu dot org  2009-09-06 19:32 ---
Subject: Bug 41241

Author: jakub
Date: Sun Sep  6 19:31:55 2009
New Revision: 151462

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151462
Log:
PR bootstrap/41241
* combine-stack-adj.c (struct csa_memlist): Rename to...
(struct csa_reflist): ... this.  Rename mem field to ref.
(free_csa_memlist): Rename to...
(free_csa_reflist): ... this.
(record_one_stack_memref): Rename to...
(record_one_stack_ref): ... this.  Handle also REG_P.
(try_apply_stack_adjustment): Handle also REG_P.
(struct record_stack_memrefs_data): Rename to...
(struct record_stack_refs_data): ... this.  Rename memlist field to
reflist.
(record_stack_memrefs): Rename to...
(record_stack_refs): ... this.  For DEBUG_INSNs keep traversing
subexpressions instead of failing when a MEM contains SP references.
For SP itself in DEBUG_INSNs queue it also onto reflist chain.
(combine_stack_adjustments_for_block): Adjust for mem to ref renaming.

* gcc.dg/pr41241.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr41241.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine-stack-adj.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2009-09-06 19:51 
---
Both patches bootstrap & regtest ok apart from

FAIL: 23_containers/forward_list/operations/6.cc execution test

hmm.


-- 


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[ktietz at gcc dot gnu dot org]

--- Comment #10 from ktietz at gcc dot gnu dot org  2009-09-06 20:05 ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > > I think I found the issue within gfortran for mingw.
> > > 
> > > I think you have this backwards.  "the issue within mingw
> > > for gfortran" would be a better description of the issue.
> > > It is afterall mingw that defines off_t.
> > > 
> > 
> > Well, in fact it is MS here. But we on mingw-w64 think at the moment about 
> > to
> > add an override option for this by defining _LARGE_FILES. But we have to 
> > plan
> > this in more detail. Would this be an option for you?
> > 
> 
> If the changes are confined to libgfortran, then I suspect that the
> above would be acceptable (although I haven't worked on libgfortran
> recently); as long as the changes can be wrapped in '#define __MINGW__'
> (or an equivalent).  If front-end changes are required, then that would
> be much more difficult to accommodate.
> 

Sorry, I think you misunderstand the suggestion I did. I said that we would
allow by defining _LARGE_FILES, that off_t (and ftell, fseek) are defined as
POSIX. You have to notice that Windows (and in special mingw targets) aren't
POSIX. They are Windows native targets, which have to live with the API MS
defines. If the suggested suggestion isn't acceptable, well then files > 2GB
won't run for gfortran, sorry.


-- 


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

[Bug ada/41286] New: a warning about renamed function result is possibly confusing

[bauhaus at futureapps dot de]

GNAT issues warnings when a declaration renames
a function result object:

11.  Text : String renames Get_Another;
   |
>>> warning: renaming function result object is suspicious
>>> warning: function "Get_Another" will be called only once
>>> warning: suggest using an initialized constant object instead

If you look at the program below, where the declaration
of Text is inside a loop, the "once" part becomes 
confusing, because Get_Line will be called during each
iteration of the loop surrounding the declaration.
  (The history of this warning seems to be a
different confusion about identifier Text not renaming
the function Get_Line but its result.)

To reproduce:
$ gnatchop -r -w rnm.ada && gnatmake -gnatwa -gnatv rnm

I like to suggest then to change the wording of
the second warning line. Something like

  warning: "Line" renames the result of this call only

or better that "pinpoints" the warning to the
line of the declaration of Text.


with Ada.Text_IO;

procedure Rnm is

   function Get_Another return String is separate;
   -- post: String'Length > 0

begin
   loop
  declare
 Text : String renames Get_Another;
  begin
 Ada.Text_IO.Put(Text(1));
  end;
   end loop;
end Rnm;


with Ada.Text_IO;

separate(Rnm)
function Get_Another return String is
   Result : String(1 .. 80);
   Last : Natural;
begin
   Ada.Text_IO.Get_Line(Result, Last);
   if Last = 0 then
  Result(1) := '?';
  Last := 1;
   end if;
   return Result(1 .. Last);
end Get_Another;


-- 
   Summary: a warning about renamed function result is possibly
confusing
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bauhaus at futureapps dot de
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[ebotcazou at gcc dot gnu dot org]

--- Comment #55 from ebotcazou at gcc dot gnu dot org  2009-09-06 21:16 
---
Subject: Bug 41241

Author: ebotcazou
Date: Sun Sep  6 21:15:45 2009
New Revision: 151463

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151463
Log:
PR bootstrap/41241
* combine-stack-adj.c (try_apply_stack_adjustment): Handle stores.
(combine_stack_adjustments_for_block): Allow insns between stack
adjustments and stores with corresponding with pre-(dec|inc)rement
or pre-modify.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine-stack-adj.c


-- 


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[ebotcazou at gcc dot gnu dot org]

--- Comment #56 from ebotcazou at gcc dot gnu dot org  2009-09-06 21:17 
---
This should be fixed everywhere.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/38591] erratic comparison failures on very fast machines

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2009-09-06 21:18 
---
In comment #6.


-- 

ebotcazou 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-09-06 21:18:42
   date||


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

[Bug fortran/41219] libgfortran build warnings

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-09-06 21:21 
---
The following patch gets rid of the two warnings in list_read.c.  The two
enumerators have equivalent value.  Regression tests fine.

@@ -2377,7 +2377,7 @@
  /* GFC_TYPE_UNKNOWN through for nulls and is detected
 after the switch block.  */

- dtp->u.p.saved_type = GFC_DTYPE_UNKNOWN;
+ dtp->u.p.saved_type = BT_NULL;
  free_saved (dtp);

   switch (nl->type)
@@ -2467,7 +2467,7 @@
  return SUCCESS;
}

-  if (dtp->u.p.saved_type == GFC_DTYPE_UNKNOWN)
+  if (dtp->u.p.saved_type == BT_NULL)
{
  dtp->u.p.expanded_read = 0;
  goto incr_idx;


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #18 from t7 at gmail dot com  2009-09-06 21:59 ---
(In reply to comment #17)
> The patch bootstrapped and tested ok but I'm holding off until you confirm 
> it's
> not the reason for the issue you see.
> 
I can confirm, that indeed patch fixed this bug.
Yes patch bootstrapped and cross compiled and compiled the cross compiler and
native compiler ok, what I meant was this patch actually causes another new
regression/issues to surface. I am using the 64-bit x86_64-w64-mingw32-g++
binary on windows to compile qt4 what is happening now is that it will compile
qmake.exe just fine. As soon as qmake.exe is run ie, "qmake.exe
qt-all-opensource-src-4.5.2/src/plugins/accessible/widgets/widgets.pro  -o
Makefile -spec win32-g++" it crashes.
It should be another issue, should I make another bug report then?
You can close this bug as resolved.


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[rguenther at suse dot de]

--- Comment #19 from rguenther at suse dot de  2009-09-06 22:02 ---
Subject: Re:  [4.5 Regression] crashed compile Qt4 gui
 library

On Sun, 6 Sep 2009, t7 at gmail dot com wrote:

> --- Comment #18 from t7 at gmail dot com  2009-09-06 21:59 ---
> (In reply to comment #17)
> > The patch bootstrapped and tested ok but I'm holding off until you confirm 
> > it's
> > not the reason for the issue you see.
> > 
> I can confirm, that indeed patch fixed this bug.
> Yes patch bootstrapped and cross compiled and compiled the cross compiler and
> native compiler ok, what I meant was this patch actually causes another new
> regression/issues to surface. I am using the 64-bit x86_64-w64-mingw32-g++
> binary on windows to compile qt4 what is happening now is that it will compile
> qmake.exe just fine. As soon as qmake.exe is run ie, "qmake.exe
> qt-all-opensource-src-4.5.2/src/plugins/accessible/widgets/widgets.pro  -o
> Makefile -spec win32-g++" it crashes.
> It should be another issue, should I make another bug report then?
> You can close this bug as resolved.

Well, the patch may cause this issue, no?  Before the patch qmake
didn't build?  So I asked you to fix this bug by increasing the
maximum stack size and not by applying the patch to see if the patch
causes the qmake issue.

Or is there a reason the patch can't be the reason for the qmake failure?

Richard.


-- 


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

[Bug libstdc++/41280] [4.5 Regression] Revision 151352 breaks 32bit libstdc++

[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=41280

[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373

[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=41245

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[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=41224

[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()

[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=41214

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #20 from t7 at gmail dot com  2009-09-06 22:14 ---
(In reply to comment #16)
> Try building without the patch but with unlimited stack (ulimit -s unlimited)
> and see if the same error appears.
> 

Actually can't try this because I'm using the native compiler to build qt4.(In
reply to comment #19)
> Subject: Re:  [4.5 Regression] crashed compile Qt4 gui
>  library
> 
> On Sun, 6 Sep 2009, t7 at gmail dot com wrote:
> 
> > --- Comment #18 from t7 at gmail dot com  2009-09-06 21:59 ---
> > (In reply to comment #17)
> > > The patch bootstrapped and tested ok but I'm holding off until you 
> > > confirm it's
> > > not the reason for the issue you see.
> > > 
> > I can confirm, that indeed patch fixed this bug.
> > Yes patch bootstrapped and cross compiled and compiled the cross compiler 
> > and
> > native compiler ok, what I meant was this patch actually causes another new
> > regression/issues to surface. I am using the 64-bit x86_64-w64-mingw32-g++
> > binary on windows to compile qt4 what is happening now is that it will 
> > compile
> > qmake.exe just fine. As soon as qmake.exe is run ie, "qmake.exe
> > qt-all-opensource-src-4.5.2/src/plugins/accessible/widgets/widgets.pro  -o
> > Makefile -spec win32-g++" it crashes.
> > It should be another issue, should I make another bug report then?
> > You can close this bug as resolved.
> 
> Well, the patch may cause this issue, no?
yes
>  Before the patch qmake
> didn't build?
no. Before the patch qmake was built and running ok.
>  So I asked you to fix this bug by increasing the
> maximum stack size and not by applying the patch to see if the patch
> causes the qmake issue.
Well I think we have some misunderstanding here, initially it is cc1plus.exe
that crash g++ (native) built the
qt4 - qmake.exe  ok
- qt4 src/core   ok
- qt4 src/guifailed (cc1plus.exe crashed)

> 
> Or is there a reason the patch can't be the reason for the qmake failure?
I think the patch should be the reason for qmake crash, but, before the patch I
tested with gcc revision 151400, now with gcc revision 151458 + patch applied.
Could this be the reason?


-- 


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

[Bug regression/41204] [4.4/4.5 regression] worse code generated compared to GCC 4.3.2

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.2


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

[Bug target/40977] [4.3/4.4/4.5 regression] problem with code like this: res = ((uint64_t)resh << 32) | resl;

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.5


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

[Bug middle-end/40106] [4.4/4.5 Regression] Time increase for the Polyhedron test air.f90 due to bad optimization

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.2


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[rguenth at gcc dot gnu dot org]

--- Comment #21 from rguenth at gcc dot gnu dot org  2009-09-06 22:19 
---
Yes, that could be the reason.  Can you test the same revision without the
patch again?


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #22 from t7 at gmail dot com  2009-09-06 22:20 ---
(In reply to comment #16)
> Try building without the patch but with unlimited stack (ulimit -s unlimited)
> and see if the same error appears.
> 

You mean cross compile the "native compiler" from linux by setting the shell
with command "ulimit -s unlimited" ?
Or you want me to build the cross compiler and native compiler then try and
build qt4?


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #23 from t7 at gmail dot com  2009-09-06 22:21 ---
(In reply to comment #16)
> Try building without the patch but with unlimited stack (ulimit -s unlimited)
> and see if the same error appears.
> 
This is under MSys/Mingw shell
$ ulimit -s unlimited
sh: ulimit: stack size: cannot modify limit: Invalid argument


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[rguenther at suse dot de]

--- Comment #24 from rguenther at suse dot de  2009-09-06 22:22 ---
Subject: Re:  [4.5 Regression] crashed compile Qt4 gui
 library

On Sun, 6 Sep 2009, t7 at gmail dot com wrote:

> 
> 
> --- Comment #22 from t7 at gmail dot com  2009-09-06 22:20 ---
> (In reply to comment #16)
> > Try building without the patch but with unlimited stack (ulimit -s 
> > unlimited)
> > and see if the same error appears.
> > 
> 
> You mean cross compile the "native compiler" from linux by setting the shell
> with command "ulimit -s unlimited" ?
> Or you want me to build the cross compiler and native compiler then try and
> build qt4?

Just the same way as you reported the bug (I understand that this
was a native compiler issue?).  There surely must be a way to increase
the maximum stack size with windows?

Richard.


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #25 from t7 at gmail dot com  2009-09-06 22:27 ---
(In reply to comment #21)
> Yes, that could be the reason.  Can you test the same revision without the
> patch again?
> 

Ok there maybe a reason for qmake.exe crash, during the process, I changed the
O flag for building the qt4 library (before the patch in my script for building
qt4 -O0 due to that it will g++ will ICE see
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41153)) After the patch I changed
that from -O0 to -O2 and for qmake.exe changed from -O0 (I had to do this or
g++ will ICE) back to -O (original) because I thought that pr41153 does not
affect the gcc-trunk 4.5


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #26 from t7 at gmail dot com  2009-09-06 22:30 ---
(In reply to comment #24)

> Just the same way as you reported the bug (I understand that this
> was a native compiler issue?).  There surely must be a way to increase
> the maximum stack size with windows?
Yes this was native compiler issue.
I have no idea on how to increase the max stack size with windows..


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #27 from t7 at gmail dot com  2009-09-06 22:41 ---
Ok I just found out that it is the -O and up causing the problem, I just
changed script back to -O0 and it compiles and runs fine, right now up to
corelib.


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #28 from t7 at gmail dot com  2009-09-06 22:43 ---
Thank you for the help, this bug can be close.


-- 


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

[Bug middle-end/41254] [4.5 Regression] crashed compile Qt4 gui library

[t66667 at gmail dot com]

--- Comment #29 from t7 at gmail dot com  2009-09-06 22:55 ---
Confirmed that qt4 library build was complete with -O0.


-- 


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

[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318

[rguenth at gcc dot gnu dot org]

--- Comment #29 from rguenth at gcc dot gnu dot org  2009-09-06 22:59 
---
Fixed as of comment #25.

For the remaining see PR41237.


-- 

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=41224

[Bug bootstrap/41237] [4.5 Regression] Bootstrap failure on powerpc-apple-darwin9 due to a revision between 151343 and 151349

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-09-06 22:59 ---
Fixed.  Please re-open if not.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-06 23:00 ---
Please check again.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c++/41287] New: -O1 optimisation of for loops in some cases omits essential functionality resulting in failed applications

[mhenson at clarityvi dot com]

In the attached standalone test case (depends only on ::memcpy in string.h),
the test fails when compiled with -O1 but succeeds with all other optimisations
(-O0, -O2, -O3).

Files attached:

testOpt.cpp - standalone test with compilation information included in the
file.
testOpt.ii

Below is the stdout/stderr for the compilation:

[mich...@belly gcc_issues]$  g++  -v -save-temps -O1  testOpt.cpp -o testOpt
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i586
--build=i586-redhat-linux
Thread model: posix
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-o' 'testOpt' '-shared-libgcc'
'-mtune=generic' '-march=i586'
 /usr/libexec/gcc/i586-redhat-linux/4.4.1/cc1plus -E -quiet -v -D_GNU_SOURCE
testOpt.cpp -mtune=generic -march=i586 -O1 -fpch-preprocess -o testOpt.ii
ignoring nonexistent directory
"/usr/lib/gcc/i586-redhat-linux/4.4.1/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../i586-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1

/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/i586-redhat-linux
 /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/backward
 /usr/local/include
 /usr/lib/gcc/i586-redhat-linux/4.4.1/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-o' 'testOpt' '-shared-libgcc'
'-mtune=generic' '-march=i586'
 /usr/libexec/gcc/i586-redhat-linux/4.4.1/cc1plus -fpreprocessed testOpt.ii
-quiet -dumpbase testOpt.cpp -mtune=generic -march=i586 -auxbase testOpt -O1
-version -o testOpt.s
GNU C++ (GCC) version 4.4.1 20090725 (Red Hat 4.4.1-2) (i586-redhat-linux)
compiled by GNU C version 4.4.1 20090725 (Red Hat 4.4.1-2), GMP version
4.2.4, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e983968af33489f00d517096be08dea1
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-o' 'testOpt' '-shared-libgcc'
'-mtune=generic' '-march=i586'
 as -V -Qy -o testOpt.o testOpt.s
GNU assembler version 2.19.51.0.14 (i586-redhat-linux) using BFD version
version 2.19.51.0.14-1.fc11 20090722
COMPILER_PATH=/usr/libexec/gcc/i586-redhat-linux/4.4.1/:/usr/libexec/gcc/i586-redhat-linux/4.4.1/:/usr/libexec/gcc/i586-redhat-linux/:/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/:/usr/libexec/gcc/i586-redhat-linux/4.4.1/:/usr/libexec/gcc/i586-redhat-linux/:/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/4.4.1/:/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-o' 'testOpt' '-shared-libgcc'
'-mtune=generic' '-march=i586'
 /usr/libexec/gcc/i586-redhat-linux/4.4.1/collect2 --eh-frame-hdr --build-id -m
elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -o testOpt
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crti.o
/usr/lib/gcc/i586-redhat-linux/4.4.1/crtbegin.o
-L/usr/lib/gcc/i586-redhat-linux/4.4.1 -L/usr/lib/gcc/i586-redhat-linux/4.4.1
-L/usr/lib/gcc/i586-redhat-linux/4.4.1/../../.. testOpt.o -lstdc++ -lm -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i586-redhat-linux/4.4.1/crtend.o
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crtn.o


-- 
   Summary: -O1 optimisation of for loops in some cases omits
essential functionality resulting in failed applications
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mhenson at clarityvi dot com
GCC target triplet: i586-redhat-linux


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

[Bug c++/41287] -O1 optimisation of for loops in some cases omits essential functionality resulting in failed applications

[mhenson at clarityvi dot com]

--- Comment #1 from mhenson at clarityvi dot com  2009-09-07 00:56 ---
Created an attachment (id=18519)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18519&action=view)
standalone test case


-- 


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

[Bug c++/41287] -O1 optimisation of for loops in some cases omits essential functionality resulting in failed applications

[mhenson at clarityvi dot com]

--- Comment #2 from mhenson at clarityvi dot com  2009-09-07 00:56 ---
Created an attachment (id=18520)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18520&action=view)
intermediate files


-- 


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

[Bug c/21759] Implement warning for codes at the intersection of C and C++

[ghazi at gcc dot gnu dot org]

--- Comment #10 from ghazi at gcc dot gnu dot org  2009-09-07 00:59 ---
(In reply to comment #9)
> See this note for some details on the semantics of this warning,
> with respect to keywords:
> http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00808.html

What's the status of this PR?  Are there any issues remaining for completing
-Wc++-compat?


-- 


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

[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)

[ghazi at gcc dot gnu dot org]

--- Comment #27 from ghazi at gcc dot gnu dot org  2009-09-07 01:04 ---
(In reply to comment #25)
> Subject: Bug 34999
> Author: jakub
> Date: Fri Jul 24 23:30:39 2009
> New Revision: 150069
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150069
> Log:
> PR rtl-optimization/34999
> * dwarf2out.c (struct dw_fde_struct): Add dw_fde_switch_cfi
> and dw_fde_switched_cold_to_hot fields.
> (output_cfi_p): New function.
> (output_call_frame_info): If fde->dw_fde_switched_sections,
> output 2 FDEs instead of one with corrupted header.
> (dwarf2out_do_cfi_startproc): New function.
> (dwarf2out_begin_prologue): Use it.  Initialize fde->dw_fde_switch_cfi
> and fde->dw_fde_switched_cold_to_hot.
> (dwarf2out_switch_text_section): Compute
> fde->dw_fde_switched_cold_to_hot.  Switch to new text section here.
> If dwarf2out_do_cfi_asm, emit .cfi_endproc before it and call
> dwarf2out_do_cfi_startproc plus emit again currently active CFI insns.
> Otherwise, compute fde->dw_fde_switch_cfi.
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/dwarf2out.c

Is this patch suitable for 4.4.x?


-- 


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

[Bug c/41288] New: gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

On both x86_64-apple-darwin* and i686-apple-darwin* using -m64, the
gcc.target/x86_64/abi/test_struct_returning.c test cases...

FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3 -g 

started to fail somewhere between 20090425 and 20090516. The failed tests
generate the following warnings...

Executing on host: gcc
/sw/src/fink.build/gcc45-4.4.999-20090516/gcc-4.5-20090516/gcc/testsuite/gcc.target/x86_64/abi/test_struct_returning.c
/sw/src/fink.build/gcc45-4.4.999-20090516/gcc-4.5-20090516/gcc/testsuite/gcc.target/x86_64/abi/asm-support-darwin.s
 -w  -O0  -W -Wall -Wno-abi  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20090516/darwin_objdir/gcc/testsuite/gcc/test_struct_returning.x0
   (timeout = 300)
cc1: warning: command line option "-Wno-abi" is valid for C++/ObjC++ but not
for C
output is:
cc1: warning: command line option "-Wno-abi" is valid for C++/ObjC++ but not
for C

FAIL: gcc.target/x86_64/abi/test_struct_returning.c compilation,  -O0 

These warnings don't appear in the gcc.log of 20090425.


-- 
   Summary: gcc.target/x86_64/abi/test_struct_returning.c
regressions on *-apple-darwin* at -m64
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: x86_64-apple-darwin10
  GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10


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

[Bug c/41288] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2009-09-07 
01:24 ---
The output from 20090425 shows...

Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20090425/gcc-4.5-20090425/gcc/testsuite/gcc.target/x86_64/abi/test_struct_returning.c
/sw/src/fink.build/gcc45-4.4.999-20090425/gcc-4.5-20090425/gcc/testsuite/gcc.target/x86_64/abi/asm-support-darwin.s
 -w  -O0  -W -Wall -Wno-abi  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/testsuite/gcc/test_struct_returning.x0
   (timeout = 300)
PASS: gcc.target/x86_64/abi/test_struct_returning.c compilation,  -O0 
Setting LD_LIBRARY_PATH to
:/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc::/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc
PASS: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O0 

Notice the compiler in the failing case now is only 'gcc' rather than
'/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/xgcc'. This is
probably broken on all platforms but only darwin is revealing the fact that the
test is being done with the system compiler and not the newly built compiler.


-- 


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

[Bug c/41288] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-09-07 
01:33 ---
Ignore the comments on the warnings. This was a glitch from running...

make -k check-gcc
RUNTESTFLAGS="abi-x86_64.exp=gcc.target/x86_64/abi/test_struct_returning.c"

in darwin_objdir which seems to cause the compiler to be incorrectly set. The
bug is in execution.


-- 


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

[Bug c/41289] New: ICE verify_ssa failed building libavformat/oggparseogm.c

[t66667 at gmail dot com]

libavformat/oggparseogm.c: In function 'ogm_header':
libavformat/oggparseogm.c:34:1: error: expected an SSA_NAME object
libavformat/oggparseogm.c:34:1: error: in statement
# DEBUG default_len => ((const struct unaligned_32 *) p + -4)->l
libavformat/oggparseogm.c:34:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [libavformat/oggparseogm.o] Error 1


-- 
   Summary: ICE verify_ssa failed building libavformat/oggparseogm.c
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: t7 at gmail dot com
 GCC build triplet: i486-slackware-linux
  GCC host triplet: x86_64-w64-mingw32
GCC target triplet: x86_64-w64-mingw32


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