[Bug target/48096] gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE fails with Xcode 4.0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2011-03-18 
08:00:08 UTC ---
As the eh_frame section has been invented by GCC, it is weird if the Apple
folks say how it must or must not be defined.  Neither debug_frame in the DWARF
standards have any limitation like that for its FDEs.  So it is just that Apple
linker is buggy and unable to handle sane things and they are unwilling to fix
it.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2011-03-18 
08:10:02 UTC ---
That's something that has been fixed in PR26208 by adding S modifier for signal
frames and introducing _Unwind_GetIPInfo.  So, if Apple unwinder has that
function, it is just a matter of making sure signal frames are marked and such
(or MD_FALLBACK_FRAME_STATE_FOR in the unwinder handles it).
If it doesn't have that entry point and you can't switch to a newer unwinder,
you are out of luck.

[Bug fortran/48174] DWARF for subroutine with no args indicates 'varargs'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-18 
08:18:23 UTC ---
No, I can reproduce it even with current trunk.
It is a FE bug, TYPE_ARG_TYPES on the function which has no arguments (as
opposed to variable number of arguments or unknown) should be void_list_node
rather than NULL.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  2011-03-18 08:32:39 
UTC ---
(In reply to comment #5)
> That's something that has been fixed in PR26208 by adding S modifier for 
> signal
> frames and introducing _Unwind_GetIPInfo.  So, if Apple unwinder has that
> function, it is just a matter of making sure signal frames are marked and such
> (or MD_FALLBACK_FRAME_STATE_FOR in the unwinder handles it).
> If it doesn't have that entry point and you can't switch to a newer unwinder,
> you are out of luck.

Dawin's (Darwin 8, 9) unwinder is essentially from gcc_s at the time the system
was released;
Darwin 10's unwinder does the same as Darwin 9.

we have _Unwind_GetIPInfo on systems >= Darwin 9.

[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2011-03-18 
08:35:22 UTC ---
Author: jakub
Date: Fri Mar 18 08:35:17 2011
New Revision: 171126

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171126
Log:
PR bootstrap/48161
* expr.c (expand_expr_addr_expr_1): Use simplify_gen_binary
instead of gen_rtx_PLUS if EXPAND_SUM or EXPAND_INITIALIZER.

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

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

[Bug fortran/48174] DWARF for subroutine with no args indicates 'varargs'

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-18 
08:36:50 UTC ---
Well, it means "unprototyped".  Without consulting the DWARF spec
DW_TAG_unspecified_parameters sounds like it would match that.

But yes, ISTR filing a bug about this FE issue at some point.

[Bug debug/48176] .debug_aranges is no longer emitted

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-18 
08:38:39 UTC ---
elfutils should be more forgiving

[Bug debug/48176] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-03-18 
08:43:35 UTC ---
See PR46704.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-03-18 
08:53:03 UTC ---
Looking at gcc-4.2, there is no darwin MD_FALLBACK_FRAME_STATE_FOR for i?86 and
for powerpc it doesn't call _Unwind_SetSignalFrame (xxx, 1) unlike e.g. linux
MD_FALLBACK_FRAME_STATE_FOR.  Apparently that state didn't change even in 4.7,
but if nothing uses the gcc unwinder, all that matters for darwin is whether
Apple unwinder gets fixed.

[Bug bootstrap/47016] bootstrap on darwin needs much more disk space than expected to complete

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target||*-apple-darwin*
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.18 08:54:44
 CC||iains at gcc dot gnu.org,
   ||mrs at gcc dot gnu.org
   Host||*-apple-darwin*
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1
  Build||*-apple-darwin*

--- Comment #2 from Iain Sandoe  2011-03-18 08:54:44 
UTC ---
(In reply to comment #1)
> The same occurs with GCC 4.6.0 RC 20110314.

At present, we don't have a suitable strip tool that works for debug across all
darwin variants.  The system tools only guarantee to work with the output of
the system compilers.

It is a compromise to use ld for this with later dwarf debug information (and
the set of flags used - see contrib/compare-debug).   However, the stripping of
the symbols forces the .zerofill section used for PCH to be represented as real
bytes in the stripped object (since .zerofill sections contain their symbol).

It's on the TODO to find a better way (this is a nuisance both in disk space
and in time taken).

[Bug debug/48176] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-03-18 
09:00:59 UTC ---
I believe Eric's change was wrong actually, .debug_aranges section has useful
content even when !arange_table_in_use.  In particular, it describes .text and
.text.unlikely sections.

So IMHO we want:

--- gcc/dwarf2out.c2011-03-17 12:54:51.0 +0100
+++ gcc/dwarf2out.c2011-03-18 09:58:06.010366417 +0100
@@ -23664,7 +23664,7 @@ dwarf2out_finish (const char *filename)

   /* Output the address range information.  We only put functions in the
arange
  table, so don't write it out if we don't have any.  */
-  if (arange_table_in_use)
+  if (arange_table_in_use || text_section_used || cold_text_section_used)
 {
   switch_to_section (debug_aranges_section);
   output_aranges ();

I assume .debug_aranges isn't useful when no code has been emitted and after
all, we haven't been emitting it before either.  I'm unsure when exactly
would be fde_table_in_use different from
arange_table_in_use || text_section_used || cold_text_section_used
though.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.18 09:01:37
   Target Milestone|--- |4.6.0
Summary|.debug_aranges is no longer |[4.6/4.7 Regression]
   |emitted |.debug_aranges is no longer
   ||emitted
 Ever Confirmed|0   |1

[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2011-03-18 
09:04:35 UTC ---
Author: jakub
Date: Fri Mar 18 09:04:31 2011
New Revision: 171127

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171127
Log:
PR bootstrap/48161
* expr.c (expand_expr_addr_expr_1): Use simplify_gen_binary
instead of gen_rtx_PLUS if EXPAND_SUM or EXPAND_INITIALIZER.

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

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr48161.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/expr.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-03-18 
09:08:41 UTC ---
And the PR42288 variant would be 
  if (info_section_emitted)
{
  switch_to_section (debug_aranges_section);
  output_aranges ();
}

[Bug bootstrap/48161] [4.6 regression] hppa*-*-* will not bootstrap on 4.6 branch with release checking

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #17 from Jakub Jelinek  2011-03-18 
09:18:01 UTC ---
Fixed.  Please retest, as the committed patch is slightly different from the
earlier version.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-03-18 
09:20:37 UTC ---
I've tried a-charac.ads and fde_table_in_use is 0 in that case, so I wonder how
the PR46704 patch could stop emitting .debug_aranges in that case (unless there
was some bug that has been fixed since then).

[Bug tree-optimization/48170] ICE: in hoist_code, at gcse.c:4524 with -fgcse --param max-hoist-depth={0,1}

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.18 09:28:02
 Ever Confirmed|0   |1

--- Comment #1 from Maxim Kuvyrkov  2011-03-18 
09:28:02 UTC ---
Mine.

The asserts should definitely say (MAX_HOIST_DEPTH == 0 || MAX_HOIST_DEPTH >
1).  I will need to investigate why this is failing for depth == 1.

[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.4.4
   Keywords||wrong-code
   Last reconfirmed||2011.03.18 09:29:27
 Ever Confirmed|0   |1
Summary|incorrect vectorization of  |[4.5/4.6/4.7 Regression]
   |loop in GCC 4.5.* with -O3  |incorrect vectorization of
   ||loop in GCC 4.5.* with -O3
   Target Milestone|--- |4.5.3
  Known to fail||4.5.0, 4.5.2, 4.6.0, 4.7.0

--- Comment #1 from Richard Guenther  2011-03-18 
09:29:27 UTC ---
Not vectorized on the 4.4 branch because of

t.c:23: note: not vectorized: unsupported unaligned store.
t.c:16: note: vect_model_induction_cost: inside_cost = 6, outside_cost = 4 .
t.c:16: note: not vectorized: relevant stmt not supported: i.16_8 = (uint32_t)
i_60;


Confirmed.

It's not the conversion but the unaligned store it seems, also fails
with 4.5.0.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-03-18 
09:32:13 UTC ---
If we want to be extra safe (and for 4.6 we need to be), I think
  if (fde_table_in_use && info_section_emitted)
or
  if ((arange_table_in_use || text_section_used || cold_text_section_used)
  && info_section_emitted)
are the conditions to use.  I think I prefer the latter, which is more explicit
on what it is testing, in particular output only if there will be any aranges
within the section actually emitted, and when there is a .Ldebug_info0 to point
the aranges to.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2011-03-18 
09:34:48 UTC ---
> I've tried a-charac.ads and fde_table_in_use is 0 in that case, so I wonder 
> how
> the PR46704 patch could stop emitting .debug_aranges in that case (unless 
> there
> was some bug that has been fixed since then).

You need to compile with -fkeep-inline-functions.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2011-03-18 
09:45:45 UTC ---
Thanks, I see.  fde_table_in_use is 2 then, arange_table_in_use is 0,
text_section_used 0 and cold_text_section_used 0.  So, the #c5 and both #c8
alternatives would fix this issue and not reintroduce the problem with
a-charac.ads -O2 -g -fkeep-inline-functions.
The only two functions in that CU are DECL_IGNORED, so begin_function debug
hook isn't called for them, just begin_prologue, and as the CU is empty
(DECL_IGNORED function are ignored for debug info) .debug_info isn't emitted
either.

[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-03-18 
09:48:39 UTC ---
(compute_affine_dependence
  (stmt_a =
D.3677_12 = array[D.3676_11];
)
  (stmt_b =
array[D.3675_10] = D.3680_16;
)
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = {0, +, 2}_2)
  (chrec_b = {514, +, 1}_2)
(analyze_siv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = [257 + 1 * x_1]
)
  (overlaps_b = [0 + 2 * x_1]
)
)
)
  (overlap_iterations_a = [257 + 1 * x_1]
)
  (overlap_iterations_b = [0 + 2 * x_1]
)
)
(Dependence relation cannot be represented by distance vector.)
)
(compute_affine_dependence
  (stmt_a =
D.3679_15 = array[D.3678_14];
)
  (stmt_b =
array[D.3675_10] = D.3680_16;
)
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = {1, +, 2}_2)
  (chrec_b = {514, +, 1}_2)
(analyze_siv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = [257 + 1 * x_1]
)
  (overlaps_b = [1 + 2 * x_1]
)
)
)
  (overlap_iterations_a = [257 + 1 * x_1]
)
  (overlap_iterations_b = [1 + 2 * x_1]
  (overlap_iterations_b = [1 + 2 * x_1]
)
)
(Dependence relation cannot be represented by distance vector.)
)
)

...

t.c:23: note: versioning for alias required: bad dist vector for
array[D.3676_11] and array[D.3675_10]
t.c:23: note: mark for run-time aliasing test between array[D.3676_11] and
array[D.3675_10]
t.c:23: note: versioning for alias required: bad dist vector for
array[D.3678_14] and array[D.3675_10]
t.c:23: note: mark for run-time aliasing test between array[D.3678_14] and
array[D.3675_10]

and the alias check looks like

  vect_parray.14_32 = &array;
  vect_parray.17_31 = &array[514];
  D.3707_29 = vect_parray.14_32 + 32;
  D.3708_28 = D.3707_29 < vect_parray.17_31;
  D.3709_63 = vect_parray.17_31 + 16;
  D.3710_64 = D.3709_63 < vect_parray.14_32;
  D.3711_65 = D.3708_28 || D.3710_64;
  D.3713_78 = !D.3711_65;
  if (D.3713_78 != 0)
goto ;
  else
goto ;

which doesn't at all test something sensible.

Shortened non-runtime testcase:

#define ASIZE 1028
#define HALF (ASIZE/2)
unsigned int array[ASIZE];

void foo(void)
{
  int i;
  for (i = 0; i < HALF-1; i++)
array[HALF+i] = array[2*i] + array[2*i + 1];
}

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  2011-03-18 
09:51:26 UTC ---
> Thanks, I see.  fde_table_in_use is 2 then, arange_table_in_use is 0,
> text_section_used 0 and cold_text_section_used 0.  So, the #c5 and both #c8
> alternatives would fix this issue and not reintroduce the problem with
> a-charac.ads -O2 -g -fkeep-inline-functions.

What about testing ranges_by_label_in_use instead?

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-03-18 
09:56:33 UTC ---
That is related to .debug_ranges, not .debug_aranges.
E.g. in the int main () { return 0; } case ranges_by_label_in_use is 0, not
surprisingly, we don't emit .debug_ranges in that case.  .debug_ranges is only
needed if some function or lexical block or inlined function doesn't have a
single range, but multiple ones.

[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2011-03-18 
10:00:34 UTC ---
Versioning for alias only seems to consider the case that DR_STEP is the
same for all DRs, right?

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   (revision 171097)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -528,6 +528,14 @@ vect_mark_for_runtime_alias_test (ddr_p
   print_generic_expr (vect_dump, DR_REF (DDR_B (ddr)), TDF_SLIM);
 }

+  if (!operand_equal_p (DR_STEP (DDR_A (ddr)), DR_STEP (DDR_B (ddr)), 0))
+{
+  if (vect_print_dump_info (REPORT_DR_DETAILS))
+   fprintf (vect_dump, "versioning not supported for accesses with "
+"different step.");
+  return false;
+}
+
   if (optimize_loop_nest_for_size_p (loop))
 {
   if (vect_print_dump_info (REPORT_DR_DETAILS))

fixes it for me.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  2011-03-18 
10:05:32 UTC ---
> That is related to .debug_ranges, not .debug_aranges.

Ah, OK.  Your solution:

  (arange_table_in_use || text_section_used || cold_text_section_used)

seems indeed to be the best one, you might even want to write it as:

  (text_section_used || cold_text_section_used || arange_table_in_use)

to match the layout of output_aranges.  Thanks for debugging this.

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-18 
10:34:16 UTC ---
Started with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164552

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-18 
10:50:29 UTC ---
The problem is not in %rdx, but %rsi.  It was originally initialized from %rbx
right before the call, but now is the %rsi assignment moved before the testing
of the j && equals (i, j) condition, which is wrong, because %rsi is call
clobbered and thus potentionally clobbered by the call, and more importantly
even set right before the call to equals function.

[Bug rtl-optimization/48170] ICE: in hoist_code, at gcse.c:4524 with -fgcse --param max-hoist-depth={0,1}

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization

--- Comment #2 from Maxim Kuvyrkov  2011-03-18 
10:57:25 UTC ---
The asserts are bogus, they probably used to verify an invariant that was
removed by a later improvement.  Will check in a fix soon.

[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-03-18 
11:57:11 UTC ---
The patch FAILs

FAIL: gcc.dg/vect/pr37539.c scan-tree-dump-times vect "vectorized 1 loops" 2
FAIL: gcc.dg/vect/pr43432.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1
l
oops" 2
FAIL: gcc.dg/vect/vect-multitypes-12.c scan-tree-dump-times vect "vectorized 1
l
oops" 2
FAIL: gcc.dg/vect/vect-multitypes-16.c scan-tree-dump-times vect "vectorized 1
l
oops" 1

on x86_64.  I can't see how the alias check is ok for pr37539.c given that
we could call ayuv2yuyv_ref with &d[0], &d[4].  Similar for pr43432.c.
For vect-multitypes-11.c type-based aliasing should handle the case
instead of

/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-11.c:14:
note: versioning for alias required: can't determine dependence between x[i_16]
and MEM[(int *)D.3264_7]

not sure why this doesn't happen.  For -fno-strict-aliasing the runtime test
looks bogus as well.  vect-multitypes-12.c and vect-multitypes-16.c look
similar
(but as character types are involved TBAA doesn't help and the vectorization
does not appear to be safe).

In particular for all tests the segment size we use for the alias tests
is not enough for data-refs with differing DR_STEP.  It would need to
take the number of iterations into account.

[Bug debug/48178] New: ICE in dwarf2out_var_location, at dwarf2out.c:21969

[kkojima at gcc dot gnu.org]

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

   Summary: ICE in dwarf2out_var_location, at dwarf2out.c:21969
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kkoj...@gcc.gnu.org


On SH, gcc.c-torture/compile/sync-2.c fails with

  internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21969

It seems that dwarf2out_var_location assumes the previous insn
of the loc_note insn is a call or sequence insn, but for
the problematic case, it's an unspec insn for the constant pool:

(gdb) call debug_rtx(prev)
(insn 603 602 604 (unspec_volatile [
(const_int 0 [0])
] 11) 295 {consttable_end}
 (nil))

at the failed gcc_assert

21965  gcc_assert (prev
21966  && (CALL_P (prev)
21967  || (NONJUMP_INSN_P (prev)
21968  && GET_CODE (PATTERN (prev)) == SEQUENCE
21969  && CALL_P (XVECEXP (PATTERN (prev), 0, 0);

The patch below looks to work for me, though I'm not sure that
it's the right thing to do.

--- ORIG/trunk/gcc/dwarf2out.c2011-03-17 09:06:42.0 +0900
+++ LOCAL/trunk/gcc/dwarf2out.c2011-03-17 13:03:39.0 +0900
@@ -21962,11 +21962,17 @@ dwarf2out_var_location (rtx loc_note)
   ca_loc->call_arg_loc_note = loc_note;
   ca_loc->next = NULL;
   ca_loc->label = last_label;
-  gcc_assert (prev
-  && (CALL_P (prev)
-  || (NONJUMP_INSN_P (prev)
-  && GET_CODE (PATTERN (prev)) == SEQUENCE
-  && CALL_P (XVECEXP (PATTERN (prev), 0, 0);
+  while (prev)
+{
+  if (CALL_P (prev)
+  || (NONJUMP_INSN_P (prev)
+  && GET_CODE (PATTERN (prev)) == SEQUENCE
+  && CALL_P (XVECEXP (PATTERN (prev), 0, 0
+break;
+  else
+prev = prev_real_insn (prev);
+}
+  gcc_assert (prev);
   if (!CALL_P (prev))
 prev = XVECEXP (PATTERN (prev), 0, 0);
   ca_loc->tail_call_p = SIBLING_CALL_P (prev);

[Bug target/48171] Missing "Save" on -mavx and -mfma

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  2011-03-18 
12:42:29 UTC ---
Author: hjl
Date: Fri Mar 18 12:42:24 2011
New Revision: 171135

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171135
Log:
Add Save to -mavx and -mfma.

2011-03-18  H.J. Lu  

Backport from mainline
2011-03-17  H.J. Lu  

PR target/48171
* config/i386/i386.opt: Add Save to -mavx and -mfma.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/i386.opt

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||bonzini at gnu dot org

--- Comment #4 from Jakub Jelinek  2011-03-18 
12:42:33 UTC ---
The problem is that try_head_merge_bb uses DF info that isn't up to date after
previous crossjumping and hasn't been updated yet.

In particular when we compute live_union, one merge_bb is:
;; basic block 4, loop depth 0, count 0
;; prev block 3, next block 5
;; pred:   3 [20.7%]  (fallthru)
;; succ:   7 [100.0%] 
;; bb 4 artificial_defs: { }
;; bb 4 artificial_uses: { u-1(7){ }}
;; lr  in   3 [bx] 7 [sp]
;; lr  use  3 [bx] 7 [sp]
;; lr  def  0 [ax] 1 [dx] 2 [cx] 4 [si] 5 [di] 8 [st] 9 [st(1)] 10 [st(2)]
11 [st(3)] 12 [st(4)] 13 [st(5)] 14 [st(6)] 15 [st(7)] 17 [flags] 18 [fpsr] 19
[fpcr] 21 [xmm0] 22 [xmm1] 23 [xmm2] 24 [xmm3] 25 [xmm4] 26 [xmm5] 27 [xmm6] 28
[xmm7] 29 [mm0] 30 [mm1] 31 [mm2] 32 [mm3] 33 [mm4] 34 [mm5] 35 [mm6] 36 [mm7]
37 [r8] 38 [r9] 39 [r10] 40 [r11] 45 [xmm8] 46 [xmm9] 47 [xmm10] 48 [xmm11] 49
[xmm12] 50 [xmm13] 51 [xmm14] 52 [xmm15]

(note 24 23 25 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 25 24 26 4 (set (reg:SI 4 si)
(reg/v:SI 3 bx [orig:59 i ] [59])) pr48156.c:31 64 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:SI 3 bx [orig:59 i ] [59])
(nil)))
(insn 26 25 62 4 (set (reg:SI 5 di)
(const_int 8 [0x8])) pr48156.c:31 64 {*movsi_internal}
 (nil))
(jump_insn 62 26 63 4 (set (pc)
(label_ref 61)) -1
 (nil)
 -> 61)
;; lr  out  7 [sp]

where lr_out is obviously wrong, lr out should also include 4 [si] 5 [di].
That lr_out comes from the bb that originally also included the call to baz
which consumed and made dead those two registers.  The other merge_bb has
exactly the same problem.  bb 7 (the new bb which contains just the call to
baz)
has lr in/use/def/out all empty.

So I guess we need to tell DF to recompute it after each successful
crossjumping or recompute it somehow manually.

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-03-18 
12:45:35 UTC ---
Steven, sorry for looking at a bug you have assigned, I've been just curious
(especially in the light if it should be a 4.6 blocker or not).
I'll leave you DF folks now to sort it out.

[Bug target/48171] Missing "Save" on -mavx and -mfma

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  2011-03-18 
12:47:40 UTC ---
Author: hjl
Date: Fri Mar 18 12:47:37 2011
New Revision: 171136

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171136
Log:
Add Save to -mavx and -mfma.

2011-03-18  H.J. Lu  

Backport from mainline
2011-03-17  H.J. Lu  

PR target/48171
* config/i386/i386.opt: Add Save to -mavx and -mfma.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.opt

[Bug target/48171] Missing "Save" on -mavx and -mfma

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.3

--- Comment #5 from H.J. Lu  2011-03-18 12:48:19 
UTC ---
Fixed.

[Bug other/48179] New: Reference mismatch in documentation chapter 6

[Denis.Excoffier at airbus dot com]

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

   Summary: Reference mismatch in documentation chapter 6
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: denis.excoff...@airbus.com


Bug in documentation presentation.

You can also try this under http://gcc.gnu.org/onlinedocs/gcc/

Jump to 6.37 "Specifying Attributes of Variables"
Click Next, you land on 6.38 "Specifying Attributes of Types". Fine.
Click Next, you land on 6.36 "Inquiring on Alignment of Types or Variables".
Strange.
Click Next, you land on 6.39 "An Inline Function Is...".

The table of content seems correct.

Also, on my texinfo gcc.info data base (from GCC 4.6.0 RC 20110314), but
not on onlinedocs, the reference (* note Variable Attributes::)
jumps to 6.37.1 "Blackfin Variable Attributes" instead
of 6.37.

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-03-18 
13:32:13 UTC ---
Actually, I think the bug is in df_get_bb_dirty:

--- gcc/df-core.c.jj2010-12-14 08:11:39.0 +0100
+++ gcc/df-core.c2011-03-18 14:22:43.0 +0100
@@ -1400,10 +1400,16 @@ df_mark_solutions_dirty (void)
 bool
 df_get_bb_dirty (basic_block bb)
 {
-  if (df && df_live)
-return bitmap_bit_p (df_live->out_of_date_transfer_functions, bb->index);
-  else
-return false;
+  if (df)
+{
+  if (df_live)
+return bitmap_bit_p (df_live->out_of_date_transfer_functions,
+ bb->index);
+  else if (df_lr)
+return bitmap_bit_p (df_lr->out_of_date_transfer_functions,
+ bb->index);
+}
+  return false;
 }

Both ifcvt.c and cfgcleanup.c via simulate_backwards_to_point call and use
df_get_live_{in,out} (), which is:
  if (df_live)
return DF_LIVE_OUT (bb);
  else
return DF_LR_OUT (bb);
On this testcase, df_live is NULL during crossjumping, so df_get_bb_dirty
always returns false, even when the solution it is using is dirty.  With the
patch above cfgcleanup.c does the right thing, bails out from the merging when
it is dirty and will df_analyze () afterwards and loop (as the dirtyness was
caused by changes).

[Bug other/48179] Reference mismatch in documentation chapter 6

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.18 13:37:45
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-03-18 
13:37:45 UTC ---
confirmed, the @menu at the start of extend.texi lists the sections in a
different order to the order the @sections actually appear:

* Variable Attributes:: Specifying attributes of variables.
* Type Attributes:: Specifying attributes of types.
* Alignment::   Inquiring about the alignment of a type or variable.
* Inline::  Defining inline functions (as fast as macros).

[Bug lto/48180] New: '-fuse-linker-plugin' doesn't work.

[henry0312 at gmail dot com]

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

   Summary: '-fuse-linker-plugin' doesn't work.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: henry0...@gmail.com


I compiled gcc version 4.6.0 20110314 (prerelease) on Mac OS X 10.6.6.

configure options:
./configure\
--build=x86_64-apple-darwin10\
--disable-debug\
--disable-multilib\
--enable-threads=posix\
--disable-bootstrap\
--enable-version-specific-runtime-libs\
--enable-languages=c,c++,objc,obj-c++\
--enable-stage1-checking\
--disable-nls\
--enable-werror\
--enable-lto\
--enable-gold\
--enable-ld\
--with-system-zlib\
--enable-fully-dynamic-string

And then,
following explanation of '-flto' (
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Optimize-Options.html#Optimize-Options
),
I tested my gcc.

$ gcc -flto -c a.c
$ gcc -flto -c b.c
$ gcc -o test -O2 -flto -fuse-linker-plugin a.o b.o
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

a.c and b.c --> http://www.privatepaste.com/34b31b77a5

My compiling environment:
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
gmp-5.0.1
mpfr-3.0.0
mpc-0.9

[Bug middle-end/47790] [4.5/4.6/4.7 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  2011-03-18 14:01:47 
UTC ---
Author: law
Date: Fri Mar 18 14:01:41 2011
New Revision: 171139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171139
Log:
PR middle-end/47790
* expr.c (optimize_bitfield_assignment_op): Revamp to work
again after expansion changes.



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

[Bug middle-end/47790] [4.5/4.6/4.7 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jeffrey A. Law  2011-03-18 14:03:00 
UTC ---
Patch installed after minor formatting and comment tweaks.

[Bug middle-end/47405] gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2011-03-18 14:10:41 UTC 
---
Author: ro
Date: Fri Mar 18 14:10:35 2011
New Revision: 171140

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171140
Log:
PR middle-end/47405
* gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/20090618-1.c

[Bug middle-end/47405] gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2011-03-18 14:13:37 UTC 
---
Author: ro
Date: Fri Mar 18 14:13:32 2011
New Revision: 171141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171141
Log:
PR middle-end/47405
* gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.

Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/20090618-1.c

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-03-18 
14:14:15 UTC ---
Another option is:

--- gcc/combine-stack-adj.c2010-12-02 11:51:32.0 +0100
+++ gcc/combine-stack-adj.c2011-03-18 15:12:09.497674812 +0100
@@ -551,7 +551,16 @@ gate_handle_stack_adjustments (void)
 static unsigned int
 rest_of_handle_stack_adjustments (void)
 {
-  cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
+  if (flag_crossjumping && optimize <= 1)
+{
+  df_live_add_problem ();
+  df_live_set_all_dirty ();
+  df_analyze ();
+  cleanup_cfg (CLEANUP_CROSSJUMP);
+  df_remove_problem (df_live);
+}
+  else
+cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);

   /* This is kind of a heuristic.  We need to run combine_stack_adjustments
  even for machines with possibly nonzero TARGET_RETURN_POPS_ARGS

ifcvt.c already does something similar, so the df_get_bb_dirty calls it does
always return whether the bb is dirty in df_live.

[Bug target/48180] '-fuse-linker-plugin' doesn't work.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin10
  Component|lto |target

--- Comment #1 from Richard Guenther  2011-03-18 
14:15:45 UTC ---
LTO is not enabled by default on x86_64-apple-darwin10 and the apple linker
does not support a linker plugin compatible with LTO.

But yes, the error message could be improved to state this (no plugin
compatible linker available) instead of complaining the way it does.

[Bug middle-end/47790] [4.5/4.6/4.7 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.5.3   |4.7.0

[Bug middle-end/47405] gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  2011-03-18 14:18:04 UTC 
---
Author: ro
Date: Fri Mar 18 14:17:58 2011
New Revision: 171142

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171142
Log:
PR middle-end/47405
* gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/20090618-1.c

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[henry0312 at gmail dot com]

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

henry0312 at gmail dot com changed:

   What|Removed |Added

  Component|target  |lto

--- Comment #2 from henry0312 at gmail dot com 2011-03-18 14:28:04 UTC ---
(In reply to comment #1)
> LTO is not enabled by default on x86_64-apple-darwin10 and the apple linker
> does not support a linker plugin compatible with LTO.
> 
> But yes, the error message could be improved to state this (no plugin
> compatible linker available) instead of complaining the way it does.


Should 'liblto_plugin.so' exist indeed?
Is this file created when compile gcc?

And If I compile binutils, will I be able to use '-fuse-linker-plugin'?

[Bug rtl-optimization/48143] [4.6/4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7114 with custom flags

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #2 from Andrey Belevantsev  2011-03-18 
14:35:30 UTC ---
We ICE because we again issue more than issue_rate insns.  And this happens
because we hit an insn which does not modify the DFA state at all, thus we do
not account for it when checking that we obey issue_rate limits.  The insn is
coming from sse2_cvtps2pd pattern of sse.md and it doesn't have a reservation
(has "nothing").

I don't have any idea how the pattern attributes should be fixed, but the
following seems to work on the test case.  Uros, does this make sense?


diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index ba2bf24..71c4bb7 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2878,6 +2878,7 @@
(set_attr "prefix" "maybe_vex")
(set_attr "mode" "V2DF")
(set_attr "prefix_data16" "0")
+   (set_attr "athlon_decode" "double")
(set_attr "amdfam10_decode" "direct")
(set_attr "bdver1_decode" "double")])

[Bug libobjc/48177] incorrect registration of typed selectors

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #1 from Nicola Pero  2011-03-18 14:36:50 
UTC ---
Good point.  Are you thinking of differences caused by protocol qualifiers,
or by argframe layout information ?

Thanks

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-18 
14:38:26 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > LTO is not enabled by default on x86_64-apple-darwin10 and the apple linker
> > does not support a linker plugin compatible with LTO.
> > 
> > But yes, the error message could be improved to state this (no plugin
> > compatible linker available) instead of complaining the way it does.
> 
> 
> Should 'liblto_plugin.so' exist indeed?
> Is this file created when compile gcc?

I think it should exist, it is built and installed unconditionally.  See
the lto-plugin/ directory in your toplevel build directory.

> And If I compile binutils, will I be able to use '-fuse-linker-plugin'?

No, upstream GNU binutils do not have complete support for Mach-O.

[Bug rtl-optimization/48181] New: [4.5/4.6/4.7 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6/4.7 Regression] wrong code with -O -fgcse
--param ira-max-conflict-table-size=0
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: ja...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Output:
$ gcc -O -fgcse --param ira-max-conflict-table-size=0 testcase.c
$ valgrind -q ./a.out 
==11903== Invalid read of size 8
==11903==at 0x4C2B44C: memcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11903==by 0x400602: foo (testcase.c:47)
==11903==by 0x4006AA: main (testcase.c:65)
==11903==  Address 0x38 is not stack'd, malloc'd or (recently) free'd

The way it crashes is similiar to PR48156:
...
learcx, [rsp+128]# tmp126,
cmpQWORD PTR [rsp+8], 0# %sfp,
jne.L11#,
movesi, r14d#, qsize
movrdi, rcx#, tmp126
callbar#
.L11:
movrdx, r12#, D.2735
movrsi, rcx#, tmp126 # -fno-gcse: lea rsi, [rsp+128]
leardi, [rsp+64]#,
callmemcpy#
movrdx, r12#, D.2735
movrsi, rcx#, tmp126 # -fno-gcse: lea rsi, [rsp+128]
leardi, [rsp+32]#,
callmemcpy#
...

both calls to memcpy() read rcx to set its parameters, but rcx is not preserved
across function call (changes either by call to bar(), or by first memcpy())

Tested revisions:
r171088 - fail
4.6 r170095 - fail
4.5 r170095 - fail
4.4 r170095 - OK

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-03-18 
14:40:23 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > LTO is not enabled by default on x86_64-apple-darwin10 and the apple 
> > > linker
> > > does not support a linker plugin compatible with LTO.
> > > 
> > > But yes, the error message could be improved to state this (no plugin
> > > compatible linker available) instead of complaining the way it does.
> > 
> > 
> > Should 'liblto_plugin.so' exist indeed?
> > Is this file created when compile gcc?
> 
> I think it should exist, it is built and installed unconditionally.  See
> the lto-plugin/ directory in your toplevel build directory.

I was wrong, lto-plugin only gets built for ELF targets and a small list
of extra targets that does not include x86_64-darwin10

[Bug rtl-optimization/48181] [4.5/4.6/4.7 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3

--- Comment #1 from Richard Guenther  2011-03-18 
14:41:47 UTC ---
I suppose a more reasonable minimum value for this param makes sense ;)

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[henry0312 at gmail dot com]

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

--- Comment #5 from henry0312 at gmail dot com 2011-03-18 14:50:59 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > LTO is not enabled by default on x86_64-apple-darwin10 and the apple 
> > > > linker
> > > > does not support a linker plugin compatible with LTO.
> > > > 
> > > > But yes, the error message could be improved to state this (no plugin
> > > > compatible linker available) instead of complaining the way it does.
> > > 
> > > 
> > > Should 'liblto_plugin.so' exist indeed?
> > > Is this file created when compile gcc?
> > 
> > I think it should exist, it is built and installed unconditionally.  See
> > the lto-plugin/ directory in your toplevel build directory.
> 
> I was wrong, lto-plugin only gets built for ELF targets and a small list
> of extra targets that does not include x86_64-darwin10

OK, I see.

Thank you very much.

[Bug libobjc/48177] incorrect registration of typed selectors

[rfm at gnu dot org]

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

--- Comment #2 from rfm at gnu dot org 2011-03-18 14:58:10 UTC ---
The problem showed up with argframe information in base ... which presumably
means that something in base is getting that wrong :-(

I wonder, could we have a runtime function to take a type encoding without
argframe info, and convert it to one with argframe info using the same
algorithm the compiler uses?  That would avoid us having to do that for
NSMethodSignature in base (and potentially getting it wrong).

[Bug c++/35315] [4.4 regression] ICE with attribute transparent_union

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-03-18 
15:06:47 UTC ---
Author: jason
Date: Fri Mar 18 15:06:41 2011
New Revision: 171145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171145
Log:
PR c++/35315
* c-common.c (handle_transparent_union_attribute): Don't
make a duplicate type in C++.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/attrib32.C

[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value

[jason at gcc dot gnu.org]

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

--- Comment #43 from Jason Merrill  2011-03-18 
15:06:54 UTC ---
Author: jason
Date: Fri Mar 18 15:06:51 2011
New Revision: 171146

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171146
Log:
PR c++/23372
* gimplify.c (gimplify_arg): Strip redundant TARGET_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr23372.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/48162] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-03-18 
15:07:16 UTC ---
Author: jason
Date: Fri Mar 18 15:07:13 2011
New Revision: 171148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171148
Log:
PR c++/48162
* semantics.c (finish_call_expr): Allow TARGET_EXPR for now.

Added:
trunk/gcc/testsuite/g++.dg/template/fn-ptr1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/48118] [4.3/4.4/4.5/4.6/4.7 regression] g++ sometimes allows copying a volatile class

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-03-18 
15:07:09 UTC ---
Author: jason
Date: Fri Mar 18 15:07:04 2011
New Revision: 171147

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171147
Log:
PR c++/48118
* call.c (build_over_call): Don't skip ck_rvalue.

Added:
trunk/gcc/testsuite/g++.dg/overload/volatile1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/48168] [4.7 regression] Solaris 2/SPARC bootstrap broken: ICE in sparc_function_arg_1, at config/sparc/sparc.c:5721

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-18 15:15:21 UTC ---
> --- Comment #1 from Eric Botcazou  2011-03-17 
> 15:21:03 UTC ---
> Duplicate of PR middle-end/48152?

While a C++-only bootstrap indeed completes as of rev 171126, an Ada
bootstrap still fails, but this seems to be a different error.

The failure can be reproduced with

$ gnat1 -quiet -O2 -fPIC -g g-debpoo.adb
+===GNAT BUG DETECTED==+
| 4.7.0 20110318 (experimental) [trunk revision 171126] (sparc-sun-solaris2.10)
GCC error:|
| output_operand: invalid expression as operand|
| Error detected around g-debpoo.adb:1723:4|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
g-debpoo.adb
g-debpoo.ads
gnat.ads
s-stoele.ads
s-chepoo.ads
s-stopoo.ads
ada.ads
a-finali.ads
s-finroo.ads
a-stream.ads
a-unccon.ads
a-except.ads
s-parame.ads
s-stalib.ads
s-traent.ads
a-exctra.ads
g-io.ads
s-addima.ads
s-memory.ads
s-soflin.ads
s-stache.ads
g-htable.ads
s-htable.ads
g-traceb.ads
s-stoele.adb
a-tags.ads
s-exctab.ads
s-secsta.ads
s-finimp.ads
s-stratt.ads
s-unstyp.ads
s-imgint.ads
s-htable.adb
a-uncdea.ads
s-strhas.ads
s-imgllu.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423


I find the following stacktrace:

#0  internal_error (gmsgid=0xba4e30 ) at
/vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:837
#1  0x00523524 in output_operand_lossage (cmsgid=0xba4eb0 ) at /vol/gcc/src/hg/trunk/local/gcc/final.c:3070
#2  0x00523960 in output_addr_const (file=0x11acca8, x=0xfe6a5ce0) at
/vol/gcc/src/hg/trunk/local/gcc/final.c:3613
#3  0x004a6f10 in dw2_asm_output_addr_rtx (size=4, addr=0xfe6a5ce0,
comment=0x0) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2asm.c:282
#4  0x004ac46c in output_loc_operands (loc=0xfe8a0f00, for_eh_or_skip=-1) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:5296
#5  output_loc_sequence (loc=0xfe8a0f00, for_eh_or_skip=-1) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:5360
#6  0x004b5360 in output_die (die=0xfe62fda0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11254
#7  0x004b4e14 in output_die (die=0xfe62fd70) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#8  0x004b4e14 in output_die (die=0xfe62ec00) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#9  0x004b4e14 in output_die (die=0xfe62e8d0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#10 0x004b4e14 in output_die (die=0xfe62e720) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#11 0x004b4e14 in output_die (die=0xff3800f0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#12 0x004b5d74 in output_comp_unit (die=0xff3800f0, output_if_empty=0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11521
#13 0x004daf04 in dwarf2out_finish (filename=Unhandled dwarf expression opcode
0xf3
) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:23613
#14 0x007119e4 in compile_file (argc=6, argv=0xffbff4c4) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:621
#15 do_compile (argc=6, argv=0xffbff4c4) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:1900
#16 toplev_main (argc=6, argv=0xffbff4c4) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:1963
#17 0x001025d4 in _start ()

Seems to be a different error caused by the same patch.

Rainer

[Bug libobjc/48177] incorrect registration of typed selectors

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.18 15:22:25
 Ever Confirmed|0   |1

--- Comment #3 from Nicola Pero  2011-03-18 15:22:25 
UTC ---

> The problem showed up with argframe information in base ... which presumably
> means that something in base is getting that wrong :-(

Ok - I see.  So, something in base is trying to create a typed selector at
runtime, and register it.  The argframe information in the generated types
doesn't  match the existing one (probably because they are generated buggy,
it's hard to generate them reliably), and the selector gets registered again.

If we were using sel_types_match(), then gnustep-base wouldn't need to provide
argframe information at all, assuming a selector with the same type already 
exists ?  Or if it provides a buggy one, it would be discarded in favour of the
existing one ?

Assuming that most compiler-generated typed selectors (which include valid
type information) are loaded in the runtime before any selector generated
by gnustep-base (or anything else) on the fly at runtime (which may include 
buggy types), then this should generally work in making sure the correct
types are used. :-)

So, I guess we should do it as it should get things to work generally better.

Is this a critical bug ?  Ie, would it actually cause any visible trouble
to users (as opposed to some inefficiency) ?  If so, we need a testcase so
we can backport it at some point to 4.6.x.


> I wonder, could we have a runtime function to take a type encoding without
> argframe info, and convert it to one with argframe info using the same
> algorithm the compiler uses?

If we could do that, then we would not need the argframe info in the selectors
at all. ;-)

In fact, maybe we should get rid of it, or hide it "more" inside the runtime.

It would be nice to audit exactly when and how it is used, and what the 
relationships are between the various parts.  Ideally we'd get rid of the
need for gnustep-base or even end-users to see or know about the argframe
layout information.  Let's have a chat about that offline.

Thanks

[Bug rtl-optimization/48182] New: ICE: SIGSEGV in try_crossjump_to_edge (cfgcleanup.c:1703) with --param min-crossjump-insns=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in try_crossjump_to_edge
(cfgcleanup.c:1703) with --param min-crossjump-insns=0
on basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -fcrossjumping --param min-crossjump-insns=0 testcase.c
-fcombine-stack-adjustments
==1021== Invalid read of size 2
==1021==at 0xF68F3C: try_crossjump_to_edge (cfgcleanup.c:1703)
==1021==by 0xF6AE27: try_crossjump_bb (cfgcleanup.c:1875)
==1021==by 0xF6BDBA: cleanup_cfg (cfgcleanup.c:2475)
==1021==by 0xFAC2F0: rest_of_handle_stack_adjustments
(combine-stack-adj.c:554)
==1021==by 0x7F9C45: execute_one_pass (passes.c:1556)
==1021==by 0x7F9F34: execute_pass_list (passes.c:1611)
==1021==by 0x7F9F46: execute_pass_list (passes.c:1612)
==1021==by 0x7F9F46: execute_pass_list (passes.c:1612)
==1021==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==1021==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==1021==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==1021==by 0xB110B9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==1021==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1021== 
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Originally, it crashed with "-O2 --param min-crossjump-insns=0", so this isn't
a case of running random passes at -O0. 

Tested revisions:
171088 - crash
4.0.4 - 4.6 - crash
3.4.6 - doesn't know min-crossjump-insns

[Bug testsuite/47965] gfortran testsuite failures on mingw32

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #1 from Janne Blomqvist  2011-03-18 15:45:59 
UTC ---
AFAICS this is due to gfortran nowadays using libcpp rather than calling an
external cpp.

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

[Bug fortran/42954] [4.5/4.6/4.7 regression] TARGET_*_CPP_BUILDINS issues with gfortran

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #14 from Janne Blomqvist  2011-03-18 
15:45:59 UTC ---
*** Bug 47965 has been marked as a duplicate of this bug. ***

[Bug c/48183] New: ICE [arm] immed_double_const at emit-rtl.c (-mfpu=neon -g -O1)

[juha.kallioinen at nokia dot com]

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

   Summary: ICE [arm] immed_double_const at emit-rtl.c (-mfpu=neon
-g -O1)
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: juha.kallioi...@nokia.com


Created attachment 23707
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23707
pre-processed source

When compiling the attached pre-processed source for arm (-march=armv7-a
-mtune=cortex-a8) and using options -mfpu=neon -g -O1 I get an ICE.

kaltsi@kaltsnatty:~/tmp/ice$ arm-linux-gnueabi-gcc-4.5 -mfpu=neon -O1 -g -c
emit-rtl-ice.i
optimized.c: In function ‘move_16bit_to_32bit’:
optimized.c:4:6: internal compiler error: in immed_double_const, at
emit-rtl.c:552
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This does not happen if I leave the -g option out.

Also reported to linaro: https://bugs.launchpad.net/gcc-linaro/+bug/736007

[Bug tree-optimization/48184] New: ICE: SIGFPE (division by zero) in compute_alignments () at final.c:731 with --param align-threshold=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGFPE (division by zero) in compute_alignments
() at final.c:731 with --param align-threshold=0 on
basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
void foo (void) { }
--

Compiler output:
$ gcc -O --param align-threshold=0 testcase.c
testcase.c: In function 'foo':
testcase.c:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGFPE, Arithmetic exception.
0x006c5d37 in compute_alignments () at
/mnt/svn/gcc-trunk/gcc/final.c:731
731   freq_threshold = freq_max / PARAM_VALUE (PARAM_ALIGN_THRESHOLD);

[Bug c++/48185] New: if(struct ...)

[lisp2d at lisp2d dot net]

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

   Summary: if(struct ...)
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lis...@lisp2d.net


Variable definition in structure if() can't receive type struct.

if(struct passwd*pwd(getpwuid(...)))return;

error: expected primary-expression before ‘struct’
error: expected ‘)’ before ‘struct’

[Bug tree-optimization/48186] New: ICE: SIGFPE (division by zero) in maybe_hot_frequency_p at predict.c:129 with --param hot-bb-frequency-fraction=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGFPE (division by zero) in
maybe_hot_frequency_p at predict.c:129 with --param
hot-bb-frequency-fraction=0 on basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
void foo (void) { }
--

Compiler output:
$ gcc -O --param hot-bb-frequency-fraction=0 testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGFPE, Arithmetic exception.
0x00806f9c in maybe_hot_frequency_p (bb=Unhandled dwarf expression
opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/predict.c:129
129   if (freq < ENTRY_BLOCK_PTR->frequency / PARAM_VALUE
(HOT_BB_FREQUENCY_FRACTION))

[Bug ada/48151] Bootstrap failure in stage3 comparison

[anhvofrcaus at gmail dot com]

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

Anh Vo  changed:

   What|Removed |Added

  Component|bootstrap   |ada

--- Comment #5 from Anh Vo  2011-03-18 15:58:57 
UTC ---
After rebooting the machine, the build resumed and passed this problem.

As the build progress, another problem surfaced due to Ada syntax error
messages as follows:

/c/Gcc/Build-Test_MinWG/./gcc/xgcc -B/c/Gcc/Build-Test_MinWG/./gcc/
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/mingw
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/w32api/lib -isystem
/c/Gcc/gcc-4.6.0-RC-20110314/winsup/mingw/include -isystem
/c/Gcc/gcc-4.6.0-RC-20110314/winsup/w32api/include
-B/usr/local/i686-pc-mingw32/bin/ -B/usr/local/i686-pc-mingw32/lib/ -isystem
/usr/local/i686-pc-mingw32/include -isystem
/usr/local/i686-pc-mingw32/sys-include-c -g -O2-W -Wall -gnatpg  
g-socket.adb -o g-socket.o
/c/Gcc/Build-Test_MinWG/./gcc/xgcc -B/c/Gcc/Build-Test_MinWG/./gcc/
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/mingw
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/w32api/lib -isystem
/c/Gcc/gcc-4.6.0-RC-20110314/winsup/mingw/include -isystem /c/Gcc/gcc-4.6.0
RC-20110314/winsup/w32api/include -B/usr/local/i686-pc-mingw32/bin/
-B/usr/local/i686-pc mingw32/lib/ -isystem /usr/local/i686-pc-mingw32/include
-isystem /usr/local/i686-pc-mingw32/sys-include-c -g -O2-W -Wall
-gnatpg   g-socthi.adb -o g-socthi.o
g-socthi.adb:280:45: value not in range of type "Interfaces.C.unsigned"
g-socthi.adb:280:45: static expression fails Constraint_Check
make[6]: *** [g-socthi.o] Error 1
make[6]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada/rts'
make[5]: *** [gnatlib] Error 2
make[5]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada'
make[4]: *** [gnatlib-shared-win32] Error 2
make[4]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory `/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/c/Gcc/Build-Test_MinWG'
make: *** [all] Error 2

After this Ada syntax error was fixed (I fixed it with my own way for now), the
build continued on. Finally, it completed successfully without any additional
problem.

[Bug objc/48187] New: infinite errors with misplaced [ in @interface definition

[cjwl at objc dot net]

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

   Summary: infinite errors with misplaced [ in @interface
definition
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: c...@objc.net


While parsing the code:

@interface InfiniteErrors { ]} @end


The compiler will repeatedly and indefinitely log the error:

error: expected specifier-qualifier-list before ']' token

This occurs in 4.2.1 also, so I believe it is an old problem, searched for an
existing report but don't see anything similar.

[Bug c++/48185] if(struct ...)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-03-18 
16:02:01 UTC ---
That is neither C nor C++.

[Bug fortran/48174] DWARF for subroutine with no args indicates 'varargs'

[longb at cray dot com]

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

--- Comment #4 from Bill Long  2011-03-18 16:08:37 UTC 
---
Additional comment from originator of the bug at Cray:

The DIE tag DW_TAG_unspecified_parameters indicates that a variable argument
list starts. Try a simple C program for contrast. Just create x.c

#include 

int foo (int a, ...)
{
return a;
}

and do

gcc -c -g x.c

then

readelf -wip x.o

and you'll see a subprogram, followed by the first formal parameter, then the
unspecified parameters. This doesn't seem to make sense in the Fortran context.

...
 <1><37>: Abbrev Number: 4 (DW_TAG_subprogram)
<38>   DW_AT_external: 1
<39>   DW_AT_name: foo
<3d>   DW_AT_decl_file   : 1
<3e>   DW_AT_decl_line   : 4
<3f>   DW_AT_prototyped  : 1
<40>   DW_AT_type: <0x6b>
<44>   DW_AT_low_pc  : 0x0
<4c>   DW_AT_high_pc : 0x91
<54>   DW_AT_frame_base  : 0x0(location list)
<58>   DW_AT_sibling : <0x6b>
 <2><5c>: Abbrev Number: 5 (DW_TAG_formal_parameter)
<5d>   DW_AT_name: a
<5f>   DW_AT_decl_file   : 1
<60>   DW_AT_decl_line   : 3
<61>   DW_AT_type: <0x6b>
<65>   DW_AT_location: 3 byte block: 91 bc 7e (DW_OP_fbreg: -196)
 <2><69>: Abbrev Number: 6 (DW_TAG_unspecified_parameters)

[Bug rtl-optimization/48188] New: ICE: SIGSEGV in remove_unnecessary_regions (ira-build.c:1855) with --param ira-max-loops-num=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in remove_unnecessary_regions
(ira-build.c:1855) with --param ira-max-loops-num=0 on
basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
void foo (void) { }
--

Compiler output:
$ gcc --param ira-max-loops-num=0 testcase.c
==13273== Use of uninitialised value of size 8
==13273==at 0x792776: remove_unnecessary_regions (ira-build.c:1855)
==13273==by 0x794213: ira_build (ira-build.c:2994)
==13273==by 0x78D4DE: ira (ira.c:3175)
==13273==by 0x78F51F: rest_of_handle_ira (ira.c:3344)
==13273==by 0x7F9C45: execute_one_pass (passes.c:1556)
==13273==by 0x7F9F34: execute_pass_list (passes.c:1611)
==13273==by 0x7F9F46: execute_pass_list (passes.c:1612)
==13273==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==13273==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==13273==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==13273==by 0xB110B9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==13273==by 0x509113: c_write_global_declarations (c-decl.c:9872)
==13273==  Uninitialised value was created by a heap allocation
==13273==at 0x4C26F30: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==13273==by 0x10BD427: xmalloc (xmalloc.c:147)
==13273==by 0x79264C: remove_unnecessary_regions (ira-build.c:1835)
==13273==by 0x794213: ira_build (ira-build.c:2994)
==13273==by 0x78D4DE: ira (ira.c:3175)
==13273==by 0x78F51F: rest_of_handle_ira (ira.c:3344)
==13273==by 0x7F9C45: execute_one_pass (passes.c:1556)
==13273==by 0x7F9F34: execute_pass_list (passes.c:1611)
==13273==by 0x7F9F46: execute_pass_list (passes.c:1612)
==13273==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==13273==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==13273==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==13273== 
==13273== Invalid write of size 1
==13273==at 0x792776: remove_unnecessary_regions (ira-build.c:1855)
==13273==by 0x794213: ira_build (ira-build.c:2994)
==13273==by 0x78D4DE: ira (ira.c:3175)
==13273==by 0x78F51F: rest_of_handle_ira (ira.c:3344)
==13273==by 0x7F9C45: execute_one_pass (passes.c:1556)
==13273==by 0x7F9F34: execute_pass_list (passes.c:1611)
==13273==by 0x7F9F46: execute_pass_list (passes.c:1612)
==13273==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==13273==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==13273==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==13273==by 0xB110B9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==13273==by 0x509113: c_write_global_declarations (c-decl.c:9872)
==13273==  Address 0x3c is not stack'd, malloc'd or (recently) free'd
==13273== 
testcase.c: In function 'foo':
testcase.c:1:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2011-03-18 
16:18:12 UTC ---
Author: jakub
Date: Fri Mar 18 16:18:05 2011
New Revision: 171150

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171150
Log:
PR debug/48176
* dwarf2out.c (dwarf2out_finish): Call output_aranges even when
arange_table_in_use is 0, but either text_section_used or
cold_text_section_used is true.  Don't call it if
!info_section_emitted.

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

[Bug tree-optimization/48189] New: [4.3/4.4/4.5/4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0

[zsojka at seznam dot cz]

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

   Summary: [4.3/4.4/4.5/4.6/4.7 Regression] ICE: SIGFPE (division
by zero) in in predict_loops () at predict.c:991 with
--param max-predicted-iterations=0
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O --param max-predicted-iterations=0 testcase.c
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGFPE, Arithmetic exception.
0x0080aab2 in predict_loops () at /mnt/svn/gcc-trunk/gcc/predict.c:991
991   probability = ((REG_BR_PROB_BASE + nitercst / 2) / nitercst);

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2011-03-18 
16:22:10 UTC ---
Author: jakub
Date: Fri Mar 18 16:22:01 2011
New Revision: 171151

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171151
Log:
PR debug/48176
* dwarf2out.c (dwarf2out_finish): Call output_aranges even when
arange_table_in_use is 0, but either text_section_used or
cold_text_section_used is true.  Don't call it if
!info_section_emitted.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/dwarf2out.c

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[bonzini at gnu dot org]

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

--- Comment #8 from Paolo Bonzini  2011-03-18 16:24:25 
UTC ---
I like the patch from comment 6.

[Bug c/48190] New: [regression?] Huge memory use while compiling qemu-0.4.0

[w41ter at gmail dot com]

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

   Summary: [regression?] Huge memory use while compiling
qemu-0.4.0
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w41...@gmail.com


Created attachment 23709
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23709
The patch to qemu code that causes gcc-4.5.2 to hog memory

While compiling qemu-0.4.0, gcc-4.5.2 consumes > 3GB of RAM at one point
(building target-i386/translate.c) instead of < 1GB needed by gcc-4.4.4.

$gcc -v
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.5.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /U/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.5.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls
--without-included-gettext --with-system-zlib --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp
--enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.5.2/python
--enable-checking=release --enable-java-awt=gtk --with-arch=i686
--enable-languages=c,c++,java --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.2 p1.1,
pie-0.4.5'
Thread model: posix
gcc version 4.5.2 (Gentoo 4.5.2 p1.1, pie-0.4.5) 

CFLAGS="-march=athlon-xp -O2 -pipe"

The memory hogging started with this commit to the qemu git repository, which I
will attach:

commit c832e3de64f1069313fc0672087791cc3dd5b4d8
Author: Richard Henderson
Date:   Mon Jan 10 19:23:47 2011 -0800

target-i386: Use deposit operation.

Use this for assignment to the low byte or low word of a register.

[Bug target/48191] New: internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sebastian.heg...@tu-dresden.de]

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

   Summary: internal compiler error: in issue_nops_and_insn, at
config/ia64/ia64.c:8258
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.heg...@tu-dresden.de


Created attachment 23710
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23710
The preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, compressed with gzip.

I am trying to compile the CGAL v3.7 ("www.cgal.org") library on IA-64, which
fails with: 

In file included from /scratch/build/CGAL-3.7/src/CGAL/all_files.cpp:37:0:
/scratch/build/CGAL-3.7/src/CGAL/MP_Float.cpp: In function
‘std::pair, int> CGAL::to_interval_exp(const
CGAL::MP_Float&)’:
/scratch/build/CGAL-3.7/src/CGAL/MP_Float.cpp:400:1: internal compiler error:
in issue_nops_and_insn, at config/ia64/ia64.c:8258



Continuing as per "http://gcc.gnu.org/bugs/#report";. Full Terminal output
follows here, the output from "-save-temps" comes as an attachment.



/home/radar-08/modules-ia64/gcc/4.5.2/bin/g++ -v -save-temps  -DCGAL_EXPORTS
-DNDEBUG -frounding-math -O3 -DNDEBUG -fPIC -I/scratch/build/CGAL-3.7/include
-I/home/h0/radar-08/modules-ia64/cgal/3.7/release/include
-I/home/radar-08/modules-ia64/cgal/3.7/release/include   -o
CMakeFiles/CGAL.dir/all_files.cpp.o -c
/scratch/build/CGAL-3.7/src/CGAL/all_files.cpp
Using built-in specs.
COLLECT_GCC=/home/radar-08/modules-ia64/gcc/4.5.2/bin/g++
COLLECT_LTO_WRAPPER=/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../libexec/gcc/ia64-unknown-linux-gnu/4.5.2/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.5.2/configure
--prefix=/home/radar-08/modules-ia64/gcc/4.5.2
--with--mpfr=/home/radar-08/modules-ia64/gcc/4.5.2
--with-gmp=/home/radar-08/modules-ia64/gcc/4.5.2
--with-mpc=/home/radar-08/modules-ia64/gcc/4.5.2
--with-libelf=/home/radar-08/modules-ia64/gcc/4.5.2 --enable-lto --enable-gold
--enable-bootstrap
Thread model: posix
gcc version 4.5.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DCGAL_EXPORTS' '-DNDEBUG'
'-frounding-math' '-O3' '-DNDEBUG' '-fPIC' '-I/scratch/build/CGAL-3.7/include'
'-I/home/h0/radar-08/modules-ia64/cgal/3.7/release/include'
'-I/home/radar-08/modules-ia64/cgal/3.7/release/include' '-o'
'CMakeFiles/CGAL.dir/all_files.cpp.o' '-c' '-shared-libgcc'

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../libexec/gcc/ia64-unknown-linux-gnu/4.5.2/cc1plus
-E -quiet -v -I/scratch/build/CGAL-3.7/include
-I/home/h0/radar-08/modules-ia64/cgal/3.7/release/include
-I/home/radar-08/modules-ia64/cgal/3.7/release/include -iprefix
/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/
-D_GNU_SOURCE -DCGAL_EXPORTS -DNDEBUG -DNDEBUG
/scratch/build/CGAL-3.7/src/CGAL/all_files.cpp -frounding-math -fPIC -O3
-fpch-preprocess -o all_files.ii
ignoring nonexistent directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../ia64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/ia64-unknown-linux-gnu"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/backward"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include-fixed"
ignoring nonexistent directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../ia64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/radar-08/modules-ia64/cgal/3.7/release/include"
#include "..." search starts here:
#include <...> search starts here:
 /scratch/build/CGAL-3.7/include
 /home/h0/radar-08/modules-ia64/cgal/3.7/release/include

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/ia64-unknown-linux-gnu

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/backward

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include-fixed
 /usr/local/include
 /home/h0

[Bug rtl-optimization/48143] [4.6/4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7114 with custom flags

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak  2011-03-18 16:39:36 
UTC ---
(In reply to comment #2)
> We ICE because we again issue more than issue_rate insns.  And this happens
> because we hit an insn which does not modify the DFA state at all, thus we do
> not account for it when checking that we obey issue_rate limits.  The insn is
> coming from sse2_cvtps2pd pattern of sse.md and it doesn't have a reservation
> (has "nothing").
> 
> I don't have any idea how the pattern attributes should be fixed, but the
> following seems to work on the test case.  Uros, does this make sense?

Sure, but there are some other patterns missing athlon_decode attribute:

*sse2_cvtpd2dq
*sse2_cvttpd2dq
sse2_cvtss2sd
*sse2_cvtpd2ps
sse2_cvtps2pd

Can you please add missing athlon_decode attribute also for these?

Patch is pre-approved for 4.7 and needs RM approval for 4.6.

[Bug preprocessor/48192] New: Conditional macros should not pass #ifdef

[meissner at gcc dot gnu.org]

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

   Summary: Conditional macros should not pass #ifdef
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: meiss...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


The PowerPC port defines 3 conditional macros, vector, bool, and pixel in
non-standards complaint mode to implement the Altivec/VSX vector keywords.  The
rs6000 backend only expands these keywords if the next token is a type or
keyword that would be used for the Altivec/VSX vector support, to allow the
user to use these 'keywords' as normal identifiers.  So vector int foo; would
expand vector to the vector __attribute__ to define a vector type, but int
vector = 0 would not be expanded.

The Spu also defines vector as a conditional macro.

No other port currently uses conditional macros.

The problem is if the user does:
#ifndef bool
#define bool char
#endif
static bool variable = 0;

The #ifndef case will not succeed because 'bool' is a macro, but 'bool' will
not be expanded because it was not preceded with 'vector'.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #8 from Perry Smith  2011-03-18 17:10:32 
UTC ---
It appears that this not a "gcc" bug but an AIX bug.  There is one change but
more changes are needed.  I'll try to update when I know more.  Expect it to be
a week or so.

[Bug rtl-optimization/48170] ICE: in hoist_code, at gcse.c:4524 with -fgcse --param max-hoist-depth={0,1}

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #3 from Maxim Kuvyrkov  2011-03-18 
17:12:24 UTC ---
Author: mkuvyrkov
Date: Fri Mar 18 17:12:19 2011
New Revision: 171155

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171155
Log:
PR rtl-optimization/48170
* gcse.c (hoist_code): Remove bogus asserts.

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

[Bug c++/48185] if(struct ...)

[lisp2d at lisp2d dot net]

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

--- Comment #2 from Lisp2D  2011-03-18 17:15:23 UTC 
---
Code

{ struct passwd*pwd(getpwuid(...));
  if(pwd)return true;}

is still compiled.

Code

if(struct passwd*pwd=getpwuid(...))return;

compiled too.

But 

if(struct passwd*pwd(getpwuid(...)))return;

will not.

Who is right?

[Bug preprocessor/48192] Conditional macros should not pass #ifdef

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  2011-03-18 
17:20:34 UTC ---
Created attachment 23711
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23711
Patch to make conditional macros not 'defined'

[Bug go/48019] Need to handle EINTR in libgo testsuite

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-18 17:21:42 UTC ---
> --- Comment #10 from Ian Lance Taylor  2011-03-17 
> 02:58:56 UTC ---
> Thanks.  It looks like the Solaris connect call does not honor SA_RESTART for
> some reason.

It's not only Solaris, though:

Tru64 UNIX V5.1B:

connect: Interrupted system call

but:

IRIX 6.5:

connect: Connection timed out

Rainer

[Bug rtl-optimization/48170] ICE: in hoist_code, at gcse.c:4524 with -fgcse --param max-hoist-depth={0,1}

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Maxim Kuvyrkov  2011-03-18 
17:24:03 UTC ---
Fixed.

[Bug c++/48185] if(struct ...)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-03-18 
17:27:43 UTC ---
G++ is right

a declaration in a selection-statement (if or switch) must be of the form:
  if ( type-specifier id = initializer )
or in C++0x:
  if ( type-specifier id { init } )

See 6.4 in the C++ standard

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth  2011-03-18 
17:28:19 UTC ---
The response to Comments 5 through 7 from the darwin linker developer is...
-
Unfortunately, the _sigtramp function in our libSystem.dylib does not have the
'S' letter in its augmentation string. I wrote a bug for that.  With that
fixed, I'll need to verify our unwinder the properly uses that 'S' flag to
change the boundary conditions when search for the applicable FDE.
-
So it appears that if this gets fixed, it will likely only be for darwin11.

[Bug c++/48162] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Jason Merrill  2011-03-18 
17:46:32 UTC ---
Fixed.

[Bug c++/48118] [4.3/4.4/4.5/4.6/4.7 regression] g++ sometimes allows copying a volatile class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|4.3.6   |4.7.0

--- Comment #2 from Jason Merrill  2011-03-18 
17:48:17 UTC ---
Fixed for 4.7.  Might backport to 4.6.1 (along with the two other patches) if
no problems turn up.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

--- Comment #9 from Daniel Richard G.  2011-03-18 
18:05:13 UTC ---
(In reply to comment #8)
> It appears that this not a "gcc" bug but an AIX bug.

The error was precipitated by an AIX system update, but at the same time, it
can be said that the AIX linker was previously being lenient in not requiring a
csect declaration for the bss section.

Whether this is an "AIX bug" or "GCC bug" isn't really relevant. IBM changed
how the AIX linker operates, and GCC needs to be updated accordingly.

[Bug bootstrap/48168] [4.7 regression] Solaris 2/SPARC bootstrap broken: ICE in sparc_function_arg_1, at config/sparc/sparc.c:5721

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.18 18:44:43
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Eric Botcazou  2011-03-18 
18:44:43 UTC ---
Investigating.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #10 from Perry Smith  2011-03-18 18:57:07 
UTC ---
IZ81343 (or one of its sister APARs) fixes the original issue.  But, it leaves
a new issue.  The new error looks like:

ld: 0711-596 SEVERE ERROR: Object expand.o
An RLD for section 2 (.data) refers to symbol 852,
but the storage class of the symbol is not C_EXT or C_HIDEXT.

The word I have presently is that that too is going to turn out to be an AIX
assembler error.

[Bug tree-optimization/48193] New: [4.7 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol with -flto --param partial-inlining-entry-probability=101

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] ICE: verify_ssa failed: type mismatch
between an SSA_NAME and its symbol with -flto --param
partial-inlining-entry-probability=101
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -flto --param partial-inlining-entry-probability=101 testcase.c
testcase.c: In function 'foo':
testcase.c:6:5: error: type mismatch between an SSA_NAME and its symbol
testcase.c:6:5: error: in statement
# VUSE <.MEM_10>
return x_12;
testcase.c:6:5: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  error (gmsgid=0x119c068 "type mismatch between an SSA_NAME and its symbol")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:747
#1  0x00a0f5f5 in verify_ssa_name (ssa_name=0x75bee528,
is_virtual=Unhandled dwarf expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/tree-ssa.c:590
#2  0x00a1273e in verify_ssa (check_modified_stmt=1 '\001') at
/mnt/svn/gcc-trunk/gcc/tree-ssa.c:1009
#3  0x007f8429 in execute_function_todo (data=Unhandled dwarf
expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/passes.c:1240
#4  0x007f8b1d in execute_todo (flags=2132516) at
/mnt/svn/gcc-trunk/gcc/passes.c:1271
#5  0x007faeb3 in execute_one_ipa_transform_pass () at
/mnt/svn/gcc-trunk/gcc/passes.c:1463
#6  execute_all_ipa_transforms () at /mnt/svn/gcc-trunk/gcc/passes.c:1487
#7  0x0093f8bd in tree_rest_of_compilation (fndecl=0x75bcef00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:415
#8  0x00b0fc42 in cgraph_expand_function (node=0x75bef000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576
#9  0x00b1239a in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635
#10 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899
#11 0x00b1291a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096
#12 0x00509124 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9872
#13 0x008e7ca8 in compile_file (argc=18, argv=0x7fffdc18) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591

Tested revisions:
r171152 - crash
r171088 - crash
4.6 r170955 - OK

[Bug c/48194] New: gcc -std=c99 fails to link when calling inline function

[adam at adamrosenfield dot com]

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

   Summary: gcc -std=c99 fails to link when calling inline
function
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@adamrosenfield.com


$ cat test.c
inline void foo() {}
int main(void) { foo(); }
$ gcc test.c -std=c99
test.c:(.text+0xa): undefined reference to `foo'
collect2: ld returned 1 exit status

Same result happens with -std=gnu99.  Bug does NOT happen with optimization
turned on: at any level besides -O0, this compiles correctly.

$ gcc --version
gcc-4.3 (Ubuntu 4.3.5-3ubuntu1) 4.3.5
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a Linux epoch 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC
2011 x86_64 GNU/Linux

This bug also happens on at least the following versions:

gcc-4.4 (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
gcc-4.5 (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1
gcc (GCC) 4.7.0 20110317 (experimental)

It does NOT happen in:

gcc-4.1 (GCC) 4.1.3 20080704 (prerelease) (Ubuntu 4.1.2-29ubuntu1)

Related: bug 34697

[Bug tree-optimization/48195] New: ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101

[zsojka at seznam dot cz]

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

   Summary: ICE: vector VEC(ipa_node_params_t,base) index domain
error, in ipa_analyze_node at ipa-prop.c:1525 with
-flto --param partial-inlining-entry-probability=101
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -flto --param partial-inlining-entry-probability=101 testcase.c
In function '_GLOBAL__D_65535_1_d1':
lto1: internal compiler error: vector VEC(ipa_node_params_t,base) index domain
error, in ipa_analyze_node at ipa-prop.c:1525
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

Tested revisions:
r171152 - crash
4.6 r170955 - crash
4.5 - doesn't know --param partial-inlining-entry-probability

[Bug c/48194] gcc -std=c99 fails to link when calling inline function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2011-03-18 
19:10:22 UTC ---
Because you are not using inline correctly.  inline without any qualifiers in
C99 is what is called GNU's extern inline;  You need to declare an extern
(exported) version of the inline function.