[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > But why should the *mov_internal use Bm or vector_operand?  It
> > can/should handle both aligned and unaligned memory operands.
> 
> Only for historical reason.

I thought Uros said:
"Looking at the comment in Patch 3, I'd say let's keep *mov_internal
constraints unchanged."
IMNSHO you only want to touch patterns which don't have ssememalign attributes
(== have it 0) and leave the others as is.  Perhaps in the next step you can
kill the UNSPEC_LOADU/UNSPEC_STOREU patterns and handle them in
*mov_internal too - the unspecs were there just to make sure they aren't
combined into SSE arithmetic instructions.

[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||davem at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
> It's probably too late to implement this in reload though.

So an incentive for the switch to LRA if one was needed.

[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3

[ubizjak at gmail dot com]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to H.J. Lu from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > But why should the *mov_internal use Bm or vector_operand?  It
> > > can/should handle both aligned and unaligned memory operands.
> > 
> > Only for historical reason.
> 
> I thought Uros said:
> "Looking at the comment in Patch 3, I'd say let's keep *mov_internal
> constraints unchanged."
> IMNSHO you only want to touch patterns which don't have ssememalign
> attributes (== have it 0) and leave the others as is.  Perhaps in the next
> step you can kill the UNSPEC_LOADU/UNSPEC_STOREU patterns and handle them in
> *mov_internal too - the unspecs were there just to make sure they
> aren't combined into SSE arithmetic instructions.

Yes, there is no need to change *mov_internal constraints.

[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #15)

> IMNSHO you only want to touch patterns which don't have ssememalign
> attributes (== have it 0) and leave the others as is.  Perhaps in the next
> step you can kill the UNSPEC_LOADU/UNSPEC_STOREU patterns and handle them in
> *mov_internal too - the unspecs were there just to make sure they
> aren't combined into SSE arithmetic instructions.

I agree with the above. In the patch, please include minimum changes needed to
solve the problem, we will do more radical changes after gcc-6 is released.
IOW, ssememalign should stay in gcc-6.

[Bug jit/69144] New: running the libgccjit tests leaves temporary files /tmp/libgccjit-*

[doko at gcc dot gnu.org]

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

Bug ID: 69144
   Summary: running the libgccjit tests leaves temporary files
/tmp/libgccjit-*
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

running the libgccjit tests leaves temporary files /tmp/libgccjit-*

these should be cleaned.

[Bug c++/69145] New: [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'

[burnus at gcc dot gnu.org]

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

Bug ID: 69145
   Summary: [6 Regression] Bogus 'warning: #pragma implementation
for ‘...’ appears after file is included'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37224=edit
Patch used to show the "note" line

Since a while, I get seemingly bogus warnings of the form:

file.cc:38:24: warning: #pragma implementation for ‘header.h’ appears after
file is included

The warning is generated in gcc/cp/lex.c's handle_pragma_implementation and
calls cpp_included_before, which contains:
   while (entry && (entry->start_dir == NULL || entry->u.file->err_no
   || entry->location > location))
 entry = entry->next;

I modified the code to print a "note" with the entry->location after the
warning call.


Example:

TDICmds.cc:7:24: warning: #pragma implementation for
‘create_defect_script_SCDBase.cc’ appears after file is included
 #pragma implementation "create_defect_script_SCDBase.cc"
^

In file included from TDICmds.cc:33:0:
./create_defect_script_SCDBase.cc:1:0: note: File was included here
 #include "create_defect_script_SCDBase.h"


I will now try to create a small example and to find the commit, which caused
the regression.

[Bug tree-optimization/67781] [5/6 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations

[mikpelinux at gmail dot com]

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

--- Comment #12 from Mikael Pettersson  ---
Thanks for posting the patch, I'm currently doing a sparc64-linux bootstrap and
regtest with it.

[Bug c/69122] -Wmisleading-indentation false positive with empty macros

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #2 from David Malcolm  ---
Candidate patch posted as:
  https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00126.html

[Bug tree-optimization/69141] [6 Regression] -O2 -fdump-tree-fre ICEs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 37223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37223=edit
gcc6-pr69141.patch

Untested fix.

[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The advantage of __builtin_unreachable () is that it allows better
optimizations, at the expense of the invalid code not being so nicely reported.
With -fsanitize=undefined you get the undefined behavior reported, but with
information loss - it is reported as a call to __builtin_unreachable rather
than call to pure virtual method.
Perhaps as a compromise we could make sure __cxa_pure_virtual is called in this
case when -fsanitize=undefined (say in particular with -fsanitize=unreachable)
and let it be optimized to __builtin_unreachable otherwise?

[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Test case (seems as if the file name of the included file matters):

$ g++ TDICmds.cc

TDICmds.cc:1:24: warning: #pragma implementation for
‘create_defect_script_SCDBase.cc’ appears after file is included
 #pragma implementation "create_defect_script_SCDBase.cc"
^

In file included from TDICmds.cc:2:0:
create_defect_script_SCDBase.cc:1:0: note: File was included here
 #include "create_defect_script_SCDBase.h"



==> create_defect_script_SCDBase.cc <==
#include "create_defect_script_SCDBase.h"

==> create_defect_script_SCDBase.h <==
#ifndef create_defect_script_SCDBase_H
#  define create_defect_script_SCDBase_H
#endif

==> TDICmds.cc <==
#pragma implementation "create_defect_script_SCDBase.cc"
#include "create_defect_script_SCDBase.cc"

[Bug target/69030] [6 Regression] ICE on x86_64-linux-gnu at -O2 and above in 32-bit mode (ICE in copy_rtx, at rtl.c:358)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Note, I need also -march=x86-64 to reproduce.
Seems in remove_pseudos for pseudo 93 we don't have pseudo_slots initialized.
This pseudo is initialized in bb3, then used there and the last use in that bb
is in a debug_insn, this bb then conditionally jumps to another bb where there
is
(insn 121 140 42 6 (set (reg/v:SI 93 [ h ])
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 93 [ h ])
(reg:SI 135))) pr69030.c:12 969 {*movsicc_noc}
 (expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_UNUSED (reg/v:SI 93 [ h ])
(expr_list:REG_EQUAL (if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 93 [ h ])
(const_int 0 [0]))
(nil))
followed by a debug_insn that uses the SI 93 pseudo, but nothing else
afterwards uses it.  And it seems (at least from *.reload dump without -g) that
LRA decides to remove the dead insn, thus shortening the live range of the
pseudo 93, but doesn't adjust the debug insns mentioning it, thus the pseudo 93
doesn't live in a register nor in memory.

[Bug target/69135] [5/6 Regression][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm*
 Status|NEW |ASSIGNED
 CC||ktkachov at gcc dot gnu.org
  Known to work||4.9.4
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
   Target Milestone|--- |5.4
Summary|[5/6][ARM] instruction  |[5/6 Regression][ARM]
   |cannot be conditional --|instruction cannot be
   |`vcvtpne.s32.f32 s0,s0' |conditional --
   ||`vcvtpne.s32.f32 s0,s0'
  Known to fail||5.3.1, 6.0

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed, mine.

[Bug c/69104] invalid atomic memory order not diagnosed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|accepts-invalid |diagnostic

--- Comment #7 from Marek Polacek  ---
I'll post a patch for 1).

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe  ---
Created attachment 37227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37227=edit
back-port of Rainer's fix.

I've been using this on my GCC5.3 WIP (it might be a reasonable starting point,
don't know if it'll apply cleanly to 5.3.1)

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

--- Comment #9 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan  5 14:40:11 2016
New Revision: 232075

URL: https://gcc.gnu.org/viewcvs?rev=232075=gcc=rev
Log:
gcc/cp/
PR c++/58583
* pt.c (build_non_dependent_expr): Don't try a checking fold when
parsing an nsdmi.

gcc/testsuite/
PR c++/58583
* g++.dg/cpp0x/nsdmi-template14.C: Adjust test & errors.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C

[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
(In reply to Tobias Burnus from comment #1)
> Test case (seems as if the file name of the included file matters):

It may be that the threshold for triggering the bug is length of token >= 32:
libcpp uses location_t to store range information for tokens and expressions,
and uses 5 bits of location_t to store short ranges.  i.e. for tokens of up to
31 chars length, it can store them directly in location_t; for 32 and above it
needs to use an ad-hoc location.

> $ g++ TDICmds.cc
> 
> TDICmds.cc:1:24: warning: #pragma implementation for
> ‘create_defect_script_SCDBase.cc’ appears after file is included
>  #pragma implementation "create_defect_script_SCDBase.cc"
> ^

FWIW, this token is 32 chars long (including the quotes), and so would have its
location stored as an ad-hoc location.

[Bug c/68612] Const-compatibility in C

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Marek Polacek  ---
Confirmed as per Comment 5.

[Bug rtl-optimization/68651] [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Fixed on trunk.

[Bug rtl-optimization/68651] [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Jan  5 16:06:06 2016
New Revision: 232077

URL: https://gcc.gnu.org/viewcvs?rev=232077=gcc=rev
Log:
[combine][v2] Canonicalise (r + r) to (r << 1) to aid recognition

PR rtl-optimization/68651
* combine.c (combine_simplify_rtx): Canonicalize x + x into
x << 1.

* gcc.target/aarch64/pr68651_1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr68651_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual

[d.frey at gmx dot de]

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

--- Comment #7 from Daniel Frey  ---
(In reply to Jakub Jelinek from comment #6)
> The advantage of __builtin_unreachable () is that it allows better
> optimizations, at the expense of the invalid code not being so nicely
> reported.
> With -fsanitize=undefined you get the undefined behavior reported, but with
> information loss - it is reported as a call to __builtin_unreachable rather
> than call to pure virtual method.
> Perhaps as a compromise we could make sure __cxa_pure_virtual is called in
> this case when -fsanitize=undefined (say in particular with
> -fsanitize=unreachable) and let it be optimized to __builtin_unreachable
> otherwise?

I checked the Itanium ABI and I guess
https://mentorembedded.github.io/cxx-abi/abi.html#pure-virtual is sufficiently
loosely specified to allow __builtin_unreachable (or basically anything you
like).

Anyways, calling __builtin_unreachable did call the terminate-handler
previously, it was able to print a backtrace and I even got a core dump. The
current behavior makes it almost impossible to debug such a situation and I'm
not sure why. No output, no hint, no core dump (when I registered my own
terminate handler). Could this be fixed in some way?

[Bug target/69151] New: missing docs for H8/3000 monitor/OS_Task attributes and related breakage in -mexr/-mno-exr options

[sandra at gcc dot gnu.org]

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

Bug ID: 69151
   Summary: missing docs for H8/3000 monitor/OS_Task attributes
and related breakage in -mexr/-mno-exr options
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

In reviewing the current state of PR1078, I found that there is no
documentation for the H8/3000 function attributes "monitor" and "OS_Task".

The "monitor" attribute is mentioned in invoke.texi, though:

@item -mexr
@opindex mexr
Extended registers are stored on stack before execution of function
with monitor attribute. Default option is @option{-mexr}.
This option is valid only for H8S targets.

@item -mno-exr
@opindex mno-exr
Extended registers are not stored on stack before execution of function 
with monitor attribute. Default option is @option{-mno-exr}. 
This option is valid only for H8S targets.

Besides needing markup fixes and copy-editing, this text is totally confusing: 
*both* of these behaviors cannot be the default.  Trying to figure this out
from the code, in "monitor_prologue" in h8300.md I see:

...
  else if (TARGET_H8300S && TARGET_NEXR )
return
"mov.l\\ter0,@-er7\;stc\tccr,r0l\;mov.b\tr0l,@(4,er7)\;mov.l\\t@er7+,er0\;orc\t#128,ccr";
 
  else if (TARGET_H8300S && TARGET_NEXR && TARGET_NORMAL_MODE)
return
"subs\\t#2,er7\;mov.l\\ter0,@-er7\;stc\tccr,r0l\;mov.b\tr0l,@(4,er7)\;mov.l\\t@er7+,er0\;orc\t#128,ccr";
...

The second clause is clearly dead code.  I think there is a mistake in logic
here, and that a target expert needs to figure out what the intended behavior
is and correct both the implementation and documentation.

[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
And
union U { int r; float f; };
struct A {
  int a;
  union U b[64];
};
double foo (double);

void
bar (struct A *z, int x)
{
  union U y;
  y.f = foo (z->b[x].f);
  z->a = y.r ? 4 : y.r;
}
too (to make it C rather than C++).

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[nickc at redhat dot com]

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

--- Comment #8 from Nick Clifton  ---
Patch applied.  (Unfortunately I cannot close this BZ...)

[Bug tree-optimization/69108] [6 Regression] ICE in gather_scalar_reductions with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE in  |[6 Regression] ICE in
   |gather_scalar_reductions|gather_scalar_reductions
   |with|with
   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2

--- Comment #1 from vries at gcc dot gnu.org ---
Starts failing at r231162, but that looks like a trigger commit.

The error occurs in double reduction handling code, so marking it 6 regression.

[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

--- Comment #3 from Jakub Jelinek  ---
Ah, ok, I can confirm
union U { int r; float f; };
struct A {
  double foo (double);
  void bar (int);
  int a;
  U b[64];
};
void
A::bar (int x)
{
  U y;
  y.f = foo (b[x].f);
  a = y.r ? 4 : y.r;
}
ICEs with -O -march=z196 -m64 on the trunk as well.

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> Sorry, I indeed made a mistake - r230176 makes compilation fail with a
> different error than the one I get with 5.3 release. However, after
> rerunning git bisect and manually checking these revisions I can confirm
> that:
> 
> - r230165 is the last good revision in the 5 branch;
> - r230176 is the first one that fails, but with a different error (internal
> compiler error: in ix86_adjust_stack_and_probe, at config/i386/i386.c:11064);
> - r230247 is the first one that fails with the error in choose_baseaddr;
> - reverting r230176 from 5.3.0 release fixes the problem (i.e. both
> testcases pass and Wine compiles and runs correctly)

I see, then please always post the full set of options.  r230176 & r230247 only
free the frame pointer register for the register allocator with -fstack-check
(this was done at the request of the Arch folks IIRC) so you can work around
the failure by forcing it to be reserved again (-fno-omit-frame-pointer).

I gather that this didn't work with 5.2, did it?  If so, then the alignment
stuff needs more work.

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
A small testcase:

[hjl@gnu-mic-2 i386]$ cat /tmp/x.ii
struct xxx_def;
typedef xxx_def *xxx;

union rtxxx
{
  const char *rt_str;
  xxx rt_xxx;
};

struct xxx_def {
  union u {
rtxxx fld[1];
  } u;
};

extern xxx bar (void);
extern int foo1 (xxx);

static inline xxx
foo2 (xxx arg0, xxx arg1)
{
  xxx rt;
  rt = bar ();
  (((rt)->u.fld[0]).rt_xxx) = arg0;
  (((rt)->u.fld[1]).rt_xxx) = arg1;
  return rt;
}

static inline xxx
foo4 (const char *arg0 )
{
  xxx rt;
  rt = bar ();
  (((rt)->u.fld[0]).rt_str) = arg0;
  (((rt)->u.fld[1]).rt_xxx) = (xxx) 0;
  return rt;
}

extern xxx foo5 (long);

struct address_cost_data
{
  unsigned costs[2][2][2][2];
};

void
get_address_cost (address_cost_data *data)
{
  unsigned acost;
  long i;
  long rat, off = 0;
  unsigned sym_p, var_p, off_p, rat_p;
  xxx addr, base;
  xxx reg0, reg1;

  reg1 = bar ();
  addr = foo2 (reg1, (xxx) 0);
  rat = 1;
  acost = 0;
  reg0 = bar ();
  reg1 = bar ();

  for (i = 0; i < 16; i++)
{
  sym_p = i & 1;
  var_p = (i >> 1) & 1;
  off_p = (i >> 2) & 1;
  rat_p = (i >> 3) & 1;

  addr = reg0;
  if (rat_p)
addr = foo2 (addr, foo5 (rat)) ;

  if (var_p)
addr = foo2 (addr, reg1);

  if (sym_p)
base = foo4 ("");
  else if (off_p)
base = foo5 (off);
  else
base = (xxx) 0;

  if (base)
addr = foo2 (addr, base);

  acost = foo1 (addr);
  data->costs[sym_p][var_p][off_p][rat_p] = acost;
}
}
[hjl@gnu-mic-2 i386]$ ./cc1plus -fpreprocessed /tmp/x.ii -quiet -dumpbase x.ii
-mtune=generic -march=x86-64 -auxbase x -g -O3 -version -fno-rtti
-fno-exceptions -o x.s

[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #9 from ktkachov at gcc dot gnu.org ---
So I did a bisection between 4.9 and 5.
The offending commit is r217624:
Author: vmakarov 
Date:   Sun Nov 16 05:00:30 2014 +

2014-11-15  Vladimir Makarov  

* lra-remat.c (cand_transf_func): Process regno for
rematerialization too.
* lra.c (lra): Switch on rematerialization pass.

i.e. when the LRA rematiralisation pass was turned on.

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Nathan Sidwell  ---
Patch tested with both checking & release builds.  Applied.

[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

--- Comment #7 from Matthias Klose  ---
> Debian is known to heavily modify their GCC sources.

While Debian applies patches, these are almost all not code-modifying patches,
just the release plus updates from the release branches.

[Bug target/69146] [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Please provide cluster.ii as an attachment.  Thanks...

[Bug c++/69113] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1875 with -fno-weak

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-05
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with

commit 8b2942f7c961ee83bb0ff605129165ecdf6ac8f6
Author: jason 
Date:   Wed Apr 15 21:17:21 2015 +

* decl.c (grokmethod): Only set DECL_COMDAT if TREE_PUBLIC is set.
* method.c (implicitly_declare_fn): Likewise.
* decl2.c (vague_linkage_p): Check TREE_PUBLIC first.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222134
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/69113] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1875 with -fno-weak

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Looks like this fixes it...

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 9a07e1e..a7212ca0 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1820,7 +1820,8 @@ comdat_linkage (tree decl)
}
 }

-  DECL_COMDAT (decl) = 1;
+  if (TREE_PUBLIC (decl))
+DECL_COMDAT (decl) = 1;
 }

 /* For win32 we also want to put explicit instantiations in

[Bug c++/58616] [meta-bug] nsdmi

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616
Bug 58616 depends on bug 58583, which changed state.

Bug 58583 Summary: [c++11] ICE with invalid non-static data member 
initialization in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[bucaneer at gmail dot com]

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

--- Comment #7 from Justas L  ---
(In reply to Eric Botcazou from comment #5)
> As expected, reverting the patch doesn't change anything on the 5 branch, so
> I'd suggest either filling a bug report for 'git bisect' or double checking
> its result next time.

Sorry, I indeed made a mistake - r230176 makes compilation fail with a
different error than the one I get with 5.3 release. However, after rerunning
git bisect and manually checking these revisions I can confirm that:

- r230165 is the last good revision in the 5 branch;
- r230176 is the first one that fails, but with a different error (internal
compiler error: in ix86_adjust_stack_and_probe, at config/i386/i386.c:11064);
- r230247 is the first one that fails with the error in choose_baseaddr;
- reverting r230176 from 5.3.0 release fixes the problem (i.e. both testcases
pass and Wine compiles and runs correctly)

Also, passing -v to the testcases shows that these additional options are
included by default, presumably from some distro (Arch) configuration:

-mtune=generic -march=x86-64 -fPIE -fstack-check=specific
-fstack-protector-strong

[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-05
 Ever confirmed|0   |1

--- Comment #2 from Andreas Krebbel  ---
I can confirm this for GCC 5 branch compiling with -march=z196. It does not
seem to get triggered with older -march levels. It also does work fine with
-mno-lra.

On S/390 we need a memory slot when copying 32 bit entities between FPRs and
GPRs. So from a first glance it appears to be related to the handling of
secondary memory needed in LRA.

[Bug target/69150] New: undocumented dllimport/dllexport attributes in mcore backend

[sandra at gcc dot gnu.org]

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

Bug ID: 69150
   Summary: undocumented dllimport/dllexport attributes in mcore
backend
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

I have been reviewing undocumented target-specific attributes for PR 1078, and
spotted that the mcore backend defines "dllimport" and "dllexport" attributes
that are missing documentation.

Rather than document these, though  I think they are obsolete, and should
be removed.  I think they were provided for the long-deleted mcore-*-pe*
target, and are not useful for the remaining bare-metal mcore-elf target. 
Right?

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
I bet vt_find_location must be oscillating for some reason and thus not
converging.  This is on the get_address_cost routine.  Alex, do you think you
could have a look?  Thanks.

[Bug c++/69145] [6 Regression] Bogus 'warning: #pragma implementation for ‘...’ appears after file is included'

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to David Malcolm from comment #3)
> (In reply to Tobias Burnus from comment #1)
> > Test case (seems as if the file name of the included file matters):
> 
> It may be that the threshold for triggering the bug is length of token >=
> 32: libcpp uses location_t to store range information for tokens and
> expressions, and uses 5 bits of location_t to store short ranges.  i.e. for
> tokens of up to 31 chars length, it can store them directly in location_t;
> for 32 and above it needs to use an ad-hoc location.

Yes, one char shorter filename works fine.

> > $ g++ TDICmds.cc
> > 
> > TDICmds.cc:1:24: warning: #pragma implementation for
> > ‘create_defect_script_SCDBase.cc’ appears after file is included
> >  #pragma implementation "create_defect_script_SCDBase.cc"
> > ^
> 
> FWIW, this token is 32 chars long (including the quotes), and so would have
> its location stored as an ad-hoc location.

Indeed, see the patch I've attached.

[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-05
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Confirmed as well.
Would be nice to have a smaller testcase though,
or a bisect to the offending commit so we can have a sane look at before/after
codegen and compiler dumps

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #37226|0   |1
is obsolete||

--- Comment #7 from H.J. Lu  ---
Created attachment 37228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37228=edit
A smaller testcase

[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This doesn't even compile on the trunk:
pr69148.C:7:17: error: flexible array member ‘adsp21062_device::m_r’ not at end
of ‘class adsp21062_device’
   SHARC_REG m_r[];
 ^

pr69148.C:6:7: note: in the definition of ‘class adsp21062_device’
 class adsp21062_device {
   ^~~~
If I move m_r declaration to the end, then it compiles fine.

[Bug target/69146] [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Oh, sorry, you provided it inline.  Need my coffee this morning.

[Bug c++/69149] Segmentation fault during compile of libre office with debug

[hauf.johannes at gmail dot com]

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

--- Comment #1 from Johannes Hauf  ---
Created attachment 37229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37229=edit
Compiler output

Compressed compiler output

[Bug c/69122] -Wmisleading-indentation false positive with empty macros

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Tue Jan  5 15:54:46 2016
New Revision: 232076

URL: https://gcc.gnu.org/viewcvs?rev=232076=gcc=rev
Log:
Fix PR c/69122 (-Wmisleading-indentation false positive with empty macros)

gcc/c-family/ChangeLog:
PR c/69122
* c-indentation.c (get_visual_column): Remove default argument.
(should_warn_for_misleading_indentation): For the multiline case,
update call to get_visual_column for next_stmt_exploc so that it
captures the location of the first non-whitespace character in the
relevant line.  Don't issue warnings if there is non-whitespace
before the next statement.

gcc/testsuite/ChangeLog:
PR c/69122
* c-c++-common/Wmisleading-indentation.c (pr69122): New function.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-indentation.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wmisleading-indentation.c

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
Could the fix be back ported to the gcc5 branch?

[Bug target/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||doko at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org
  Known to work||4.9.3
   Host|arm-linux-gnueabihf |
Summary|arm miss compiled code  |[5/6 Regression] wrong code
   |since gcc 5 |in thumb mode on
   ||arm-linux-gnueabihf
  Known to fail||5.3.1, 6.0
  Build|arm-linux-gnueabihf |

--- Comment #6 from Matthias Klose  ---
$ gcc -g -O2 -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb
fp_mul_comba_32.c && ./a.out 
27 0x0a7d8ff8 != 0xce804437
28 0x1c8a1f70 != 0x1c8a1f6f
-> 3

works with -marm.

[Bug c++/69149] New: Segmentation fault during compile of libre office with debug

[hauf.johannes at gmail dot com]

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

Bug ID: 69149
   Summary: Segmentation fault during compile of libre office with
debug
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hauf.johannes at gmail dot com
  Target Milestone: ---

Command line:
S=/home/johannes/core && I=$S/instdir && W=$S/workdir &&  mkdir -p
$W/CxxObject/sw/source/uibase/app/ $W/Dep/CxxObject/sw/source/uibase/app/ && cd
/home/johannes/core &&   g++ -DBOOST_ERROR_CODE_HEADER_ONLY
-DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DINTEL -DLINUX
-DOSL_DEBUG_LEVEL=1 -DSAL_LOG_INFO -DSAL_LOG_WARN -DUNIX -DUNX -DX86
-D_PTHREADS -D_REENTRANT   -DSW_DLLIMPLEMENTATION
-DSWUI_DLL_NAME=\"libswuilo.so\"  -DSYSTEM_LIBXML  
-DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden   -Wall -Wno-missing-braces
-Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunused-macros
-fmessage-length=0 -fno-common -pipe  -fvisibility-inlines-hidden
-fstack-protector-strong -fPIC -Wshadow -Woverloaded-virtual -std=gnu++14  
-DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -O0 -fstrict-aliasing
-fstrict-overflow -ggdb2 -finline-limit=0 -fno-inline -fno-default-inline 
-DLIBO_INTERNAL_ONLY  -c $S/sw/source/uibase/app/apphdl.cxx -o
$W/CxxObject/sw/source/uibase/app/apphdl.o -MMD -MT
$W/CxxObject/sw/source/uibase/app/apphdl.o -MP -MF
$W/Dep/CxxObject/sw/source/uibase/app/apphdl.d_ -I$S/sw/source/uibase/app/
-I$W/UnpackedTarball/icu/source -I$W/UnpackedTarball/icu/source/i18n
-I$W/UnpackedTarball/icu/source/common -I$W/UnpackedTarball/boost
-I$S/sw/source/core/inc -I$S/sw/source/filter/inc -I$S/sw/source/uibase/inc
-I$S/sw/inc -I$W/SdiTarget/sw/sdi  -I$S/include 
-I/usr/lib/jvm/java-7-openjdk-i386/include
-I/usr/lib/jvm/java-7-openjdk-i386/include/linux -I$S/config_host  
-I$W/CustomTarget/officecfg/registry -I$W/CustomTarget/sw/generated
-I$W/UnoApiHeadersTarget/udkapi/normal -I$W/UnoApiHeadersTarget/offapi/normal  
 -isystem /usr/include/libxml2 -save-temps 

Output:
g++: warning: -pipe ignored because -save-temps specified
In file included from
/home/johannes/core/sw/source/uibase/app/apphdl.cxx:117:0:
/home/johannes/core/workdir/SdiTarget/sw/sdi/swslots.hxx:1870:87:   in
constexpr expansion of ‘operator|((SfxSlotMode)1,
(SfxSlotMode)16)’
/home/johannes/core/workdir/SdiTarget/sw/sdi/swslots.hxx:1933:1: internal
compiler error: Segmentation fault
 };
 ^
0x84579b6 crash_signal
../../src/gcc/toplev.c:383
0x8a87449 bool vec_safe_reserve(vec*&, unsigned int, bool)
../../src/gcc/vec.h:575
0x8a87449 tree_node** vec_safe_push(vec*&, tree_node* const&)
../../src/gcc/vec.h:669
0x8a87449 add_local_decl(function*, tree_node*)
../../src/gcc/function.c:6703
0x8be2b09 remap_decls
../../src/gcc/tree-inline.c:653
0x8e82282 remap_block
../../src/gcc/tree-inline.c:721
0x8be175e copy_bind_expr
../../src/gcc/tree-inline.c:794
0x8be175e copy_tree_body_r(tree_node**, int*, void*)
../../src/gcc/tree-inline.c:1128
0x8ce20ea walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set*))
../../src/gcc/tree.c:11092
0x8e8351c copy_tree_body
../../src/gcc/tree-inline.c:2966
0x8e8351c copy_fn(tree_node*, tree_node*&, tree_node*&)
../../src/gcc/tree-inline.c:6044
0x8980127 cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:1387
0x897b848 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3161
0x897c4ba cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3219
0x897ff24 cxx_bind_parameters_in_call
../../src/gcc/cp/constexpr.c:1115
0x897ff24 cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:1305
0x897b848 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3161
0x897c4ba cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3219
0x897ff24 cxx_bind_parameters_in_call
../../src/gcc/cp/constexpr.c:1115
0x897ff24 cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:1305
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

gcc Version:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/5/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-5ubuntu1'
--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 

[Bug c/68960] __attribute__ ((aligned ())) is ignored for OpenMP private variables

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37230=edit
gcc6-pr68960.patch

Untested fix.

[Bug c++/69149] Segmentation fault during compile of libre office with debug

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
ICEs on the trunk too.  Reducing...

[Bug other/60465] [4.9/5/6 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[law at gcc dot gnu.org]

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

--- Comment #38 from Jeffrey A. Law  ---
Author: law
Date: Tue Jan  5 17:57:05 2016
New Revision: 232080

URL: https://gcc.gnu.org/viewcvs?rev=232080=gcc=rev
Log:
[PATCH v2] ia64: don't use dynamic relocations for local symbols
PR other/60465
* config/ia64/ia64.c (ia64_expand_load_address): Use gprel64
for local symbolic operands.
* config/ia64/predicates.md (local_symbolic_operand64): New
predicate.

PR other/60465
* gcc.target/ia64/pr60465-gprel64.c: New test.
* gcc.target/ia64/pr60465-gprel64-c37.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/ia64/pr60465-gprel64-c37.c
trunk/gcc/testsuite/gcc.target/ia64/pr60465-gprel64.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/ia64/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[bucaneer at gmail dot com]

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

--- Comment #9 from Justas L  ---
Yes, forced stack alignment on x86_64 was introduced after 5.2, in r228728 for
pr66697. Also, I can confirm that adding -fno-omit-frame-pointer allows Wine to
compile normally.

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
This change makes it to compile:

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 07eea84..43a85b7 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -4968,7 +4968,7 @@ dataflow_set_different (dataflow_set *old_set,
dataflow_set *new_set)
   if (old_set->vars == new_set->vars)
 return false;

-  if (shared_hash_htab (old_set->vars)->elements ()
+  if (0 && shared_hash_htab (old_set->vars)->elements ()
   != shared_hash_htab (new_set->vars)->elements ())
 return true;

[Bug rtl-optimization/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #10 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #9)
> So I did a bisection between 4.9 and 5.
> The offending commit is r217624:
> Author: vmakarov 
> Date:   Sun Nov 16 05:00:30 2014 +
> 
> 2014-11-15  Vladimir Makarov  
> 
>   * lra-remat.c (cand_transf_func): Process regno for
>   rematerialization too.
>   * lra.c (lra): Switch on rematerialization pass.
> 
> i.e. when the LRA rematiralisation pass was turned on.

Consequently, compiling with -fno-lra-remat the testcase runs successfully (no
output)

[Bug target/69143] PowerPC64: aggregate results are badly handled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-05
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.1.0, 6.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  A slightly simpler (but equivalent) test case that generates the
same code is below.  See also bug 65421.

typedef struct B { float x, y; } B;

B bar (B y) { return y; }

[Bug c++/69149] Segmentation fault during compile of libre office with debug

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-05
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Markus Trippelsdorf  ---
This is what creduce came up with:

markus@x4 tmp % cat deb.ii
template  struct A { typedef __underlying_type(_Tp) type; };
namespace o3tl {
template  struct typed_flags;
template ::type> struct is_typed_flags {
  class Wrap {
  public:
constexpr operator E() {}
  };
};
}
template 
constexpr typename o3tl::typed_flags::Wrap operator|(E, E) {
  __PRETTY_FUNCTION__;
}
enum SfxSlotMode { NONE, PROPGET };
namespace o3tl {
template <>
struct typed_flags : is_typed_flags {};
class {
public:
  short nGroupId;
} a{(short)(NONE | PROPGET)};
}

markus@x4 tmp % g++ deb.ii
deb.ii:22:20:   in constexpr expansion of
‘operator|((SfxSlotMode)0u, (SfxSlotMode)1u)’
deb.ii:22:28: internal compiler error: Segmentation fault
 } a{(short)(NONE | PROPGET)};
^

0xcc988f crash_signal
../../gcc/gcc/toplev.c:334
0x7f1334c6230f ???
   
/home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xa48714 bool vec_safe_reserve(vec*&, unsigned int, bool)
../../gcc/gcc/vec.h:553
0xa48714 tree_node** vec_safe_push(vec*&, tree_node* const&)
../../gcc/gcc/vec.h:647
0xa48714 add_local_decl(function*, tree_node*)
../../gcc/gcc/function.c:6791
0xd3c416 remap_decls
../../gcc/gcc/tree-inline.c:611
0xd3d290 remap_block
../../gcc/gcc/tree-inline.c:679
0xd4373e copy_bind_expr
../../gcc/gcc/tree-inline.c:752

[Bug fortran/68009] [6 Regression] prototype for gfortran_runtime_error with inline matmul

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
I will poke at this unless Thomas wants to take it.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #11 from Eric Botcazou  ---
> Yes, forced stack alignment on x86_64 was introduced after 5.2, in r228728
> for pr66697. Also, I can confirm that adding -fno-omit-frame-pointer allows
> Wine to compile normally.

I see, thanks.  Uros, would you mind having a look?  I don't know this stuff.

[Bug testsuite/68232] gcc.dg/ifcvt-4.c fails on some arm configurations

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
(In reply to James Greenhalgh from comment #5)
> "Fixed" with the testsuite skips. Feel free to add any other target triplets
> for which this test is unreliable.

I was going to modify the powerpc64le triplet to just powerpc*-*-* since it
also fails for powerpc64 (big endian) and powerpc-ibm-aix, but looking at
gcc/config/rs6000/rs6000.h, it has BRANCH_COST defined to a non-zero value:

#define BRANCH_COST(speed_p, predictable_p) 3


So there must be something more than just "doesn't work for targets with branch
cost == 0". I'm still happy to make the change if there are other reasons, but
didn't want to do so without hearing first.

[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(insn:TI 248 289 246 8 (set (reg:V2DI 21 xmm0 [130])
(mem/c:V2DI (plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])) [9 %sfp+-32 S16 A128])) /tmp/x.ii:24
1215 {*movv2di_internal}
 (nil))
...
(insn:TI 250 118 120 9 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])) [9 %sfp+-32 S8 A128])
(reg/v/f:DI 0 ax [orig:120 base ] [120])) /tmp/x.ii:33 85
{*movdi_internal}
 (nil))

seem to confuse canonicalize_values_star and lead to infinite loop.

[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression]|[4.9/5 Regression]
   |Compiling glibc-2.17,2.18   |Compiling glibc-2.17,2.18
   |with gcc-4.8.2 and  |with gcc-4.8.2 and
   |binutils-2.23.2,2.24|binutils-2.23.2,2.24
   |results in segfaults in |results in segfaults in
   |_start /|_start /
   |elf_get_dynamic_info|elf_get_dynamic_info

--- Comment #39 from Jeffrey A. Law  ---
Fixed on the trunk.  Patch is backportable to the active release branches, but
I'm not sure it's worth the effort.

[Bug other/60465] [4.9/5 Regression] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[vapier at gcc dot gnu.org]

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

--- Comment #40 from Mike Frysinger  ---
(In reply to Jeffrey A. Law from comment #39)

we should at least do gcc-5.  i'm guessing there won't be another 4.9.

[Bug rtl-optimization/69124] [5/6 Regression] wrong code in thumb mode on arm-linux-gnueabihf

[mikpelinux at gmail dot com]

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

--- Comment #11 from Mikael Pettersson  ---
(In reply to ktkachov from comment #9)
> So I did a bisection between 4.9 and 5.
> The offending commit is r217624:
> Author: vmakarov 
> Date:   Sun Nov 16 05:00:30 2014 +
> 
> 2014-11-15  Vladimir Makarov  
> 
>   * lra-remat.c (cand_transf_func): Process regno for
>   rematerialization too.
>   * lra.c (lra): Switch on rematerialization pass.
> 
> i.e. when the LRA rematiralisation pass was turned on.

Strange, my bisect identified r217588 as the culprit, although it also talks
about lra materialization:

2014-11-14  Vladimir Makarov  

   * lra-int.h (lra_create_live_ranges): Add parameter.
   * lra-lives.c (temp_bitmap): Move higher.
   (initiate_live_solver): Move temp_bitmap initialization into
   lra_live_ranges_init.
   (finish_live_solver): Move temp_bitmap clearing into
   live_ranges_finish.
   (process_bb_lives): Add parameter.  Use it to control live info
   update and dead insn elimination.  Pass it to mark_regno_live and
   mark_regno_dead.
   (lra_create_live_ranges): Add parameter.  Pass it to
   process_bb_lives.
   (lra_live_ranges_init, lra_live_ranges_finish): See changes in
   initiate_live_solver and finish_live_solver.
   * lra-remat.c (do_remat): Process insn non-operand hard regs too.
   Use temp_bitmap to update avail_cands.
   * lra.c (lra): Pass new parameter to lra_create_live_ranges.  Move
   check with lra_need_for_spill_p after live range pass.  Switch on
   rematerialization pass.

[Bug target/1078] Problems with attributes documentation

[sandra at gcc dot gnu.org]

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

--- Comment #10 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Tue Jan  5 18:04:01 2016
New Revision: 232081

URL: https://gcc.gnu.org/viewcvs?rev=232081=gcc=rev
Log:
2016-01-05  Sandra Loosemore 

PR 1078
gcc/
* doc/extend.texi (MicroBlaze Function Attributes): Document
interrupt_handler and fast_interrupt attributes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #11 from Jerry DeLisle  ---
I will work this one.

[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Created attachment 37231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37231=edit
Reduced testcase

To be compiled with -O2 -mincoming-stack-boundary=3

[Bug c++/66460] ICE using __func__ in constexpr function.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hauf.johannes at gmail dot com

--- Comment #6 from Markus Trippelsdorf  ---
*** Bug 69149 has been marked as a duplicate of this bug. ***

[Bug c++/69149] Segmentation fault during compile of libre office with debug

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Markus Trippelsdorf  ---
dup.

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

[Bug fortran/62536] ICE (segfault) for invalid END BLOCK statement

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #8 from vehre at gcc dot gnu.org ---
ICE confirmed.

You need to provide a main program to compilation unit and not compile with -c,
i.e.,

$ cat test_pr62536.f90
function f2 (x)
implicit none
  integer f2, x
  block
   block named
integer a ! should be SAVEd
a = a + x ! should increment by y every time
f2 = a
   end block named
  end block
  return
endfunction

end

$ ./gfortran.sh -g test_pr62536.f90 -o test_pr62536
Fortraning using ***DEVelopment*** version...
test_pr62536.f90:5:3:

block named
   1

Error: Unclassifiable statement at (1)
test_pr62536.f90:9:18:

end block named
  1

Error: Syntax error in END BLOCK statement at (1)
test_pr62536.f90:10:5:

   end block
 1

Error: Expecting END FUNCTION statement at (1)
f951: internal compiler error: Segmentation fault
0xe3e374 crash_signal
.../gcc/gcc/toplev.c:334
0x7d1efd gfc_resolve(gfc_namespace*)
.../gcc/gcc/fortran/resolve.c:15543

[Bug c/68960] __attribute__ ((aligned ())) is ignored for OpenMP private variables

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Severity|major   |normal

--- Comment #1 from Marek Polacek  ---
GCC 4.8 is no longer supported.  Please try some supported version.

[Bug c/69122] -Wmisleading-indentation false positive with empty macros

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed as of r232076.

[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3

[hjl at gcc dot gnu.org]

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

--- Comment #19 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jan  5 20:19:16 2016
New Revision: 232088

URL: https://gcc.gnu.org/viewcvs?rev=232088=gcc=rev
Log:
Use vector_operand on SSE with 16b memory operand

Add vector_operand, which is vector_memory_operand or register_operand,
and use it, instead of nonimmediate_operand, in SSE patterns with 16-byte
memory operand.

gcc/

PR target/68991
* config/i386/i386.c (ix86_expand_vector_logical_operator):
Replace nonimmediate_operand with vector_operand.
* config/i386/predicates.md (vector_operand): New predicate.
(general_vector_operand): Replace nonimmediate_operand with
vector_operand.
* config/i386/sse.md: Replace nonimmediate_operand with
vector_operand and m constraint with Bm constraint on SSE
patterns with 16-byte memory operand.
* config/i386/subst.md (round_nimm_predicate): Replace
nonimmediate_operand with vector_operand.
(round_saeonly_nimm_predicate): Likewise.
(round_saeonly_nimm_scalar_predicate): New.

gcc/testsuite/

PR target/68991
* gcc.target/i386/pr68991.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr68991.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/predicates.md
trunk/gcc/config/i386/sse.md
trunk/gcc/config/i386/subst.md
trunk/gcc/testsuite/ChangeLog

[Bug c/69104] invalid atomic memory order not diagnosed

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jan  5 20:24:02 2016
New Revision: 232090

URL: https://gcc.gnu.org/viewcvs?rev=232090=gcc=rev
Log:
PR c/69104
* builtins.c (get_memmodel): Use expansion point location rather than
the input location.  Call warning_at rather than warning.
(expand_builtin_atomic_compare_exchange): Likewise.
(expand_builtin_atomic_load): Likewise.
(expand_builtin_atomic_store): Likewise.
(expand_builtin_atomic_clear): Likewise.

* gcc.dg/atomic-invalid-2.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/atomic-invalid-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/69152] New: _GLIBCXX_BITSET_BITS_PER_WORD is wrong for x32

[hjl.tools at gmail dot com]

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

Bug ID: 69152
   Summary: _GLIBCXX_BITSET_BITS_PER_WORD is wrong for x32
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x32

The size of word on x32 is 8 byte and the size of long is 4 byte.
include/std/bitset has

#define _GLIBCXX_BITSET_BITS_PER_WORD  (__CHAR_BIT__ * __SIZEOF_LONG__)

which is incorrect for x32.

[Bug target/69148] [5/6 Regression] ICE (floating point exception) on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #5 from Andreas Krebbel  ---
I think the problem comes with the hard coded operand indexes in
curr_insn_transform when trying to reuse the existing insn for the secondary
memory load.

  if (use_sec_mem_p)
{
  rtx new_reg, src, dest, rld;
  machine_mode sec_mode, rld_mode;

  lra_assert (sec_mem_p);
  lra_assert (curr_static_id->operand[0].type == OP_OUT
  && curr_static_id->operand[1].type == OP_IN);
  dest = *curr_id->operand_loc[0];
  src = *curr_id->operand_loc[1];
...

This does not work for parallels consisting of more than one set. 
(insn 15 14 24 2 (parallel [
(set (reg:CCZ 33 %cc)
(compare:CCZ (subreg:SI (reg:SF 69 [ D.1498 ]) 0)
(const_int 0 [0])))
(set (reg:SI 60 [ D.1497 ])
(subreg:SI (reg:SF 69 [ D.1498 ]) 0))
]) t.c:13 839 {*tstsi_extimm}
 (expr_list:REG_DEAD (reg:SF 69 [ D.1498 ])
(expr_list:REG_UNUSED (reg:CCZ 33 %cc)
(nil

The first set is dead so single_set returns just the second set for
curr_insn_set. Since the operands in the second set are NOT numbered 0 and 1
this code doesn't do the right thing.

Can we just use the "old" code in such a case? So emitting both the spill insns
before and after the original insn instead of trying to reuse the insn? In the
original PR55433 this was supposed to fix an infinite loop in reload. So I'm
not sure if that might bring back that problem then?!

[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug target/69153] --with-advance-toolchain configure option does not correctly set configure variable target_header_dir

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
(In reply to Andrew Pinski from comment #1)
> You are leaking a target specific configure option to the configure script. 
> This seems wrong.  Can't you set target_header_dir in config.gcc instead?

As the code is now, no, since config.gcc is included before the code that sets
$target_header_dir and that code unconditionally sets it, but I suppose we
could modify things such that the setting of $target_header_dir first tests
whether it's set or not before setting it, giving us the ability to set it in
config.gcc.  How about the following change that does that?

Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 231201)
+++ gcc/configure.ac(working copy)
@@ -1401,6 +1401,7 @@
 . ${srcdir}/config.host

 target_gtfiles=
+target_header_dir=

 # Collect target-machine-specific information.
 . ${srcdir}/config.gcc
@@ -1997,20 +1998,22 @@
 SYSTEM_HEADER_DIR=$build_system_header_dir
 fi

-if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
-  if test "x$with_headers" != x; then
-target_header_dir=$with_headers
-  elif test "x$with_sysroot" = x; then
-target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
-  elif test "x$with_build_sysroot" != "x"; then
-target_header_dir="${with_build_sysroot}${native_system_header_dir}"
-  elif test "x$with_sysroot" = xyes; then
-   
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
+if test "x$target_header_dir" == x; then
+  if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
+if test "x$with_headers" != x; then
+  target_header_dir=$with_headers
+elif test "x$with_sysroot" = x; then
+ 
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
+elif test "x$with_build_sysroot" != "x"; then
+  target_header_dir="${with_build_sysroot}${native_system_header_dir}"
+elif test "x$with_sysroot" = xyes; then
+ 
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
+else
+  target_header_dir="${with_sysroot}${native_system_header_dir}"
+fi
   else
-target_header_dir="${with_sysroot}${native_system_header_dir}"
+target_header_dir=${native_system_header_dir}
   fi
-else
-  target_header_dir=${native_system_header_dir}
 fi

 # If this is a cross-compiler that does not
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 231201)
+++ gcc/config.gcc  (working copy)
@@ -4162,6 +4162,7 @@
-d "/opt/$with_advance_toolchain/bin/." -a \
-d "/opt/$with_advance_toolchain/include/."; then

+   target_header_dir=`find /opt/$with_advance_toolchain/
-path '*/include/features.h' | sed -e 's#/features.h##'`
tm_file="$tm_file ./advance-toolchain.h"
(at="/opt/$with_advance_toolchain"
 echo "/* Use Advance Toolchain $at */"

[Bug target/65421] inefficient code returning float aggregates on powepc64le

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
See also bug 69143.

[Bug tree-optimization/68398] [6 Regression] coremark regression due to r229685

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|coremark regression due to  |[6 Regression] coremark
   |r229685 |regression due to r229685

[Bug middle-end/46555] [4.9/5/6 Regression] PHI RTL expansion leads to CSiBE regression

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
I am going to try to work on this so it can be in for stage 1 of 7.

[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Markus Trippelsdorf from comment #2)
> 
> The code included here is undefined due to ODR violations.

Yes, that is why I used "ice-on-invalid-code" keyword, that you wrongly
changed.

[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
I don't think this has anything to do with `end`. Consider the following code:

#include 

template struct foo {
T f();
void g(T);
};
template void operator<<(const T&, const foo&) {}

struct x : public std::ostream
{
  virtual void flush() = 0;
};

void bar(x& os)
{
  os << std::endl;
}

I don't have access to 4.8.0, but this compiles on 4.7.3 and fails on 4.8.1+.
(In the  case, std::operator<<(const T&, const valarray&) is
picked up by ADL.)

Deduction for this operator<< function template succeeds: `T` is deduced to be
`x` from the left operand; the right operand is a non-deduced context because
the supplied argument names a function template. Then substitution takes place,
and we instantiate valarray (whose definition is needed to decide if it can
be constructed from std::endl), which triggers a hard error because you can't
return or take an abstract type by value. This is not diagnosed in GCC 4.7.3,
likely due to PR51184.

[Bug libstdc++/69116] [4.9/5/6 Regression] compile error when including valarray

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to TC from comment #2) 
> Deduction for this operator<< function template succeeds: `T` is deduced to
> be `x` from the left operand; the right operand is a non-deduced context
> because the supplied argument names a function template. Then substitution
> takes place, and we instantiate valarray (whose definition is needed to
> decide if it can be constructed from std::endl), which triggers a hard error
> because you can't return or take an abstract type by value. This is not
> diagnosed in GCC 4.7.3, likely due to PR51184.

Hmm, there is a SFINAE issue here then.
We should reduce this further.  A simple reduction based on the description
works still:
template struct foo {
T f();
void g(T);
};
template void operator<<(const T&, const foo&) {}
template void operator<<(const T&, void (*)(void)) {}

void endl(int);
void endl(void);

struct x
{
  virtual void flush() = 0;
};

void bar(x& os)
{
  os << endl;
}

--- CUT ---

Also I had confused end and endl earlier which is why I had messed up.

[Bug bootstrap/69134] building a mips-cross compiler with in-tree mpfr-2.4.2 fails

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #1 from Paul Hua  ---
Try this patch for mpfr-2.4.2.

--- mpfr-longlong.h.bak 2016-01-06 11:13:03.474846621 +0800
+++ mpfr-longlong.h 2016-01-06 11:44:38.839800251 +0800
@@ -1011,7 +1011,7 @@
 #endif /* __m88000__ */

 #if defined (__mips) && W_TYPE_SIZE == 32
-#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7
+#if __GNUC__ < 4
 #define umul_ppmm(w1, w0, u, v) \
   __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
 #else
@@ -1024,7 +1024,7 @@
 #endif /* __mips */

 #if (defined (__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if __GNUC__ > 2 || __GNUC_MINOR__ >= 7
+#if __GNUC__ < 4
 #define umul_ppmm(w1, w0, u, v) \
   __asm__ ("dmultu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
 #else

[Bug target/45390] CPU2006 434.zeusmp: gcc 4.6 7% regression from gcc 4.5

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
No word in over 6 months so closing.

[Bug middle-end/46555] [4.9/5/6 Regression] PHI RTL expansion leads to CSiBE regression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Last reconfirmed|2010-11-19 10:55:11 |2016-1-5
   Target Milestone|--- |7.0
Summary|PHI RTL expansion leads to  |[4.9/5/6 Regression] PHI
   |CSiBE regression|RTL expansion leads to
   ||CSiBE regression

--- Comment #2 from Andrew Pinski  ---
  :

  # _6 = PHI <-1(17), 0(15), -1(10)>
:


It is not as bad on the trunk now but I don't think it has been fixed.

[Bug tree-optimization/67755] [5/6 Regression] Bad edge probability/block freqency for tree jump threading

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4
Summary|[5 Regression] Bad edge |[5/6 Regression] Bad edge
   |probability/block freqency  |probability/block freqency
   |for tree jump threading |for tree jump threading

[Bug target/69153] New: --with-advance-toolchain configure option does not correctly set configure variable target_header_dir

[bergner at gcc dot gnu.org]

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

Bug ID: 69153
   Summary: --with-advance-toolchain configure option does not
correctly set configure variable target_header_dir
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

The --with-advance-toolchain configure option is supposed to build a GCC that
uses the header files, libraries and dynamic linker from the specified Advance
Toolchain (AT) release, rather than the system files.

In testing a new configure fragment for a new builtin that requires a specific
GLIBC version, I noticed that the configure testing was using the system header
files instead of the AT's header files.  This was due to $target_header_dir not
being set correctly.  The following code which sets it doesn't handle
--with-advance-toolchain at all:

if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
  if test "x$with_headers" != x; then
target_header_dir=$with_headers
  elif test "x$with_sysroot" = x; then
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
  elif test "x$with_build_sysroot" != "x"; then
target_header_dir="${with_build_sysroot}${native_system_header_dir}"
  elif test "x$with_sysroot" = xyes; then
   
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
  else
target_header_dir="${with_sysroot}${native_system_header_dir}"
  fi
else
  target_header_dir=${native_system_header_dir}
fi

I'm testing the following patch to fix this:

Index: configure.ac
===
--- configure.ac(revision 231201)
+++ configure.ac(working copy)
@@ -1997,7 +1997,9 @@
 SYSTEM_HEADER_DIR=$build_system_header_dir 
 fi

-if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
+if test "x$with_advance_toolchain" != x; then
+  target_header_dir=`find /opt/$with_advance_toolchain/ -path
'*/include/features.h' | sed -e 's#/features.h##'`
+elif test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
   if test "x$with_headers" != x; then
 target_header_dir=$with_headers
   elif test "x$with_sysroot" = x; then

[Bug c++/68049] [5/6 Regression] template instantiation involving may_alias defines symbol twice

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2015-12-08 00:00:00 |2016-1-5
   Target Milestone|--- |5.4

[Bug target/69153] --with-advance-toolchain configure option does not correctly set configure variable target_header_dir

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Target||powerpc*-linux
 CC||meissner at gcc dot gnu.org,
   ||tuliom at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug c++/68525] [6 Regression] bogus use of deleted function error on a template with a flexible array member

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|rejects-valid   |
   Last reconfirmed|2015-11-25 00:00:00 |2016-1-5
   Target Milestone|--- |6.0
  Known to fail||4.8.4, 6.0

--- Comment #1 from Andrew Pinski  ---
Fails with the same message in GCC 4.8.4 but passes with GCC 5.3.0.

Though I don't think this is valid code.  Changing "T a[];" to "T a[1];" will
cause it to be rejected with the same message.  

Basically GCC decides for B::B(), T::T() (aka A::A()) needs to exists and
works.  That is what the error message is saying. it is not really mysterious
either.

[Bug c++/69098] [6.0 regression] Member function pointer template flagged with 'is not a function template'

[hir...@trash-mail.com]

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

--- Comment #3 from hir...@trash-mail.com ---
Your testcase is really quite a bit smaller still – impressive skills! :)

Thanks for confirming and since 5.1.0 works for you, on Wandbox and
additionally your testcase doesn’t fail locally, I guess I might just have
looked at the wrong one of my two installations when I queried the version,
perhaps I forgot to prepend '.\' or something like that.

[Bug target/45389] CPU2006 cactusADM: gcc 4.6 15% regression from 4.5

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Andrew Pinski  ---
No word on this one in 6 months so closing.

[Bug libstdc++/69152] _GLIBCXX_BITSET_BITS_PER_WORD is wrong for x32

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
This macro is about the typedef _WordT in bitset (currently "long", so
__SIZEOF_LONG__ is exactly what we want), not about the compiler notion of
"word". Using "long" for that typedef is suboptimal on x32, but also on win64.
I think there is already a PR asking to change it, but since it would break the
ABI...

[Bug rtl-optimization/49358] [4.9/5/6 Regression] RA regressed for SSE 2 operand math

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|optimization regression in  |[4.9/5/6 Regression] RA
   |4.7.0, 4.6.1 from 4.5.4 |regressed for SSE 2 operand
   ||math

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug c++/66944] ICE on static thread_local member in class template

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[6 regression] ICE on   |ICE on static thread_local
   |static thread_local member  |member in class template
   |in class template   |
   Severity|major   |normal

--- Comment #2 from Andrew Pinski  ---
>Today's trunk crashes with the following ICE so making this a regression:

Except the previous versions also ICEd.
That is what:
bug.cc:14: confused by earlier errors, bailing out

Is about really.