[Bug lto/69254] [6 Regression] ICE in streamer_get_builtin_tree when using -fsanitize=shift on the compile side only

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 14 Jan 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69254
> 
> --- Comment #12 from Jakub Jelinek  ---
> I think this will require moving out the common_handle_option handling of
> -fsanitize{,-recover}= arguments (parsing them into a bitmask) into a separate
> function, because lto-wrapper seems to look at unparsed options.

Parts of it can go to opts-common.c I think though I wonder if you can't
handle the most important parts with just the unparsed code?  After all
you have to "emit" unparsed opts as well.

[Bug target/69252] [4.9/5/6 Regression] gcc.dg/vect/vect-iv-9.c FAILs with -Os -fmodulo-sched -fmodulo-sched-allow-regmoves -fsched-pressure

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Roman Zhuykov from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > insufficient SMS testsuite coverage.
> Not sure it's helpful, but 3 weeks ago I succesfully reg-strapped some bunch
> of my SMS patches including this fix on x86-64 and aarch64 using trunk
> 20151222. fmodulo-sched and fmodulo-sched-allow-regmoves options were
> enabled by default,  fsched-pressure left untouched. No new regressions,
> excluding some scan-assembler-times failures because of loop versioning.
> Maybe later on stage1 I'll send all my stuff to gcc-patches.

Please do, if the patches aren't posted, others can't benefit from them.

[Bug tree-optimization/69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 15 08:16:08 2016
New Revision: 232401

URL: https://gcc.gnu.org/viewcvs?rev=232401&root=gcc&view=rev
Log:
2016-01-15  Richard Biener  

PR tree-optimization/69117
* tree-ssa-sccvn.h (struct vn_ssa_aux): Add info member.
* tree-ssa-sccvn.c (set_ssa_val_to): Save and adjust SSA name info
of the leader conservatively.
(free_scc_vn): Restore original SSA name infos.

* gcc.dg/torture/pr69117.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69117.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug tree-optimization/69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed on trunk.

[Bug target/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |target

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #6)
> I can only reproduce with a ppc64le cross, but not be cross, supposedly
> because my ppc64le cross is using auto-host.h which Marek sent me from a
> native configured compiler, while the be one does not.  Maybe the difference
> is whether power8 instructions are supported by assembler or something
> similar.
> 
> Looking at the be->le differences, it starts in esra:
> ...
> -Rejected (2230): not aggregate: a
> -Rejected (2231): not aggregate: aa
> -Candidate (2234): u
> -Created a replacement for u offset: 0, size: 64: u$d$0
> +Rejected (2351): not aggregate: a
> +Rejected (2352): not aggregate: aa
> +Candidate (2355): u
> +! Disqualifying u - No scalar replacements to be created.
> ...
>  pack (double a, double aa)
>  {
> -  double u$d$0;
>union u_ld u;
>long double _6;
>  
>:
> -  u$d$0_8 = a_2(D);
> +  u.d[0] = a_2(D);
>u.d[1] = aa_4(D);
> -  _6 = u$d$0_8;
> +  _6 = u.ld;
>u ={v} {CLOBBER};
>return _6;
> 
> and if we don't SRA this, we don't optimize it away.  Ah, actually, I can
> reproduce even with the ppc64be cross, if I use explicit -mlong-double-128.

Ok, I can reproduce with -mlong-double-128 and with that the SLP vectorizer
triggers and produces

pack (double a, double aa)
{
  vector(2) double * vectp.6;
  vector(2) double * vectp_u.5;
  union u_ld u;
  long double _6;
  vector(2) double vect_cst__8;

  :
  vect_cst__8 = {a_2(D), aa_4(D)};
  MEM[(double *)&u] = vect_cst__8;
  _6 = u.ld;
  u ={v} {CLOBBER};
  return _6;

which then, as no FRE is running after vectorization, is not optimized
to a register vector-to-long-double punning (not sure if that would help).
SRA would help as well here.

With -fno-tree-slp-vectorize it's optimized somewhere on RTL.  Not sure
why it is able to grok the more complicated two-stores-one-load but
not the load-after-store.  Before combine we have with the vector code

(note 5 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 5 3 2 (set (reg/v:DF 158 [ a ])
(reg:DF 33 1 [ a ])) t.c:5 443 {*movdf_hardfloat64}
 (expr_list:REG_DEAD (reg:DF 33 1 [ a ])
(nil)))
(insn 3 2 4 2 (set (reg/v:DF 159 [ aa ])
(reg:DF 34 2 [ aa ])) t.c:5 443 {*movdf_hardfloat64}
 (expr_list:REG_DEAD (reg:DF 34 2 [ aa ])
(nil)))
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 9 2 (set (reg:V2DF 160)
(vec_concat:V2DF (reg/v:DF 158 [ a ])
(reg/v:DF 159 [ aa ]))) t.c:7 1084 {vsx_concat_v2df}
 (expr_list:REG_DEAD (reg/v:DF 159 [ aa ])
(expr_list:REG_DEAD (reg/v:DF 158 [ a ])
(nil
(insn 9 7 13 2 (set (reg:TF 157 [  ])
(subreg:TF (reg:V2DF 160) 0)) t.c:9 447 {*movtf_64bit_dm}
 (expr_list:REG_DEAD (reg:V2DF 160)
(nil)))
(insn 13 9 14 2 (set (reg/i:TF 33 1)
(reg:TF 157 [  ])) t.c:10 447 {*movtf_64bit_dm}
 (expr_list:REG_DEAD (reg:TF 157 [  ])
(nil)))

and with the non-vector code

(insn 2 5 3 2 (set (reg/v:DF 157 [ a ])
(reg:DF 33 1 [ a ])) t.c:5 443 {*movdf_hardfloat64}
 (expr_list:REG_DEAD (reg:DF 33 1 [ a ])
(nil)))
(insn 3 2 4 2 (set (reg/v:DF 158 [ aa ])
(reg:DF 34 2 [ aa ])) t.c:5 443 {*movdf_hardfloat64}
 (expr_list:REG_DEAD (reg:DF 34 2 [ aa ])
(nil)))
(note 4 3 16 2 NOTE_INSN_FUNCTION_BEG)
(insn 16 4 7 2 (set (reg/v:TI 155 [ u ])
(const_int 0 [0])) t.c:7 -1
 (nil))
(insn 7 16 8 2 (set (subreg:DF (reg/v:TI 155 [ u ]) 0)
(reg/v:DF 157 [ a ])) t.c:7 443 {*movdf_hardfloat64}
 (expr_list:REG_DEAD (reg/v:DF 157 [ a ])
(nil)))
(insn 8 7 9 2 (set (subreg:DF (reg/v:TI 155 [ u ]) 8)
(reg/v:DF 158 [ aa ])) t.c:8 443 {*movdf_hardfloat64}
 (expr_list:REG_DEAD (reg/v:DF 158 [ aa ])
(nil)))
(insn 9 8 13 2 (set (reg:TF 156 [  ])
(subreg:TF (reg/v:TI 155 [ u ]) 0)) t.c:9 447 {*movtf_64bit_dm}
 (expr_list:REG_DEAD (reg/v:TI 155 [ u ])
(nil)))
(insn 13 9 14 2 (set (reg/i:TF 33 1)
(reg:TF 156 [  ])) t.c:10 447 {*movtf_64bit_dm}
 (expr_list:REG_DEAD (reg:TF 156 [  ])
(nil)))


so the difference is

(insn 7 4 9 2 (set (reg:V2DF 160)
(vec_concat:V2DF (reg/v:DF 158 [ a ])
(reg/v:DF 159 [ aa ]))) t.c:7 1084 {vsx_concat_v2df}
 (expr_list:REG_DEAD (reg/v:DF 159 [ aa ])
(expr_list:REG_DEAD (reg/v:DF 158 [ a ])
(nil
(insn 9 7 13 2 (set (reg:TF 157 [  ])
(subreg:TF (reg:V2DF 160) 0)) t.c:9 447 {*movtf_64bit_dm}
 (expr_list:REG_DEAD (reg:V2DF 160)
(nil)))

vs.

(insn 16 4 7 2 (set (reg/v:TI 155 [ u ])
(const_int 0 [0])) t.c:7 -1
 (nil))
(insn 7 16 8 2 (set (subreg:DF (reg/v:TI 155 [ u ]) 0)
(reg/v:DF 157 [ a ])) t.c:7 4

[Bug target/69275] ICE compiling rs6000/float-128.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed by reverting.

[Bug c++/69277] [6 Regression] ICE mangling a flexible array member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug other/69280] Where did -fno-plt go?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
The option is new with GCC 6.

[Bug tree-optimization/69282] [6 Regression] aarch64/armhf ICE on SPEC2006 464.h264ref at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Andrew Pinski from comment #5)
> The vect generic issue is really gimple_buildN should be using
> STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.

?  vect generic doesn't use gimple_buildN but it uses the GENERIC folders
and the gimplifier.  It _should_ use gimple_build () instead...

>  Note this code should
> assuming the fold_buildN would not produce a NOP_EXPR (cast) from one type
> to another; that is it did not expect a == 0? 0 : 1 be convert into (int)a.
> 
> Note also the produced code is garbage as we go from vectorized code to non
> vectorized code.

Yeah, this shouldn't happen if the code is produced by the vectorizer
(which is supposed to create only supported code that doesn't require
lowering).

> I am still looking into a generic fix for VEC_COND_EXPR issue.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[chrbr at gcc dot gnu.org]

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

--- Comment #36 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Jan 15 08:46:49 2016
New Revision: 232403

URL: https://gcc.gnu.org/viewcvs?rev=232403&root=gcc&view=rev
Log:
gcc
2015-01-16  Christian Bruel  

PR target/65837
* config/arm/arm-builtins.c (ARM_BUILTIN_CRYPTO_BASE): New enum tag.
(arm_init_neon_builtins_internal): Rename arm_init_neon_builtins,
(arm_init_crypto_builtins_internal): Rename arm_init_crypto_builtins.
use add_builtin_function_ext_scope instead of add_builtin_function.
(neon_set_p, neon_crypto_set_p): Remove.
(arm_init_builtins): Always call arm_init_neon_builtins and
arm_init_crypto_builtins.
(arm_expand_builtin): Check that builtins are allowed for the arch.
* config/arm/arm-protos.h (arm_init_neon_builtins): Remove prototype.
* config/arm/arm.c (arm_valid_target_attribute_tree): Remove
arm_init_neon_builtins call.

gcc/testsuite
2015-01-16  Christian Bruel  

PR target/65837
* gcc.target/arm/attr-neon-builtin-fail2.c: New test.
* gcc.target/arm/lto/pr65837-attr_0.c: New test.
* gcc.target/arm/lto/pr65837_0.c: Fix skip condition and use ACLE name.


Added:
trunk/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
trunk/gcc/testsuite/gcc.target/arm/lto/pr65837-attr_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/lto/pr65837_0.c

[Bug c++/69283] Auto deduction fails when ADL is required

[gccbugs at astrant dot net]

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

--- Comment #1 from gccbugs at astrant dot net ---
I think this may be a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67835.

[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
The original testcase fails all the way back to r11 or so, don't have older
snapshots around.
The #c4 one also failed since forever, started to pass with r217465 and then
reappeared with C++ delayed folding r230365.

[Bug c++/69289] Compiling without --profile-generate causes longer execution time (-O3)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
If you disable inlining it behaves as expected.  I think you are measuring
the clearing of the vector with the .resize() call which is inlined in the
non-profile case but happens to end up using memset in the profile case.
The code of the actual copying function is the same.

Not sure how we end up "optimizing" the resize without profile-generate though.

[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
I think the problem here is that check_function_arguments_recurse just folds
using fold_for_warn the condition, if instead of folding the condition the
check_function_nonnull caller of check_function_arguments_recurse would
fold_for_warn the whole argument and only then call
check_function_arguments_recurse on it, it would rule out the NULL argument
from there.  But the disadvantage of that is that then we'd be warning on
perhaps completely newly created trees that perhaps don't match very match the
original, something the delayed folding rightly wants to avoid.
Perhaps one option would be to do the non-NULL warning in two steps, where the
first step is fold_for_warn the whole argument, recurse on it with a variant
that will not fold_for_warn recursively (not needed) and just note if there is
a need to warn instead of actually warning.  And then, if this pass returned
there is a reason to warn, call what we do now on the unfolded argument.
Of course, the question is if the warning isn't really desirable, the user
should really just choose some non-NULL magic value to pass in the impossible
cases.

[Bug tree-optimization/69292] New: ICE with -floop-nest-optimize

[vries at gcc dot gnu.org]

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

Bug ID: 69292
   Summary: ICE with -floop-nest-optimize
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37350&action=edit
test-case pr39516.c

Attached test-case pr39516.c is:
- src/gcc/testsuite/gfortran.dg/graphite/pr39516.f
- rewritten to C, and 
- replaced the int *__restrict m function argument with a file-scope
  declared m[1] (to get a valid data-ref without the fix for PR69110)

When compiling with -floop-nest-optimize:
...
$ gcc pr39516.c -O2 -floop-nest-optimize -S
...

we run into:
...
pr39516.c: In function ‘foo’:
pr39516.c:4:1: internal compiler error: Segmentation fault
 foo (double a[20][20], double b[20])
 ^~~

0xefb0cc crash_signal
src/gcc/toplev.c:334
0xf62761 ssa_default_def(function*, tree_node*)
src/gcc/tree-dfa.c:305
0xf62b08 get_or_create_ssa_default_def(function*, tree_node*)
src/gcc/tree-dfa.c:357
0xfa9a21 get_reaching_def
src/gcc/tree-into-ssa.c:1168
0xfaaf82 maybe_replace_use
src/gcc/tree-into-ssa.c:1755
0xfab5c1 rewrite_update_stmt
src/gcc/tree-into-ssa.c:1950
0xfabcf0 rewrite_update_dom_walker::before_dom_children(basic_block_def*)
src/gcc/tree-into-ssa.c:2130
0x1c3a9a0 dom_walker::walk(basic_block_def*)
src/gcc/domwalk.c:265
0xfabe35 rewrite_blocks
src/gcc/tree-into-ssa.c:2194
0xfaeb45 update_ssa(unsigned int)
src/gcc/tree-into-ssa.c:3356
0x1c75308 graphite_regenerate_ast_isl(scop*)
src/gcc/graphite-isl-ast-to-gimple.c:3319
0x1c6c572 graphite_transform_loops()
src/gcc/graphite.c:329
0x1c6c5f6 graphite_transforms
src/gcc/graphite.c:356
0x1c6c719 execute
src/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required

[amylaar at gcc dot gnu.org]

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

--- Comment #11 from Jorn Wolfgang Rennecke  ---
(In reply to Jakub Jelinek from comment #10)
 > Of course, the question is if the warning isn't really desirable, the user
> should really just choose some non-NULL magic value to pass in the
> impossible cases.

Are you saying the *_TYPE definitions in newlib-stdint.h should not use 0 in
any branches of their expressions?

[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Jorn Wolfgang Rennecke from comment #11)
> (In reply to Jakub Jelinek from comment #10)
>  > Of course, the question is if the warning isn't really desirable, the user
> > should really just choose some non-NULL magic value to pass in the
> > impossible cases.
> 
> Are you saying the *_TYPE definitions in newlib-stdint.h should not use 0 in
> any branches of their expressions?

If you pass such *_TYPE definitions to functions with nonnull argument, maybe
yes.  Find out some other invalid type, like "".

[Bug target/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Btw, the testcase seems to be really "special" given exact register overlap
between return value and incoming args (if you'd look at the vectorizers choice
to say this is profitable to vectorize).  Making it fairer like with

long double
pack (double x, double a, double aa)
{
  union u_ld u;
  u.d[0] = a;
  u.d[1] = aa;
  return u.ld;
}

produces without SLP

pack:
mfvsrd 10,2
fmr 2,3
mtvsrd 1,10
blr

and with

pack:
xxpermdi 0,3,2,0
addi 9,1,-16
xxpermdi 0,0,0,2
stxvd2x 0,0,9
lfd 1,-16(1)
lfd 2,-8(1)
blr

to that would be the thing to compare cost-wise.  Currently we have

t.c:9:11: note: Cost model analysis:
  Vector inside of basic block cost: 1
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 2

so for some reason the vector build is not accounted for.

Ah, I see why.  Mine.

[Bug tree-optimization/69292] [graphite] ICE with -floop-nest-optimize

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

Summary|ICE with|[graphite] ICE with
   |-floop-nest-optimize|-floop-nest-optimize

--- Comment #1 from vries at gcc dot gnu.org ---
The first basic block starts with the load from m:
...
;;   basic block 2, loop depth 0, count 0, freq 2, maybe hot
  # VUSE <.MEM_11(D)>
  _8 = mD.1755[0];
  if (_8 > 0)
goto ;
  else
goto ;
...

The load is labelled as S_2:
...
Converting dr: pdr_0 (read
in gimple stmt: _8 = m[0];
data accesses: [P_8] -> { S_2[] -> [1, 0] }
subscript sizes: { [1, 0] }
)
To polyhedral representation:
  - access functions: [P_8] -> { S_2[] -> [1, 0] }
  - subscripts: { [1, 0] }
...

And after the loop nest transformation, the S_2 statement is now the last:
...
AST generated by isl:
{
  for (int c1 = 0; c1 < P_8; c1 += 51)
for (int c2 = 0; c2 < P_8; c2 += 51)
  for (int c3 = c1; c3 <= min(P_8 - 1, c1 + 50); c3 += 1)
for (int c4 = c2; c4 <= min(P_8 - 1, c2 + 50); c4 += 1)
  S_4(c3, c4);
  for (int c1 = 0; c1 <= 19; c1 += 1)
for (int c2 = 0; c2 < P_8; c2 += 1) {
  S_10(c1, c2);
  for (int c4 = 0; c4 < P_8; c4 += 1)
S_11(c1, c2, c4);
}
  S_2();
}
...
while P_8 is dependent on the result (_8) of S_2.

So either:
- the transformation is invalid because is doesn't respect the dependence from
  S_2 to _P8, or
- the code generation mechanism fails to instantiate P_8 before the first use.

[Bug tree-optimization/69292] [graphite] ICE with -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 37351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37351&action=edit
pr39516.c.137t.graphite

[Bug tree-optimization/69292] [graphite] ICE with -floop-nest-optimize

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
After isl code generation, the first BB is bb 28:
...
  :
  if (1 != 0)
goto ;
  else
goto ;

  :

  :
  _48 = _8 > 0;
  if (_48 != 0)
goto ;
  else
goto ;
...

The ICE during update_ssa happens while updating stmt '_48 = _8 > 0' because it
cannot find a reaching def for _8.

[Bug tree-optimization/69110] [4.9/5/6 Regression] execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Depends on|68976   |

--- Comment #16 from vries at gcc dot gnu.org ---
Removing dependency on PR68976. After looking into it in more detail, the two
seem unrelated.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68976
[Bug 68976] [6 Regression] ICE w/ -O2 (and above) -fgraphite-identity (or
-floop-nest-optimize)

[Bug tree-optimization/69110] [4.9/5/6 Regression] execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #17 from vries at gcc dot gnu.org ---
(In reply to vries from comment #15)
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00801.html:
> ...
> > During testing however, I ran into two testsuite regressions:
> > 
> > 1.
> > 
> > -PASS: gfortran.dg/graphite/pr39516.f   -O  (test for excess errors)
> > +FAIL: gfortran.dg/graphite/pr39516.f   -O  (internal compiler error)
> > +FAIL: gfortran.dg/graphite/pr39516.f   -O  (test for excess errors)
> > 

I've managed to reproduce the pr39516.f failure in C, and modified the
test-case to trigger without the fix for this PR. Filed as PR69292.

[Bug debug/69137] [6 Regression] ICE in odr_type_p, at ipa-utils.h:257

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Created attachment 37352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37352&action=edit
patch

Patch I am testing.

[Bug c++/69289] Compiling without --profile-generate causes longer execution time (-O3)

[xonar.leroux at gmail dot com]

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

--- Comment #4 from Paul le roux  ---
I compiled gcc/g++ from svn and the slowdown is still present without the
--profile-generate flag. (But both are faster than what they were :D )

[Bug ipa/68148] Devirtualization only applies to last of multiple successive calls

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Fri Jan 15 11:00:24 2016
New Revision: 232410

URL: https://gcc.gnu.org/viewcvs?rev=232410&root=gcc&view=rev
Log:

PR ipa/68148
* ipa-icf.c (sem_function::merge): Virtual functions may become
reachable even if they address is not taken and there are no
idrect calls.
* g++.dg/ipa/devirt-49.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/ipa/devirt-49.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-icf.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/12672] Evals template defaults args that it should not

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
EDG rejects the reduced examples in comments 3 and 4 (the original testcase
doesn't compile any more for other reasons due to the preprocessed library
headers).

[Bug c++/12672] Evals template defaults args that it should not

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2009-04-16 16:42:54 |2016-1-15

--- Comment #8 from Jonathan Wakely  ---
(In reply to Wolfgang Bangerth from comment #4)
> Confirmed. Here's something even shorter:
> ---
> template  struct S {
> typedef typename T::type type;
> };
> 
> template::type>
> struct A {};
> 
> template A Foo(T);
> template void Foo(T, T);
> 
> int main() {
>   Foo(1, 2);
> }
> 
> This fails to compile because the compiler tries to instantiate
> the return type of the first Foo function. Whether that is actually
> taken is irrelevant here, since we are only doing name lookup at this
> stage, but we shouldn't error out: this is a SFINAE failure and
> should just remove the first Foo function from the list of candidates.
> It shouldn't be an error.

I disagree, the error is not in the immediate context, so SFINAE doesn't apply.

Clang does accept it though, maybe it doesn't instantiate the return type
during name lookup? Not sure.

[Bug target/69228] Default mask is not allowed for AVX512 prefetch gather/scatter insns

[afomin at gcc dot gnu.org]

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

--- Comment #4 from afomin at gcc dot gnu.org ---
Author: afomin
Date: Fri Jan 15 11:03:24 2016
New Revision: 232412

URL: https://gcc.gnu.org/viewcvs?rev=232412&root=gcc&view=rev
Log:
Backport from mainline
2016-01-13  Alexander Fomin  

gcc/

PR target/69228
* config/i386/sse.md (define_expand "avx512pf_gatherpfsf"):
Change first operand predicate from register_or_constm1_operand
to register_operand.
(define_expand "avx512pf_gatherpfdf"): Likewise.
(define_expand "avx512pf_scatterpfsf"): Likewise.
(define_expand "avx512pf_scatterpfdf"): Likewise.
(define_insn "*avx512pf_gatherpfsf"): Remove.
(define_insn "*avx512pf_gatherpfdf"): Likewise.
(define_insn "*avx512pf_scatterpfsf"): Likewise.
(define_insn "*avx512pf_scatterpfdf"): Likewise.
* config/i386/i386.c (ix86_expand_builtin): Remove first operand
comparison with constm1_rtx from vec_prefetch_gen part.

gcc/testsuite

PR target/69228
* gcc.target/i386/avx512pf-vscatterpf0dpd-1.c: Adjust.
* gcc.target/i386/avx512pf-vscatterpf0dps-1.c: Likewise.
* gcc.target/i386/avx512pf-vscatterpf0qpd-1.c: Likewise.
* gcc.target/i386/avx512pf-vscatterpf0qps-1.c: Likewise.
* gcc.target/i386/avx512pf-vscatterpf1dpd-1.c: Likewise.
* gcc.target/i386/avx512pf-vscatterpf1dps-1.c: Likewise.
* gcc.target/i386/avx512pf-vscatterpf1qpd-1.c: Likewise.
* gcc.target/i386/avx512pf-vscatterpf1qps-1.c: Likewise.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/config/i386/sse.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf0dpd-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf0dps-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf0qpd-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf0qps-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf1dpd-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf1dps-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf1qpd-1.c
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/avx512pf-vscatterpf1qps-1.c

[Bug ipa/68148] Devirtualization only applies to last of multiple successive calls

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug c++/12672] Evals template defaults args that it should not

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
This seems to be:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1635

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2008 might be
related, and seems to agree with GCC.

[Bug lto/69271] LTO drops weak binding from aliases

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
mine.  I wonder why WEAK makes difference here at all when all symbols are
interposable with PIC.

[Bug c++/12672] Evals template defaults args that it should not

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Ivan Godard from comment #0)
> The problem seems to be that the compiler is not first pruning all
> candidates with the wrong number of formals before doing type matching.

Which is correct. The first thing it has to do is find the set of all the
candidate functions, *then* it determines the subset which are viable functions
("those that have the proper number of arguments and meet certain other
conditions").

13.3.1 says:

  In each case where a candidate is a function template, candidate function
  template specializations are generated using template argument deduction
  (14.8.3, 14.8.2). Those candidates are then handled as candidate functions
  in the usual way.124

Footnote 124 says:

  124) The process of argument deduction fully determines the parameter types
  of the function template specializations, i.e., the parameters of function
  template specializations contain no template parameter types. Therefore,
  except where specified otherwise, function template specializations and
  non-template functions (8.3.5) are treated equivalently for the remainder
  of overload resolution.

So to find the candidate functions template argument deduction is done on each
Foo, and that deduction results in an error outside the immediate context,
where SFINAE doesn't apply.

[Bug target/63890] [4.9/5/6 regression] Compiling trivial program with -O -p leads to misaligned stack

[dominiq at lps dot ens.fr]

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

--- Comment #27 from Dominique d'Humieres  ---
> Certainly adding TARGET_MACHO is Ok by me.

I don't think this is the problem. I have reapplied the patch in comment 12 for
config/i386/darwin.h and

--- ../_clean/gcc/config/i386/i386.c2016-01-13 19:03:17.0 +0100
+++ gcc/config/i386/i386.c  2016-01-14 20:04:06.0 +0100
@@ -10168,6 +10168,14 @@ ix86_va_start (tree valist, rtx nextarg)
  pop_topmost_sequence ();
}
 }
+  /* Be sure we get stack aligned for mcount call.  */
+  /* else if (TARGET_MACHO && crtl->profile && flag_fentry) */
+  else if (TARGET_MACHO && crtl->profile)
+{
+  crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
+  if (crtl->stack_alignment_needed < PREFERRED_STACK_BOUNDARY)
+   crtl->stack_alignment_needed = PREFERRED_STACK_BOUNDARY;
+}

   /* Only 64bit target needs something special.  */
   if (is_va_list_char_pointer (TREE_TYPE (valist)))

and confirm the results reported in comment 20: three tests fixed and seven new
failures.

[Bug lto/69271] LTO drops weak binding from aliases

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
The optimization was intentional - dropping the weak bit makes GCC to optimize
the references to symbol better (knowing it won't be NULL because the
definition
is provided). I wonder how this break glibc. What is the difference between
weak
and non-weak symbols in dynamic linking?

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 15 11:49:43 2016
New Revision: 232415

URL: https://gcc.gnu.org/viewcvs?rev=232415&root=gcc&view=rev
Log:
2016-01-15  Richard Biener  

PR tree-optimization/68961
* tree-vect-slp.c (vect_analyze_slp_cost_1): Consider cost
of invariants in stores again.

* gcc.dg/vect/costmodel/x86_64/costmodel-pr68961.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-pr68961.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/69170] [6 Regression] ICE (segfault) in find_uses_to_rename_use

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Fails in GIMPLE verification because

vect_cst__127 = {_172, _162};

references the released SSA name _172 after BB vectorization.

Not a dup of PR66856.

It looks like we end up building a SLP node from scalars that are pattern
stmts.  Oops.

[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Should be fixed now.

[Bug tree-optimization/66797] [6 Regression] FAIL: gcc.dg/tree-ssa/pr65447.c scan-tree-dump-not ivopts "\\nuse 5\\n"

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
Seems HPPA only supports small int in addressing mode "REG+OFFSET" of floating
mode load/store.  In effect, we can only group every two address iv uses,
resulting in 20 iv uses.  Even with this restriction, code generated with
iv_use groups is better than before.
I am going to refine the test by further relaxing nuse.

[Bug c++/68586] [6 Regression] Enum template parameter wrongly rejected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
This passes with trunk with -std=c++03, because the difference comes from
maybe_constant_value in convert_nontype_argument:

 6260   /* In C++11, integral or enumeration non-type template arguments can be
 6261  arbitrary constant expressions.  Pointer and pointer to
 6262  member arguments can be general constant expressions that evaluate
 6263  to a null value, but otherwise still need to be of a specific form. 
*/
 6264   if (cxx_dialect >= cxx11)
 6265 {
 6266   if (TREE_CODE (expr) == PTRMEM_CST)
 6267 /* A PTRMEM_CST is already constant, and a valid template
 6268argument for a parameter of pointer to member type, we just
want
 6269to leave it in that form rather than lower it to a
 6270CONSTRUCTOR.  */;
 6271   else if (INTEGRAL_OR_ENUMERATION_TYPE_P (type))
 6272 expr = maybe_constant_value (expr);

gcc-5 compiles this testcase fine even with -std=c++11 though.  It looks as if
the difference is that for const_decl 'x' gcc-6's maybe_constant_value returns
"1" (integer_cst) while gcc-5's maybe_constant_value returns "1" (enumeral_type
E).

[Bug lto/69271] LTO drops weak binding from aliases

[nsz at gcc dot gnu.org]

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

--- Comment #5 from nsz at gcc dot gnu.org ---
copy pasting from
http://www.openwall.com/lists/musl/2016/01/13/2
(this is musl libc, but glibc has the same issue)

lto breaks symbol binding for environ, _environ, ___environ.
(they should be weak, without that environ in a main binary
has different address than in libc.so)

libc.so built with -flto:
$ readelf --dyn-syms -W libc.so |grep envi
22: 0028eb90 8 OBJECT  GLOBAL DEFAULT   15 __environ
   398: 0028eb90 8 OBJECT  GLOBAL PROTECTED   15 ___environ
  1034: 0028eb90 8 OBJECT  GLOBAL PROTECTED   15 _environ
  1107: 0028eb90 8 OBJECT  GLOBAL DEFAULT   15 environ

libc.so without -flto:
$ readelf --dyn-syms -W libc.so |grep envi
22: 0028d2d8 8 OBJECT  GLOBAL DEFAULT   15 __environ
   398: 0028d2d8 8 OBJECT  WEAK   PROTECTED   15 ___environ
  1034: 0028d2d8 8 OBJECT  WEAK   PROTECTED   15 _environ
  1107: 0028d2d8 8 OBJECT  WEAK   DEFAULT   15 environ

[Bug testsuite/56194] FAIL: g++.dg/init/const9.C -std=c++98 scan-assembler-not rodata

[krebbel at gcc dot gnu.org]

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

--- Comment #8 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Jan 15 12:53:00 2016
New Revision: 232422

URL: https://gcc.gnu.org/viewcvs?rev=232422&root=gcc&view=rev
Log:
S/390: const9.C: Disable test.

gcc/testsuite/ChangeLog

PR c++/56194
* g++.dg/init/const9.C: Disable test on S/390.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/init/const9.C

[Bug c++/68586] [6 Regression] Enum template parameter wrongly rejected

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
GCC6 uses a cache for evaluated constant expressions:

4019 tree
4020 maybe_constant_value (tree t, tree decl)
4021 {
4022   tree ret = cv_cache.get (t);

The CONST_DECL x is in the cache, associated with 1 of INTEGER_TYPE.  It got
there when we were processing the LSHIFT_EXPR (x << 1) of the enum in
cp_build_binary_op.  At that point, x had INTEGER_TYPE (I guess because enum E
wasn't complete yet).

Later on, when we're in convert_nontype_argument, this function gets CONST_DECL
x already of the enum E type, but we pull out 1 of INTEGER_TYPE from the cache,
and I think this discrepancy might be the problem here.

[Bug libstdc++/69293] New: scoped_allocator_adaptor::construct calls wrong function

[forever14 at bk dot ru]

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

Bug ID: 69293
   Summary: scoped_allocator_adaptor::construct calls wrong
function
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: forever14 at bk dot ru
  Target Milestone: ---

There is a bug in scoped_allocator_adaptor::construct. Consider following code:

#include 
#include 
#include 

struct use_arg {
template
use_arg(int i, Alloc&)
{ std::cout << i << " in use_arg()\n"; }
};

namespace std {

template  struct uses_allocator: true_type {};

} // namespace std

void test_scoped()
{
std::scoped_allocator_adaptor> sa;
auto p = sa.allocate(1);
sa.construct(p, 4);
sa.destroy(p);
sa.deallocate(p, 1);
}

int main() 
{
   test_scoped();
}

There will not be compilation error, but should be, since:

template 
void construct(T* p, Args&&... args);
9
(9.1)
Effects:
...
(9.3) — Otherwise, if uses_allocator::value is true
and is_construct-
ible::value is true, calls OUTERMOST_ALLOC_-
TRAITS(*this):: construct(OUTERMOST (*this), p, std::forward(args)...,
inner_allocator()).
(9.4) — Otherwise, the program is ill-formed. [ Note: An error will result if
uses_allocator evaluates
to true but the specific constructor does not take an allocator. This
definition prevents a silent
failure to pass an inner allocator to a contained element. — end note ]

In code, is_constructible::value is false,
since use_arg receives Alloc by reference, but there is no test for this case
in libstdc++.

[Bug c/69291] [6 Regression] wrong code at -O1 for ruby-2.3.0/regcomp.c:985:compile_length_quantifier_node()

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from Markus Trippelsdorf  ---
It turned out that this issue is unrelated to the unaligned word accesses.
But fortunately it is already fix on today's trunk.

[Bug libstdc++/69294] New: [6 Regression] std::isinf and std::isnan declaration conflict

[dje at gcc dot gnu.org]

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

Bug ID: 69294
   Summary: [6 Regression] std::isinf and std::isnan declaration
conflict
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

FAIL: 26_numerics/headers/cmath/48891.cc (test for excess errors)
Excess errors:
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/26_numerics/headers/cmath/48891
.cc:26:12: error: 'constexpr bool std::isinf(double)' conflicts with a previous 
declaration
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/26_numerics/headers/cmath/48891
.cc:27:12: error: 'constexpr bool std::isnan(double)' conflicts with a previous 
declaration

[Bug libstdc++/69294] [6 Regression] std::isinf and std::isnan declaration conflict

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
confirmed.

[Bug libstdc++/69295] New: [6 Regression] New special math function failures

[dje at gcc dot gnu.org]

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

Bug ID: 69295
   Summary: [6 Regression] New special math function failures
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

FAIL: special_functions/02_assoc_legendre/check_value.cc execution test
FAIL: ext/special_functions/hyperg/check_value.cc execution test

[Bug libstdc++/69295] [6 Regression] New special math function failures

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target||powerpc-ibm-aix*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-15
 CC||redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug libstdc++/69294] [6 Regression] std::isinf and std::isnan declaration conflict

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Jonathan Wakely  ---
The underlying bug has always been present on AIX, but until I added this new
test it wasn't noticed.

[Bug tree-optimization/68976] [6 Regression] ICE w/ -O2 (and above) -fgraphite-identity (or -floop-nest-optimize)

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01067.html

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
More reduced testcase:
typedef struct
{
  char bits;
  short val;
} code;

union uu
{
  short us;
  char b[2];
};

int a, b, c, f, g, h;
code *d;

code e;

int
fn1 ()
{
  char i;
  do
if (e.bits)
  {
  dodist:
f = c;
if (e.bits & 6)
  {
++i;
if (g)
  do
{
  union uu j;
  j.b[1] = a;
  h = j.us;
}
  while (fn1);
  }
else
  {
e = d[b];
goto dodist;
  }
  }
  while (i);
}

[Bug libstdc++/69295] [6 Regression] New special math function failures

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||emsr at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
I also see this on ppc64-linux, but not ppc64le-linux.

Ed, do you know why these tests would fail on big-endian POWER targets?

[Bug fortran/69296] New: Problem with associate and vector subscript

[mrestelli at gmail dot com]

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

Bug ID: 69296
   Summary: Problem with associate and vector subscript
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

The attached code, when compiled with gfortran, prints

shape: 2

and then crashes printing "ai". The same code compiled with ifort
shows what I thing is the correct behaviour, namely

$ ./test
 shape:2   3
 ai =1 -10   3 -30   5 -50

Notice that gfortran considers "ai" to have rank 1, while ifort
correctly detects the rank 2.


program p
 implicit none

 integer :: j, a(2,6), i(3,2)

  a(1,:) = (/ ( j , j=1,6) /)
  a(2,:) = (/ ( -10*j , j=1,6) /)

  i(:,1) = (/ 1 , 3 , 5 /)
  i(:,2) = (/ 4 , 5 , 6 /)

  associate( ai => a(:,i(:,1)) )
  write(*,*) "shape: ", shape(ai)
  write(*,*) "ai = ", ai
  end associate

end program p

[Bug fortran/69296] Problem with associate and vector subscript

[mrestelli at gmail dot com]

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

--- Comment #1 from mrestelli  ---
I should also mention that this happens for me with

GNU Fortran (GCC) 6.0.0 20160112 (experimental)

[Bug jit/68446] [6 Regression] jit testsuite failures seen inside dwarf2out.c:gen_producer_string

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Hi David.

Removal of lazy initialization:
diff --git a/gcc/opts.c b/gcc/opts.c
index 2add158..cc96150 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -273,7 +273,7 @@ init_opts_obstack (void)
 {
   static bool opts_obstack_initialized = false;

-  if (!opts_obstack_initialized)
+//  if (!opts_obstack_initialized)
 {
   opts_obstack_initialized = true;
   gcc_obstack_init (&opts_obstack);

Introduces back the memory leak that was removed in r230264:
$ valgrind --leak-check=yes --trace-children=yes ./xgcc -B. -c
/home/marxin/Programming/gcc3/gcc/testsuite/g++.dg/ext/mv1.C -O2 -fPIC

==24974== 1,245,184 bytes in 19 blocks are definitely lost in loss record 922
of 924
==24974==at 0x4C2A00F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24974==by 0x1B32A77: xmalloc (xmalloc.c:148)
==24974==by 0xAE53CA: memory_block_pool::allocate() (memory-block.h:56)
==24974==by 0x1AE7465: mempool_obstack_chunk_alloc(unsigned long)
(memory-block.cc:49)
==24974==by 0x1B31B37: _obstack_begin_worker (obstack.c:141)
==24974==by 0x1AC7341: init_opts_obstack() (opts.c:279)
==24974==by 0x1AC7362: init_options_struct(gcc_options*, gcc_options*)
(opts.c:290)
==24974==by 0x145F196: ix86_valid_target_attribute_p(tree_node*,
tree_node*, tree_node*, int) (i386.c:6253)
==24974==by 0xACAD03: handle_target_attribute(tree_node**, tree_node*,
tree_node*, int, bool*) (c-common.c:9421)
==24974==by 0xA8D645: decl_attributes(tree_node**, tree_node*, int)
(attribs.c:548)
==24974==by 0x8D6CDE: cplus_decl_attributes(tree_node**, tree_node*, int)
(decl2.c:1490)
==24974==by 0x7EB0CB: grokfndecl(tree_node*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, int, overload_flags, int, cp_ref_qualifier,
tree_node*, int, int, int, int, bool, special_function_kind, bool, int,
tree_node*, tree_node**, unsigned int) (decl.c:8152)


Using trunk with the patch you suggest, I see invalid write operation by
valgrind (same command line):

==27543== Invalid write of size 8
==27543==at 0x4C2C7DF: memset (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27543==by 0xAE54D6: memory_block_pool::release(void*) (memory-block.h:70)
==27543==by 0xAE5696: base_pool_allocator::release()
(alloc-pool.h:302)
==27543==by 0xC97CAE:
base_pool_allocator::release_if_empty() (alloc-pool.h:325)
==27543==by 0xC97C61: object_allocator::release_if_empty()
(alloc-pool.h:477)
==27543==by 0xC97404: et_free_pools (et-forest.c:509)
==27543==by 0xC191D1: free_dominance_info(function*, cdi_direction)
(dominance.c:686)
==27543==by 0xC19223: free_dominance_info(cdi_direction) (dominance.c:696)
==27543==by 0xF935CB: execute_pass_list(function*, opt_pass*)
(passes.c:2424)
==27543==by 0xBC7FAB: cgraph_node::analyze() (cgraphunit.c:636)
==27543==by 0xBC9716: analyze_functions(bool) (cgraphunit.c:1080)
==27543==by 0xBCDCD8: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2531)
==27543==  Address 0x72f15d0 is 16 bytes inside a block of size 65,536 alloc'd
==27543==at 0x4C2A00F: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27543==by 0x1B32AA7: xmalloc (xmalloc.c:148)
==27543==by 0xAE53CA: memory_block_pool::allocate() (memory-block.h:56)
==27543==by 0xAE576A: base_pool_allocator::allocate()
(alloc-pool.h:365)
==27543==by 0xC97BC5: object_allocator::allocate()
(alloc-pool.h:486)
==27543==by 0xC97259: et_new_occ(et_node*) (et-forest.c:445)
==27543==by 0xC97315: et_new_tree (et-forest.c:472)
==27543==by 0xC18FEF: calculate_dominance_info(cdi_direction)
(dominance.c:647)
==27543==by 0x1109047: cleanup_tree_cfg_noloop() (tree-cfgcleanup.c:753)
==27543==by 0x110915B: cleanup_tree_cfg() (tree-cfgcleanup.c:812)
==27543==by 0x10EB907: execute_build_cfg() (tree-cfg.c:360)
==27543==by 0x10EB966: (anonymous
namespace)::pass_build_cfg::execute(function*) (tree-cfg.c:389)

Martin

[Bug libstdc++/69293] scoped_allocator_adaptor::construct calls wrong function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/68976] [6 Regression] ICE w/ -O2 (and above) -fgraphite-identity (or -floop-nest-optimize)

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 37353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37353&action=edit
pdfs.tgz

For the record:

1-pre.pdf
Before scop detection

2-scops.pdf
After scop detection

3-cond.pdf
After moving region into condition

4-ice.pdf
At ICE.

[Bug tree-optimization/68976] [6 Regression] ICE w/ -O2 (and above) -fgraphite-identity (or -floop-nest-optimize)

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
Created attachment 37354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37354&action=edit
test.c.137t.graphite

[Bug tree-optimization/69297] New: [6 Regression] Performance regression after r230020

[ysrumyan at gmail dot com]

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

Bug ID: 69297
   Summary: [6 Regression] Performance regression after r230020
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

This regression was found on spec2006/464.h264ref. The problem is related to
SLP vectorization of BB's and caused by the wrong calculation of scalar cost,
e.g. for attached test-case:
  Cost model analysis: 
  Vector inside of basic block cost: 188
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 512

although the basic block contains only 96 statements.
I found out that vect_bb_slp_scalar_cost takes into account the same stmt
several times and results in non-profitable SLP vectorization.

[Bug fortran/69298] New: Array finalisers seem to be given the wrong array when the array is a member variable.

[matthew.hambley at metoffice dot gov.uk]

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

Bug ID: 69298
   Summary: Array finalisers seem to be given the wrong array when
the array is a member variable.
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.hambley at metoffice dot gov.uk
  Target Milestone: ---

Created attachment 37355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37355&action=edit
Minimal test case which exhibits problem

The attached example program exhibits the problem.

The basic situation is a type (stuff_type) and an array of that type which are
initialised, some make-work is done and then they go out of scope so are
finalised.

When this is done within a procedure within the program all works as expected.

When this is done within another type (test_type) the array finaliser does not
behave as expected. The array passed to it (which should contain 3 stuff_type
objects containing 1, 2 and 3) appears to contain objects only containing 1.

Compiling this example throws a lot of warnings about a missing scalar
finaliser which is clearly not true. This is a known problem, see 58175.

This example behaves as expected when built using Intel Fortran.

[Bug target/69299] New: [6 Regression] -mavx performance degradation with r232088

[jakub at gcc dot gnu.org]

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

Bug ID: 69299
   Summary: [6 Regression] -mavx performance degradation with
r232088
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: hjl.tools at gmail dot com, uros at gcc dot gnu.org,
vmakarov at gcc dot gnu.org
  Target Milestone: ---

Reduced testcase:

-Ofast -mavx -mno-avx2 -mtune=bdver2

float *a, *b;
int c, d, e, f;
void
foo (void)
{
  for (; c; c++)
a[c] = 0;
  if (!d)
for (; c < f; c++)
  b[c] = (double) e / b[c];
}

There are various differences of the kind:
-   vcvtps2pd   16(%rsp), %xmm3
+   vmovaps 16(%rsp), %xmm7
+   vcvtps2pd   %xmm7, %xmm3

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-15
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug tree-optimization/69297] [6 Regression] Performance regression after r230020

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 37356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37356&action=edit
test-case to reproduce

TO reproduce compile with -Ofast -march=core-avx2 options.

[Bug lto/68799] lto ICE on powerpc64le-linux-gnu builing python 2.7.x

[doko at gcc dot gnu.org]

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

--- Comment #13 from Matthias Klose  ---
yes, this works, and I don't see any regressions in the testsuite compared to
non pgo/lto build.

[Bug lto/69271] LTO drops weak binding from aliases

[nsz at gcc dot gnu.org]

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

--- Comment #6 from nsz at gcc dot gnu.org ---
to complete the example here is a test application:

#include 
#include 
extern char **environ;
int main()
{
printf("&environ: %p, environ: %p, *environ: %p\n", &environ, environ,
*environ);
clearenv(); // *environ = 0
putenv("TEST=1"); // should change environ
printf("&environ: %p, environ: %p, *environ: %p\n", &environ, environ,
*environ);
}

with correct libc.so:

$ gcc a.c
$ ./a.out 
&environ: 0x6008b0, environ: 0x7fffb9b0b478, *environ: 0x7fffb9b0d651
&environ: 0x6008b0, environ: 0x600020, *environ: 0x400649
$ readelf --dyn-sym -W ./a.out |grep envi
 2: 006008b0 8 OBJECT  WEAK   DEFAULT   19 _environ
 5: 006008b0 8 OBJECT  GLOBAL DEFAULT   19 __environ
 7: 006008b0 8 OBJECT  WEAK   DEFAULT   19 environ
 8: 006008b0 8 OBJECT  WEAK   DEFAULT   19 ___environ

if libc.so is compiled with -flto:

$ gcc a.c
$ ./a.out 
&environ: 0x600850, environ: 0x7fff52af6158, *environ: 0x7fff52af6651
&environ: 0x600850, environ: 0x7fff52af6158, *environ: 0
$ readelf --dyn-sym -W ./a.out |grep envi
 5: 00600850 8 OBJECT  GLOBAL DEFAULT   19 environ

so environ is shared between a.out and libc.so
in the beginning (clearenv worked), but the
address of the symbol (&environ) is different
so changing it in the libc did not have an effect
in the main module (putenv failed).

this might be an issue in the static or dynamic
linker but the difference is observable.

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from chrbr at gcc dot gnu.org ---
Created attachment 37357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37357&action=edit
new arm_set_current_function implementation

A complete refactoring of arm_set_current_function. Much simpler. 

Also fixes pr68896 due to discrepancies between #pragma GCC target and
set_current_function global_options cl_target_option_restore restores.

Still want to play a little bit with it before sending it to the list.

[Bug libstdc++/69293] scoped_allocator_adaptor::construct calls wrong function

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Actually I think this is a defect in the standard, it is inconsistent to check
is_constructible but then pass inner_allocator_type&.

Consider this type:

struct use_arg {
  using allocator_type = std::allocator;
  use_arg(allocator_type&&) { }
};

The uses_allocator and is_constructible traits are both true, but
scoped_allocator_adaptor::construct(pointer) will fail to compile.

[Bug rtl-optimization/69246] [6 Regression] ICE in distribute_notes, at combine.c:13693 on i686-linux-gnu

[rsandifo at gcc dot gnu.org]

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

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Jan 15 14:41:10 2016
New Revision: 232428

URL: https://gcc.gnu.org/viewcvs?rev=232428&root=gcc&view=rev
Log:
PR 69246: Invalid REG_ARGS_SIZE for sibcalls

The problem in this PR was that we were treating a sibcall as popping
arguments, leading to a negative REG_ARGS_SIZE.

It doesn't really make sense to treat sibcalls as popping since
(a) they're deallocating the caller's stack, not ours, and
(b) there are no optabs for popping sibcalls (any more).

Tested on x86_64-linux-gnu.

gcc/
PR middle-end/69246
* calls.c (emit_call_1): Force n_popped to zero for sibcalls.

gcc/testsuite/
PR middle-end/69246
* gcc.target/i386/pr69246.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69246.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69246] [6 Regression] ICE in distribute_notes, at combine.c:13693 on i686-linux-gnu

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug tree-optimization/68976] [6 Regression] ICE w/ -O2 (and above) -fgraphite-identity (or -floop-nest-optimize)

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to vries from comment #9)
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01067.html

Hmm. The patch does not address the dup PR68692, and introduces a new ICE for
that test-case.

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Depends on||68991

--- Comment #1 from H.J. Lu  ---
With

diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index bac9d66..1a7d386 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -161,7 +161,7 @@
   "@internal GOT memory operand."
   (match_operand 0 "GOT_memory_operand"))

-(define_constraint "Bm"
+(define_memory_constraint "Bm"
   "@internal Vector memory operand."
   (match_operand 0 "vector_memory_operand"))

I got

-   vmovaps 16(%rsp), %xmm7
-   vcvtps2pd   %xmm7, %xmm3
+   vcvtps2pd   16(%rsp), %xmm3

But we can't use define_memory_constraint:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00125.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
[Bug 68991] -O3 generates misaligned xorv4si3

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
The related LRA code is

   case CT_MEMORY:
  if (MEM_P (op)
  && satisfies_memory_constraint_p (op, cn))
win = true;
  else if (spilled_pseudo_p (op))
win = true;

  /* If we didn't already win, we can reload constants
 via force_const_mem or put the pseudo value into
 memory, or make other memory by reloading the
 address like for 'o'.  */
  if (CONST_POOL_OK_P (mode, op)
  || MEM_P (op) || REG_P (op))
badop = false;

 /* If this operand accepts a register, and if the
 register class has at least one allocatable register,
 then this operand can be reloaded.  */
  if (winreg && !no_regs_p)
badop = false;

[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes

[Predelnik at gmail dot com]

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

Sergey Semushin  changed:

   What|Removed |Added

 CC||Predelnik at gmail dot com

--- Comment #8 from Sergey Semushin  ---
Encountered this warning and it makes me wonder why there is no warning for
naming variable inside some namespace with the same name as a class in outer
namespace, like:
struct C {};

namespace D
{
int C;
}

This case is very similar to enum class one and I believe it's a lot easier to
somehow be confused here due to shadowing however no warning with Wshadow is
issued this case. Personally I would prefer to not receive warning in both
cases.

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Maybe we really need to have two types of memory
constraints, ones which can be worst case always satisfied by reloading
their address into an address register and another ones which can be worst
case always satisfied by loading the memory into a temporary register (for
loads) or storing it from a temporary register.

Or consider the constraint as CT_MEMORY only if the operand satisfies the
constraint predicate and as CT_FIXED_FORM (or whatever is the default)
otherwise?  Only normal CT_MEMORY, for Bm as long as it satisfies
memory_operand, the exact address form doesn't really matters, but what matters
is something inherent in the memory (and ISA flags).

[Bug sanitizer/67515] crash from ubsan for non-virtual call in initializer list with an invalid vtable

[yury.zaytsev at traveltainment dot de]

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

Yury V. Zaytsev  changed:

   What|Removed |Added

 CC||yury.zaytsev@traveltainment
   ||.de

--- Comment #9 from Yury V. Zaytsev  ---
Hi Roger, I'm bitten by the same problem. Did you report the issue against
boost::format? Is there a workaround that I could make use of? Thanks!

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #13 from James Greenhalgh  ---
This is a similar case I reduced from the Ubuntu rebuild failures, hitting the
"max" idiom recognition:

---

#pragma GCC push_options
#pragma GCC target("fpu=crypto-neon-fp-armv8")
static void
foo (void)
{
}
#pragma GCC pop_options
float
max_idiom (float x, float y)
{
  return x > y ? x : y;
}

---

Compile with -march=armv7-a -mfloat-abi=hard -mfpu=neon -O2 -ffast-math

Presumably the same root cause.

bug.c:12:1: error: unrecognizable insn:
 }
 ^

(insn 7 4 8 2 (set (reg:SF 113)
(smax:SF (reg/v:SF 112 [ y ])
(reg/v:SF 111 [ x ]))) bug2.c:11 -1
 (nil))

bug.c:12:1: internal compiler error: in extract_insn, at recog.c:2286
0xa411e9 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.../gcc/rtl-error.c:108
0xa41208 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.../gcc/rtl-error.c:116
0xa1404d extract_insn(rtx_insn*)
.../gcc/recog.c:2286
0x82b664 instantiate_virtual_regs_in_insn
.../gcc/function.c:1582
0x82b664 instantiate_virtual_regs
.../gcc/function.c:1950
0x82b664 execute
.../gcc/function.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/69293] scoped_allocator_adaptor::construct calls wrong function

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to ForEveR from comment #0)
> In code, is_constructible::value is false,
> since use_arg receives Alloc by reference, but there is no test for this
> case in libstdc++.

There doesn't need to be a check for that case, because if the
is_constructible case is false then we will
try to construct as T(Args..., Alloc), and so if that is not constructible 
then we get an error, i.e. it's ill-formed. We don't need to test
is_constructible, we can just attempt the cosntruction.

The bug is in the standard: it says that the actual construction is done as
T(Args..., Alloc&) which is not the same as the is_constructible test, so it's
possible for the is_constructible test to fail but for the actual construction
to succeed. That should not be possible.

I can add a static assertion to the __uses_alloc partial
specialization, as that will improve the diagnostics anyway, and cause this
example to be ill-formed.

[Bug debug/69137] [6 Regression] ICE in odr_type_p, at ipa-utils.h:257

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 15 15:37:38 2016
New Revision: 232434

URL: https://gcc.gnu.org/viewcvs?rev=232434&root=gcc&view=rev
Log:
2016-01-15  Richard Biener  

PR debug/69137
* dwarf2out.c (add_linkage_name_raw): New function split out from ...
(add_linkage_name): ... here.
(gen_typedef_die): Use add_linkage_name_raw instead of
add_linkage_attr to delay DECL_ASSEMBLER_NAME computation
if necessary.

* g++.dg/lto/pr69137_0.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr69137_0.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
Created attachment 37358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37358&action=edit
gcc6-pr68271.patch

Untested fix.

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||rguenth at gcc dot gnu.org

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 15 15:43:48 2016
New Revision: 232435

URL: https://gcc.gnu.org/viewcvs?rev=232435&root=gcc&view=rev
Log:
2016-01-15  Richard Biener  

PR tree-optimization/66856
* tree-vect-loop.c (vect_transform_loop): Free SLP instances here.
* tree-vect-slp.c (vect_free_slp_tree): Decrement stmt reference count.
(vect_create_new_slp_node): Increment stmt reference count.
(vect_get_and_check_slp_defs): Make sure stmts are nor already in
an SLP tree before swapping operands.
(vect_build_slp_tree): Likewise.
(destroy_bb_vec_info): Free stmt info after SLP instances.
* tree-vect-stmts.c (new_stmt_vec_info): Initialize reference count.
* tree-vectorizer.h (struct _stmt_vec_info): Add num_slp_uses field.
(STMT_VINFO_NUM_SLP_USES): New macro.

* gcc.dg/torture/pr66856-1.c: New testcase.
* gcc.dg/torture/pr66856-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66856-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr66856-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug debug/69137] [6 Regression] ICE in odr_type_p, at ipa-utils.h:257

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Should be fixed.

[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Should be fixed now.

[Bug c++/69257] g++ ICE in "create_tmp_var" on invalid inline-asm

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Jan 15 15:57:07 2016
New Revision: 232436

URL: https://gcc.gnu.org/viewcvs?rev=232436&root=gcc&view=rev
Log:
PR c++/69257
* typeck.c (decay_conversion): Don't call mark_rvalue_use for
array/function-to-pointer conversion.  Call
complete_type_or_maybe_complain for lvalue-to-rvalue conversion.
* call.c (convert_like_real): Print call context if
decay_conversion errors.

Added:
trunk/gcc/testsuite/g++.dg/ext/asm13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/typeck.c

[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Fri Jan 15 15:57:17 2016
New Revision: 232438

URL: https://gcc.gnu.org/viewcvs?rev=232438&root=gcc&view=rev
Log:
PR c++/68847
* call.c (build_cxx_call): Use fold_non_dependent_expr.

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

[Bug tree-optimization/66797] [6 Regression] FAIL: gcc.dg/tree-ssa/pr65447.c scan-tree-dump-not ivopts "\\nuse 5\\n"

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
HPPA 1.0 and 1.1 only support a 5 bit offset in REG+D addressing modes for
floating point loads/stores.  So, yes, it's quite limited.

For HPPA 2.0 and beyond a 14 bit offset is supported.

[Bug target/68609] PowerPC reciprocal estimate missed opportunities

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
Author: dje
Date: Fri Jan 15 16:38:08 2016
New Revision: 232439

URL: https://gcc.gnu.org/viewcvs?rev=232439&root=gcc&view=rev
Log:
PR target/68609
* config/rs6000/rs6000.c (rs6000_emit_msub): Delete.
(rs6000_emit_swsqrt): Convert to Goldschmidt's Algorithm
* config/rs6000/rs6000.md (sqrt2): Limit swsqrt to high
precision estimate.

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

[Bug c++/69091] [6 Regrssion] valid code with operator| causes ICE "tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:12851"

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/68385] [6 Regression] ICE building libstdc++ on arm-none-eabi

[andre.simoesdiasvieira at arm dot com]

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

--- Comment #8 from Andre Vieira  ---
It did fix it for me, sorry for the late reply.

[Bug target/69252] [4.9/5/6 Regression] gcc.dg/vect/vect-iv-9.c FAILs with -Os -fmodulo-sched -fmodulo-sched-allow-regmoves -fsched-pressure

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #5)
> a) bootstrap/regtest it

The patch passes all C, C++, and FORTRAN tests with no regressions WRT
baxeline.
I'll look at (b) next.

[Bug rtl-optimization/68955] [6 Regression] wrong code at -O3 on x86-64-linux-gnu in 32-bit mode

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
So, we have before DSE2:
...
(insn 525 192 458 12 (set (reg:SI 1 dx [orig:247 ivtmp.44 ] [247])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -76 [0xffb4])) [4 %sfp+-52 S4 A32]))
pr68955.c:27 86 {*movsi_internal}
 (nil))
(insn 458 525 524 12 (set (reg:SI 0 ax [orig:247 ivtmp.44 ] [247])
(reg:SI 1 dx [orig:247 ivtmp.44 ] [247])) pr68955.c:27 86
{*movsi_internal}
 (nil))
(insn 524 458 194 12 (set (reg:SI 4 si [orig:124 _95 ] [124])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -80 [0xffb0])) [4 %sfp+-56 S4 A32]))
pr68955.c:27 86 {*movsi_internal}
 (nil))
(insn 194 524 523 12 (set (mem:SI (reg:SI 0 ax [orig:247 ivtmp.44 ] [247]) [2
MEM[base: _165, offset: 0B]+0 S4 A32])
(reg:SI 4 si [orig:124 _95 ] [124])) pr68955.c:27 86 {*movsi_internal}
 (nil))
(note 523 194 567 12 NOTE_INSN_DELETED)
(insn 567 523 460 12 (set (reg:SI 2 cx [orig:125 pretmp_96 ] [125])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -84 [0xffac])) [4 %sfp+-60 S4 A32]))
pr68955.c:28 86 {*movsi_internal}
 (nil))
(insn 460 567 196 12 (set (reg:SI 0 ax [orig:125 pretmp_96 ] [125])
(reg:SI 2 cx [orig:125 pretmp_96 ] [125])) pr68955.c:28 86
{*movsi_internal}
 (nil))
(insn 196 460 598 12 (set (mem/c:SI (const:SI (plus:SI (symbol_ref:SI ("i")
[flags 0x2]  )
(const_int 308 [0x134]))) [2 i+308 S4 A32])
(reg:SI 0 ax [orig:125 pretmp_96 ] [125])) pr68955.c:28 86
{*movsi_internal}
 (nil))
(insn 598 196 197 12 (set (reg:SI 0 ax [orig:209 ivtmp.42 ] [209])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -28 [0xffe4])) [4 %sfp+-4 S4 A32]))
pr68955.c:26 86 {*movsi_internal}
 (nil))
(insn 197 598 198 12 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 5 di [orig:122 _93 ] [122])
(mem:SI (plus:SI (reg:SI 0 ax [orig:209 ivtmp.42 ] [209])
(const_int 20 [0x14])) [2 MEM[base: _327, offset: 20B]+0 S4
A32]))) pr68955.c:26 7 {*cmpsi_1}
 (nil))
...
and the bug IMHO is that the read in 197 can alias the store in insn 194 (well,
in the testcase for e == 0, h == 2 it actually is some later read, insn 194 is
from unrolled k == 0, 197 from k == 1, while the actual problem on the testcase
occurs on k <= 4 store vs. k == 5 first read, but the alias oracle really
doesn't know this), but during
check_mem_read_rtx we call canon_true_dependence with:
(gdb) p debug_rtx (mem)
(mem:SI (reg:SI 0 ax [orig:247 ivtmp.44 ] [247]) [2 MEM[base: _165, offset:
0B]+0 S4 A32])
(gdb) p mem_mode
$41 = SImode
(gdb) p debug_rtx (mem_addr)
(reg:SI 0 ax [orig:247 ivtmp.44 ] [247])
(gdb) p debug_rtx (x)
(mem:SI (plus:SI (reg:SI 0 ax [orig:209 ivtmp.42 ] [209])
(const_int 20 [0x14])) [2 MEM[base: _327, offset: 20B]+0 S4 A32])
(gdb) p debug_rtx (x_addr)
(plus:SI (reg:SI 0 ax [orig:209 ivtmp.42 ] [209])
(const_int 20 [0x14]))
arguments and that tells us that the two can't alias, because
memrefs_conflict_p returns that they don't.  That is because it sees register
%eax used as base address of both, one memory is biased by offset 20 and the
other is not, and both sizes are 4 bytes.  That is true, except the register
contains different value in between the two instructions.
So, the question is why nothing (get_addr?) has not converted the memory
addresses into VALUEs.

[Bug rtl-optimization/63577] [4.9/5/6 Regression]: Huge compile time and memory usage with -O and not -fPIC

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #13 from Bernd Schmidt  ---
Ideally we'd move RTL back out of garbage-collected memory and onto obstacks.
The combiner was designed to throw away garbage RTL after each failed
combination.

[Bug target/68661] __attribute__ ((no_caller_saved_registers)) trashes stack

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug target/68661] __attribute__ ((no_caller_saved_registers)) trashes stack

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug c++/68586] [6 Regression] Enum template parameter wrongly rejected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Another testcase (explicit underlying type):

enum E : int { x = 1, y = x << 1 };
template struct A {};
A a;

It appears this could be solved by *not* inserting const_decls of enums that
haven't been finished into the cv_cache.  I don't know how to do that though.

[Bug c++/68767] [6 regression] spurious warning: null argument where non-null required

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/69300] New: g++ segfault on silly noexcept case

[redbeard0531 at gmail dot com]

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

Bug ID: 69300
   Summary: g++ segfault on silly noexcept case
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

Created attachment 37359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37359&action=edit
Preprocessed test case

This is a reduced example from a ridiculous code contest. It compiles with
clang++ but segfaults during compilation on g++. It isn't something that I
actually need to work, but I thought I'd report it since it probably shouldn't
be crashing g++.

Code:

template
struct F {
template
void f() && noexcept(&F::template f) {}
};

int main (int argc, char ** argv) {
F().f();
}

g++ output:

> g++ -v -save-temps -std=c++14 bug.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
bug.cpp -mtune=generic -march=x86-64 -std=c++14 -fpch-preprocess -o bug.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0

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

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -fpreprocessed bug.ii
-quiet -dumpbase bug.cpp -mtune=generic -march=x86-64 -auxbase bug -std=c++14
-version -o bug.s
GNU C++14 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9ed1d81099b98de89457560501a9ea0c
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug lto/69271] LTO drops weak binding from aliases

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #7 from Rich Felker  ---
Jan Hubicka, when ld resolves a reference that requires a copy relocation to a
weak definition in a shared library, it searches for a strong symbol for which
the weak definition is an alias, and replaces the reference with one to the
strong symbol. This is necessary to ensure that &weak_alias == &strong_sym at
runtime after the copy relocation changes the address of the symbol.

[Bug lto/68820] [6 regression] FAIL: gcc.c-torture/execute/builtins/memops-asm.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Jan Hubicka from comment #8)
> this does not reproduce for me at PPC nor x86-64. Are there any compilation
> farm machines that reproduce it?

-fno-use-linker-plugin is needed.

Following will trigger the abort on Fedora 23 (otherwise OK with the plugin):

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -g -flto
-fno-use-linker-plugin -c memops-asm.c

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -g -flto
-fno-use-linker-plugin -c main.c

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -g -flto
-fno-use-linker-plugin -c memops-asm-lib.c

$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O2 -g -flto
-fno-use-linker-plugin main.o memops-asm-lib.o memops-asm.o

[uros@localhost mem]$ ./a.out
Aborted (core dumped)

(gdb) r
Starting program: /home/uros/test/mem/a.out 

Program received signal SIGABRT, Aborted.
0x77a4fa98 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x77a4fa98 in raise () from /lib64/libc.so.6
#1  0x77a5169a in abort () from /lib64/libc.so.6
#2  0x00400967 in memcpy (d=d@entry=0x601120 , s=s@entry=0x601080
, n=) at memops-asm-lib.c:67
#3  0x00400773 in main_test () at memops-asm.c:37
#4  0x004004d3 in main () at main.c:10

The problem is in the call to memcpy, my_memcpy should be called instead.