[Bug tree-optimization/32199] jc1: out of memory allocating 4072 bytes after a total of 805021000 bytes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #20 from Richard Biener  ---
As some data point, for the largest testcase in this PR we improved from peak
memory use of ~360MB with GCC 4.2.1 to ~57MB with GCC 6.2 (GCC 4.8 used ~70MB).

[Bug c++/79085] ICE with placement new to unaligned location

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm-none-eabi
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/32306] [5/6/7 Regression] redundant && || not eliminated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #32 from Richard Biener  ---
> grep if t.c.227t.optimized  | wc -l
109

should be 12 if CSE worked.

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[m.ostapenko at samsung dot com]

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

--- Comment #8 from Maxim Ostapenko  ---
(In reply to Jakub Jelinek from comment #7)
> Comment on attachment 40514 [details]
> Untested fix 1.
> 
> But DECL_SOURCE_FILE is not the main input file of the TU that contains it,
> if e.g. a variable is defined in a header.
> Can't you find the corresponding TRANSLATION_UNIT_DECL (see e.g. how
> dwarf2out.c is_cxx now looks for that) and get the name from that?
> And, the multiple ?s look just weird, (in_lto_p && something ? something :
> main_input_filename); would be nicer.

Yes, but with following helper (extracted from is_cxx) I get DECL_NAME
(translation_unit_decl) == NULL:

static const_tree
get_translation_unit_decl (tree decl)
{
  const_tree context = decl;
  while (context && TREE_CODE (context) != TRANSLATION_UNIT_DECL)
{
  if (TREE_CODE (context) == BLOCK)
context = BLOCK_SUPERCONTEXT (context);
  else 
context = get_containing_scope (context);
}
  return context;
}

and from gdb:

Breakpoint 1, asan_add_global (decl=0x77ff7f30, type=0x7658df18,
v=0x7659d2d0) at /home/max/workspace/downloads/gcc/gcc/asan.c:2410
2410  const_tree translation_unit_decl = get_translation_unit_decl (decl);
(gdb) n
2411  if (translation_unit_decl)
(gdb) call debug_tree(translation_unit_decl)
 
(gdb)

[Bug c++/79091] [7 regression] ICE in write_unnamed_type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r241944.

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
I think it is fine if it has DECL_NAME NULL, but it would be helpful if
DECL_SOURCE_LOCATION of the TRANSLATION_UNIT_DECL was set to some location in
the main input file (e.g. first column on first line of the main_input_file).
Maybe it should be done by each caller build_translation_unit_decl, or by
build_translation_unit_decl itself.

[Bug bootstrap/79098] [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|powerpc-e500v2-linux-gnuspe |powerpc-e500v2-linux-gnuspe
   ||, ppc64le
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||amodra at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed.
I also see it on ppc64le.
Started with r244465.

[Bug bootstrap/79098] [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/71737] [5/6/7 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Jan 16 09:09:30 2017
New Revision: 244486

URL: https://gcc.gnu.org/viewcvs?rev=244486&root=gcc&view=rev
Log:
/c-family
2017-01-16  Paolo Carlini  

PR c++/71737
* c-common.c (set_underlying_type): Always set DECL_ORIGINAL_TYPE.

/testsuite
2017-01-16  Paolo Carlini  

PR c++/71737
* g++.dg/cpp0x/pr71737.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr71737.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71737] [5/6 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE
   |following 2x pack expansion |following 2x pack expansion
   |in non-pack with template   |in non-pack with template
   |alias   |alias

--- Comment #7 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug demangler/79099] Memory leak in cplus-dem.c:2232

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[vogt at linux dot vnet.ibm.com]

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

--- Comment #22 from Dominik Vogt  ---
That looks like a similar problem.  I'm lacking some knowledge about how
register pairs are allocated for paradoxical subregs on bigendian systems
though.  Deducing from the code quoted above and from what register allocation
generates; is this correct?

On a 32 bit, bigendian system, the register pair for r:SI is

* r/r for input operands (OP_IN)
* r/r for output operands (OP_OUT or OP_INOUT)

Are even/odd and odd/even pairs both valid?

--

Assuming this is correct... 

For the pseudoregs in

> (insn 11 8 15 2 (set (reg:DI 118)
> (and:DI (subreg:DI (reg:SI 116) 0)
> (const_int 1 [0x1]))) "pr79058b.c":13 79 {*anddi3_insn}

Ira chooses r2 for both, r116 and r118:

> Disposition:
> ... 1:r116 l0 20:r118 l0 2

Lra then expands the paradoxical subreg in r116, using r122:

>Choosing alt 5 in insn 11:  (0) &r  (1) r  (2) De {*anddi3_insn}
>  Creating newreg=122 from oldreg=118, assigning class GENERAL_REGS to r122
>   11: r122:DI=r116:SI#0&0x1
>  REG_DEAD r116:SI
> Inserting insn reload after:
>21: r118:DI=r122:DI

and reloads r122 to r0:

> Assigning to 122 (cl=GENERAL_REGS, orig=118, freq=2000, tfirst=122, 
> tfreq=2000)...
>Assign 0 to reload r122 (freq=2000)

As r116:SI (r2:SI) maps to r116-1:DI (r1:DI) this results in

> (insn 11 8 21 2 (set (reg:DI 0 r0 [118])
> (and:DI (reg:DI 1 r1 [orig:116+-4 ] [116])
> (const_int 1 [0x1]))) "pr79058b.c":13 79 {*anddi3_insn}

With the register pair r0/r1 [118] overlapping the pair r1/r2 [116].  Because
of the earlyclobber in the pattern, this test "fails" and alternative 5 does
not match:

  if ((MEM_P (recog_data.operand[opno]) 
   || recog_data.operand_type[opno] != OP_OUT) 
  && opno != eopno 
  /* Ignore things like match_operator operands.  */ 
  && *recog_data.constraints[opno] != 0 
  && ! (matching_operands[opno] == eopno 
&& operands_match_p (recog_data.operand[opno], 
 recog_data.operand[eopno])) 
  && ! safe_from_earlyclobber (recog_data.operand[opno], 
   recog_data.operand[eopno])) 
lose = 1; 

(safe_from_earlyclobber correctly returns false because of the overlapping
register pairs).

Now, where should this conflict have been noticed?  This may again be a case
where the code assumes that the register pair is r2/r3, but on bigendian it is
r1/r2, but what is the place to look for this code?

[Bug middle-end/79089] [7 Regression] error: incorrect sharing of tree nodes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 40523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40523&action=edit
gcc7-pr79089.patch

Untested fix.

[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 16 09:33:12 2017
New Revision: 244487

URL: https://gcc.gnu.org/viewcvs?rev=244487&root=gcc&view=rev
Log:
2017-01-13  Richard Biener  

PR tree-optimization/77283
* gimple-ssa-split-paths.c: Include gimple-ssa.h, tree-phinodes.h
and ssa-iterators.h.
(is_feasible_trace): Implement a cost model based on joiner
PHI node uses.

* gcc.dg/tree-ssa/split-path-7.c: Adjust.
* gcc.dg/tree-ssa/split-path-8.c: New testcase.
* gcc.dg/tree-ssa/split-path-9.c: Likewise.

Modified:
trunk/gcc/ChangeLog

[Bug tree-optimization/79054] missing range information with INT_MAX

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|poerpc64*-*-*   |powerpc64*-*-*
 CC||clyon at gcc dot gnu.org
   Host|poerpc64*-*-*   |powerpc64*-*-*
  Build|poerpc64*-*-*   |powerpc64*-*-*

--- Comment #6 from Christophe Lyon  ---
Not sure if I should update this bug or create another one.
After r244382, I can see
gcc.dg/attr-alloc_size-4.c (test for excess errors)
failing on aarch64/arm targets.

[Bug c++/79095] [7 regression] spurious stringop-overflow warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Ugh, -Wstringop-overflow is enabled by default even without -Wall?  That is
just wrong.  When it solely warns about __*_chk builtins known to overflow that
is fine, but the other newly added warnings in this area should be only in
-Wall or -Wextra or not enabled by default at all.
This is yet another case showing why very late warnings after path isolation
etc. are harmful.  Sure, if foo doesn't grow the vector there will be UB in the
resize, but there is nothing in the testcase that would show that is expected.

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
> Maybe the load sign-extends instead of zero-extending as specified initially.

But I'm not sure that this matters here, since:

(insn 58 57 59 3 (set (subreg:SI (reg:DI 316 [ iftmp.3_114 ]) 0)
(ne:SI (reg/f:DI 469 [ current_scope.1_1->bindings ])
(const_int 0 [0])))
"/althome/mips/v6/src/gcc/gcc/c/c-decl.me.c":915 501 {*sne_zero_disi}
 (expr_list:REG_DEAD (reg/f:DI 469 [ current_scope.1_1->bindings ])
(nil)))

can put only 0 or 1 in the SUBREG, can't it?

[Bug sanitizer/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jakub Jelinek  ---
Assuming fixed.

[Bug translation/79100] New: Superfluous % in messages from cfgloop.c

[fmarchal at perso dot be]

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

Bug ID: 79100
   Summary: Superfluous % in messages from cfgloop.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In cfgloop.c, starting at line 1424, several messages contain a superfluous %
character:

if (!bb_loop_header_p (loop->header))
{
  error ("loop %d%'s header is not a loop header", i);
  err = 1;
}

Variable "i" is the loop number. It is not reported as a percentage at other
places.

Messages like this can be found between line 1424 and line 1472.

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[mpf at gcc dot gnu.org]

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

--- Comment #13 from mpf at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #12)
> > Maybe the load sign-extends instead of zero-extending as specified 
> > initially.
> 
> But I'm not sure that this matters here, since:
> 
> (insn 58 57 59 3 (set (subreg:SI (reg:DI 316 [ iftmp.3_114 ]) 0)
> (ne:SI (reg/f:DI 469 [ current_scope.1_1->bindings ])
> (const_int 0 [0])))
> "/althome/mips/v6/src/gcc/gcc/c/c-decl.me.c":915 501 {*sne_zero_disi}
>  (expr_list:REG_DEAD (reg/f:DI 469 [ current_scope.1_1->bindings ])
> (nil)))
> 
> can put only 0 or 1 in the SUBREG, can't it?

Yes, that is true but the upper 32-bits still need to be 'zero'. What happens
later on is that the (subreg:SI (reg:DI 316)) is spilled, spilling only 32-bits
to the stack but it gets reloaded as DImode/64-bit. The upper-32 bits are junk.
I don't believe that is an LRA bug as it is doing exactly what is described by
the subreg.

The original zero_extend in insn 58 to DImode is therefore very important here
and cannot be converted to a subreg.

(I haven't got to the specific combine rule yet that is doing this substitution
to see which decision is bad.)

[Bug bootstrap/79098] [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
> Yes, that is true but the upper 32-bits still need to be 'zero'. What
> happens later on is that the (subreg:SI (reg:DI 316)) is spilled, spilling
> only 32-bits to the stack but it gets reloaded as DImode/64-bit. The
> upper-32 bits are junk.

Then either the MIPS port is not correctly parameterized, because
LOAD_EXTEND_OP says that the upper 32 bits are *not* junk (see also comment 11)
or...

> I don't believe that is an LRA bug as it is doing exactly what is described by
> the subreg.

...it's a LRA bug if it spills 32 bits but reloads 64 bits; Old Reload knows
that it cannot do that if WORD_REGISTER_OPERATIONS is 1.

So does LRA generate a full 64-bit load or an extended 32-to-64-bit load?

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||amker at gcc dot gnu.org
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
With -fwhole-program there's no regression from GCC 6.2 to current trunk. 
Without I still can see a small regression (here 0.86s vs 0.92s).

>From looking at the assembly it's hard to tell what the issue is.  perf shows
hot spots at mispredicted branches it seems (for both good and bad case).

In .optimized I see that IVO with different choices for trunk with the input
into IVO being more or less the same.  Trunk ends up with

   [92.50%]:
  # i_138 = PHI 
  # ivtmp.78_378 = PHI 
  _5 = (const int *) ivtmp.78_378;
  _366 = (void *) ivtmp.78_378;
  _6 = MEM[base: _366, offset: 0B];
  if (_6 > L.2_7)
goto ; [50.00%]
  else
goto ; [50.00%]

   [46.25%]:
  _370 = (unsigned int) i_138;
  _369 = _370 * 4;
  _10 = _369;
  _368 = ivtmp.78_378 + 4294967292;
  _367 = (const int *) _368;
  _11 = _367;
  _374 = (void *) ivtmp.78_378;
  _12 = MEM[base: _374, offset: 4294967292B];
  if (L.2_7 >= _12)
goto ; [7.50%]
  else
goto ; [92.50%]

   [89.03%]:
  i_128 = i_138 + 1;
  ivtmp.78_377 = ivtmp.78_378 + 4;
  if (i_128 != _371)
goto ; [92.50%]
  else
goto ; [7.50%]

   [82.35%]:
  goto ; [100.00%]

while GCC 6 did

  :
  # i_153 = PHI <0(7), i_19(12)>
  _572 = (sizetype) i_153;
  _17 = MEM[base: pretmp_509, index: _572, step: 4, offset: 4B];
  if (_17 > pretmp_506)
goto ;
  else
goto ;

  :
  _591 = (sizetype) i_153;
  _22 = MEM[base: pretmp_509, index: _591, step: 4, offset: 0B];
  if (_22 <= pretmp_506)
goto ;
  else
goto ;

  :
  i_19 = i_153 + 1;
  if (i_19 != _573)
goto ;
  else
goto ;

  :
  goto ;

but not sure if that ends up slower.  GCC 6.2 asm:

.L23:
movl%edx, %eax
.L27:
movl4(%esi,%eax,4), %ecx
cmpl%ebx, %ecx
jle .L11
movl(%esi,%eax,4), %ebp
cmpl%ebx, %ebp
jle .L34
.L11:
leal1(%eax), %edx
cmpl%edi, %edx
jne .L23

GCC 7:

.L23:
movl%edx, %ecx
.L13:
cmpl%esi, (%eax)
movl%eax, %ebx
jle .L11
cmpl-4(%eax), %esi
leal0(,%ecx,4), %edx
leal-4(%eax), %ebp
jge .L30
.L11:
leal1(%ecx), %edx
addl$4, %eax
cmpl%edi, %edx
jne .L23

at least this is the most notable difference in the innermost loops on GIMPLE
(plenty of differences in the outer loop stuff).

Bin, any idea why IVO does the "bad" choice here?

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> With -fwhole-program there's no regression from GCC 6.2 to current trunk. 
> Without I still can see a small regression (here 0.86s vs 0.92s).
> 
> From looking at the assembly it's hard to tell what the issue is.  perf shows
> hot spots at mispredicted branches it seems (for both good and bad case).
> 
...
> at least this is the most notable difference in the innermost loops on GIMPLE
> (plenty of differences in the outer loop stuff).
> 
> Bin, any idea why IVO does the "bad" choice here?

Thanks for the investigation, I will have a look.

[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #20 from Richard Biener  ---
Fixed.

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
> So does LRA generate a full 64-bit load or an extended 32-to-64-bit load?

The former it seems, I can see:

(insn 218 211 8356 2 (set (reg:SI 4 $4 [2479])
(ne:SI (reg:DI 22 $22 [orig:230 _3 ] [230])
(const_int 0 [0]))) "/althome/mips/v6/src/gcc/gcc/c/c-decl.c":5551
505 {*sne_zero_disi}
 (nil))

(insn 8356 218 220 2 (set (mem/c:SI (plus:DI (reg/f:DI 29 $sp)
(const_int 208 [0xd0])) [680 %sfp+208 S4 A64])
(reg:SI 4 $4 [2479])) "/althome/mips/v6/src/gcc/gcc/c/c-decl.c":5551
312 {*movsi_internal}
 (nil))

[...]

(insn 8609 4185 4186 635 (set (reg/v:DI 2 $2 [orig:279 threadp ] [279])
(mem/c:DI (plus:DI (reg/f:DI 29 $sp)
(const_int 208 [0xd0])) [680 %sfp+208 S8 A64]))
"/althome/mips/v6/src/gcc/gcc/c/c-decl.c":6618 310 {*movdi_64bit}
 (nil))

That's incorrect, see what reload1.c:eliminate_regs_1 says about it:

  if (MEM_P (new_rtx)
  && ((x_size < new_size
   /* On RISC machines, combine can create rtl of the form
  (set (subreg:m1 (reg:m2 R) 0) ...)
  where m1 < m2, and expects something interesting to
  happen to the entire word.  Moreover, it will use the
  (reg:m2 R) later, expecting all bits to be preserved.
  So if the number of words is the same, preserve the
  subreg so that push_reload can see it.  */
   && !(WORD_REGISTER_OPERATIONS
&& (x_size - 1) / UNITS_PER_WORD
   == (new_size -1 ) / UNITS_PER_WORD))
  || x_size == new_size)
  )
return adjust_address_nv (new_rtx, GET_MODE (x), SUBREG_BYTE (x));
  else
return gen_rtx_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE (x));

[Bug bootstrap/79098] [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target

[amodra at gcc dot gnu.org]

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

--- Comment #2 from Alan Modra  ---
Author: amodra
Date: Mon Jan 16 11:12:57 2017
New Revision: 244489

URL: https://gcc.gnu.org/viewcvs?rev=244489&root=gcc&view=rev
Log:
Powerpc bootstrap failure due to duplicate case value

PR target/79098
* config/rs6000/rs6000.c (rs6000_legitimate_combined_insn): Don't
use a switch.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug regression/53203] [5/6/7 Regression]: gcc.dg/setjmp-1.c

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #10 from Aldy Hernandez  ---
Cannot reproduce.  Can we close this?

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed

[mpf at gcc dot gnu.org]

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

--- Comment #16 from mpf at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #15)
> That's incorrect, see what reload1.c:eliminate_regs_1 says about it:
> 
> if (MEM_P (new_rtx)
> && ((x_size < new_size
>  /* On RISC machines, combine can create rtl of the form
> (set (subreg:m1 (reg:m2 R) 0) ...)
> where m1 < m2, and expects something interesting to
> happen to the entire word.  Moreover, it will use the
> (reg:m2 R) later, expecting all bits to be preserved.
> So if the number of words is the same, preserve the
> subreg so that push_reload can see it.  */
>  && !(WORD_REGISTER_OPERATIONS
>   && (x_size - 1) / UNITS_PER_WORD
>  == (new_size -1 ) / UNITS_PER_WORD))
> || x_size == new_size)
> )
>   return adjust_address_nv (new_rtx, GET_MODE (x), SUBREG_BYTE (x));
> else
>   return gen_rtx_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE (x));

I was just contemplating your comments on LRA and coming to the conclusion it
must be LRA in the end. The implications of the subreg with
WORD_REGISTER_OPERATIONS are quite a brain teaser.

I'll move on to LRA instead.

I forgot to say that while reviewing this issue I saw that your original patch
in combine removed a decent amount of zero extensions from MIPS. Thanks!

[Bug c++/79077] [7 regression][new inheriting ctors] bad code for inherited ctor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, the problem is that we set CALL_FROM_THUNK_P:
378   if (current_function_decl && decl
379   && flag_new_inheriting_ctors
380   && DECL_INHERITED_CTOR (current_function_decl)
381   && (DECL_INHERITED_CTOR (current_function_decl)
382   == DECL_CLONED_FUNCTION (decl)))
383 /* Pass arguments directly to the inherited constructor.  */
384 CALL_FROM_THUNK_P (function) = true;
on the Service::Service call in extends:extends inherited ctor, where the
second argument of current_function_decl is:
parm_decl 0x7fffefc50500 D.2359 type 
and the second argument of decl is:
parm_decl 0x7fffefc41980 name type 
The CALL_FROM_THUNK_P then prevents cp_genericize_r from actually transforming
the D.2359 parameter to *D.2359 that is needed after cp_genericize turned the
nameless D.2359 parameter into is_invisiref_parm.
I have no idea why call.c:384 sets the CALL_FROM_THUNK_P (is that for the case
that it can be called also when the DECL_INHERITED_CTOR (current_function_decl)
has invisiref parms replaced?

[Bug bootstrap/79098] [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #3 from Alan Modra  ---
Fixed.

[Bug tree-optimization/79088] [7 Regression] wrong code at -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Boostrapped/tested on x86_64-unknown-linux-gnu.

[Bug c++/79101] New: Registers aren't used for passing and returning objects when there is a move constructor

[o_kniemeyer at maxon dot net]

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

Bug ID: 79101
   Summary: Registers aren't used for passing and returning
objects when there is a move constructor
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: o_kniemeyer at maxon dot net
  Target Milestone: ---

According to the calling conventions of System V AMD64 ABI (e.g.
https://www.uclibc.org/docs/psABI-x86_64.pdf) a simple class with trivial copy
constructor and trivial destructor is passed and returned in a register, no
matter if there is a non-trivial move constructor or not. However this code:

struct X
{
  X(char* p = nullptr) : ptr(p) { }
  X(const X& src) = default;
  X(X&& src) : ptr(src.ptr) { src.ptr = nullptr; }
  X& operator=(const X&) = default;
  char* ptr;
};

X Test(X x)
{
  return x.ptr+1;
}

is (wrongly) compiled to

Test(X):
mov rdx, QWORD PTR [rsi]
mov rax, rdi
add rdx, 1
mov QWORD PTR [rdi], rdx
ret

whereas the code without move constructor is correctly compiled to

Test(X):
lea rax, [rdi+1]
ret

I checked this with all GCC versions on http://gcc.godbolt.org. Clang correctly
compiles the code to the two-liner with or without the move constructor.

[Bug rtl-optimization/70710] [5/6 Regression] Compile time hog w/ -O -g -fpeel-loops

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
Summary|[5/6/7 Regression] Compile  |[5/6 Regression] Compile
   |time hog w/ -O -g   |time hog w/ -O -g
   |-fpeel-loops|-fpeel-loops

--- Comment #3 from Aldy Hernandez  ---
Fixed on trunk by r243662.  Removing GCC7 regression marker.

commit c94328179741e7bdcaf59e888db809681859c6c6
Author: jakub 
Date:   Wed Dec 14 19:40:05 2016 +

PR debug/77844
* valtrack.c: Include rtl-iter.h.
(struct rtx_subst_pair): Add insn field.
(propagate_for_debug_subst): If pair->to contains at least 2
regs, create a DEBUG_INSN with a debug temp before pair->insn
and replace from with the debug temp instead of pair->to.
(propagate_for_debug): Initialize p.insn.
* combine.c (insn_uid_check): New inline function.
(INSN_COST, LOG_LINKS): Use it instead of INSN_UID.
(find_single_use, combine_instructions,
cant_combine_insn_p, try_combine): Use NONDEBUG_INSN_P instead of
INSN_P.

* g++.dg/opt/pr77844.C: New test.


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

[Bug libstdc++/78389] list::merge and list::sort are not exception safe

[ville at gcc dot gnu.org]

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

--- Comment #6 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jan 16 11:36:33 2017
New Revision: 244490

URL: https://gcc.gnu.org/viewcvs?rev=244490&root=gcc&view=rev
Log:
PR libstdc++/78389 fix backwards size adjustments.

PR libstdc++/78389
* include/bits/list.tcc (merge(list&&)): Fix backwards size adjustments.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/78389.cc: Add
better test for the sizes.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/list.tcc
trunk/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc

[Bug libstdc++/78702] [libstdc++] class __shim in locale::facet is private

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 16 11:41:41 2017
New Revision: 244491

URL: https://gcc.gnu.org/viewcvs?rev=244491&root=gcc&view=rev
Log:
PR78702 fix accessibility of locale::facet::__shim

PR libstdc++/78702
* include/bits/locale_classes.h (locale::facet::__shim): Change from
private to protected.
* src/c++11/cxx11-shim_facets.cc (__shim_accessor): Define helper to
make locale::facet::__shim accessible.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/locale_classes.h
trunk/libstdc++-v3/src/c++11/cxx11-shim_facets.cc

[Bug libstdc++/78702] [libstdc++] class __shim in locale::facet is private

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Should be fixed for gcc 7.

In general we still don't support building libstdc++ with Clang, and if you are
reporting bugs with unsupported setups please be sure to make it clear what
strange configuration y9ou're using.

[Bug c++/79101] Registers aren't used for passing and returning objects when there is a move constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is a bug in Clang, not GCC. This case has been discussed with the C++ ABI
group and GCC's behaviour is what was intended.

https://llvm.org/bugs/show_bug.cgi?id=19668

[Bug translation/79100] Superfluous % in messages from cfgloop.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
%' is documented format string:
   %': apostrophe (should only be used in untranslated messages;
   translations should use appropriate punctuation directly).

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
 CC||amker at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
CCing Bin, he was looking into PRE/predcom as well AFAIR.  predictive commoning
here performs unrolling to be able to avoid some loop-carried dependencies
while PRE has the larger distances covered by for example

 [85.00%]:
# prephitmp_656 = PHI <_125(6), pretmp_655(5)>
# prephitmp_674 = PHI 

this kind of loop carried PHIs should be a hint for a tree level unroller
to perform unrolling (just in case they literally appear in source for
example).
OTOH if unrolling can solve the RA problem then the it must be solvable not
unrolled as well?  Note that with predcom we end up with 11 pointer IVs while
with PRE we have just one (but use 20 others from the outer loop...) - possibly
the versioning predcom performs makes IVO not do any outer loop IVO.  Using
-fschedule-insns -fsched-pressure helps somewhat but not much.

So it looks like a RA related issue and IVO is as much relevant as PRE doing
predictive commoning at -O2 (and at -O3 doing predcoms job but worse in this
case).

During PHI translation we can tame this down to a level pre this rev. again,
for example with the following.  But ideally we'd compute antic and do
insertion
for the full dataflow problem and only apply this "cost modeling" during
elimination to not lose secondary level transforms that are profitable
(also below we do not know whether we need to insert a PHI for the value in
the end).

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 244484)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -1465,16 +1465,16 @@ phi_translate_1 (pre_expr expr, bitmap_s
  {
/* For non-CONSTANTs we have to make sure we can eventually
   insert the expression.  Which means we need to have a
-  leader for it.  */
-   if (constant->kind != CONSTANT)
+  leader for it.  Avoid doing this across backedges though. 
*/
+   if (constant->kind == CONSTANT)
+ return constant;
+   else if (! dominated_by_p (CDI_DOMINATORS, pred, phiblock))
  {
unsigned value_id = get_expr_value_id (constant);
constant = find_leader_in_sets (value_id, set1, set2);
if (constant)
  return constant;
  }
-   else
- return constant;
  }

tree result = vn_nary_op_lookup_pieces (newnary->length,


But as said, a whole different question is whether we want PRE to add IVs at
all
(but we do have some testcases requesting exactly that, for example
gcc.dg/tree-ssa/pr71347.c or ssa-pre-23.c requesting store-motion w/o actually
sinking the store).

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 244484)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -4290,6 +4290,31 @@ eliminate_dom_walker::before_dom_childre
   VN_INFO_RANGE_INFO (lhs));
}

+ if (sprime
+ && TREE_CODE (sprime) == SSA_NAME
+ && do_pre
+ && loop_outer (b->loop_father)
+ && has_zero_uses (sprime)
+ && bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (sprime)))
+   {
+ gimple *def_stmt = SSA_NAME_DEF_STMT (sprime);
+ basic_block def_bb = gimple_bb (def_stmt);
+ if (gimple_code (def_stmt) == GIMPLE_PHI
+ && def_bb->loop_father->header == def_bb)
+   {
+ bool ok = true;
+ edge_iterator ei;
+ edge e;
+ FOR_EACH_EDGE (e, ei, def_bb->preds)
+   if (dominated_by_p (CDI_DOMINATORS, e->src, e->dest)
+   && TREE_CODE (PHI_ARG_DEF_FROM_EDGE (def_stmt, e)) ==
SSA_NAME)
+ ok = false;
+ /* Don't keep sprime available.  */
+ if (!ok)
+   sprime = NULL_TREE;
+   }
+   }
+
  /* Inhibit the use of an inserted PHI on a loop header when
 the address of the memory reference is a simple induction
 variable.  In other cases the vectorizer won't do anything

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #2)
> (In reply to John Paul Adrian Glaubitz from comment #1)
> > I'll report back tomorrow.
> 
> Problem persists:

Correction: The patch fixes the alignment problem, but it exposes another bug:

root@mama:~# gccgo-6 hello-world.go -o hello-world2
root@mama:~# ./hello-world2
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x2 addr=0xa5eec0cf]

runtime stack:
runtime_dopanic
../../../src/libgo/runtime/panic.c:135
runtime_throw
../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
../../../src/libgo/runtime/go-signal.c:249
sig_panic_info_handler
../../../src/libgo/runtime/go-signal.c:283

:0
scanblock
../../../src/libgo/runtime/mgc0.c:1117
markroot
../../../src/libgo/runtime/mgc0.c:1368
runtime_parfordo
../../../src/libgo/runtime/parfor.c:93
gc
../../../src/libgo/runtime/mgc0.c:2270
mgc
../../../src/libgo/runtime/mgc0.c:2215
runtime_mstart
../../../src/libgo/runtime/proc.c:1076

goroutine 16 [garbage collection]:
runtime_mcall
../../../src/libgo/runtime/proc.c:295
runtime_gc
../../../src/libgo/runtime/mgc0.c:2191
runtime_mallocgc
../../../src/libgo/runtime/malloc.goc:259
__go_new
../../../src/libgo/runtime/go-new.c:16
main.main
/root/hello-world.go:6
runtime_main
../../../src/libgo/runtime/proc.c:626

goroutine 17 [runnable]:
kickoff
../../../src/libgo/runtime/proc.c:232
created by runtime_main
../../../src/libgo/runtime/proc.c:598

goroutine 18 [runnable]:
kickoff
../../../src/libgo/runtime/proc.c:232
created by runtime_createfing
../../../src/libgo/runtime/mgc0.c:2577
root@mama:~#

Looks like we're missing a signal handler on m68k.

[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature

[andrew.n.senkevich at gmail dot com]

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

--- Comment #12 from Andrew Senkevich  ---
(In reply to Kirill Yukhin from comment #10)
> (In reply to Andrew Senkevich from comment #8)
> > I think we should follow here declarations from icc headers to be compatible
> > with it.
> Okay. Could you pls state which rules ICC follows for all gather/scatter
> intrinsics?
> Could we use void const * for base in all gather intrinsics?
> What about scatters?

ICC uses "void const*" for gathers, "void*" for scatters.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> CCing Bin, he was looking into PRE/predcom as well AFAIR.  predictive
> commoning here performs unrolling to be able to avoid some loop-carried
> dependencies
> while PRE has the larger distances covered by for example
> 
>  [85.00%]:
> # prephitmp_656 = PHI <_125(6), pretmp_655(5)>
> # prephitmp_674 = PHI 
> 
> this kind of loop carried PHIs should be a hint for a tree level unroller
> to perform unrolling (just in case they literally appear in source for
> example).
> OTOH if unrolling can solve the RA problem then the it must be solvable not
> unrolled as well?  Note that with predcom we end up with 11 pointer IVs while
> with PRE we have just one (but use 20 others from the outer loop...) -
> possibly
> the versioning predcom performs makes IVO not do any outer loop IVO.  Using
> -fschedule-insns -fsched-pressure helps somewhat but not much.
> 
> So it looks like a RA related issue and IVO is as much relevant as PRE doing
> predictive commoning at -O2 (and at -O3 doing predcoms job but worse in this
> case).
> 
> During PHI translation we can tame this down to a level pre this rev. again,
> for example with the following.  But ideally we'd compute antic and do
> insertion
> for the full dataflow problem and only apply this "cost modeling" during
> elimination to not lose secondary level transforms that are profitable
> (also below we do not know whether we need to insert a PHI for the value in
> the end).
> 
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c  (revision 244484)
> +++ gcc/tree-ssa-pre.c  (working copy)
> @@ -1465,16 +1465,16 @@ phi_translate_1 (pre_expr expr, bitmap_s
>   {
> /* For non-CONSTANTs we have to make sure we can eventually
>insert the expression.  Which means we need to have a
> -  leader for it.  */
> -   if (constant->kind != CONSTANT)
> +  leader for it.  Avoid doing this across backedges though.
> */
> +   if (constant->kind == CONSTANT)
> + return constant;
> +   else if (! dominated_by_p (CDI_DOMINATORS, pred, phiblock))
>   {
> unsigned value_id = get_expr_value_id (constant);
> constant = find_leader_in_sets (value_id, set1, set2);
> if (constant)
>   return constant;
>   }
> -   else
> - return constant;
>   }
>  
> tree result = vn_nary_op_lookup_pieces (newnary->length,
> 
> 
> But as said, a whole different question is whether we want PRE to add IVs at
> all
> (but we do have some testcases requesting exactly that, for example
> gcc.dg/tree-ssa/pr71347.c or ssa-pre-23.c requesting store-motion w/o
> actually sinking the store).
> 
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c  (revision 244484)
> +++ gcc/tree-ssa-pre.c  (working copy)
> @@ -4290,6 +4290,31 @@ eliminate_dom_walker::before_dom_childre
>VN_INFO_RANGE_INFO (lhs));
> }
>  
> + if (sprime
> + && TREE_CODE (sprime) == SSA_NAME
> + && do_pre
> + && loop_outer (b->loop_father)
> + && has_zero_uses (sprime)
> + && bitmap_bit_p (inserted_exprs, SSA_NAME_VERSION (sprime)))
> +   {
> + gimple *def_stmt = SSA_NAME_DEF_STMT (sprime);
> + basic_block def_bb = gimple_bb (def_stmt);
> + if (gimple_code (def_stmt) == GIMPLE_PHI
> + && def_bb->loop_father->header == def_bb)
> +   {
> + bool ok = true;
> + edge_iterator ei;
> + edge e;
> + FOR_EACH_EDGE (e, ei, def_bb->preds)
> +   if (dominated_by_p (CDI_DOMINATORS, e->src, e->dest)
> +   && TREE_CODE (PHI_ARG_DEF_FROM_EDGE (def_stmt, e))
> == SSA_NAME)
> + ok = false;
> + /* Don't keep sprime available.  */
> + if (!ok)
> +   sprime = NULL_TREE;
> +   }
> +   }
> +
>   /* Inhibit the use of an inserted PHI on a loop header when
>  the address of the memory reference is a simple induction
>  variable.  In other cases the vectorizer won't do anything

I am trying to model register pressure and use that information to direct
predcom.  So far it detects only one case 436.cactusADM but does improve a lot.
 Though it's hard to model cost of pre_expr, but for loop carries ones, we may
be able to simply control the number using pressure information too.  According
to the report, t

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #9 from Thomas Preud'homme  ---
It fails on arm-none-eabi too. But given it allocates 12 bytes on the stack and
goes on to write 32 bytes that seems pretty normal, no? Shouldn't this test
just be a compile test?

[Bug tree-optimization/79054] missing range information with INT_MAX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
I see the same failure on i386-pc-solaris2.12, sparc-sun-solaris2.12, and
i686-pc-linux-gnu:

+FAIL: gcc.dg/attr-alloc_size-4.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/attr-alloc_size-4.c:142:3:
warning: argument 1 range [1236, 2147483647] exceeds maximum object size 1234
[-Walloc-size-larger-than=]

  Rainer

[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Indeed it is.

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So initially we generate

DIE0: DW_TAG_GNU_call_site (0x768cd690)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_low_pc: label: *.LVL1
  DW_AT_abstract_origin: address

but that later gets rewritten invalidly where Jakub points out.  The regression
is because we prune the DIE for Baz as unused after

  /* Generate separate COMDAT sections for type DIEs. */
  if (use_debug_types)
{
  break_out_comdat_types (comp_unit_die ());

... now it is in a type unit ...

  /* In the process of copying declarations from one unit to another,
 we may have left some declarations behind that are no longer
 referenced.  Prune them.  */
  prune_unused_types ();
}

... and gets pruned.  But nothing adjusts what the decl refers to via
lookup_decl_die (not sure if we are supposed to adjust sth here).

Previously the call-site attribute kept the DIE live in the main CU DIE so
we had duplicate DIEs in the type unit plus the main CU.  With -gstrict-dwarf
it is only on the type unit as expected.

[Bug libstdc++/78389] list::merge and list::sort are not exception safe

[ville at gcc dot gnu.org]

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

--- Comment #7 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jan 16 13:30:58 2017
New Revision: 244492

URL: https://gcc.gnu.org/viewcvs?rev=244492&root=gcc&view=rev
Log:
PR libstdc++/78389 fix backwards size adjustments

Backport from mainline
2017-01-16  Ville Voutilainen  

PR libstdc++/78389
* include/bits/list.tcc (merge(list&&)): Fix backwards size adjustments.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/78389.cc: Add
better test for the sizes.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/list.tcc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc

[Bug libstdc++/78389] list::merge and list::sort are not exception safe

[ville at gcc dot gnu.org]

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

--- Comment #8 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Jan 16 13:32:39 2017
New Revision: 244493

URL: https://gcc.gnu.org/viewcvs?rev=244493&root=gcc&view=rev
Log:
PR libstdc++/78389 fix backwards size adjustments

Backport from mainline
2017-01-16  Ville Voutilainen  

PR libstdc++/78389
* include/bits/list.tcc (merge(list&&)): Fix backwards size adjustments.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/78389.cc: Add
better test for the sizes.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/list.tcc
   
branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc

[Bug fortran/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 Depends on||70696
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #14 from vehre at gcc dot gnu.org ---
Now that I have a second to check what is going on:

The error is fixed by the patch for 70696. The event-code in caf_single was
assuming a uint32_t but allocated only a bool, which made valgrind and the
instrumentation rightfully report an invalid access.

I have added the dependency to 70696 to get you notified, that when the
backport to gcc-6 is checked in this should be fixed on gcc-6, too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696
[Bug 70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[Bug fortran/78935] [7 Regression] ICE on allocating derived type coarray with allocatable components

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from vehre at gcc dot gnu.org ---
No regressions reported so far, closing.

[Bug fortran/78781] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from vehre at gcc dot gnu.org ---
No regressions reported so far, closing.

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[mail at milianw dot de]

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

--- Comment #16 from Milian Wolff  ---
So how can I silence the warning then for the case I pasted in the first
comment:

~~~+
#include 

template struct foo {};
foo emit_unexpected_warning;

int main() { return 0; }
~~~+

Most notably when you take into account that this is only sometimes required
based on the optimization level. Should I simply not use decltype and instead
paste the definition of malloc inline? Or is there a "silent" decltype
alternative I could use?

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[m.ostapenko at samsung dot com]

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

--- Comment #10 from Maxim Ostapenko  ---
Yeah, but it seems that lto doesn't propagate source location either:

/* Output info about new location into bitpack BP.
   After outputting bitpack, lto_output_location_data has
   to be done to output actual data.  */

void
lto_output_location (struct output_block *ob, struct bitpack_d *bp,
 location_t loc)
{
  expanded_location xloc;

  loc = LOCATION_LOCUS (loc);
  bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
loc < RESERVED_LOCATION_COUNT
? loc : RESERVED_LOCATION_COUNT);
  if (loc < RESERVED_LOCATION_COUNT)
return;

[...]
}

where RESERVED_LOCATION_COUNT == 2. Or maybe I missed something?
We can probably teach it to propagate source location but is it OK for current
stage?

[Bug c/79102] New: gcc fails to auto-vectorise the product of an array of complex floats

[drraph at gmail dot com]

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

Bug ID: 79102
   Summary: gcc fails to auto-vectorise the product of an array of
complex floats
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drraph at gmail dot com
  Target Milestone: ---

Consider this simple piece of code.

#include 
complex float f(complex float x[]) {
  complex float p = 1.0;
  for (int i = 0; i < 128; i++)
p *= x[i];
  return p;
}

If I compile it with -O3 -march=bdver2 -ffast-math  I get

f:
vmovss  xmm2, DWORD PTR .LC1[rip]
vxorps  xmm1, xmm1, xmm1
lea rax, [rdi+256]
.L2:
vmovss  xmm0, DWORD PTR [rdi+4]
add rdi, 8
vmulss  xmm3, xmm0, xmm2
vmulss  xmm0, xmm0, xmm1
vfmadd132ss xmm1, xmm3, DWORD PTR [rdi-8]
vfmsub132ss xmm2, xmm0, DWORD PTR [rdi-8]
cmp rax, rdi
jne .L2
vmovss  DWORD PTR [rsp-8], xmm2
vmovss  DWORD PTR [rsp-4], xmm1
vmovq   xmm0, QWORD PTR [rsp-8]
ret
.LC1:
.long   1065353216


This is unvectorised code. However if I do the same using float instead, that
is with:

float f(float x[], int n ) {
  float p = 1.0;
  for (int i = 0; i < 32; i++)
p *= x[i];
  return p;
}

I get

vmovups xmm2, XMMWORD PTR [rdi]
vmulps  xmm0, xmm2, XMMWORD PTR [rdi+16]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+32]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+48]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+64]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+80]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+96]
vmulps  xmm0, xmm0, XMMWORD PTR [rdi+112]
vpsrldq xmm1, xmm0, 8
vmulps  xmm0, xmm0, xmm1
vpsrldq xmm1, xmm0, 4
vmulps  xmm0, xmm0, xmm1
ret

This is vectorised.

As a test I also the Intel C compiler version 17. In this case the assembly you
get using complex float is however vectorised giving:

f:
mov   rdx, rdi  #4.3
and   rdx, 15   #4.3
movsd xmm0, QWORD PTR p.152.0.0.1[rip]  #3.19
test  dl, dl#4.3
je..B1.4# Prob 50%  #4.3
test  dl, 7 #4.3
jne   ..B1.12   # Prob 10%  #4.3
movsd xmm0, QWORD PTR [rdi] #5.10
mov   dl, 1 #4.3
..B1.4: # Preds ..B1.3 ..B1.1
movzx eax, dl   #4.3
neg   dl#4.3
and   dl, 3 #4.3
movzx edx, dl   #4.3
movss xmm1, DWORD PTR .L_2il0floatpacket.0[rip] #3.19
neg   rdx   #4.3
movlhps   xmm0, xmm1#3.19
add   rdx, 128  #4.3
..B1.5: # Preds ..B1.5 ..B1.4
movapsxmm2, xmm0#5.5
movupsxmm1, XMMWORD PTR [rdi+rax*8] #5.10
shufpsxmm2, xmm0, 160   #5.5
mulps xmm2, xmm1#5.5
xorps xmm1, XMMWORD PTR .L_2il0floatpacket.1[rip]   #5.5
shufpsxmm1, xmm1, 177   #5.5
shufpsxmm0, xmm0, 245   #5.5
mulps xmm1, xmm0#5.5
movupsxmm3, XMMWORD PTR [16+rdi+rax*8]  #5.10
add   rax, 4#4.3
addps xmm2, xmm1#5.5
movapsxmm0, xmm2#5.5
shufpsxmm0, xmm2, 160   #5.5
mulps xmm0, xmm3#5.5
xorps xmm3, XMMWORD PTR .L_2il0floatpacket.1[rip]   #5.5
shufpsxmm3, xmm3, 177   #5.5
shufpsxmm2, xmm2, 245   #5.5
mulps xmm3, xmm2#5.5
addps xmm0, xmm3#5.5
cmp   rax, rdx  #4.3
jb..B1.5# Prob 99%  #4.3
movapsxmm1, xmm0#3.19
movhlps   xmm1, xmm0 

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Perhaps we could combine the #c1 patch with some changes to make sure we don't
prune those types that appear in callgraph edges callee contexts?
Is the early finish debug hook called after some minimal cgraph optimizations
(removal of unused functions)?

[Bug bootstrap/78616] Poison strndup in system.h

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm  ---
Author: dmalcolm
Date: Mon Jan 16 15:03:41 2017
New Revision: 244494

URL: https://gcc.gnu.org/viewcvs?rev=244494&root=gcc&view=rev
Log:
system.h: Poison strndup (PR bootstrap/78616)

gcc/ChangeLog:
PR bootstrap/78616
* system.h: Poison strndup.


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

[Bug bootstrap/78616] Poison strndup in system.h

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #15 from David Malcolm  ---
(In reply to Jeffrey A. Law from comment #12)
> Regression fixed (regression marker removed).  All that's left is to poison
> strndup in system.h

Poisoned in r244494; marking this PR as resolved.

[Bug c++/79103] New: [7 Regression] build_variant_type_copy ICE

[dje at gcc dot gnu.org]

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

Bug ID: 79103
   Summary: [7 Regression] build_variant_type_copy ICE
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
Blocks: 71737
  Target Milestone: ---
Target: powerpc-ibm-aix*

The patch for PR 71737 introduced a new regression in libstdc++

libstdc++-v3/include/tr1/shared_ptr.h:556: internal compiler error:
tree check: expected class 'type', have 'exceptional' (error_mark) in
build_variant_type_copy, at tree.c:6737


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71737
[Bug 71737] [5/6 Regression] ICE following 2x pack expansion in non-pack with
template alias

[Bug c++/79103] [7 Regression] build_variant_type_copy ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
New

[Bug c++/71737] [5/6 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo at gcc dot gnu.org]

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

--- Comment #8 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Jan 16 15:43:06 2017
New Revision: 244496

URL: https://gcc.gnu.org/viewcvs?rev=244496&root=gcc&view=rev
Log:
/c-family
2017-01-16  Paolo Carlini  

Revert:
2017-01-16  Paolo Carlini  

PR c++/71737
* c-common.c (set_underlying_type): Always set DECL_ORIGINAL_TYPE.

/testsuite
2017-01-16  Paolo Carlini  

Revert:
2017-01-16  Paolo Carlini  

PR c++/71737
* g++.dg/cpp0x/pr71737.C: New.

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

[Bug c++/71737] [5/6/7 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[5/6 Regression] ICE|[5/6/7 Regression] ICE
   |following 2x pack expansion |following 2x pack expansion
   |in non-pack with template   |in non-pack with template
   |alias   |alias

--- Comment #9 from Paolo Carlini  ---
Patch reverted, unfortunately,
tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc regresses.

[Bug c++/71737] [5/6/7 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo.carlini at oracle dot com]

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

Bug 79103 Summary: [7 Regression] build_variant_type_copy ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79103

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/79103] [7 Regression] build_variant_type_copy ICE

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from Paolo Carlini  ---
Yes, I noticed, patch reverted, sorry.

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Mon Jan 16 15:50:47 2017
New Revision: 244497

URL: https://gcc.gnu.org/viewcvs?rev=244497&root=gcc&view=rev
Log:
PR testsuite/79051 - FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line
140)

gcc/testsuite/ChangeLog:
* gcc.dg/attr-alloc_size-4.c: Avoid exercising a test case except
on x86.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c

[Bug tree-optimization/79054] missing range information with INT_MAX

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
I committed r244497 to avoid exercising the test case on that line on
non-x86_64 targets.  It passes on x86_64 with the native compiler and with a
sparc-sun-solaris2.11 cross-compiler, in both ILP32 and LP64 modes.

This bug tracks the GCC bug that causes the test assertion failure.  If there
are any other failures in this particular assertion they should probably be
brought up in bug 79051 which tracked the failing assertion for this test case
(now caused by the ineffective/incomplete target directive and the missing
preprocessor guard).  If any other assertions in the test fail I think it would
be best to open a separate bug for those since they are likely unrelated to
this bug.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely  ---
Author: redi
Date: Mon Jan 16 15:58:06 2017
New Revision: 244498

URL: https://gcc.gnu.org/viewcvs?rev=244498&root=gcc&view=rev
Log:
PR66145 use new ABI for std::ios::failure exceptions

PR libstdc++/66145
* src/c++11/functexcept.cc: Use new ABI for std::ios_base::failure
exceptions.
* testsuite/27_io/basic_ios/copyfmt/char/1.cc: Don't override ABI
for test, so new ios::failure can be caught.
* testsuite/27_io/basic_ios/exceptions/char/1.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/char/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/
exceptions_failbit.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/char/12297.cc: Likewise.
* testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/
exceptions_null.cc: Likewise.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/
exceptions_null.cc: Likewise.
* testsuite/27_io/ios_base/storage/2.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/functexcept.cc
trunk/libstdc++-v3/testsuite/27_io/basic_ios/copyfmt/char/1.cc
trunk/libstdc++-v3/testsuite/27_io/basic_ios/exceptions/char/1.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_null.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/12297.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_null.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc
trunk/libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |7.0

--- Comment #29 from Jonathan Wakely  ---
GCC 7 will throw the new ios_base::failure type (unless built so the cxx11 ABI
is completely disabled).

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[m.ostapenko at samsung dot com]

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

--- Comment #11 from Maxim Ostapenko  ---
(In reply to Maxim Ostapenko from comment #10)
> Yeah, but it seems that lto doesn't propagate source location either:
> 
> /* Output info about new location into bitpack BP.
>After outputting bitpack, lto_output_location_data has
>to be done to output actual data.  */
> 
> void
> lto_output_location (struct output_block *ob, struct bitpack_d *bp,
>  location_t loc)
> {
>   expanded_location xloc;
> 
>   loc = LOCATION_LOCUS (loc);
>   bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
> loc < RESERVED_LOCATION_COUNT
> ? loc : RESERVED_LOCATION_COUNT);
>   if (loc < RESERVED_LOCATION_COUNT)
> return;
> 
> [...]
> }
> 
> where RESERVED_LOCATION_COUNT == 2. Or maybe I missed something?
> We can probably teach it to propagate source location but is it OK for
> current stage?

Hm, attached patch seems to propagate source location normally:

diff --git a/gcc/tree-streamer-in.c b/gcc/tree-streamer-in.c
index 3496df5..714a5b1 100644
--- a/gcc/tree-streamer-in.c
+++ b/gcc/tree-streamer-in.c
@@ -405,6 +405,7 @@ unpack_ts_translation_unit_decl_value_fields (struct
data_in *data_in,
  struct bitpack_d *bp, tree expr)
 {
   TRANSLATION_UNIT_LANGUAGE (expr) = xstrdup (bp_unpack_string (data_in, bp));
+  DECL_SOURCE_LOCATION (expr) = stream_input_location_now (bp, data_in);
   vec_safe_push (all_translation_units, expr);
 }

diff --git a/gcc/tree-streamer-out.c b/gcc/tree-streamer-out.c
index 0ee2abe..3c11d61 100644
--- a/gcc/tree-streamer-out.c
+++ b/gcc/tree-streamer-out.c
@@ -359,6 +359,7 @@ pack_ts_translation_unit_decl_value_fields (struct
output_block *ob,
struct bitpack_d *bp, tree expr)
 {
   bp_pack_string (ob, bp, TRANSLATION_UNIT_LANGUAGE (expr), true);
+  stream_output_location (ob, bp, DECL_SOURCE_LOCATION (expr));
 }


diff --git a/gcc/tree.c b/gcc/tree.c
index cffa36d..ee611e2 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -4758,7 +4758,9 @@ vec *all_translation_units;
 tree
 build_translation_unit_decl (tree name)
 {
-  tree tu = build_decl (UNKNOWN_LOCATION, TRANSLATION_UNIT_DECL,
+  linemap_add (line_table, LC_ENTER, false, main_input_filename, 1);
+  location_t loc = linemap_line_start (line_table, 1, 0);
+  tree tu = build_decl (loc, TRANSLATION_UNIT_DECL,
name, NULL_TREE);
   TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.name;
   vec_safe_push (all_translation_units, tu);

The only issue is failing diagnostic test now:
/home/max/workspace/downloads/gcc/gcc/diagnostic.c:1557:
test_print_parseable_fixits_insert: FAIL: ASSERT_STREQ
("fix-it:\"test.c\":{5:10-5:10}:\"added content\"\n", pp_formatted_text (&pp))
expected="fix-it:"test.c":{5:10-5:10}:"added content"
" actual="fix-it:"/dev/null":{33:10-33:10}:"added content"
"

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #9 from Zaak  ---
Will this fix get back ported to the 6 and 5 branches?

[Bug target/61729] FAIL: g++.dg/abi/scoped1.C -std=gnu++11 execution test

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
FWIW, new C floating-point types such as _Float16 and _Float32 are not 
promoted in variable arguments either, which has required a few back-end 
changes.  Complex types such as _Complex float or _Complex char never are 
promoted, but for a long time it seems we weren't testing those in 
variable arguments either (I'm not sure if we now have tests for such 
types in variable arguments).

So it's consistent with that to have unpromoted new C++ types (and 
presumably naming those types in va_arg needs to work correctly), but they 
might well cause more problems than the above examples.

[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-16
 CC||mpf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dgilmore at mips dot com
 Ever confirmed|0   |1

--- Comment #13 from mpf at gcc dot gnu.org ---
(In reply to Maciej W. Rozycki from comment #11)
> TBH this does look like trying to rely on UB to me, as per section
> 6.5.6 "Additive operators" clause 8 of the C language standard, which
> states (among others):
> 
> "If both the pointer operand and the result point to elements of the
> same array object, or one past the last element of the array object,
> the evaluation shall not produce an overflow; otherwise, the behavior
> is undefined."
> 
> Here under the triggering conditions the pointer the integer is added
> to with LDXC1 does not point to an element of the array operated on (or
> to one past the last), so the hardware operation matches the standard's
> semantics WRT overflow and I don't think we ought to be pushing it.

Aren't language rules mostly irrelevant at this stage though?
We don't really have the concept of a pointer after generating RTL we just
happen to have some values in a mode that is the same as Pmode.

mips.h comment for Pmode:

/* Specify the machine mode that pointers have.
   After generation of rtl, the compiler makes no further distinction
   between pointers and any other objects of this machine mode.  */

> So it looks like a middle end bug to me and the backend is fine in
> faithfully assuming its RTL pattern won't be passed operands leading to
> UB.

I can't see any feature/option/setting that gives this guarantee. Why do you
think the backend can make this assumption?

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The important thing is that it is only possible to refer to a single DIE in the
type unit (.debug.types.* in DWARF4, .debug_info DW_UT_type unit in DWARF5);
in the #c0 case it is the Bar DW_TAG_structure_type, a child of
DW_TAG_unit_type.
If one needs to refer to anything else, the DIE with selected needed children
needs to be copied from the type unit to the compilation unit.
So if you e.g. look at what debug info we generate for:
struct Bar { void Baz (); int i; };
Bar b;
void Foo (Bar &t) { t.Baz (); }
(compile with -g -fdebug-types-section -O2 -dA -gstrict-dwarf, the last option
so that it doesn't ICE), and
struct Bar { void Baz (); static int i; };
int Bar::i = 17;
Bar b;
void Foo (Bar &t) { t.Baz (); }
(compile with -g -fdebug-types-section -O2 -dA), you'll see that in the former
case we don't know about any references to Bar::Baz and everything that needs
Bar only needs Bar itself and thus there is the type unit, the b variable's
DW_AT_type uses DW_FORM_ref_sig8 to refer to the Bar DIE in the type unit and
similarly DW_TAG_reference_type's DW_AT_type (used in t's type).
Without -gstrict-dwarf there is a need for the reference to Bar::Baz that can't
refer to the type unit, but we don't know about that reference during early
debug finish.
Now compare that to the second case.  We need to refer to Bar::i, because we
provide a definition for that.  So there is a skeleton DW_TAG_structure_type in
the compilation unit for Bar type, with DW_AT_signature that says for anything
not mentioned here, refer to the type unit's Bar.  This testcase doesn't ICE
without -gstrict-dwarf.

[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP

[wilco at gcc dot gnu.org]

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

--- Comment #27 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #26)
> Hello, did the Gap scores on arm too? Both Itanium and PPC testers seems to
> show improved gap scores, so hope arm and the other ppc tester too.

On SPEC2000 the latest changes look good, compared to the old predictor gap
improved by 10% and INT/FP by 0.8%/0.6%. I'll run SPEC2006 tonight.

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[vehre at gcc dot gnu.org]

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

--- Comment #10 from vehre at gcc dot gnu.org ---
The effort is quite significant, because several support functions have to be
ported from other commits. I.e., I do not want to spend too much time on it.

[Bug c++/79104] New: [7.0 regression] ambiguity calling std::end on a local constexpr array of structs

[msebor at gcc dot gnu.org]

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

Bug ID: 79104
   Summary: [7.0 regression] ambiguity calling std::end on a local
constexpr array of structs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The program below reduced from the test case for bug 56973 compiles
successfully with GCC 6 (in addition to Clang and Oracle Solaris Studio) but
fails with the current trunk of GCC 7.0 (and also EDG 4.11).  Making the array
static or moving the declaration to namespace scope resolves the error. 
Changing the array from one of structs to one of characters also works.

$ cat u.C && g++ u.C
template 
inline auto
begin (C& c) -> decltype (c.begin ());

template 
inline constexpr T*
begin (T (&a)[N]) { return a; }

void f ()
{
  constexpr struct { const char *s; } a[] = { { "a" } };

  auto i = begin (a);

  auto test=[&]() {
i = begin (a);
  };
}
u.C: In lambda function:
u.C:16:17: error: no matching function for call to ‘begin(const f():: [1])’
 i = begin (a);
 ^
u.C:3:1: note: candidate: template decltype (c.begin()) begin(C&)
 begin (C& c) -> decltype (c.begin ());
 ^
u.C:3:1: note:   template argument deduction/substitution failed:
u.C: In substitution of ‘template decltype (c.begin()) begin(C&) [with
C = const f():: [1]]’:
u.C:16:17:   required from here
u.C:3:29: error: request for member ‘begin’ in ‘c’, which is of non-class type
const f():: [1]’
 begin (C& c) -> decltype (c.begin ());
   ~~^
u.C:7:1: note: candidate: constexpr T* begin(T (&)[N]) [with T = const
f()::; long unsigned int N = 1]
 begin (T (&a)[N]) { return a; }
 ^
u.C:7:1: note:   no known conversion for argument 1 from ‘const f():: [1]’ to ‘const f():: (&)[1]’

[Bug c++/79104] [7.0 regression] ambiguity calling std::end on a local constexpr array of structs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56973

--- Comment #1 from Martin Sebor  ---
See bug 56973 for the original test case.

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Now, even going through all cgraph edges and marking the callee DIEs as used
(setting die_mark for them) early (but I guess it would be better to do the
early finish then after early optimizations, but before free_lang_data) would
help in this particular case, but not when we only need devirtualization or
later optimizations to turn indirect calls into direct calls.
Creating a skeleton DIE tree in resolve_addr is yet another option, but I'm not
very familiar with the break_out_comdat_types details (generate_skeleton and
the like) to know how difficult it would be exactly.  Though, for LTO we'll
need to figure out anyway where to create those.

[Bug c++/79104] [7.0 regression] ambiguity calling std::end on a local constexpr array of structs

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
As a couple of additional data points EDG 4.11 and IBM XLC++ both reject the
test case.  EDG with an error similar to GCC.

[Bug fortran/79097] coarray and pointer component

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||vehre at gcc dot gnu.org
   Host|x86_64-apple-darwin15.6.0   |
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from vehre at gcc dot gnu.org ---
The memory pointing to is not registered correctly with coarrays.

[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
Compiling the test in comment 0 with -fcoarray=lib -lcaf_single at r244453
fails at link time with

Undefined symbols for architecture x86_64:
  "_caf_token.0.3515", referenced from:
  __caf_init.1.3517 in ccsoo9HI.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

[Bug c/78304] [7 Regression] -Wformat doesn't warn anymore for inttypes.h format string argument type mismatches

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Author: dmalcolm
Date: Mon Jan 16 18:08:45 2017
New Revision: 244502

URL: https://gcc.gnu.org/viewcvs?rev=244502&root=gcc&view=rev
Log:
Fix testcases for PR c/78304

The testcases as written made assumptions about size_t and long
being invalid for use with "%u".

We only need some invalid type, so this patch converts them to
attempt a "const char *" with "%u", which should be invalid for
every target.

gcc/testsuite/ChangeLog:
PR c/78304
* gcc.dg/format/pr78304.c: Convert argument from integral type
to a pointer.
* gcc.dg/format/pr78304-2.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/format/pr78304-2.c
trunk/gcc/testsuite/gcc.dg/format/pr78304.c

[Bug target/79105] New: Autovectorized NEON code slower than vfpv4 on Cortex A5

[tulipawn at gmail dot com]

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

Bug ID: 79105
   Summary: Autovectorized NEON code slower than vfpv4 on Cortex
A5
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

As the title says, many results seem to suffer from switching to -mfpu=neon,
etc.

http://openbenchmarking.org/result/1701165-TA-1701143TA78

Could anyone explain the abnormally small difference between armv7 and aarch64
in OpenSSL?

[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #23 from Vladimir Makarov  ---
Thanks for reporting and investigation this problem.  I've just started to work
on this PR.

[Bug fortran/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib" on gcc-6 only

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-16
 CC||vehre at gcc dot gnu.org
  Component|middle-end  |fortran
Summary|ICE when mixing |ICE when mixing
   |"-fprofile-arcs |"-fprofile-arcs
   |-ftest-coverage" and|-ftest-coverage" and
   |"-fcoarray=lib" |"-fcoarray=lib" on gcc-6
   ||only
 Ever confirmed|0   |1

[Bug debug/78835] [7 regression] ICE with -fdebug-types-section and member function

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 40524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40524&action=edit
gcc7-pr78835.patch

Untested patch that fixes the ICE on this testcase by marking directly called
functions as needed.  Will see what will it do with the size of the debug info.
Of course, it is not sufficient, with -fdebug-types-section we can still ICE
unless the earlier patch is also applied 9or some more sophisticated one to
construct skeleton DIEs if type inside of type unit is detected).

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

  Attachment #40514|0   |1
is obsolete||

--- Comment #12 from Maxim Ostapenko  ---
Created attachment 40525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40525&action=edit
Untested fix 2.

The patch I'm testing now.

[Bug preprocessor/79106] New: wrong source line printed in diagnostics for a translation unit

[msebor at gcc dot gnu.org]

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

Bug ID: 79106
   Summary: wrong source line printed in diagnostics for a
translation unit
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When printing the source file line in diagnostic messages for a translation
unit (a .i or .ii file) GCC uses the source file the translation unit was
created from rather than the translation unit itself.  That can be pretty
confusing for those unaware of this "feature."  (It took me a few minutes to
figure out what was going on while reducing a large translation unit to a small
test case.)

$ (set -x && cat a.c && cat a.i && /build/gcc-5-branch/gcc/xgcc -B
/build/gcc-5-branch/gcc -S a.i)
+ cat a.c
int foo (void) {
  return -1;
}

+ cat a.i
# 1 "a.c"
int foo (void) {
  return "";
}
+ /build/gcc-5-branch/gcc/xgcc -B /build/gcc-5-branch/gcc -S a.i
a.c: In function ‘foo’:
a.c:2:10: warning: return makes integer from pointer without a cast
[-Wint-conversion]
   return -1;
  ^

Clang, in contrast, prints the contents of translation unit as one would
presumably expect as I do:

$ clang -S a.i
a.c:2:10: warning: incompatible pointer to integer conversion returning
  'char [1]' from a function with result type 'int' [-Wint-conversion]
  return "";
 ^~
1 warning generated.

[Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
IMNSHO the GCC behavior is the right thing to do, that is how the source looks
like.  If the preprocessed file has been hand-edited, it is just a user bug.

[Bug c++/79104] [7.0 regression] ambiguity calling std::begin on a local constexpr array of structs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
This changed with r240819.

[Bug fortran/79107] New: ICE on name resolution within internal subroutine

[baradi09 at gmail dot com]

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

Bug ID: 79107
   Summary: ICE on name resolution within internal subroutine
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

I get an ICE on the minimal self containing input below. Shifting the module
import from within the internal subroutine to the host (program) level avoids
the ICE. Also, enabling the type(Extended) to be public in module mod_test (by
commenting out the private statement in mod_test) avoids the ICE as well.

module mod_base

  type :: Base
  contains
procedure :: init
  end type Base

contains

  subroutine init(this)
class(Base), intent(inout) :: this
continue
  end subroutine init

end module mod_base


module mod_extended
  use mod_base

  type, extends(Base) :: Extended
  end type Extended

end module mod_extended


module mod_test
  use mod_extended
  ! If you comment out the next line, no
  private

  public :: test

contains

  subroutine test(this)
class(Extended), intent(inout) :: this
continue
  end subroutine test

end module mod_test


program prg_test
  use mod_extended

  call run_test()

contains

  subroutine run_test()
! If you import mod_test on the program level, no ICE
use mod_test
type(Extended) :: myExt
!!!
!!! ICE at next line
!!!
call myExt%init()
call test(myExt)

  end subroutine run_test

end program prg_test

[Bug c/68473] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #17 from David Malcolm  ---
(In reply to David Malcolm from comment #12)
> (In reply to David Malcolm from comment #11)
> > Author: dmalcolm
> > Date: Tue Dec 22 22:27:45 2015
> > New Revision: 231919
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=231919&root=gcc&view=rev
> > Log:
> > PR c/68473: sanitize source range-printing within certain macro expansions
> 
> This commit corresponds to the patch from comment #5, rather than the one
> from comment #9.  Keeping this open in the hope of doing a more thorough fix
> for this, but this may need to wait for gcc 7.

I believe the commits in comment #14 and comment #15 address this.

I've verified that both reproducers are fixed; marking this one as resolved.

[Bug jit/69435] Truncated lines in jit.log

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Followup was here:
  http://lists.gnu.org/archive/html/dejagnu/2016-02/msg6.html

2016-02-15  Ben Elliston  

Reported by David Malcolm.
* lib/dejagnu.exp (text): Allow angle brackets in test messages.

diff --git a/lib/dejagnu.exp b/lib/dejagnu.exp
index b2ffe40..89016b4 100644
--- a/lib/dejagnu.exp
+++ b/lib/dejagnu.exp
@@ -20,7 +20,7 @@
 # This file was written by Rob Savoye .

 # A hairy pattern to recognize text.
-set text "\[- A-Za-z0-9\.\;\"\_\:\'\`\(\)\!\#\=\+\?\&\*]"
+set text "\[- A-Za-z0-9\.\;\"\_\:\'\`\(\)\!\#\=\+\?\&\*<>]"

 set SIZE size
 if { [which $SIZE] == 0 } {

[Bug jit/69435] Truncated lines in jit.log

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #4)
> Followup was here:
>   http://lists.gnu.org/archive/html/dejagnu/2016-02/msg6.html

which is:
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commitdiff;h=e3d0bafb18ebf56cad1822dafc4332643903b084

and would appear to be present in DejaGnu 1.6 onwards.

[Bug ipa/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m, pinskia at gmail dot com

--- Comment #10 from Andrew Senkevich  ---
This commit breaks 5 SPEC CPU 2006 benchmarks (416.gamess, 454.calculix,
459.GemsFDTD, 465.tonto, 481.wrf) with ICE on x86_64 (and looks like on aarch64
the same - https://gcc.gnu.org/ml/gcc/2017-01/msg00126.html).

commit 72b16d90bd23d9c5758c165f8258522871c755ff
Author: jamborm 
Date:   Mon Jan 9 18:26:37 2017 +

[PR 78365] Prudent type handling in IPA VR-prop

[Bug target/61729] FAIL: g++.dg/abi/scoped1.C -std=gnu++11 execution test

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Okay, I'll make it work for SVR4 in the rs6000 backend then.

The generic code makes suboptimal code, many ABIs need to update (even
those that haven't changed for 25 years), and more backends will need
to adjust; but if this is what C++ decided, we'll have to work with that.

Thanks for the confirmation.

[Bug ipa/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Senkevich from comment #10)
> This commit breaks 5 SPEC CPU 2006 benchmarks (416.gamess, 454.calculix,
> 459.GemsFDTD, 465.tonto, 481.wrf) with ICE on x86_64 (and looks like on
> aarch64 the same - https://gcc.gnu.org/ml/gcc/2017-01/msg00126.html).

Looks like a GC issue as I was reducing the code but removing the comments and
empty lines caused the testcase to no longer crash.  Adding --param
ggc-min-expand=1 --param ggc-min-heapsize=1 allowed it to ICE now.

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
   Target Milestone|--- |7.0

[Bug driver/49726] [5/6/7 Regression] -g0 file.S -g does not produce debug info

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 16 21:33:07 2017
New Revision: 244505

URL: https://gcc.gnu.org/viewcvs?rev=244505&root=gcc&view=rev
Log:
PR driver/49726
* gcc.c (debug_level_greater_than_spec_func): New function.
(static_spec_functions): Add debug-level-gt spec function.
(ASM_DEBUG_SPEC, cpp_options): Use %:debug-level-gt(0) instead of
!g0.
* config/darwin.h (DSYMUTIL_SPEC, ASM_DEBUG_SPEC): Likewise.
* config/darwin9.h (DSYMUTIL_SPEC, ASM_DEBUG_SPEC): Likewise.
* common.opt (g, gcoff, gdwarf, gdwarf-, ggdb, gno-pubnames,
gpubnames, ggnu-pubnames, gno-record-gcc-switches,
grecord-gcc-switches, gno-strict-dwarf, gstrict-dwarf, gstabs,
gstabs+, gtoggle, gvms, gxcoff, gxcoff+): Add Driver flag.
c-family/
* c.opt (gen-decls): Add Driver flag.
ada/
* gcc-interface/lang.opt (gant, gnatO, gnat): Add Driver flag.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/lang.opt
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/config/darwin.h
trunk/gcc/config/darwin9.h
trunk/gcc/gcc.c

[Bug ipa/79108] New: [7 Regression] ICE on some fortran code with -flto -Ofast

[pinskia at gcc dot gnu.org]

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

Bug ID: 79108
   Summary: [7 Regression] ICE on some fortran code with -flto
-Ofast
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: GC, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take the following fortran 90 code:
MODULE Errorcheck_mod
CONTAINS
SUBROUTINE Check_open(ios, outputstr, errortype)
character(len=*), intent(in) :: outputstr
if (ios > 0 .AND. errortype == FATAL) then
  write(*,*) 'The value of ios was:', ios
end if
END SUBROUTINE Check_open
END MODULE Errorcheck_mod

 CUT 
Compile it like:
gfortran  -nostdlib -r -Ofast -flto --param ggc-min-expand=0 --param
ggc-min-heapsize=0 errorcheck.f90
You get the following ICE:
lto1: internal compiler error: in ipa_get_type, at ipa-prop.h:448
0x107c737 ipa_get_type
../../gcc/gcc/ipa-prop.h:448
0x107c737 propagate_constants_across_call
../../gcc/gcc/ipa-cp.c:2259
0x10810f7 propagate_constants_topo
../../gcc/gcc/ipa-cp.c:3170
0x10810f7 ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:3267
0x1082173 ipcp_driver
../../gcc/gcc/ipa-cp.c:4997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gfortran returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status