[Bug fortran/52788] -fbounds-check fails for 2-rank allocatable arrays when reading

[Edouard.Canot at irisa dot fr]

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

--- Comment #1 from Edouard.Canot at irisa dot fr 2012-03-30 07:11:41 UTC ---
For a one dimensional allocatable array, gfortran leads to a correct behavior
when reading, i.e. it detects the bounds overflow.

[Bug ada/52782] Compiler prints "bug box"

[jan.karv at gmail dot com]

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

Lobivia  changed:

   What|Removed |Added

   Severity|normal  |minor

--- Comment #1 from Lobivia  2012-03-30 07:18:33 UTC 
---
The provided source is incorrect Ada, thus not so severe, still a bug. 'Q.Data'
is missing before the second pair of parentheses on the offending line (no.
34).

[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  2012-03-30 
07:58:49 UTC ---
Your testcase is broken - it doesn't honour reinterpret_casts properly . This
is  a better testcase. 

#include 

uint32x4_t sqrlen4D_16u8( const uint8x16_t A, const uint8x16_t B )
{
 const uint8x16_t absAB = vabdq_u8( A, B );
 const uint16x8_t square_l = vmull_u8( vget_low_u8( absAB ), vget_low_u8( absAB
) );
 const uint16x8_t square_h = vmull_u8( vget_high_u8( absAB ), vget_high_u8(
absAB ) );
 const uint32x4x2_t rgrgrgrg_babababa = vuzpq_u32( vreinterpretq_u32_u16
(square_l), vreinterpretq_u32_u16 (square_h) );
 const uint16x8_t rgrgrgrg = vreinterpretq_u16_u32 (rgrgrgrg_babababa.val[0]);
 const uint16x8_t babababa = vreinterpretq_u16_u32 (rgrgrgrg_babababa.val[1]);
 const uint32x4_t rpg_rpg_rpg_rpg = vpaddlq_u16( rgrgrgrg );
 const uint32x4_t dp = vpadalq_u16( rpg_rpg_rpg_rpg, babababa );
 return ( dp );
}

[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  2012-03-30 
08:17:21 UTC ---
Experimenting with : 

Applying the patch of PR48941 and the patch for lower-subreg here

http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01886.html

I now see : We still have too many moves for my liking but the gratuituous
spilling is now gone. 

  .cpu cortex-a9
.eabi_attribute 27, 3
.fpu neon
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file   "t2.c"
.text
.align  2
.global sqrlen4D_16u8
.type   sqrlen4D_16u8, %function
sqrlen4D_16u8:
@ args = 16, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vmovd16, r0, r1  @ v16qi
vmovd17, r2, r3
vldmia  sp, {d18-d19}
vabd.u8 q10, q8, q9
vmull.u8q11, d20, d20
vmull.u8q10, d21, d21
vmovq8, q11  @ v4si  -- unnecessary ? 
vmovq9, q10  @ v4si  -- unnecessary ? 
vuzp.32 q8, q9
vpaddl.u16  q10, q8
vmovq11, q10  @ v4si  -- unnecessary
vpadal.u16  q11, q9
vmovr0, r1, d22  @ v4si
vmovr2, r3, d23
bx  lr
.size   sqrlen4D_16u8, .-sqrlen4D_16u8
.ident  "GCC: (GNU) 4.8.0 20120330 (experimental)"
.section.note.GNU-stack,"",%progbits

This probably makes it a dup of PR48941 but it's starting to look more
promising now. 

Eric, could you try the 2 patches and see what you get - This isn't something
to be gratuitously backported as we still have to see the effects elsewhere but
it would be worth seeing if this helps on your intrinsics testcases. 

Ramana

[Bug libstdc++/52765] -std=c++0x requires multilib for non-optimized libstdc++

[christophe.lyon at st dot com]

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

--- Comment #9 from christophe.lyon at st dot com 2012-03-30 08:39:19 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > I am not sure this is really a bug (is building libstdc++ at -O0 
> > supported?),
> 
> Yes, the --enable-libstdcxx-debug configure option builds an alternative
> libstdc++.so with -O0 (but I can't reproduce this when using that lib)

I have experimented with this configure option. I didn't know about it: what is
the intended way of using the debug libraries? I have add -L/debug to my
link command, and I do reproduce the problem in this context:
- target arm-none-eabi
- --disable-shared

# Using default libs, built at -O2
$ arm-none-eabi-g++ cplx.cxx -o cplx.u -mcpu=cortex-a9 -std=c++0x
$ qemu-system-arm -semihosting -cpu cortex-a9 -nographic -kernel ./cplx.u
23
(23,101)

# Using debug libs, built at -O0
$ arm-none-eabi-g++ cplx.cxx -o cplx.u -mcpu=cortex-a9 -std=c++0x -L
.../lib/debug
$ qemu-system-arm -semihosting -cpu cortex-a9 -nographic -kernel ./cplx.u
23
(0,101)

[Bug c++/52772] [4.8 Regression] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Guenther  2012-03-30 
09:04:47 UTC ---
Mine.

[Bug other/52777] [4.8 Regression] ./options.h:3546:0: error: "MASK_SIO" redefined [-Werror]

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug lto/52779] [4.6 only] LTO produces false warning with type merging

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Guenther  2012-03-30 
09:10:47 UTC ---
There is a duplicate of this bug which was fixed for 4.7.  There is even a
testcase somewhere.  We can't fix this in 4.6, thus, fixed for 4.7.

[Bug c++/52780] ice in create_preheader with -O2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-03-30
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-03-30 
09:11:29 UTC ---
Mine.  Maybe a dup.

[Bug other/52786] double-int.c:231:31: error: comparison between signed and unsigned

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2012-03-30 
09:21:00 UTC ---
Author: rguenth
Date: Fri Mar 30 09:20:54 2012
New Revision: 186000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186000
Log:
2012-03-30  Richard Guenther  

PR middle-end/52786
* double-int.c (rshift_double): Remove not needed cast.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/double-int.c

[Bug other/52786] double-int.c:231:31: error: comparison between signed and unsigned

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Richard Guenther  2012-03-30 
09:21:26 UTC ---
Fixed.

[Bug c++/52772] [4.8 Regression] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from Richard Guenther  2012-03-30 
09:44:40 UTC ---
*** Bug 52780 has been marked as a duplicate of this bug. ***

[Bug c++/52780] ice in create_preheader with -O2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Richard Guenther  2012-03-30 
09:44:40 UTC ---
My patch for PR52772 also fixes this testcase.

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

[Bug libstdc++/52765] -std=c++0x requires multilib for non-optimized libstdc++

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2012-03-30 
09:59:51 UTC ---
(In reply to comment #9)
> I have experimented with this configure option. I didn't know about it: what 
> is
> the intended way of using the debug libraries?

I use debug/libstdc++.so via LD_LIBRARY_PATH when I want to run in gdb and
step-through code in the library. i.e. I link as normal, but switch to using
the debug lib at run-time. Obviously if using static linking that doesn't work
so you'd have to decide to use that lib at link-time.

I mentioned it here because it's a common (and supported) way to get a
libstdc++ built with -O0 while keeping the primary libs built with the usual
flags (-O2 etc.)

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-03-30 
10:22:45 UTC ---
We indeed should not create negative array indices (well, out-of-bound array
indices).  The issue why this happens is that we transform

 const unsigned int * ii = (const unsigned int *) &indexes[i];
 *(ii + 12)

to

 MEM[(const unsigned int *)&indexes + 12B][i_3];

via

ii = &indexes[i];
D.3849 = ii + 12;
D.3850 = *D.3849;

forwprop1 (still ok):

  ii_9 = &indexes[i_3];
  D.3850_11 = MEM[(const unsigned int *)ii_9 + 12B];

forwprop2 (bogus):

  D.3850_11 = MEM[(const unsigned int *)&indexes + 12B][i_3];

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2012-03-30 
10:45:28 UTC ---
Created attachment 27042
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27042
alternative patch

[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #9 from Paolo Carlini  2012-03-30 
10:52:32 UTC ---
Let's try to finally make progress on this. Note: the locations have been
already fixed.

[Bug libfortran/52758] libgfortran/intrinsics/chmod.c: Array index out of bounds

[uros at gcc dot gnu.org]

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

--- Comment #1 from uros at gcc dot gnu.org 2012-03-30 11:07:51 UTC ---
Author: uros
Date: Fri Mar 30 11:07:46 2012
New Revision: 186008

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186008
Log:
PR libgfortran/52758
* intrinsics/chmod.c: Remove out-of-bound initialization of rwxXstugo.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/chmod.c

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[kretz at kde dot org]

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

--- Comment #8 from Matthias Kretz  2012-03-30 11:13:59 
UTC ---
(In reply to comment #7)
> alternative patch

Just tested it on the 4.7-20120324 snapshot and all bogus warnings are gone, as
are the crashes. No regressions in my testsuite.

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2012-03-30 
11:31:58 UTC ---
(In reply to comment #7)
> Created attachment 27042 [details]
> alternative patch

I'm not against it, but what if the source code and/or some other pass result
in similar ARRAY_REF?  To me pcom still looks potentially buggy...

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  
2012-03-30 11:41:35 UTC ---
On Fri, 30 Mar 2012, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52754
> 
> --- Comment #9 from Jakub Jelinek  2012-03-30 
> 11:31:58 UTC ---
> (In reply to comment #7)
> > Created attachment 27042 [details]
> > alternative patch
> 
> I'm not against it, but what if the source code and/or some other pass result
> in similar ARRAY_REF?  To me pcom still looks potentially buggy...

If that happens the other pass is broken or the source invokes undefined
behavior.  I had the following patch which fixed the issue, too:

Index: tree-predcom.c
===
--- tree-predcom.c  (revision 186007)
+++ tree-predcom.c  (working copy)
@@ -1414,9 +1414,11 @@ ref_at_iteration (struct loop *loop, tre
}
   else
{
- val = fold_build2 (MULT_EXPR, type, iv.step,
-build_int_cst_type (type, iter));
- val = fold_build2 (PLUS_EXPR, type, iv.base, val);
+ tree itype = signed_type_for (type);
+ val = fold_build2 (MULT_EXPR, itype, fold_convert (itype, 
iv.step),
+build_int_cst (itype, iter));
+ val = fold_build2 (PLUS_EXPR, itype,
+fold_convert (itype, iv.base), val);
}
   *idx_p = unshare_expr (val);
 }

as we know iter is negative.  We could also change the caller so
we pass a positive count and instead subtract it from the base
value, though that's still going to get possibly negative
(and in case iv.base is not a constant we will not know this here).

The above would not be a real fix, instead we would need to cater
for a large unsigned iv.base, thus, promote val and iv.base to
[u]intptr_t.

But - we can't really "win" here for array indices that ultimatively
will be out-of-bound.  If some GCC pass re-constructs invalid
array-refs it has to be fixed.

[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-03-30 
13:26:57 UTC ---
(In reply to comment #3)
> DOM jump threading threads the loop latch edge:
> 
>   if (latch->aux)
> {
>   /* First handle the case latch edge is redirected.  */
>   loop->latch = thread_single_edge (latch);
>   gcc_assert (single_succ (loop->latch) == tgt_bb);
>   loop->header = tgt_bb;

At this point everything is still ok, but

>   /* Thread the remaining edges through the former header.  */
>   thread_block (header, false);

this creates a multiple entry loop (with the old entry being an
unreachable block after threading - sth cfgcleaup exposes, which
in turn would turn that into a valid loop, albeit with bogus header/latch,
again).

Now, thread_through_loop_header ensures (fingers crossing) that we never
create a multiple entry loop.  Thus the following fix would work.

Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 186007)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -649,6 +649,17 @@ thread_block (basic_block bb, bool noloo
  || THREAD_TARGET2 (e
continue;

+  /* thread_through_loop_header made sure we are not creating
+a multiple entry loop.  If we are creating a new loop
+entry the destination will become the new header of the
+loop and the old entry will become unreachable.  */
+  if (e->src->loop_father != e2->dest->loop_father)
+   {
+ e2->dest->loop_father->header = e2->dest;
+ /* Discard knowledge about the latch.  */
+ e2->dest->loop_father->latch = NULL;
+   }
+
   if (e->dest == e2->src)
update_bb_profile_for_threading (e->dest, EDGE_FREQUENCY (e),
 e->count, THREAD_TARGET (e));

[Bug c++/52772] [4.8 Regression] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-03-30 
13:40:31 UTC ---
Author: rguenth
Date: Fri Mar 30 13:40:17 2012
New Revision: 186011

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186011
Log:
2012-03-30  Richard Guenther 

PR middle-end/52772
* except.c (emit_to_new_bb_before): Move loop updating ...
(dw2_build_landing_pads): ... here.  Use a proper block for
querying the loop father.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr52772.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/except.c
trunk/gcc/testsuite/ChangeLog

[Bug other/52754] [4.7/4.8 Regression] indirect indexing broken with -fpredictive-commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther  2012-03-30 
13:41:31 UTC ---
Author: rguenth
Date: Fri Mar 30 13:41:24 2012
New Revision: 186012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186012
Log:
2012-03-30  Richard Guenther  

PR tree-optimization/52754
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Only
propagate arbitrary addresses into really plain dereferences.

* gcc.target/i386/pr52754.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr52754.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug other/52754] [4.7 Regression] indirect indexing broken with -fpredictive-commoning

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.8.0
Summary|[4.7/4.8 Regression]|[4.7 Regression] indirect
   |indirect indexing broken|indexing broken with
   |with -fpredictive-commoning |-fpredictive-commoning

--- Comment #12 from Richard Guenther  2012-03-30 
13:42:14 UTC ---
Fixed on trunk sofar.

[Bug c++/52772] [4.8 Regression] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Richard Guenther  2012-03-30 
13:41:41 UTC ---
Fixed.

[Bug fortran/52789] New: gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense

[mathewc at nag dot co.uk]

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

 Bug #: 52789
   Summary: gfortran sets -Wunused-parameter in the C sense as
well as the Fortran sense
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: math...@nag.co.uk


I'm using

$ uname -a
Linux stonehenge 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux

$ gfortran --version
GNU Fortran (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)

and with

$ cat unused.f90
subroutine s(x)
integer, parameter :: i = 0
end

I get

$ gfortran -Wunused-parameter -c unused.f90
unused.f90:2.23:

integer, parameter :: i = 0
   1
Warning: Unused parameter 'i' declared at (1)
unused.f90:1:0: warning: unused parameter ‘x’ [-Wunused-parameter]

I think the C warning used to be suppressed at 4.5(?).

Specifying -Wunused-dummy-argument gets rid of the C message:

$ gfortran -Wunused-parameter -Wunused-dummy-argument -c unused.f90
unused.f90:2.23:

integer, parameter :: i = 0
   1
Warning: Unused parameter 'i' declared at (1)
unused.f90:1.14:

subroutine s(x)
  1
Warning: Unused dummy argument 'x' at (1)

[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[3dw4rd at verizon dot net]

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

--- Comment #2 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-03-30 
14:30:20 UTC ---
I short-circuited the overflow check in libcpp in case the literal was resolved
in C++ FE as a raw literal.  The raw literal should be able to take any number
of digits.  Ditto the literal operator template.

[Bug libitm/52787] Segmentation fault on MinGW

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  2012-03-30 14:38:57 
UTC ---
Based to your e-mail on gcc-help, you left out a very important piece of
information.  This is using a build with the following patch:

> Moreover, if I replace line 134 in file gccroot/libitm/configure.tgt [1] from:
> >   | *-*-darwin* | *-*-aix*)
> to:
> >   | *-*-darwin* | *-*-aix* | *-w64-mingw32)

As far as I know libitm is not expected to work on MinGW.

[Bug fortran/52790] New: Problems using x86_64-w64-mingw-w32-gfortran with mcmodel=large and medium

[wyldckat+gcc.bugzilla at gmail dot com]

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

 Bug #: 52790
   Summary: Problems using x86_64-w64-mingw-w32-gfortran with
mcmodel=large and medium
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wyldckat+gcc.bugzi...@gmail.com


Created attachment 27043
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27043
Example that works on Linux x86_64 but not with mingw-w64 on/for Windows

Attached is "test.f", an example file of Fortran code that will build just fine
on Linux x86_64, but it will not build with "x86_64-w64-mingw32-gfortran.exe"
on Windows or with a cross-compilation "build kit" on Linux.

Commands for building this test file:
- on several Linux x86_64 boxes with various gcc versions, all of these work:
 1.   gfortran -O3 test.f
 2.   gfortran -O3 -mcmodel=medium test.f
 3.   gfortran -O3 -mcmodel=large test.f
the last one is what I have to use with the real code, due to the number and
dimensions of the pre-allocated arrays.


- on Windows or cross-compiled from Linux, all of these don't work:
 1.   x86_64-w64-mingw32-gfortran.exe -O3 test.f
 2.   x86_64-w64-mingw32-gfortran.exe -O3 -mcmodel=medium test.f
 3.   x86_64-w64-mingw32-gfortran.exe -O3 -mcmodel=large test.f

The errors vary depending on option. In order, the summary "complaints" are:
 1.   In function `pre_c_init' [...] crtexe.c [...] relocation truncated to
fit: R_X86_64_PC32 against symbol ...

 2.   as.exe: BFD (GNU Binutils) 2.22.51.20111217 assertion fail [...]
coff-x86_64.c [...] cannot represent relocation type BFD_RELOC_386_GOTPC

 3.   as.exe [...] cannot represent relocation type BFD_RELOC_X86_64_GOTPC64


Tested build systems:
- custom build: binutils 2.21 + gcc 4.5.3 (gmp 4.3.2 + mpfr 2.4.2 + mpc 0.8.2)
+ mingw-w64 CRT v1.x
- custom build: binutils 2.22 + gcc 4.6.3 (gmp 5.0.2 + mpfr 3.0.1 + mpc 0.9) +
mingw-w64 CRT v2.x
- automatic build from the mingw-w64 project (Gcc 4.7.0 and binutils
2.22.51.20111217), namely with the package:
mingw-w64-bin_i686-mingw_20111220.zip



This was initially reported on the mingw-w64 project bug tracker:
http://sourceforge.net/tracker/?func=detail&atid=983354&aid=3505342&group_id=202880
The answer was and I quote:
  «This bug report is invalid on this list. You can open a feature-request on
gcc's bugtracker for it, but x64 windows target is using small-memory model
only. larget memory-model isn't supported at all, and medium is at least
absolutely untested.
  Therefore I close this bug as invalid, as it has nothing to do with mingw-w64
itself.»

[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2012-03-30 
15:08:58 UTC ---
I think it depends on what the literal operator is used.  If it is a const char
* or template, then it should allow any number of chars without a warning IMHO.
But when the C++ FE needs to parse that number as unsigned long long or long
double and the literal has too many digits for that, we should warn.

[Bug bootstrap/52784] i386-apple-darwin multilib bootstrap broken

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|i386-apple-darwin10 |i386-apple-darwin10
   ||i386-pc-solaris2.1[01]
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-30
 CC||ro at gcc dot gnu.org
   Host|i386-apple-darwin10 |i386-apple-darwin10,
   ||i386-pc-solaris2.1[01]
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1
  Build|i386-apple-darwin10 |i386-apple-darwin10
   ||i386-pc-solaris2.1[01]

--- Comment #2 from Rainer Orth  2012-03-30 15:10:38 UTC 
---
Same on Solaris 10 and 11/x86.

Please fix.
  Rainer

[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2012-03-30 
15:12:38 UTC ---
So?

Note that you have also

[macbook] f90/bug% gfc -Wall pr52789.f90
pr52789.f90:1.14:

subroutine s(x)
  1
Warning: Unused dummy argument 'x' at (1)
[macbook] f90/bug% gfc -Wall -Wextra pr52789.f90
pr52789.f90:2.23:

integer, parameter :: i = 0
   1
Warning: Unused parameter 'i' declared at (1)
pr52789.f90:1.14:

subroutine s(x)
  1
Warning: Unused dummy argument 'x' at (1)

for gcc version 4.4.6 up to 4.8.0 (trunk).

[Bug c++/52791] New: structure should always be returned by passing a hidden argument with ms_abi, x86_64

[piotr at codeweavers dot com]

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

 Bug #: 52791
   Summary: structure should always be returned by passing a
hidden argument with ms_abi, x86_64
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pi...@codeweavers.com


Created attachment 27044
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27044
program that demonstrates the problem

Even if structure returned by function is small it should be passed as hidden
argument, pointer to it should be returned when ms_abi is used.

I've attached a program that demonstrates this problem.

[Bug c++/52792] New: this pointer and return pointer are passed in wrong order when ms_abi is used (x86_64)

[piotr at codeweavers dot com]

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

 Bug #: 52792
   Summary: this pointer and return pointer are passed in wrong
order when ms_abi is used (x86_64)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pi...@codeweavers.com


Created attachment 27045
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27045
program that demonstrates the problem

When class function returns structure this pointer should be passed as first
argument. Pointer to memory used by returned value should be passed as second
argument. Currently gcc swaps these to parameters.

[Bug libfortran/52758] libgfortran/intrinsics/chmod.c: Array index out of bounds

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org 2012-03-30 15:37:58 UTC ---
Author: uros
Date: Fri Mar 30 15:37:51 2012
New Revision: 186014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186014
Log:
PR libgfortran/52758
* intrinsics/chmod.c (chmod_func): Remove out-of-bounds
initialization of rwxXstugo.


Modified:
branches/gcc-4_7-branch/libgfortran/ChangeLog
branches/gcc-4_7-branch/libgfortran/intrinsics/chmod.c

[Bug libfortran/52758] libgfortran/intrinsics/chmod.c: Array index out of bounds

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

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

--- Comment #3 from Uros Bizjak  2012-03-30 15:39:51 
UTC ---
Fixed.

[Bug bootstrap/52784] i386-apple-darwin multilib bootstrap broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Target|i386-apple-darwin10 |i386  --enable-targets=all
   |i386-pc-solaris2.1[01]  |
 Status|NEW |ASSIGNED
 CC|hjl.tools at gmail dot com  |
   Host|i386-apple-darwin10,|
   |i386-pc-solaris2.1[01]  |
 AssignedTo|unassigned at gcc dot   |hjl.tools at gmail dot com
   |gnu.org |
  Build|i386-apple-darwin10 |
   |i386-pc-solaris2.1[01]  |

--- Comment #3 from H.J. Lu  2012-03-30 15:42:38 
UTC ---
Mine.

[Bug c++/40942] GCC accepts code that Comeau and MSVC deems invalid.

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

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

[Bug bootstrap/52784] i386-apple-darwin multilib bootstrap broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-03/msg01948.htm
   ||l

--- Comment #4 from H.J. Lu  2012-03-30 16:20:19 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01948.html

[Bug fortran/52789] gfortran sets -Wunused-parameter in the C sense as well as the Fortran sense

[mathewc at nag dot co.uk]

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

--- Comment #2 from Mat Cross  2012-03-30 16:22:34 
UTC ---
(In reply to comment #1)
> So?

If I RTM I see:

"-Wunused-parameter
Contrary to gcc's meaning of -Wunused-parameter, gfortran's implementation
of this option does not warn about unused dummy arguments (see
-Wunused-dummy-argument), but about unused PARAMETER values. -Wunused-parameter
is not included in -Wall but is implied by -Wall -Wextra."

[Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  2012-03-30 16:24:25 
UTC ---
Zdenek certainly knows this part of the code better than I and may comment, but
it looks reasonable to me.

[Bug libstdc++/52689] static linking with libstdc++ fails

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #10 from Rainer Orth  2012-03-30 16:42:20 
UTC ---
Unfortuntately, the fix causes link failures during mainline bootstrap on
Solaris:

I'm using a static g++ 4.4 built libppl_c.a, which contains references to

Undefined   first referenced
 symbol in file
_ZNSt15_List_node_base4swapERS_S0_ 
/vol/gcc/lib/libppl_c.a(ppl_c_Pointset_Powerset_C_Polyhedron.o)
_ZNSt15_List_node_base4hookEPS_ /vol/gcc/lib/libppl_c.a(ppl_c_Polyhedron.o)
_ZNSt15_List_node_base6unhookEv
/vol/gcc/lib/libppl_c.a(ppl_c_Pointset_Powerset_C_Polyhedron.o)
_ZNSt15_List_node_base8transferEPS_S0_
/vol/gcc/lib/libppl_c.a(ppl_c_Pointset_Powerset_C_Polyhedron.o)
ld: fatal: symbol referencing errors. No output written to go1

These references are now unresolved.  It could be considered a build bug since
the just build libstdc++.a is searched before the gcc 4.4 libstdc++.a specified
via -L/vol/gcc-4.4/lib.

Whether it is considered an accident or not that this worked so far is the
question.

  Rainer

[Bug target/52667] sh_reorg segfault

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Schwinge  2012-03-30 
17:23:37 UTC ---
Has been committed.

[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[3dw4rd at verizon dot net]

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

--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-03-30 
17:34:36 UTC ---
Agreed.  Testing a patch.  This will have the advantage over libcpp that long
double will also be tested for overflow.

[Bug middle-end/52793] New: [4.8 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

 Bug #: 52793
   Summary: [4.8 Regression] 483.xalancbmk in SPEC CPU 2006 failed
to build
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 185913 gave

g++ -c -o DOMNormalizer.o -DSPEC_CPU -DNDEBUG  -DAPP_NO_THREADS
-DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl
-Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -O3
-funroll-loops -ffast-math-DSPEC_CPU_LP64  -DSPEC_CPU_LINUX
DOMNormalizer.cpp
...
DOMNormalizer.cpp:434:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
specmake[3]: *** [DOMNormalizer.o] Error 1

Revision 185825 is OK.

[Bug debug/52727] [4.7/4.8 Regression] internal compiler error at dwarf2cfi.c2:685

[rth at gcc dot gnu.org]

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

--- Comment #13 from Richard Henderson  2012-03-30 
18:00:45 UTC ---
Author: rth
Date: Fri Mar 30 18:00:37 2012
New Revision: 186018

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186018
Log:
PR debug/52727
* combine-stack-adj.c (prev_active_insn_bb): New.
(next_active_insn_bb): New.
(force_move_args_size_note): New.
(combine_stack_adjustments_for_block): Use it.

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

[Bug debug/52727] [4.7/4.8 Regression] internal compiler error at dwarf2cfi.c2:685

[rth at gcc dot gnu.org]

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

--- Comment #14 from Richard Henderson  2012-03-30 
18:23:10 UTC ---
Author: rth
Date: Fri Mar 30 18:23:06 2012
New Revision: 186019

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186019
Log:
PR debug/52727
* g++.dg/opt/pr52727.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr52727.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/52794] New: gcc.dg/tree-prof/pr52027.c fails on x86_64/i386-apple-darwin*

[howarth at nitro dot med.uc.edu]

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

 Bug #: 52794
   Summary: gcc.dg/tree-prof/pr52027.c fails on
x86_64/i386-apple-darwin*
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The new gcc.dg/tree-prof/pr52027.c fails on x86_64-apple-darwin* and
i386-apple-darwin*...

FAIL: gcc.dg/tree-prof/pr52027.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr52027.c execution,-fprofile-use
-D_PROFILE_USE

http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02630.html
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02708.html
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02742.html

Apple responded to radar Bug ID 10960042: linker bug gcc.dg/tree-prof/pr52027.c
with the comment


pr52027 is failing because there are two FDE pointing to the same start address
(LFB0 and LCOLDB0 are labels to the same point).  You cannot have two FDEs that
cover the same range.

[Bug c++/52680] std::this_thread::sleep_for #ifdef'd out by _GLIBCXX_USE_NANOSLEEP

[mkline at cs dot wisc.edu]

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

--- Comment #4 from Matt Kline  2012-03-30 19:19:03 
UTC ---
Where should I specify that flag? _GLIBCXX_USE_NANOSLEEP is still undefined
when I build gcc with

configure CFLAGS='-O3' --disable-bootstrap --disable-multilib
--enable-ibstdccxx-time=rt --enable-languages=c,c++

[Bug c++/52762] Firefox 11 segfault with gcc 4.7 (-O3 -march=corei7-avx)

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot
   ||org

--- Comment #7 from Andi Kleen  2012-03-30 
19:21:19 UTC ---
Happens in java script, which does JITed code.
My guess is that one of the transition points between JITed code and C code
does not save AVX registers correctly or something like that.
I would file it with mozilla.org, it's more likely their bug.

[Bug c/52794] gcc.dg/tree-prof/pr52027.c fails on x86_64/i386-apple-darwin*

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2012-03-30 
19:22:23 UTC ---
Created attachment 27046
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27046
testcase from radar://10960042  generated on x86_64-apple-darwin11

The FSF gcc testsuite failure...

FAIL: gcc.dg/tree-prof/pr52027.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr52027.c execution,-fprofile-use
-D_PROFILE_USE

seen at -m32/-m64 with Xcode 4.3's linker may be showing a linker bug. The
attached
testcase contains the files obtained with...

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120228/gcc/testsuite/gcc.dg/tree-prof/pr52027.c
-O -freorder-blocks-and-partition -fno-reorder-functions -fprofile-generate
-D_PROFILE_GENERATE -lm -m64 -o pr52027.x01

Executing the resulting pr52027.x01 to produce the profiling code in
pr52027.gcda (provided) and...

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120228/gcc/testsuite/gcc.dg/tree-prof/pr52027.c
-O -freorder-blocks-and-partition -fno-reorder-functions -fprofile-use
-D_PROFILE_USE -lm -m64 -v --save-temps -o pr52027.x02

which produces the linker error...

Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-128.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1519.
0  0x1010331df  __assert_rtn + 79
1  0x10104eae5 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 917
2  0x10103c32e  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 286
3  0x101038b2b  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 91
4  0x1010716fd  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 653
5  0x101072cfb  ld::tool::InputFiles::InputFiles(Options&, char const**) + 651
6  0x101033426  main + 358
7  0x1010236a4  start + 52

which can be reproduced with the provided bad_link shell script which
executes...

ld -dynamic -arch x86_64 -macosx_version_min 10.7.3 -weak_reference_mismatches
non-weak -o pr52027.x02 -lcrt1.10.6.o -L. pr52027.o -no_compact_unwind -lSystem
-lgcc_ext.10.5 -lgcc -lSystem -v

[Bug c/52795] New: FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

[howarth at nitro dot med.uc.edu]

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

 Bug #: 52795
   Summary: FAIL: gcc.dg/tree-prof/pr34999.c compilation,
-fprofile-use -D_PROFILE_USE on
{x86_64,i386}-apple-darwin{10,11} at -m64
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The failure...

FAIL: gcc.dg/tree-prof/pr34999.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr34999.c execution,-fprofile-use
-D_PROFILE_USE

occurs at -m64 on {x86_64,i386}-apple-darwin{10,11}. This occurs as a linker
failure of the form...

Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-128.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1519.
0  0x10c62d1df  __assert_rtn + 79
1  0x10c648ae5 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 917
2  0x10c63632e  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 286
3  0x10c632b2b  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 91
4  0x10c66b6fd  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 653
5  0x10c66ccfb  ld::tool::InputFiles::InputFiles(Options&, char const**) + 651
6  0x10c62d426  main + 358

This was filed as radr://10960042 and Apple's analysis was...

pr34999 is failing because the third FDE points to (LCOLDB2) which has no
non-local label preceding it, so the assembler creates a local relocation.  But
that loses information, and the linker cannot recover what the FDE is supposed
to point to.  A simple fix in the compiler is to not use relocations in the
__eh_frame section:

--- /tmp/pr34999.org/pr34999.s2012-02-29 18:59:32.0 -0800
+++ /tmp/pr34999.fix/pr34999.s2012-03-14 17:37:56.0 -0700
@@ -210,7 +210,8 @@
 .long L$set$9
 LASFDE5:
 .longLASFDE5-EH_frame1
-.quadLCOLDB2-.
+.set L$set$temp,LCOLDB2-.
+.quadL$set$temp
 .set L$set$10,LCOLDE2-LCOLDB2
 .quad L$set$10
 .byte0

The darwin linker knows how to parse __eh_frame. It does not need relocations.

[Bug c/52794] gcc.dg/tree-prof/pr52027.c fails on x86_64/i386-apple-darwin*

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

  Attachment #27046|0   |1
is obsolete||

--- Comment #2 from Jack Howarth  2012-03-30 
19:39:28 UTC ---
Created attachment 27047
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27047
testcase from radar://10960042 generated on x86_64-apple-darwin11

[Bug c/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2012-03-30 
19:40:43 UTC ---
Created attachment 27048
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27048
testcase from radar://10960042 generated on x86_64-apple-darwin11 (

The FSF gcc testsuite failure...

FAIL: gcc.dg/tree-prof/pr34999.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr34999.c execution,-fprofile-use
-D_PROFILE_USE

seen at -m64 with Xcode 4.3's linker may be showing a linker bug. The attached
testcase contains the files obtained with...

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120228/gcc/testsuite/gcc.dg/tree-prof/pr34999.c
   -O2 -freorder-blocks-and-partition -fprofile-generate -D_PROFILE_GENERATE 
-lm   -m64 -o pr34999.x01

Executing the resulting pr34999.x01 to produce the profiling code in
pr34999.gcda (provided) and...

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120228/gcc/testsuite/gcc.dg/tree-prof/pr34999.c
-O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -lm -m64
--save-temps -v -o pr34999.x02

which produces the linker error...

Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-128.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1519.
0  0x10c62d1df  __assert_rtn + 79
1  0x10c648ae5 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 917
2  0x10c63632e  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 286
3  0x10c632b2b  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 91
4  0x10c66b6fd  ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool)
+ 653
5  0x10c66ccfb  ld::tool::InputFiles::InputFiles(Options&, char const**) + 651
6  0x10c62d426  main + 358

which can be reproduced with the provided bad_link shell script which
executes...

ld -dynamic -arch x86_64 -macosx_version_min 10.7.3 -weak_reference_mismatches
non-weak -o pr34999.x02 -lcrt1.10.6.o -L. pr34999.o -no_compact_unwind -lSystem
-lgcc_ext.10.5 -lgcc -lSystem -v

[Bug c++/52762] Firefox 11 segfault with gcc 4.7 (-O3 -march=corei7-avx)

[fragabr at gmail dot com]

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

--- Comment #8 from Dâniel Fraga  2012-03-30 19:54:47 
UTC ---
(In reply to comment #7)
> Happens in java script, which does JITed code.
> My guess is that one of the transition points between JITed code and C code
> does not save AVX registers correctly or something like that.
> I would file it with mozilla.org, it's more likely their bug.

Thanks Andi. I already had filled a bug in mozilla bugzilla. But unfortunatelly
nobody answered. I'll wait. Thanks.

Ps: should I mark this bug as "invalid"?

[Bug libitm/52787] Segmentation fault on MinGW

[i.nixman at gmail dot com]

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

--- Comment #2 from niXman  2012-03-30 19:55:51 UTC 
---
>Based to your e-mail on gcc-help, you left out a very important piece of
information.
Yes, Ian. I had to mention it.
And yes, I'm not saying that libitm is supported by MinGW. And yes, as libitm
is not supported by MinGW - it's not a bug. I hurried with the creation of the
bug report.

I'd really like to make libitm work with MinGW. I would like to understand why
SIGSEGV occurs...

Thanks.

[Bug libitm/52787] Segmentation fault on MinGW

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #3 from Kai Tietz  2012-03-30 20:15:13 
UTC ---
(In reply to comment #2)
> >Based to your e-mail on gcc-help, you left out a very important piece of
> information.
> Yes, Ian. I had to mention it.
> And yes, I'm not saying that libitm is supported by MinGW. And yes, as libitm
> is not supported by MinGW - it's not a bug. I hurried with the creation of the
> bug report.
> 
> I'd really like to make libitm work with MinGW. I would like to understand why
> SIGSEGV occurs...
> 
> Thanks.

Well, the configure patch required for this bug-report misses an important part
AFAICS.  You have to make sure that pthread-API is present, as libitm depends
on pthread.
This report is btw invalid, as this feature isn't supported for mingw targets
right now. So I close it.  Please keep discussion about adding support for
libitm on gcc's patches ML.

[Bug c++/52796] New: [4.6/4.7 C++11] Initialization of primitive object with 0-length parameter pack fails to value-initialize

[jyasskin at gcc dot gnu.org]

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

 Bug #: 52796
   Summary: [4.6/4.7 C++11] Initialization of primitive object
with 0-length parameter pack fails to value-initialize
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


The following program attempts to initialize a 'char' member using a variadic
parameter pack. With length 0, the initialization doesn't happen, leaving the
original value of the memory in the field. I originally noticed this in gcc-4.6
when std::list(3) failed to initialize the list elements.


$ cat test.cc
#include 
#include 

template
class Wrapper {
 public:
#if WORK
  Wrapper()
  : t() {
  }
#endif
  template
  Wrapper(Args&&... args)
  : t(args...) {
  }

  T t;
};

int main() {
  __attribute__(aligned(alignof(Wrapper))) char
space[sizeof(Wrapper)];
  memset(space, '\xab', sizeof(space));
  Wrapper*w = new(space) Wrapper;
  std::cout << (int)w->t << '\n';
  w->~Wrapper();
  memset(space, '\xab', sizeof(space));
  w = new(space) Wrapper();
  std::cout << (int)w->t << '\n';
  w->~Wrapper();
  memset(space, '\xab', sizeof(space));
  w = new(space) Wrapper((int)'y');
  std::cout << (int)w->t << '\n';
  w->~Wrapper();
}

$ g++-4.7pre --version
g++-4.7pre (GCC) 4.7.1 20120330 (prerelease)
...
$ g++-4.7pre -Wall -std=c++11 test.cc -g3 -o test && ./test
-85
0
121


Disassembling with gdb shows:

Dump of assembler code for function Wrapper::Wrapper<>():
   0x00400a70 <+0>: push   %rbp
   0x00400a71 <+1>: mov%rsp,%rbp
   0x00400a74 <+4>: mov%rdi,-0x8(%rbp)
=> 0x00400a78 <+8>: pop%rbp
   0x00400a79 <+9>: retq

[Bug tree-optimization/52797] New: Revision 185913 causes ICE in get_loop_body, at cfgloop.c:831 on PowerPC

[pthaugen at gcc dot gnu.org]

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

 Bug #: 52797
   Summary: Revision 185913 causes ICE in get_loop_body, at
cfgloop.c:831 on PowerPC
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: berg...@gcc.gnu.org, rgue...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


ICE during build of libstdc++.

/home/pthaugen/src/gcc/trunk/gcc/libstdc++-v3/src/c++98/streambuf.cc:113:5:
internal compiler error: in get_loop_body, at cfgloop.c:831
Please submit a full bug report,


Config command used:

/home/pthaugen/src/gcc/trunk/gcc/configure
--prefix=/home/pthaugen/install/gcc/trunk --target=powerpc64-linux
--host=powerpc64-linux --build=powerpc64-linux --enable-secureplt
--enable-threads=posix --enable-shared --enable-__cxa_atexit
--with-long-double-128 --enable-decimal-float --disable-alsa --enable-checking
--with-lto --with-as=/home/pthaugen/install/binutils/binutils-2.21.1/bin/as
--with-ld=/home/pthaugen/install/binutils/binutils-2.21.1/bin/ld
--with-gmp=/home/pthaugen/install/gcc-host-libs
--with-mpfr=/home/pthaugen/install/gcc-host-libs
--with-mpc=/home/pthaugen/install/gcc-host-libs
--with-ppl=/home/pthaugen/install/gcc-host-libs
--with-cloog=/home/pthaugen/install/gcc-host-libs
--with-host-libstdcxx=-Wl,-Bstatic,-L/home/pthaugen/install/gcc-host-libs/lib,-lstdc++,-Bdynamic,-lm
--enable-languages=c,fortran,c++ --disable-bootstrap

[Bug tree-optimization/52797] [4.8 Regression] Revision 185913 causes ICE in get_loop_body, at cfgloop.c:831 on PowerPC

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|powerpc64-linux |powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-30
   Host|powerpc64-linux |powerpc*-*-*
Summary|Revision 185913 causes ICE  |[4.8 Regression] Revision
   |in get_loop_body, at|185913 causes ICE in
   |cfgloop.c:831 on PowerPC|get_loop_body, at
   ||cfgloop.c:831 on PowerPC
 Ever Confirmed|0   |1
  Build|powerpc64-linux |powerpc*-*-*

--- Comment #1 from Dominique d'Humieres  2012-03-30 
21:15:17 UTC ---
Confirmed on powerpc-apple-darwin9. Compiling the preprocessed code with '-O2
-m64' gives the ICE, but not when using '-O2' nor '-O1 -m64'.

[Bug tree-optimization/52797] [4.8 Regression] Revision 185913 causes ICE in get_loop_body, at cfgloop.c:831 on PowerPC

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-03-30 
21:16:28 UTC ---
Created attachment 27049
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27049
Preprocessed file streambuf.ii

[Bug c++/52796] [4.6/4.7 C++11] Initialization of primitive object with 0-length parameter pack fails to value-initialize

[jyasskin at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey Yasskin  2012-03-30 
21:18:09 UTC ---
Created attachment 27050
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27050
Test file demonstrating improvement from 4.6->4.7

The attached 46_vs_47.cc shows that gcc-4.7 calls the default constructor for
pack uses like new Type(args...), while gcc-4.6 didn't. So 4.7 doesn't have the
std::list bug.  I tested this with valgrind-3.6.0:

$ g++-4.6.x --version
g++-4.6.x (GCC) 4.6.4 20120330 (prerelease)

$ g++-4.6.x -Wall -std=c++0x 46_vs_47.cc -g3 -o test && /usr/bin/valgrind
./test
...
==15840== Conditional jump or move depends on uninitialised value(s)
==15840==at 0x4EB8074: std::ostreambuf_iterator > std::num_put > >::_M_insert_int(std::ostreambuf_iterator >, std::ios_base&, char, long) const
(locale_facets.tcc:872)
==15840==by 0x4EB8395: std::num_put > >::do_put(std::ostreambuf_iterator >, std::ios_base&, char, long) const
(locale_facets.h:2475)
==15840==by 0x4EC33CC: std::ostream& std::ostream::_M_insert(long)
(locale_facets.h:2336)
==15840==by 0x400BF7: void check_init<>() (46_vs_47.cc:19)
==15840==by 0x400AC1: main (46_vs_47.cc:24)
...
0
3
==15840== Conditional jump or move depends on uninitialised value(s)
==15840==at 0x4EB8074: std::ostreambuf_iterator > std::num_put > >::_M_insert_int(std::ostreambuf_iterator >, std::ios_base&, char, long) const
(locale_facets.tcc:872)
==15840==by 0x4EB8395: std::num_put > >::do_put(std::ostreambuf_iterator >, std::ios_base&, char, long) const
(locale_facets.h:2475)
==15840==by 0x4EC33CC: std::ostream& std::ostream::_M_insert(long)
(locale_facets.h:2336)
==15840==by 0x400B03: main (46_vs_47.cc:27)
...
0

$ g++-4.7pre --version
g++-4.7pre (GCC) 4.7.1 20120330 (prerelease)
$ g++-4.7pre -Wall -std=c++11 test.cc -g3 -o test && /usr/bin/valgrind ./test
==8931== Memcheck, a memory error detector
==8931== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==8931== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==8931== Command: ./test
==8931== 
0
3
0

[Bug c++/52796] [4.6/4.7/4.8 C++11] Initialization of primitive object with 0-length parameter pack fails to value-initialize

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin  changed:

   What|Removed |Added

Summary|[4.6/4.7 C++11] |[4.6/4.7/4.8 C++11]
   |Initialization of primitive |Initialization of primitive
   |object with 0-length|object with 0-length
   |parameter pack fails to |parameter pack fails to
   |value-initialize|value-initialize

--- Comment #2 from Jeffrey Yasskin  2012-03-30 
21:22:30 UTC ---
And 4.8.0 20120330 matches 4.7's behavior for both test cases.

[Bug tree-optimization/52798] New: __builtin_object_size() based overflow check is a false positive due to parameter optimisation

[gcc at breakpoint dot cc]

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

 Bug #: 52798
   Summary: __builtin_object_size() based overflow check is a
false positive due to parameter optimisation
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@breakpoint.cc
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu


This is slightly modified from linux kernel fs/binfmt_misc.c:

 static int parse_command(const char __user *buffer, size_t count)
 {   
 char s[40];
 if (!count)
 return 0;
 if (count > 3)
 return -EINVAL;
 if (count == 1 || count == 2 || count == 3)
 if (copy_from_user(s, buffer, count))
 return -EFAULT;
 if (copy_from_user(s, buffer, count))
 return -EFAULT;
}

Each copy_from_user() has a __builtin_object_size() based check for length of s
vs length specified in count. The s buffer is 40bytes, we return if count >3.
copy_from_user() produces a #error/#warning for in the overflow case where
count is larger than s.
Since we do check for count >3 and abort, there is no overflow.
gcc on the other hand detects one. Both calls are in my opinion the same. Using
only the first check (count ==1 || count...) avoids the warning, the second
triggers the warning.

The short version of the assembly looks the following way (param via regs in
x86-32, count in edx):
07e0 :
8d 72 fflea-0x1(%edx),%esi
83 fe 02cmp$0x2,%esi
77 5d   ja 858 

(esi - 1) compared against 2, so this is the >3 check (and 0 I guess).
#1 call to the copy routine

   89 d9   mov%ebx,%ecx
   89 fa   mov%edi,%edx
   e8 fc ff ff ff  call   81a 
#2 call to the copy routine. There is no check for ebx/ecx in between, so the
count check from #1 is 
recognized as unchanged and valid.

This looks to me like gcc knows the exact (and correct) size of s in both cases
but somehow an optimization pass removes it (because it redundant) and the gcc
threats it as not available and therefore produces the warning.

The copy routine looks the following:

 static inline unsigned long __must_check copy_from_user(void *to,
   const void __user *from,
   unsigned long n)
 {
 int sz = __compiletime_object_size(to);
/* asm volatile(""); */

 if (likely(sz == -1 || sz >= n))
 n = _copy_from_user(to, from, n);
 else
 copy_from_user_overflow();

 return n;
 }

Adding the asm volatile statement (where it is commented out) adds the
follwoing code before the second call:

  83 fb 28cmp$0x28,%ebx
  77 65   ja 875 

So here the compiler really assumes that there is no upper limit of count.

I attach the .i output of the testcase which can be compiled with:
 gcc -O2 -m32 -pipe -c -o binfmt_misc.o binfmt_misc.i

The outout "error: call to ‘co.." is returned if gcc detects the overflow.

Sebastian

[Bug tree-optimization/52798] __builtin_object_size() based overflow check is a false positive due to parameter optimisation

[gcc at breakpoint dot cc]

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

--- Comment #1 from Sebastian Andrzej Siewior  
2012-03-30 21:54:33 UTC ---
Created attachment 27051
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27051
.i test case

[Bug libstdc++/52799] New: deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist

[jyasskin at gcc dot gnu.org]

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

 Bug #: 52799
   Summary: deque::emplace(iterator, ...) tries to call
push_front(...), which doesn't exist
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


$ cat emplace.cc
#include 

int main() {
  std::deque d;
  d.emplace(d.begin());
}
$ g++-4.8pre --version
g++-4.8pre (GCC) 4.8.0 20120330 (experimental)
$ g++-4.8pre -std=c++11 emplace.cc -c -o /dev/null
In file included from .../include/c++/4.8.0/deque:67:0,
 from emplace.cc:1:
.../include/c++/4.8.0/bits/deque.tcc: In instantiation of ‘std::deque<_Tp,
_Alloc>::iterator std::deque<_Tp, _Alloc>::emplace(std::deque<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {}; _Tp = int; _Alloc =
std::allocator; std::deque<_Tp, _Alloc>::iterator =
std::_Deque_iterator]’:
emplace.cc:5:22:   required from here
.../include/c++/4.8.0/bits/deque.tcc:178:6: error: no matching function for
call to ‘std::deque::push_front()’
.../include/c++/4.8.0/bits/deque.tcc:178:6: note: candidates are:
In file included from .../include/c++/4.8.0/deque:65:0,
 from emplace.cc:1:
.../include/c++/4.8.0/bits/stl_deque.h:1357:7: note: void std::deque<_Tp,
_Alloc>::push_front(const value_type&) [with _Tp = int; _Alloc =
std::allocator; std::deque<_Tp, _Alloc>::value_type = int]
.../include/c++/4.8.0/bits/stl_deque.h:1357:7: note:   candidate expects 1
argument, 0 provided
.../include/c++/4.8.0/bits/stl_deque.h:1370:7: note: void std::deque<_Tp,
_Alloc>::push_front(std::deque<_Tp, _Alloc>::value_type&&) [with _Tp = int;
_Alloc = std::allocator; std::deque<_Tp, _Alloc>::value_type = int]
.../include/c++/4.8.0/bits/stl_deque.h:1370:7: note:   candidate expects 1
argument, 0 provided
...


The problem is that deque::emplace(iterator __position, _Args&&... __args)
tries to forward to push_front(std::forward<_Args>(__args)...) instead of
emplace_front(std::forward<_Args>(__args)...), and similarly for *_back().

I haven't checked the other containers for similar problems.

[Bug middle-end/52800] New: eglibc build broken with internal compiler error in cfgloop .

[ramana at gcc dot gnu.org]

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

 Bug #: 52800
   Summary: eglibc build broken with internal compiler error in
cfgloop .
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ram...@gcc.gnu.org
  Host: x86_64-linux-gnu
Target: arm-linux-gnueabi
 Build: x86_64-linux-gnu


eglibc builds broken with trunk on arm-linux-gnueabi with an internal compiler
error in cfgloop.c  - it has happened in about the last 3 days or so since my
last successful build was on 27th March. 

$> 
/work/cross-build/fsf/arm-none-linux-gnueabi/tools-lowersubregchanges-patched/bin/arm-none-linux-gnueabi-gcc
-c -O2 ./besttry.c  -mfloat-abi=soft -march=armv5te
./besttry.c: In function ‘_IO_new_file_write’:
./besttry.c:36:1: internal compiler error: in get_loop_body, at cfgloop.c:831


__extension__ typedef int __ssize_t;
extern __thread int __libc_errno __attribute__ ((tls_model ("initial-exec")));
struct _IO_FILE {
  int _fileno;
  int _flags2;
};
typedef struct _IO_FILE _IO_FILE;
_IO_new_file_write (f,
  data,
  n)
 _IO_FILE *f;
{
  __ssize_t to_do = n;
  while (to_do>  0)
{
  __ssize_t count =
 (__builtin_expect (f->_flags2&  2, 0) ?

  ({ unsigned int _sys_result = ({ register int _a1 asm ("r0"), _nr asm ("r7");
int _a3tmp = (int) ((to_do));
int _a2tmp = (int) ((data));
register int _a2 asm ("a2") = _a2tmp;
register int _a3 asm ("a3") = _a3tmp; _nr = ((0 + 4));
asm volatile ("swi 0x0 @ syscall " "SYS_ify(write)" : "=r"
(_a1) : "r" (_nr) , "r" (_a1), "r" (_a2), "r" (_a3) : "memory"); _a1;
});
if (__builtin_expect (((unsigned int) (_sys_result)>= 0xf001u), 0))
  { (__libc_errno = ((-(_sys_result;
_sys_result = (unsigned int) -1; }
(int) _sys_result; })
  : __write (f->_fileno, data, to_do));
  if (count<  0)
 {
   break;
}
  to_do -= count;
}
}

[Bug middle-end/52800] eglibc build broken with internal compiler error in cfgloop .

[ramana at gcc dot gnu.org]

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

--- Comment #1 from Ramana Radhakrishnan  2012-03-30 
23:34:41 UTC ---
Richi - probably yours - 

svn+ssh://gcc.gnu.org/svn/gcc/trunk@185913 broken 
svn+ssh://gcc.gnu.org/svn/gcc/trunk@185910 good 


regards,
Ramana

[Bug c++/52801] New: improve selective typedef unwrapping

[manu at gcc dot gnu.org]

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

 Bug #: 52801
   Summary: improve selective typedef unwrapping
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


#include 
#include 
using namespace std;
typedef double Real;
string str;
vector vec;

void foo(void) {
  str = vec;
}

manuel@gcc12:~$ ~/bin/clang -fsyntax-only ~/g2.cpp 
/home/manuel/g2.cpp:9:7: error: no viable overloaded '='
  str = vec;
  ~~~ ^ ~~~
/usr/include/c++/4.3/bits/basic_string.h:500:7: note: candidate function not
viable: no known conversion from 'vector' to 'const
std::basic_string' for 1st argument; 
  operator=(const basic_string& __str) 
  ^
/usr/include/c++/4.3/bits/basic_string.h:508:7: note: candidate function not
viable: no known conversion from 'vector' to 'const char *' for 1st
argument;  
  operator=(const _CharT* __s) 
  ^
/usr/include/c++/4.3/bits/basic_string.h:519:7: note: candidate function not
viable: no known conversion from 'vector' to 'char' for 1st argument; 
  operator=(_CharT __c) 
  ^
1 error generated.  


/home/manuel/g2.cpp: In function ‘void foo()’:
/home/manuel/g2.cpp:9:9: error: no match for ‘operator=’ in ‘str = vec’
/home/manuel/g2.cpp:9:9: note: candidates are:
In file included from
/home/manuel/trunk/180166/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/string:54:0,
 from /home/manuel/g2.cpp:2:
/home/manuel/trunk/180166/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/basic_string.h:541:7:
note: std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT,
_Traits, _Alloc>::operator=(const std::basic_string<_CharT, _Traits, _Alloc>&)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator; std::basic_string<_CharT, _Traits, _Alloc> =
std::basic_string]
/home/manuel/trunk/180166/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/basic_string.h:541:7:
note:   no known conversion for argument 1 from ‘std::vector’ to ‘const
std::basic_string&’
/home/manuel/trunk/180166/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/basic_string.h:549:7:
note: std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT,
_Traits, _Alloc>::operator=(const _CharT*) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string]
/home/manuel/trunk/180166/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/basic_string.h:549:7:
note:   no known conversion for argument 1 from ‘std::vector’ to ‘const
char*’
/home/manuel/trunk/180166/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/basic_string.h:560:7:
note: std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT,
_Traits, _Alloc>::operator=(_CharT) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string]
/home/manuel/trunk/180166/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/basic_string.h:560:7:
note:   no known conversion for argument 1 from ‘std::vector’ to ‘char’

Example #4 of Typedef Preservation and Selective Unwrapping
http://clang.llvm.org/diagnostics.html

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[manu at gcc dot gnu.org]

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

--- Comment #22 from Manuel López-Ibáñez  2012-03-31 
00:25:50 UTC ---
Is there a final verdict on this? Jonathan, Paolo, did you change your mind? 

Or do you still think this should be fixed but you don't believe there is any
hope to get your patch approved?

[Bug c/52802] New: Equality rewrites pessimizes code

[gcc at magfr dot user.lysator.liu.se]

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

 Bug #: 52802
   Summary: Equality rewrites pessimizes code
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@magfr.user.lysator.liu.se


I have a function (in foo.c)

unsigned f(unsigned a, unsigned b)
{
if (a < 8)
return a;
else if (a == 8)
return b;
else
return 4711;
}

that GCC compiles to (x86_64, -Os)

cmpl$7, %edi#, a
movl%edi, %eax  # a, a
jbe .L2 #,
cmpl$8, %edi#, a
movl$4711, %eax #, tmp63
cmove   %esi, %eax  # b,, a
.L2:
ret

Here it is confusing to see that it starts by doing a "cmp $7, %edi" and then
goes on to do a "cmp $8, %edi" since I never said anything but 8, so the big
question is why there are two compares.

The reason seems to be premature optimization. The C parser tries to minimize
the value of all comparision values so that -fdump-tree-original shows

;; Function f (null)
;; enabled by -tree-original


{
  if (a <= 7)
{
  return a;
}
  else
{
  if (a == 8)
{
  return b;
}
  else
{
  return 4711;
}
}
}

and there the 7 have magically appeared.

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[manu at gcc dot gnu.org]

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

--- Comment #23 from Manuel López-Ibáñez  2012-03-31 
00:34:58 UTC ---
BTW, I think this example was mentioned some where already, but I cannot find
it now. From http://clang.llvm.org/diagnostics.html

manuel@gcc12:~$ cat t.cc
struct a {
  virtual int bar();
};

struct foo : public virtual a {
};

int test(foo *P) {
  return P->bar() + *P;
}

manuel@gcc12:~$ trunk/180166/install/bin/g++ -fsyntax-only ~/t.cc
/home/manuel/t.cc: In function ‘void test(foo*)’:
/home/manuel/t.cc:9:22: error: no match for ‘operator+’ in ‘(((a*)P) +
((sizetype)(*(long int*)(P->foo::.a::_vptr.a +
0xffe0u->a::bar() + * P’

manuel@gcc12:~$ ~/bin/clang -fsyntax-only ~/t.cc 
/home/manuel/t.cc:9:19: error: invalid operands to binary expression ('int' and
'foo')
  return P->bar() + *P;
  ^ ~~
1 error generated.

[Bug libstdc++/52799] deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-03-31
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.7.1
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-03-31 
00:57:22 UTC ---
Oh my, let's fix this for 4.7.1 too.

[Bug c++/39858] "expected primary-expression" error could be more useful

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #3 from Manuel López-Ibáñez  2012-03-31 
01:25:53 UTC ---
This patch does what you want, but it probably fails in unexpected ways because
some callers to cp_parser_primary_expression expect it to give the error
itself, so they won't actually emit an error. One would need to check
error_mark_node in all callers and give an appropriate diagnostic. Even if
someone did that work, I still doubt it will be accepted.


Index: parser.c
===
--- parser.c(revision 184424)
+++ parser.c(working copy)
@@ -4379,11 +4379,11 @@ cp_parser_primary_expression (cp_parser 
return decl;
   }

   /* Anything else is an error.  */
 default:
-  cp_parser_error (parser, "expected primary-expression");
+  /*  cp_parser_error (parser, "expected primary-expression");*/
   return error_mark_node;
 }
 }

 /* Parse an id-expression.
@@ -5862,12 +5862,14 @@ cp_parser_postfix_open_square_expression
{
  bool expr_nonconst_p;
  maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
  index = cp_parser_braced_list (parser, &expr_nonconst_p);
}
-  else
+  else 
index = cp_parser_expression (parser, /*cast_p=*/false, NULL);
+  if (index == error_mark_node)
+   error_at (input_location, "missing subscript");
 }

   /* Look for the closing `]'.  */
   cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE);



An alternative would be to just give a normal error that is:

@@ -4379,11 +4379,11 @@ cp_parser_primary_expression (cp_parser 
return decl;
   }

   /* Anything else is an error.  */
 default:
-  cp_parser_error (parser, "expected primary-expression");
+  error ("expected expression");
   return error_mark_node;
 }
 }

 /* Parse an id-expression.

[Bug libstdc++/52799] deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2012-03-31 01:57:20 UTC ---
Author: paolo
Date: Sat Mar 31 01:57:14 2012
New Revision: 186036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186036
Log:
2012-03-30  Jeffrey Yasskin  
Paolo Carlini  

PR libstdc++/52799
* include/bits/deque.tcc (emplace): Fix thinko, replace push_front
-> emplace_front, and likewise for *_back.
* testsuite/23_containers/deque/modifiers/emplace/52799.cc: New.
* testsuite/23_containers/list/modifiers/emplace/52799.cc: Likewise.
* testsuite/23_containers/vector/modifiers/emplace/52799.cc: Likewise.

Added:
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/52799.cc
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/list/modifiers/emplace/
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/list/modifiers/emplace/52799.cc
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/vector/modifiers/emplace/
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/vector/modifiers/emplace/52799.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/deque.tcc

[Bug libstdc++/52799] deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2012-03-31 01:57:00 UTC ---
Author: paolo
Date: Sat Mar 31 01:56:55 2012
New Revision: 186035

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186035
Log:
2012-03-30  Jeffrey Yasskin  
Paolo Carlini  

PR libstdc++/52799
* include/bits/deque.tcc (emplace): Fix thinko, replace push_front
-> emplace_front, and likewise for *_back.
* testsuite/23_containers/deque/modifiers/emplace/52799.cc: New.
* testsuite/23_containers/list/modifiers/emplace/52799.cc: Likewise.
* testsuite/23_containers/vector/modifiers/emplace/52799.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/
trunk/libstdc++-v3/testsuite/23_containers/deque/modifiers/emplace/52799.cc
trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/emplace/
trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/emplace/52799.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/emplace/
   
trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/emplace/52799.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/deque.tcc

[Bug libstdc++/52799] deque::emplace(iterator, ...) tries to call push_front(...), which doesn't exist

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Paolo Carlini  2012-03-31 
01:59:27 UTC ---
Done.

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[paolo.carlini at oracle dot com]

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

--- Comment #24 from Paolo Carlini  2012-03-31 
02:03:02 UTC ---
Personally, I don't believe Gaby is open to other solutions outside the
full-fledged "caret diagnostics" context, thus for the time being at least I'm
personally going to stand to his judgment (as diagnostics maintainer).

[Bug c++/49152] Unhelpful diagnostic for iterator dereference

[paolo.carlini at oracle dot com]

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

--- Comment #25 from Paolo Carlini  2012-03-31 
02:15:19 UTC ---
And, hey, I'm of course speaking only for myself, you are welcome to pursue a
compromise solution. For example, I don't know, if we could identify a
*restricted* class of expressions which we have troubles reconstructing and
propose skipping printing the expressions only in those specific cases.