[Bug inline-asm/65898] GCC puts auto generated code between two asm volatile(".intel_syntax"); and asm volatile(".att_syntax"); globally syntaxed rather than not put or change it's syntax

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65898

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andreas Schwab  ---
There is no way for GCC to know the meaning or effect of your hand crafted asm
statements.

[Bug fortran/37131] inline matmul for small matrix sizes

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131

--- Comment #22 from Andreas Schwab  ---
Program aborted. Backtrace:
#0  0x3FF95D8B973
FAIL: gfortran.dg/bound_9.f90   -O  execution test

[Bug fortran/37131] inline matmul for small matrix sizes

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131

--- Comment #23 from Uroš Bizjak  ---
(In reply to Andreas Schwab from comment #22)
> Program aborted. Backtrace:
> #0  0x3FF95D8B973
> FAIL: gfortran.dg/bound_9.f90   -O  execution test

Thanks for the report! Before we can proceed, please send us all the
information that we need to solve the bug. Please read [1] for further
instructions.

[1] https://gcc.gnu.org/bugs/#report

[Bug translation/65959] New: plain text incorrectly marked as format-c

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65959

Bug ID: 65959
   Summary: plain text incorrectly marked as format-c
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From gcc/po/gcc.pot:

#: params.def:417
#, c-format
msgid "Set the estimated probability in percentage for builtin expect. The
default value is 90% probability."
msgstr "Wahrscheinlichkeit in Prozent für das eingebaute »expect«. Vorgabewert
ist 90 % Wahrscheinlichkeit."

This is not a %p format specifier.

[Bug c++/60198] ICE with _Cilk_spawn in expression within template function

[hvdieren at elis dot ugent.be]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198

Hans Vandierendonck  changed:

   What|Removed |Added

 CC||hvdieren at elis dot ugent.be

--- Comment #7 from Hans Vandierendonck  ---
The following code snippet
===
template int foo()
{
  int i = (_Cilk_spawn foo()) + 0;
  return i;
}

template int foo();
===

is invalid. You are not allowed to use the result of a spawned function until
after a _Cilk_sync; statement.

But that is no excuse for an ICE.

[Bug translation/65959] plain text incorrectly marked as format-c

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65959

--- Comment #1 from Roland Illig  ---
I only noticed this because GNU gettext complains that I must not translate %p
to %W.

Error: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the
directive number 1, the character 'W' is not a valid conversion specifier.

[Bug middle-end/65960] New: ICE in Cilk spawn with argument with non-trivial constructor

[hvdieren at elis dot ugent.be]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65960

Bug ID: 65960
   Summary: ICE in Cilk spawn with argument with non-trivial
constructor
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hvdieren at elis dot ugent.be
  Target Milestone: ---

This code causes an ICE:

struct non_trivial {
int x;

non_trivial( int y ) : x( y ) { }
non_trivial( const non_trivial & s ) : x( s.x ) { }
~non_trivial() { }
};

int foo( non_trivial s );

int func( non_trivial s ) {
int x = cilk_spawn foo( s );
int y = 10;
cilk_sync;
return y - x;
}



Command line output:
$ g++-4.9.2 -fcilkplus struct.cc -o struct
struct.cc: In function '':
struct.cc:28:31: internal compiler error: in lower_stmt, at gimple-low.c:370
 int x = cilk_spawn foo( s );
   ^
0xddba13 lower_stmt
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:370
0xddba13 lower_sequence
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:206
0xddbb1a lower_try_catch
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:443
0xddbb1a lower_stmt
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:270
0xddbb1a lower_sequence
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:206
0xddb8dc lower_stmt
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:275
0xddb8dc lower_sequence
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:206
0xddb741 lower_gimple_bind
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:415
0xddc5cd lower_function_body
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:118
0xddc5cd execute
/var/jonny/gcc/objdir/../gcc-4.9.2/gcc/gimple-low.c:184
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The tested OS was CentOS 6.6.

For reference Intel icc handles this case correctly.

[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[rai...@emrich-ebersheim.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #30 from Rainer Emrich  ---
I'm testing the following instead:

Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (Revision 222611)
+++ gcc/lto-wrapper.c   (Arbeitskopie)
@@ -934,12 +934,9 @@ run_gcc (unsigned argc, char *argv[])
  filename[p - argv[i]] = '\0';
  file_offset = (off_t) loffset;
}
-  fd = open (argv[i], O_RDONLY);
+  fd = open (argv[i], O_RDONLY|O_BINARY);
   if (fd == -1)
-   {
- lto_argv[lto_argc++] = argv[i];
- continue;
-   }
+   continue;

   if (find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
  &fdecoded_options, &fdecoded_options_count,

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65955

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-01
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Created attachment 35434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35434&action=edit
Proposed fix

Could you please give this patch a try?
Unfortunately I don't have ada on my arm system so I can't try it out at the
moment.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968

--- Comment #30 from Frédéric Buclin  ---
(I added some debug code to Bugzilla to try to understand what's wrong. Just
ignore this email.)

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968

--- Comment #31 from Frédéric Buclin  ---
(ignore this one as well)

[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65951

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Yes you are right, we have no V2DI multiply. We do have V2DI shifts + add,
however, which would work well for some constants, e.g. the multiply by 16 in
PR/65952; perhaps the vectorizer does not consider such possibilities (whereas
we do for scalar code).

[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Hmmm. Yes. Well, x * 16 = x << 4, of course. Or, in theory something like VRP
could let us see that

  # i_12 = PHI 
  # ivtmp_18 = PHI 
  _5 = (long unsigned int) i_12;
  _6 = _5 * 16;
  _7 = pretmp_11 + _6;
  ptrs[i_12] = _7;
  i_9 = i_12 + 1;

could be rewritten to something like

  # i_12 = PHI 
  # ivtmp_18 = PHI 
  _5 = _12 * 16;
  _6 = (long unsigned int) _5;
  _7 = pretmp_11 + _6;
  ptrs[i_12] = _7;
  i_9 = i_12 + 1;

which would then be vectorizable.

[Bug libgomp/65904] Memory corruption with acc_shutdown, nvptx offloading, libgomp.oacc-c-c++-common/asyncwait-1.c

[jules at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65904

jules at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-01
 Ever confirmed|0   |1

--- Comment #1 from jules at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00021.html

[Bug tree-optimization/64454] optimize (x%5)%5

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454

--- Comment #9 from Marc Glisse  ---
VRP could still do better:

typedef unsigned short T;
T f(T x, T y){
  // Avoid narrowing in the front-end
  int ix=x;
  int iy=y;
  T z=ix%iy;
  int iz=z;
  return z%iy;
}

ix and iy both have range [0, 65535], but we don't optimize

_9 = _5 & 65535;

because

Visiting statement:
_5 = ix_2 % iy_4;
Found new range for _5: VARYING

Whereas (since the type is unsigned, the signed case is slightly more
complicated but should still be doable) the range for _5 should be the
intersection of [0, 65535] (at most max(ix_2)) and [0, 65534] (at most
max(iy_4)-1).

Even in the constant case, if x has range [0, 3], VRP currently says that x%7
has range [0, 6].

[Bug c/65961] New: ice in vect_is_simple_use_1 with -O3

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961

Bug ID: 65961
   Summary: ice in vect_is_simple_use_1 with -O3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35435&action=edit
C source code

The attached code, when compiled by gcc trunk dated 20150429
and with flag -O3, says this:

qshs.c: In function ‘shs1’:
qshs.c:136:1: internal compiler error: in vect_is_simple_use_1, at
tree-vect-stmts.c:7867
0xdca504 vect_is_simple_use_1(tree_node*, gimple_statement_base*,
_loop_vec_info*, _bb_vec_info*, gimple_statement_base**, tree_node**,
vect_def_type*, tree_node**)
../../src/trunk/gcc/tree-vect-stmts.c:7867
0xdd3d5a vectorizable_operation
../../src/trunk/gcc/tree-vect-stmts.c:4676
0xddc731 vect_analyze_stmt(gimple_statement_base*, bool*, _slp_tree*)
../../src/trunk/gcc/tree-vect-stmts.c:7196
0xdf1319 vect_slp_analyze_node_operations
../../src/trunk/gcc/tree-vect-slp.c:2094

tree-vect-stmts.c:7867 is

gcc_assert (*vectype != NULL_TREE);

[Bug c/65958] -fstack-check breaks __builtin(alloca)

[basile at opensource dot dyc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65958

Anthony G. Basile  changed:

   What|Removed |Added

 CC||basile at opensource dot 
dyc.edu

--- Comment #1 from Anthony G. Basile  ---
We should add that we've only seen this on arm arch.

[Bug fortran/37131] inline matmul for small matrix sizes

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131

--- Comment #24 from Dominique d'Humieres  ---
Reduced test

module tst
  implicit none
contains

  subroutine bar (a, b, n, m)
integer, dimension(:), allocatable, intent(inout) :: a
integer, dimension(:), pointer, intent(inout) :: b
integer, intent(out) :: n, m
n = lbound(a,1)
m = lbound(b,1)
  end subroutine bar

end module tst

program main
  use tst
  implicit none
  integer, dimension(:), allocatable :: x
!  integer, dimension(:), allocatable, target :: x
  integer, dimension(:), pointer :: y
  integer :: n,m


  allocate (x(0))
!  y => x
  call bar (x, y, n, m)
!  print *, m, n
  if (n .ne. 1 .or. m .ne. 1) call abort

end program main

gives

Program aborted. Backtrace:
#0  0x1020a0472
#1  0x1020a1612
#2  0x102176428
#3  0x102098ecb
Abort

The program runs without abort if

(1) I uncomment the line

!  print *, m, n

(2) I uncomment the lines

!  integer, dimension(:), allocatable, target :: x

and

!  y => x

and I comment the line

  integer, dimension(:), allocatable :: x

I wonder if the above code is valid Fortran.

[Bug tree-optimization/65961] [6 Regression] ice in vect_is_simple_use_1 with -O3

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65961

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-01
 CC||trippels at gcc dot gnu.org
  Component|c   |tree-optimization
Summary|ice in vect_is_simple_use_1 |[6 Regression] ice in
   |with -O3|vect_is_simple_use_1 with
   ||-O3
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
int *a;
void
foo ()
{
  do
{
  a[16] = (a[1] ^ a[0]) << 1 | a[1];
  a[17] = (a[0] ^ a[1]) << 1 | a[0];
  a[18] = (a[0] ^ a[1]) << 1 | a[0];
  a[19] = (a[0] ^ a[1]) << 1 | a[0];
  a[20] = (a[0] ^ a[1]) << 1 | a[0];
  a[21] = (a[0] ^ a[1]) << 1 | a[0];
  a[22] = (a[0] ^ a[1]) << 1 | a[0];
  a[23] = (a[20] ^ a[1]) << 1 | a[9];
  a += 8;
}
  while (1);
}

[Bug middle-end/65962] New: Missed vectorization of strided stores

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

Bug ID: 65962
   Summary: Missed vectorization of strided stores
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---

This does not vectorize at -O3 on x86_64/-mavx or aarch64:
int
loop (int *data)
{
  int tot = 0;
  for (int i = 0; i < 256; i++)
data[i * 2] += 7;
  return tot;
}

-fdump-tree-vect-details reveals:

loadstore.c:6:3: note: === vect_analyze_data_ref_accesses ===
loadstore.c:6:3: note: Detected single element interleaving *_8 step 8
loadstore.c:6:3: note: Data access with gaps requires scalar epilogue loop
loadstore.c:6:3: note: not consecutive access *_8 = _10;

loadstore.c:6:3: note: not vectorized: complicated access pattern.
loadstore.c:6:3: note: bad data access.

However, a similar testcase that only reads from those locations, vectorizes
ok:
int
loop_12 (int *data)
{
  int tot = 0;
  for (int i = 0; i < 256; i++)
tot += data[i * 2];
  return tot;
}
blocksort.c:6:3: note: === vect_analyze_data_ref_accesses ===
blocksort.c:6:3: note: Detected single element interleaving *_7 step 8
blocksort.c:6:3: note: Data access with gaps requires scalar epilogue loop

[Bug middle-end/65962] Missed vectorization of strided stores

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65962

--- Comment #1 from alalaw01 at gcc dot gnu.org ---
I believe this is a known issue, but have not identified an existing PR.

[Bug middle-end/65963] New: Missed vectorization of loads strided with << when equivalent * succeeds

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65963

Bug ID: 65963
   Summary: Missed vectorization of loads strided with << when
equivalent * succeeds
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---

This testcase does not vectorize at -O3 on x86_64/-mavx or AArch64:
void
loop (int *in, int *out)
{
  for (int i = 0; i < 256; i++) {
 out[i] = in[i << 1] + 7;
  }
}

-fdump-tree-vect-details reveals:
Creating dr for *_12
analyze_innermost: failed: evolution of base is not affine.
base_address: 
offset from base address: 
constant offset from base address: 
step: 
aligned to: 
base_object: *_12

However, this testcase succeeds:
void
loop (int *in, int *out)
{
  for (int i = 0; i < 256; i++) {
 out[i] = in[i * 2] + 7;
  }
}

The relevant extract of -fdump-tree-vect-details showing:
Creating dr for *_12
analyze_innermost: success.
base_address: in_11(D)
offset from base address: 0
constant offset from base address: 0
step: 8
aligned to: 256
base_object: *in_11(D)
Access function 0: {0B, +, 8}_1

The only difference is the multiplication:
$ diff splice{,2}.c.131t.ifcvt
27c27
<   _8 = i_19 * 2;
---
>   _8 = i_19 << 1;
$

[Bug c/65958] [arm] -fstack-check breaks __builtin(alloca)

[felix.janda at posteo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65958

--- Comment #2 from Felix Janda  ---
Actually I can hit this issue also with sh4 and microblaze. The test
program needs to be modified slightly:

int main(void)
{
char *p;
if(1) {
char i[48];
p = __builtin_alloca(8);
p[0] = 1;
}
if(1) {
char i[48] , j[64];
j[52] = 0;
}
return !p[0];
}

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[torvald at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #49 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #43)
> (In reply to torvald from comment #37)
> > (In reply to James Greenhalgh from comment #35)
> > > So by the strict letter of the specification, no memory references to
> > > visible data should be allowed to move from after the entire body of the
> > > intrinsic to before it. That is to say in:
> > > 
> > >   __sync_lock_test_and_set (foo, 1)
> > >   bar = 1
> > > 
> > > an observer should not be able to observe the write to bar before the 
> > > write
> > > to foo. This is a difference from the C++11 semantics.
> > 
> > Can you clarify how this observer would look like?  I think we should look
> > at both code examples that just use __sync for concurrent accesses, and
> > examples that also use normal memory accesses as if those would be
> > guaranteed to be atomic.  None of the __sync docs nor the psABI guarantee
> > any of the latter AFAIK.  I don't think it would be unreasonable to argue
> > that __sync doesn't make promises about non-DRF normal accesses, and so,
> > strictly speaking, maybe programs can't in fact rely on any of the behaviors
> > that are complicated to implement for ARM.  That's why I'd like to
> > distinguish those two cases.
> 
> Sure, it would look much like your cppmem example above, though you can add
> some
> barriers to the observer if you want to make a stronger example
> 
> bar = 0, foo = 0;
> 
> thread_a {
>   __sync_lock_test_and_set (foo, 1)
>   bar = 1
> }
> 
> thread_b {
>   /* If we can see the write to bar, the write
>  to foo must also have happened.  */
>   if (bar) /* Reads 1.  */
>assert (foo) /* Should never read 0.  */
> }

This is the case of allowing non-DRF normal accesses.  The *other* case I was
thinking about is how the test would have to look like when *not* allowing
them.  One way to do it would be:

thread_a {
  __sync_lock_test_and_set (foo, 1)
  __sync_lock_test_and_set (bar, 1) // or __sync_lock_release, or __sync RMW
}

thread_b {
  if (__sync_fetch_and_add (bar, 0))
assert (foo)  // DRF if thread_a's write is the final one
}

In this case, would the current ARM implementation still produce insufficient
code?  If not, at least in this test case, we could argue that there's nothing
wrong with what ARM does.  (The question whether we wan't to require DRF
strictly for __sync usage is of course still open.)

> > > I'm not worried about __sync_lock_release, I think the documentation is
> > > strong enough and unambiguous.
> > 
> > Are you aware that the GCC's __sync disallow store-store reordering across
> > __sync_lock_release, whereas the psABI docs don't?
> 
> No I was not, and even looking exactly for the text you were referring to,
> it took
> me three attempts to spot it. Yes, I understand now why you are concerned
> about
> the GCC wording. Perhaps this is just an artefact of a mistake transcribing
> the psABI?

I suppose so, but can't say for sure.  Somebody might have had x86 TSO in mind
when writing that, and perhaps not just accidentally.

However, we say psABI is the reference spec, so I agree we should change the
GCC __sync_lock_release docs accordingly.

[Bug fortran/37131] inline matmul for small matrix sizes

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131

--- Comment #25 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #24)
> I wonder if the above code is valid Fortran.

y is not associated, so not suitable for passing as ARRAY argument to LBOUND:

ARRAY
shall be an array of any type. It shall not be an unallocated allocatable
variable or a pointer that is not associated.

[Bug ada/65476] Long_Float array does not byte-swap correctly with reverse Scalar_Storage_Order

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65476

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri May  1 13:24:16 2015
New Revision: 222680

URL: https://gcc.gnu.org/viewcvs?rev=222680&root=gcc&view=rev
Log:
PR ada/65476
* config/arm/arm.c (arm_assemble_integer): Adjust call to assemble_real

Modified:
branches/scalar-storage-order/gcc/config/arm/arm.c

[Bug target/63791] use 32-byte version of vpbroadcastb (and register to poulate) on AVX/AVX2 platforms

[marcus.kool at urlfilterdb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791

Marcus Kool  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|use 32-byte version of  |use 32-byte version of
   |vpbroadcastb on AVX2|vpbroadcastb (and register
   |platform|to poulate) on AVX/AVX2
   ||platforms
  Known to fail||4.8.4, 4.9.2, 5.1.0
   Severity|minor   |normal

--- Comment #2 from Marcus Kool  ---
After the comment of Jakub I waited for the release of gcc 5.1.0 but
performance of programs that use *_set1_epi8() got 6% worse because gcc 5.1.0
now uses vpbroadcastb in the intended way but to populate the ymm register it
uses slow memory instead of a register.

This is what 5.1.0 generates:

movl%edi, -20(%rbp)
vpbroadcastb-20(%rbp), %ymm0

while this is optimal:
   vmovd %edi, %xmm0
   vpbroadcastb  %xmm0, %ymm0

Also for the AVX platform (see attachment avx.c) gcc 5.1.0 also uses memory and
many instructions to populate an xmm register:
movl%edi, -12(%rsp)
vpxor   %xmm1, %xmm1, %xmm1
vmovd   -12(%rsp), %xmm0
xorl%eax, %eax
vpshufb %xmm1, %xmm0, %xmm0
where
vmovd   %edi, %xmm0
vpbroadcastb %xmm0, %xmm0
is optimal.

To resume, gcc 4.8.4 and gcc 4.9.2 produce code that can be optimised further,
and gcc 5.1.0 produces even slower code which means that the implementation of
*_set1_epi8() is slower/much-slower than that it can be.

[Bug target/63791] use 32-byte version of vpbroadcastb (and register to poulate) on AVX/AVX2 platforms

[marcus.kool at urlfilterdb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791

--- Comment #3 from Marcus Kool  ---
Created attachment 35436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35436&action=edit
example code to show code generation on AVX platform (avx.c)

[Bug tree-optimization/65964] New: [meta] Operand Shortening

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964

Bug ID: 65964
   Summary: [meta] Operand Shortening
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com
  Target Milestone: ---

Meta bug for tracking operand shortening issues

[Bug translation/65959] plain text incorrectly marked as format-c

[schwab at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65959

--- Comment #2 from Andreas Schwab  ---
Author: schwab
Date: Fri May  1 14:07:51 2015
New Revision: 222682

URL: https://gcc.gnu.org/viewcvs?rev=222682&root=gcc&view=rev
Log:
Summary: Mark help string in DEFPARAM as no-c-format

PR translation/65959
* params.h (DEFPARAM): Rename msgid to nocmsgid.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.h

[Bug target/63791] use 32-byte version of vpbroadcastb (and register to poulate) on AVX/AVX2 platforms

[marcus.kool at urlfilterdb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791

--- Comment #4 from Marcus Kool  ---
> movl%edi, -12(%rsp)
> vpxor   %xmm1, %xmm1, %xmm1
> vmovd   -12(%rsp), %xmm0
> xorl%eax, %eax
> vpshufb %xmm1, %xmm0, %xmm0

The xorl instruction is part of an other statement and is not part of the code
generated by _mm_set1_epi8().

[Bug translation/65959] plain text incorrectly marked as format-c

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65959

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #3 from Andreas Schwab  ---
Fixed for gcc 6.

[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #31 from Kai Tietz  ---
(In reply to Richard Biener from comment #23)
> The patch looks pretty obvious to me - though I wonder if archives still
> work on x86_64-linux after it (or rather I wonder how they worked before...).
> 
> I'm not aware of @ doing any magic for filenames - do they?

No, me neither.

> So - please test this with boostrap-lto on x86_64-linux as well.

I did bootstrap for all languages (including lto) for x86_64-unknown-linux-gnu
without any new regressions.

Ok to apply to trunk?  Ok for release-branch 5, too?

[Bug middle-end/65965] New: Straight-line memcpy/memset not vectorized when equivalent loop is

[alalaw01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65965

Bug ID: 65965
   Summary: Straight-line memcpy/memset not vectorized when
equivalent loop is
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alalaw01 at gcc dot gnu.org
  Target Milestone: ---

Testcase:
void
test(int *__restrict__ a, int *__restrict__ b)
{
  a[0] = b[0];
  a[1] = b[1];
  a[2] = b[2];
  a[3] = b[3];
  a[5] = 0;
  a[6] = 0;
  a[7] = 0;
  a[8] = 0;
}
produces (at -O3) on AArch64:
test:
ldp w4, w3, [x1]
ldp w2, w1, [x1, 8]
stp w4, w3, [x0]
stp w2, w1, [x0, 8]
stp wzr, wzr, [x0, 20]
stp wzr, wzr, [x0, 28]
ret
or on x86_64/-mavx:
test:
.LFB0:
movl(%rsi), %eax
movl$0, 20(%rdi)
movl$0, 24(%rdi)
movl$0, 28(%rdi)
movl$0, 32(%rdi)
movl%eax, (%rdi)
movl4(%rsi), %eax
movl%eax, 4(%rdi)
movl8(%rsi), %eax
movl%eax, 8(%rdi)
movl12(%rsi), %eax
movl%eax, 12(%rdi)
ret
(there is no -fdump-tree-vect)

In contrast, testcase
void
test(int *__restrict__ a, int *__restrict__ b)
{
  for (int i = 0; i < 4; i++) a[i] = b[i];
  for (int i = 0; i < 4; i++) a[i+4] = 0;
}
the memcpy is recognized by ldist, and the 'memset' by slp1 (neither of which
triggers on the first case), producing (superior) AArch64:
test:
moviv0.4s, 0
ldp x2, x3, [x1]
stp x2, x3, [x0]
str q0, [x0, 16]
ret
or x86_64:
test:
.LFB0:
movq(%rsi), %rax
movq8(%rsi), %rdx
vpxor   %xmm0, %xmm0, %xmm0
movq%rax, (%rdi)
movq%rdx, 8(%rdi)
vmovups %xmm0, 16(%rdi)
ret

[Bug tree-optimization/65964] [meta] Operand Shortening

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 35437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35437&action=edit
combo.c: C test case

The problem in PR41076 is mostly about composing bytes to wider integer values
as indicated in the test case.

It can be handled in the backend (in the case of avr) by adding some more
complex combiner patterns, at least for the 16-bit cases like for (from
.combine dump):

(set (regi:HI 24)
 (ior:HI (ashift:HI (reg:HI 51)
(const_int 8))
 (zero_extend:HI (reg:QI 24

or

(set (reg:HI 24)
 (ior:HI (ashift:HI (zero_extend:HI (reg:QI 49))
(const_int 8))
 (zero_extend:HI (reg:QI 24


The 32-bit cases are beyond anything a sane avr backend could do.

Maybe such patterns could be detected similar to the bswap detection? (which
does not work very well from my experience).

[Bug c++/65966] New: "sorry, unimplemented: unexpected AST of kind try_block" when initializing a 2D array

[lhyatt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966

Bug ID: 65966
   Summary: "sorry, unimplemented: unexpected AST of kind
try_block" when initializing a 2D array
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

This fails to compile with gcc 5.1, is fine with 4.9:


struct A {
A();
~A();
};

struct B {
A a{};
};

struct C {
B array[100][100];
} c;
=

$ g++ -v -c -std=c++14 t.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/usr/local/gcc-5.1.0
--with-tune=westmere --with-arch=nehalem
Thread model: posix
gcc version 5.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++14' '-shared-libgcc' '-mtune=westmere'
'-march=nehalem'
 /usr/local/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -quiet
-v -D_GNU_SOURCE t.cpp -quiet -dumpbase t.cpp -mtune=westmere -march=nehalem
-auxbase t -std=c++14 -version -o /tmp/ccmhY1ZH.s
GNU C++14 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0

/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/x86_64-unknown-linux-gnu

/usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../include/c++/5.1.0/backward
 /usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include
 /usr/local/include
 /usr/local/gcc-5.1.0/include
 /usr/local/gcc-5.1.0/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2a9de20833bb0c7b695acd3b2e90df62
t.cpp: In constructor 'constexpr C::C()':
t.cpp:10:8: sorry, unimplemented: unexpected AST of kind try_block
 struct C {
^
t.cpp:10: confused by earlier errors, bailing out


Generally all the features in the testcase must be present (need a 2d array,
not 1d; need to explicitly put the constructor + destructor for class A; need
class B to have the NSDMI for its "a" subobject) for the error to occur.

If I make the following small change to explicitly initialize the array in
class C:


struct A {
A();
~A();
};

struct B {
A a{};
};

struct C {
B array[100][100] = {};
} c;
=

then it compiles OK. However, in this case there seems to be some sort of other
issue, instead of a loop, it outputs 1 individual instructions to
initialize the array:

.LEHB0:
call_ZN1AC1Ev
.LEHE0:
leaq1(%rbx), %rax
movq%rax, %rdi
.LEHB1:
call_ZN1AC1Ev
.LEHE1:
leaq2(%rbx), %rax
movq%rax, %rdi
.LEHB2:
call_ZN1AC1Ev
.LEHE2:
leaq3(%rbx), %rax
movq%rax, %rdi
.LEHB3:
call_ZN1AC1Ev
.LEHE3:
leaq4(%rbx), %rax
movq%rax, %rdi


... etc 1 times.

We have a use case where we have a 100x100x100 3d array, and the compiler
spends hours generating these 1 millions instructions, whereas gcc 4.9 just
generated a reasonable loop right away.

Thank you...

-Lewis

[Bug c/65967] New: error: unable to emulate ‘XF’

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65967

Bug ID: 65967
   Summary: error: unable to emulate ‘XF’
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

[hjl@gnu-6 abi-1]$ cat x.i
typedef float XFtype __attribute__ ((mode (XF)));

XFtype
bar2 (XFtype x)
{
  return x;
}
[hjl@gnu-6 abi-1]$ gcc -m32 -mno-80387 -S x.i   
[hjl@gnu-6 abi-1]$ gcc -m32 -mno-80387 -S x.i   -mlong-double-64
x.i:1:1: error: unable to emulate ‘XF’
 typedef float XFtype __attribute__ ((mode (XF)));
 ^
[hjl@gnu-6 abi-1]$

[Bug c/65967] error: unable to emulate ‘XF’

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65967

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from H.J. Lu  ---
Never mind

[Bug tree-optimization/65968] New: Failure to remove casts, cause poor code generation

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65968

Bug ID: 65968
   Summary: Failure to remove casts, cause poor code generation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at redhat dot com
  Target Milestone: ---

Failure to shorten the multiplies from int mode down to their more native short
modes causes poor code generation for this loop:


void f(short*a) {
  a = __builtin_assume_aligned(a,128);
  for (int i = 0; i < (1<<22); ++i) {
#ifdef EASY
a[i] *= a[i];
#else
int x = a[i];
x *= x;
a[i] = x;
#endif
  }
}

With -DEASY, a nice little loop:
.L2:
movdqa(%rdi), %xmm0
addq$16, %rdi
pmullw%xmm0, %xmm0
movaps%xmm0, -16(%rdi)
cmpq%rdi, %rax
jne.L2

while without EASY, we get the uglier:
.L2:
movdqa(%rdi), %xmm0
addq$16, %rdi
movdqa%xmm0, %xmm2
movdqa%xmm0, %xmm1
pmullw%xmm0, %xmm2
pmulhw%xmm0, %xmm1
movdqa%xmm2, %xmm0
punpckhwd%xmm1, %xmm2
punpcklwd%xmm1, %xmm0
movdqa%xmm2, %xmm1
movdqa%xmm0, %xmm2
punpcklwd%xmm1, %xmm0
punpckhwd%xmm1, %xmm2
movdqa%xmm0, %xmm1
punpcklwd%xmm2, %xmm0
punpckhwd%xmm2, %xmm1
punpcklwd%xmm1, %xmm0
movaps%xmm0, -16(%rdi)
cmpq%rdi, %rax
jne.L2

The narrowing patterns currently in match.pd and proposed for match.pd at the
time of submitting this BZ handle plus/minus, but not multiply.  When writing
the current patterns I saw regressions when mult handling was included. 
Finding a way to avoid the regressions (should have filed BZs for them) while
still shortening for this case would be good.

Marc indicates that pattern along these lines:

(simplify
 (vec_pack_trunc (widen_mult_lo @0 @1) (widen_mult_hi:c @0 @1))
 (mult @0 @1))

Would help this specific case, but we may do better if we can do the type
narrowing before vectorization.

[Bug target/63791] use 32-byte version of vpbroadcastb (and register to poulate) on AVX/AVX2 platforms

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from H.J. Lu  ---
(In reply to Marcus Kool from comment #2)
>
> To resume, gcc 4.8.4 and gcc 4.9.2 produce code that can be optimised
> further, and gcc 5.1.0 produces even slower code which means that the
> implementation of *_set1_epi8() is slower/much-slower than that it can be.

That is done on purpose.  Add -mtune=intel will get what you want.

[Bug c++/65858] [5/6 Regression] ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65858

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri May  1 18:43:40 2015
New Revision: 222699

URL: https://gcc.gnu.org/viewcvs?rev=222699&root=gcc&view=rev
Log:
/cp
2015-05-01  Paolo Carlini  
Prathamesh Kulharni  

PR c++/65858
* typeck2.c (check_narrowing): Set ok = true when pedwarn returns
false.

/testsuite
2015-05-01  Paolo Carlini  
Prathamesh Kulharni  

PR c++/65858
* g++.dg/cpp0x/Wnarrowing4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/65858] [5/6 Regression] ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65858

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri May  1 18:47:55 2015
New Revision: 222700

URL: https://gcc.gnu.org/viewcvs?rev=222700&root=gcc&view=rev
Log:
/cp
2015-05-01  Paolo Carlini  
Prathamesh Kulharni  

PR c++/65858
* typeck2.c (check_narrowing): Set ok = true when pedwarn returns
false.

/testsuite
2015-05-01  Paolo Carlini  
Prathamesh Kulharni  

PR c++/65858
* g++.dg/cpp0x/Wnarrowing3.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/Wnarrowing3.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/typeck2.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/65858] [5/6 Regression] ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65858

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Paolo Carlini  ---
Fixed.

[Bug c++/65969] New: typename allowed in using declaration of non-types names

[bitte.keine.werbung.einwerfen at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65969

Bug ID: 65969
   Summary: typename allowed in using declaration of non-types
names
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bitte.keine.werbung.einwerfen at googlemail dot com
  Target Milestone: ---

Created attachment 35438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35438&action=edit
various cases of using declarations of non-types

The standard draft states for using declarations in 7.3.3/19:
---
If a using-declaration uses the keyword typename and specifies a dependent name
(14.6.2), the name introduced by the using-declaration is treated as a
typedef-name
---

However, if the 'nested-name-specifier unqualified-id' names a non-type, a
typedef on this name would be invalid. Nevertheless, g++-5.1 issues no error
for the following code snippet:

<<< SNIP
template < typename T >
class BaseTemplate {
  protected:
T member;
};

template < typename T >
struct SubTypename : protected BaseTemplate< T > {
using typename BaseTemplate< T >::member; // clang and icpc fail here
};
>>> SNAP

More related cases are in the attached file. The standard is not 100% concise
about the usage of typename in using declarations. However, clang and icpc both
complain about misplaced typenames. What do the experts think?

related: 55664
I wrote on stackoverflow, but I'm actually unsure if I'm really right:
http://stackoverflow.com/questions/25944000/c-using-declaration-with-typename-in-inheriting-constructors/29965088#29965088

[Bug c++/65970] New: [C++14] Endless loop with constexpr

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65970

Bug ID: 65970
   Summary: [C++14] Endless loop with constexpr
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The compiler loops forever when compiling the following invalid testcase with
-std=c++14:


constexpr int foo()
{
  while (true) x;
  return 0;
}

int i = foo();


At least it gives an error before it hangs:

bug.cc: In function 'constexpr int foo()':
bug.cc:3:16: error: 'x' was not declared in this scope
   while (true) x;

[Bug bootstrap/65971] New: bootstrap fails with "multiple definition of '__cpu_indicator_init'"

[manfred99 at gmx dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971

Bug ID: 65971
   Summary: bootstrap fails with "multiple definition of
'__cpu_indicator_init'"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manfred99 at gmx dot ch
  Target Milestone: ---

Since 2015-04-17
(probably since https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222178),
my bootstrap of trunk fails with

gold: error: cpuinfo_s.o: multiple definition of '__cpu_indicator_init'
gold: cpuinfo_s.o: previous definition here
gold: error: cpuinfo_s.o: multiple definition of '__cpu_model'
gold: cpuinfo_s.o: previous definition here
collect2: error: ld returned 1 exit status
make[3]: *** [libgcc_s.so] Error 1
make[3]: *** Waiting for unfinished jobs
gold: error: cpuinfo_s.o: multiple definition of '__cpu_indicator_init'
gold: cpuinfo_s.o: previous definition here
gold: error: cpuinfo_s.o: multiple definition of '__cpu_model'
gold: cpuinfo_s.o: previous definition here
collect2: error: ld returned 1 exit status
make[5]: *** [libgcc_s.so] Error 1
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap2-lean] Error 2


before this date everything was fine. Are there any new prerequisites
on the build environment?

I build with
  ../build/configure \
  --enable-languages=c,c++,fortran \
  --enable-checking=release \
  --disable-libstdcxx-pch --enable-libgomp \
  --enable-lto --enable-gold --with-plugin-ld=gold

  make BOOT_CFLAGS="-g -O2" bootstrap2-lean

with gcc 4.5.1, glibc 2.11.3 and binutils 2.21

[Bug bootstrap/65971] bootstrap fails with "multiple definition of '__cpu_indicator_init'"

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-01
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Please try gold from binutils 2.25.

[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[breedlove.matt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #32 from Matt Breedlove  ---
I've been building with just the corrected open call and have successfully
built LTO versions of binutils, mpc, mpfr, isl, libiconv, bzip2, zlib, etc
without any issue but have had issues on doing a bootstrap-lto with it.

I'll try the last patch and do a native bootstrap-lto build with it and report
back shortly.

[Bug bootstrap/65971] bootstrap fails with "multiple definition of '__cpu_indicator_init'"

[manfred99 at gmx dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971

--- Comment #2 from Manfred Schwarb  ---
Hmm, that's a pretty new binutils version.

So it is not possible any more to build GCC on somewhat older
installations?

This seems not to be documented at https://gcc.gnu.org/install/specific.html,
at least.

[Bug ipa/65972] New: ICE after applying a patch to enable the vectorizer.

[hiraditya at msn dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972

Bug ID: 65972
   Summary: ICE after applying a patch to enable the vectorizer.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

I was trying to debug a compiler crash while compiling a program with auto-fdo
enabled during which the compiler crashed. I could triage the bug to this small
case. The issue  here is that ssa is not in a valid form at this point and the
compiler analyzes a function for inlining.

diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c
index 5d99887..d76f396 100644
--- a/gcc/ipa-inline-analysis.c
+++ b/gcc/ipa-inline-analysis.c
@@ -128,6 +128,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-utils.h"
 #include "cilk.h"
 #include "cfgexpand.h"
+#include "tree-ssa.h"

 /* Estimate runtime of function can easilly run into huge numbers with many
nested loops.  Be sure we can compute time * INLINE_SIZE_SCALE * 2 in an
@@ -2506,6 +2507,7 @@ estimate_function_body_sizes (struct cgraph_node *node,
bool early)
  <0,2>.  */
   basic_block bb;
   struct function *my_function = DECL_STRUCT_FUNCTION (node->decl);
+  verify_ssa (false, true);
   int freq;
   struct inline_summary *info = inline_summaries->get (node);
   struct predicate bb_predicate;



Configured with: ../configure --prefix=../install-crash --enable-shared
--enable-static --target=arm-foo-linux-gnueabihf
--with-sysroot=/compiler/tools/cross/arm-foo-linux-gnueabihf/gcc-5.1/2015-04-22-222321-2c9bf40-release-5.1/arm-foo-linux-gnueabihf/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--with-gmp=/compiler/tools/cross/arm-foo-linux-gnueabihf/gcc-5.1/2015-04-22-222321-2c9bf40-release-5.1
--with-mpfr=/compiler/tools/cross/arm-foo-linux-gnueabihf/gcc-5.1/2015-04-22-222321-2c9bf40-release-5.1
--enable-target-optspace --disable-libquadmath --enable-tls
--disable-libmudflap --enable-threads
--with-mpc=/compiler/tools/cross/arm-foo-linux-gnueabihf/gcc-5.1/2015-04-22-222321-2c9bf40-release-5.1
--disable-decimal-float --enable-languages=c,c++,lto
--with-build-time-tools=/compiler/tools/cross/arm-foo-linux-gnueabihf/gcc-5.1/2015-04-22-222321-2c9bf40-release-5.1/arm-foo-linux-gnueabihf/bin
--disable-libgomp --with-pkgversion='Built at foo from commit SHA:2c9bf40,
Rev:222321' --with-bugurl=foo...@samsung.com --with-abi=aapcs-linux
--with-cpu=cortex-a15 --with-fpu=neon --with-float=hard --with-mode=arm
--disable-bootstrap --enable-languages=c,c++
Thread model: posix

The compiler crashes like this:

../../../libgcc/config/arm/unwind-arm.c: In function ‘__gnu_unwind_pr_common’:
../../../libgcc/config/arm/unwind-arm.c:511:1: error: virtual definition of
statement not up-to-date
 }
 ^
# .MEM_102 = VDEF <.MEM_97>
_103 = _Unwind_decode_typeinfo_ptr.isra.0 (_101);
../../../libgcc/config/arm/unwind-arm.c:511:1: internal compiler error:
verify_ssa failed

gcc/build-crash/./gcc/xgcc -Bgcc/build-crash/./gcc/
-Bgcc/build-crash/../install-crash/arm-foo-linux-gnueabihf/bin/
-Bgcc/build-crash/../install-crash/arm-foo-linux-gnueabihf/lib/ -isystem
gcc/build-crash/../install-crash/arm-foo-linux-gnueabihf/include -isystem
gcc/build-crash/../install-crash/arm-foo-linux-gnueabihf/sys-include-g -O2
-g -Os -O2  -g -O2 -g -Os -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC
-fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC
-fno-inline -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/.
-I../../../libgcc/../gcc -I../../../libgcc/../include  -DHAVE_CC_TLS  -o
unwind-arm.o -MT unwind-arm.o -MD -MP -MF unwind-arm.dep -fexceptions -c
../../../libgcc/config/arm/unwind-arm.c


0xb80500 convert_callers_for_node
../../gcc/tree-sra.c:4940
0xb853cb cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/cgraph.h:3025
0xb853cb convert_callers
../../gcc/tree-sra.c:4955
0xb853cb modify_function
../../gcc/tree-sra.c:5011
0xb8e861 ipa_early_sra
../../gcc/tree-sra.c:5239
0xb8e861 execute
../../gcc/tree-sra.c:5286
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.



make[2]: *** [unwind-arm.o] Error 1
make[2]: *** Waiting for unfinished jobs
0xc966ab verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1068
0x8ef1d0 estimate_function_body_sizes
../../gcc/ipa-inline-analysis.c:2510
0x8f1f43 compute_inline_parameters(cgraph_node*, bool)
../../gcc/ipa-inline-analysis.c:2973
0xb80500 convert_callers_for_node
../../gcc/tree-sra.c:4940
0xb853cb cgraph_node::call_

[Bug ipa/65776] ICE in varpool_node::get_constructor() during chromium build on arm-linux-gnueabihf with LTO

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65776

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Duplicate of PR65858.

Thanks,
Prathamesh

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

[Bug c++/65858] [5/6 Regression] ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65858

--- Comment #8 from prathamesh3492 at gcc dot gnu.org ---
*** Bug 65776 has been marked as a duplicate of this bug. ***

[Bug target/63791] use 32-byte version of vpbroadcastb (and register to poulate) on AVX/AVX2 platforms

[marcus.kool at urlfilterdb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791

Marcus Kool  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #6 from Marcus Kool  ---
(In reply to H.J. Lu from comment #5)
> (In reply to Marcus Kool from comment #2)
> >
> > To resume, gcc 4.8.4 and gcc 4.9.2 produce code that can be optimised
> > further, and gcc 5.1.0 produces even slower code which means that the
> > implementation of *_set1_epi8() is slower/much-slower than that it can be.
> 
> That is done on purpose.  Add -mtune=intel will get what you want.

I do not understand why with the "-O3 -mavx2" flags gcc "on purpose" produces 4
instructions and the compiler flag "-mtune=intel" is mandatory to improve this. 

The -mavx2 flags says that the platform is AVX2 (i.e. Haswell and better).
I read the man page of 5.1.0 and must say that I am frustrated with the
explanation given for the flag "-mtune=intel".  I always thought that -O3 was
the way to tell the compiler "do your best to make the code run fast" and up to
gcc 4.9.2, "-mavx2" was good enough to say to generate code for AVX2.

Resuming, for gcc previous to 5.x, "-O3 -mavx2" did the trick and starting with
5.x "-O3 -mavx2 -mtune=intel" does the trick.  And the additional caveat is
that the behaviour of "-mtune=intel" can change in the future.  
What is the reasoning behind this ?

[Bug target/63791] use 32-byte version of vpbroadcastb (and register to poulate) on AVX/AVX2 platforms

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
The reason is because -mavx2 is not a tuning option.  It does not or should not
change the tuning of the code.  It just enables an ISA feature of the produced
code.  If you want explicit tuning for intel cores, use -mtune=intel.

The reason why -mtune=intel can change in the future is because Intel cores are
not set in stone and newer intel cores can and will have different tuning
parameters.  -mtune=intel is based on the current majority of intel cores at
the released time of GCC.  So if say 10 years down the line, some newer intel
core which has a major tuning difference to the current ones; -mtune=intel will
change for those cores rather than stay constant for the ones now (2015).

[Bug c++/65973] New: Current gcc 6 snapshot fails with segmentation fault when compiling C++14 code

[philipp.classen at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973

Bug ID: 65973
   Summary: Current gcc 6 snapshot fails with segmentation fault
when compiling C++14 code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philipp.classen at gmx dot net
  Target Milestone: ---

Created attachment 35439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35439&action=edit
gzipped output of "-freport-bug"

Current gcc 6 snapshot fails to compile C++14 code:

internal compiler error: Segmentation fault

g++ -freport-bug -DHAVE_CONFIG_H -I.  -Wall -Wfatal-errors -Wextra
-Wno-type-limits -Wstrict-aliasing -Wvla -Wdisabled-optimization
-Wdouble-promotion  -pipe --std=c++1y   -D
EXTENDED_PARALLEL_LOGGING__DEPENDS_ON_TARGET__  -DUSE_TABLEBASES
-DUSE_NALIMOV_TABLEBASES  -DENABLE_GHOST_HTTP_SERVER  -DUSE_BITBASES
-DUSE_SINGLE_PAWN_BITBASES -DUSE_TWO_PAWNS_BITBASES -DUSE_RAMMED_PAWNS_BITBASES
-g3   -I gmock-bundle/include -I gmock-bundle/gtest/include -g  -MT
debug-ghost.o -MD -MP -MF .deps/debug-ghost.Tpo -c -o debug-ghost.o `test -f
'ghost.cpp' || echo './'`ghost.cpp
In file included from evaluation.h:8:0,
 from ghost.cpp:15:
evaluation_value.h: In constructor ‘constexpr
GhostEvaluation::OptimizedForAdding::VALUE::VALUE(int, int)’:
evaluation_value.h:243:5: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccyVvJtP.out file, please attach this to
your bugreport.

[Bug c++/65974] New: Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods

[vz-gcc at zeitlins dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974

Bug ID: 65974
   Summary: Bogus deprecated-declarations warnings for inline
definitions of deprecated virtual methods
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vz-gcc at zeitlins dot org
  Target Milestone: ---

Consider the following example:

% cat -n deprdecl.cpp
 1  struct S {
 2  void bar();
 3
 4  __attribute__((deprecated("use bar() instead.")))
 5  virtual void foo();
 6  };
 7
 8  inline void S::foo() { bar(); }
 9
10  int main()
11  {
12  return 0;
13  }
% g++-5 -c -Wall deprdecl.cpp
deprdecl.cpp:13:1: warning: 'virtual void S::foo()' is deprecated: use
bar() instead. [-Wdeprecated-declarations]
 }
 ^
deprdecl.cpp:8:13: note: declared here
 inline void S::foo() { bar(); }
 ^

I believe this warning shouldn't appear when the deprecated method is just
being defined and not used. Notice that it indeed does not appear if the method
is either not virtual (i.e. remove "virtual" in line 5) or is defined inline
(i.e. move the body from line 8 to line 5). Nor does it appear with 4.9.

Also notice that the warning location is always the last line of the last
function in the file and has nothing to do with the function it complains
about.

This warning may look like not a big deal, but when compiling my real code it
occurs many thousands times making it impossible to use deprecated attribute
with g++ 5.1.

Compiler information:

% g++-5 -v
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.1.1-2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++11 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.1.1 (Debian 5.1.1-2)

[Bug bootstrap/65971] bootstrap fails with "multiple definition of '__cpu_indicator_init'"

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
(In reply to Manfred Schwarb from comment #2)
> Hmm, that's a pretty new binutils version.
> 
> So it is not possible any more to build GCC on somewhat older
> installations?
> 
> This seems not to be documented at https://gcc.gnu.org/install/specific.html,
> at least.

gold is not exactly a standard linker so nobody documents this.  If you change
the default to gold you need to expect somethings to break and report them to
gold or use a newer version of gold linker.  gold itself is known to be still
not able to link the kernel or glibc in some cases so you can't expect it to
always work.

[Bug fortran/65975] New: !$ is not recognized as a comment when -fopenmp flag is used

[CPonder at nVidia dot Com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65975

Bug ID: 65975
   Summary: !$ is not recognized as a comment when -fopenmp flag
is used
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: CPonder at nVidia dot Com
  Target Milestone: ---

I'm working with WRF, the Weather Research Forecasting model.
One of the Fortran files contains these lines

   1336 !$ external, logical:: omp_in_parallel
   1337 !$ external, integer:: omp_get_thread_num

Evidently the programmer decided to comment-out these declarations by changing

!$OMP   --> !$

By my reading of the Fortran standard, this is a legal comment, though I would
much rather have done

!$OMP   --> !!$OMP

since it's clearer on what had been commented-out.
Regardless, if I compile the file using the -fopenmp flag, I get the error

 !$ external, logical:: omp_in_parallel
1
Error: Invalid character in name at (1)
module_fr_fire_util.orig.F:1337:12:

 !$ external, integer:: omp_get_thread_num
1
Error: Invalid character in name at (1)

This error does not happen if I don't use the -fopenmp flag, so it looks like
the parser is insisting on the !$ form denoting a directive whether it is
well-formed or not.
Again, I believe this mal-formed directive is still valid as a comment under
the Fortran standard, and should be treated as such, not triggering an error.
Perhaps a warning would be better?

 !$ external, logical:: omp_in_parallel
   1
Warning: possible mal-formed OMP or ACC directive at (1)

(if -fopenmp was used, I'd flag it as a possible OMP directive; if -fopenacc
had been used, I would flag it as a possible ACC directive. I both flags are
used, I'd state as above).

As an aside, the PGI compiler doesn't trigger any error here.
Also we're working on changing the WRF source code to clean this up.

[Bug fortran/65975] !$ is not recognized as a comment when -fopenmp flag is used

[CPonder at nVidia dot Com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65975

--- Comment #1 from Carl Ponder  ---
This is a problem with both 4.8.4 and 5.1.0.
I didn't test any of the others.

[Bug fortran/65976] New: gfortran man-page lists the -fno-fixed-form flag but does not define it, and it doesn't work

[CPonder at nVidia dot Com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65976

Bug ID: 65976
   Summary: gfortran man-page lists the -fno-fixed-form flag but
does not define it, and it doesn't work
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: CPonder at nVidia dot Com
  Target Milestone: ---

When I run the command

   man gfortran

with GCC 5.1.0, I get a list of options that includes -fno-fixed-form:

   Fortran Language Options
   -fall-intrinsics -fbackslash -fcray-pointer -fd-lines-as-code
-fd-lines-as-comments -fdefault-double-8
   -fdefault-integer-8 -fdefault-real-8 -fdollar-ok
-ffixed-line-length-n -ffixed-line-length-none -ffree-form
   -ffree-line-length-n -ffree-line-length-none -fimplicit-none
-finteger-4-integer-8 -fmax-identifier-length
   -fmodule-private -fno-fixed-form -fno-range-check -fopenacc -fopenmp
-freal-4-real-10 -freal-4-real-16
   -freal-4-real-8 -freal-8-real-10 -freal-8-real-16 -freal-8-real-4
-std=std

Unlike, say, -fno-range-check, the -fno-fixed-form is not defined anywhere in
the document.
Further, if I actually try to use it, I get the error-message

gfortran: error: unrecognized command line option ‘-fno-fixed-form’

I'd suggest completely removing this reference to -fno-fixed-form from the
man-page.

[Bug c/59098] Unwarranted warning: promoted ~unsigned is always non-zero [-Wsign-compare]

[fenugrec at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59098

fenugrec at users dot sourceforge.net changed:

   What|Removed |Added

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

--- Comment #3 from fenugrec at users dot sourceforge.net ---
Probable duplicate of Bug 38341

[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[breedlove.matt at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

--- Comment #33 from Matt Breedlove  ---
bootstrap-lto fails to build:

`isl_union_map_read_from_str' referenced in section `.text' of
M:\msys64\tmp\cceOtKWH.ltrans0.ltrans.o: defined in discarded section `.text'
of isl_input.o (symbol from plugin)
`isl_union_map_read_from_str' referenced in section `.text' of
M:\msys64\tmp\cceOtKWH.ltrans0.ltrans.o: defined in discarded section `.text'
of isl_input.o (symbol from plugin)
`isl_union_map_copy' referenced in section `.text' of
M:\msys64\tmp\cceOtKWH.ltrans0.ltrans.o: defined in discarded section 
...


Replacing the lto-wrapper with the one from my previous build makes these
errors disappear.  The patch from my previous build was the following:

--- gcc-5.1.0/gcc/lto-wrapper.c.orig2015-05-01 16:38:03.348243300 -0400
+++ gcc-5.1.0/gcc/lto-wrapper.c 2015-05-02 00:30:58.345729900 -0400
@@ -934,7 +934,7 @@
  filename[p - argv[i]] = '\0';
  file_offset = (off_t) loffset;
}
-  fd = open (argv[i], O_RDONLY);
+  fd = open (filename, O_RDONLY|O_BINARY);
   if (fd == -1)
{
  lto_argv[lto_argc++] = argv[i];


Rainer hasn't tested this yet.  I'm going to do a full native bootstrap-lto
with this, however it was working fine on everything else I compiled.  The
issue with the last tested patch was archive files with offsets were getting
discarded from the build since we were back to not using the parsed archive
filename.