[Bug middle-end/80053] Label with address taken should prevent duplication of containing basic block

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Thu, 16 Mar 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
> 
> --- Comment #2 from Alexander Monakov  ---
> (In reply to Richard Biener from comment #1)
> > The question is whether the transform at hand is valid if the label is
> > duplicated
> > but all referers still refer to the original one (so if the label is dropped
> > at duplication time).
> 
> Well, you still need to initialize 'lp' somehow, so I don't follow.

To the value in the other BB/function.  This works if the jump
targets are semantically compatible.  For function cloning it's
probably hard to say as things like frame allocation may be
incompatible.  For BB level it might be possible.

> > The current handling for cloning is certainly too conservative.
> 
> How so?  I find that it's not conservative enough: it's possible to break it
> even without resorting to inline asm!  The following testcase is miscompiled 
> at
> -O3, because thanks to function cloning the .constprop clone will try to jump
> to the general implementation.  Their epilogues are incompatible, so it
> manifests with a crash.

Interesting ;)  And worth a separate bug.

> #include 
> __attribute__((noinline, noclone))
> static int noop(char *c)
> {
>   return 1;
> }
> __attribute__((noinline))
> static int cloneme(int p, void **target)
> {
>   if (p == -1)
> *target = &&L1;
>   if (p == -2)
> *target = &&L2;
>   if (p < 0)
> return 0;
>   char *tmp = 0;
>   if (p) {
> puts("p != 0");
> tmp = __builtin_alloca(p);
>   } else
> puts("p == 0");
>   goto **target;
> L1:
>   return 0;
> L2:
>   return noop(tmp);
> }
> 
> int main(int argc, char *argv[])
> {
>   void *target1, *target2;
>   cloneme(-1, &target1);
>   cloneme(-2, &target2);
>   for (int i=0; i<10; i++)
> cloneme(0, &target1);
>   cloneme(argc, &target2);
> }
> 
>

[Bug other/80050] gcc/genmatch.c: PVS-Studio: V590

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Fri, 17 Mar 2017, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80050
> 
> Martin Sebor  changed:
> 
>What|Removed |Added
> 
>  CC||msebor at gcc dot gnu.org
> 
> --- Comment #3 from Martin Sebor  ---
> I thought the same thing.  It looks like a deficiency in the implementation. 
> The following is a simple test case for the missing warning.  I'm undecided
> whether to open a separate bug for it or if this bug should track it.

Separate bug please.

> $ cat u.c && gcc -S -Wall -Wextra -Wpedantic -Wlogical-op u.c
> int f (int i)
> {
>   if (i == 123 && i != 456)
> return 1;
> 
>   return 2;
> }

[Bug middle-end/80053] Label with address taken should prevent duplication of containing basic block

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 17 Mar 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
> 
> --- Comment #3 from Alexander Monakov  ---
> ... unless labels are intended to act similar to non-static function-scope
> variables, with computed address usable only until the containing function
> returns?  Except when used in static initializers, which makes them act as if
> their addresses were constant expressions?

Not sure - we do have nonlocal gotos (but those are introduced by
means of nested functions and thus follow the static initialization rule).
Certainly an interesting testcase ;)  I suppose we simply forget to
set DECL_NONLOCAL on L1/L2, doing so might pessimize the case where
we have computed goto with local labels only though.

> (still, if the this testcase is deemed invalid, the original issue remains)

[Bug sanitizer/80067] [6/7 Regression] ICE in fold_comparison with -fsanitize=undefined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug other/80069] ICE at graphite-sese-to-poly.c:1176

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||69728

--- Comment #3 from Richard Biener  ---
Possibly a duplicate of PR69728.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728
[Bug 69728] [6/7 Regression] internal compiler error: in outer_projection_mupa,
at graphite-sese-to-poly.c:1175

[Bug c++/80073] [7 Regression] ICE with virtual base

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug middle-end/80074] missing -Wstringop-overflow on a detected __builtin___sprintf_chk overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|8.0 |---

[Bug c++/80075] [7 regression] ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-17
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a looksee.

[Bug c++/80077] [7 Regression] constant expressions and -fno-elide-constructors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
   Target Milestone|--- |7.0
Summary|constant expressions and|[7 Regression] constant
   |-fno-elide-constructors |expressions and
   ||-fno-elide-constructors
 Ever confirmed|0   |1

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

[Bug tree-optimization/80072] [7 Regression] ICE in gimple_build_assign_1 with -O3 -march=broadwell/skylake-avx512

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
  Known to work||6.3.1
   Target Milestone|--- |7.0
Summary|ICE in  |[7 Regression] ICE in
   |gimple_build_assign_1 with  |gimple_build_assign_1 with
   |-O3 |-O3
   |-march=broadwell/skylake-av |-march=broadwell/skylake-av
   |x512|x512
 Ever confirmed|0   |1
  Known to fail||7.0.1

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

#3  0x013be796 in rewrite_expr_tree (
stmt=, opindex=8, ops=..., changed=true)
at /space/rguenther/src/svn/gcc-7-branch/gcc/tree-ssa-reassoc.c:4243
4243   oe1->op, oe2->op);
(gdb) l
4238  gimple *insert_point
4239= find_insert_point (stmt, oe1->op, oe2->op);
4240  lhs = make_ssa_name (TREE_TYPE (lhs));
4241  stmt
4242= gimple_build_assign (lhs, gimple_assign_rhs_code
(stmt),
4243   oe1->op, oe2->op);
(gdb) p gimple_assign_rhs_code (stmt)
$1 = NOP_EXPR

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug c++/80078] Incorrect classification of address of volatile as not constant

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

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

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
And bootstrap-asan shows:

SUMMARY: AddressSanitizer: SEGV ../../gcc/gcc/gimple-ssa-store-merging.c:869 in
terminate_and_release_chain
==6305==ABORTING
make[3]: *** [_muldc3.o] Error 1
#0 0x134b7cbc in terminate_and_release_chain
../../gcc/gcc/gimple-ssa-store-merging.c:869
#1 0x134bdb24 in terminate_and_process_all_chains
../../gcc/gcc/gimple-ssa-store-merging.c:769
#2 0x134bebfc in execute ../../gcc/gcc/gimple-ssa-store-merging.c:1516
#3 0x1172f160 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2465
#4 0x1173128c in execute_pass_list_1 ../../gcc/gcc/passes.c:2554
#5 0x117312bc in execute_pass_list_1 ../../gcc/gcc/passes.c:2555
#6 0x11731398 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2565
#7 0x10a0cd24 in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2038
#8 0x10a12738 in expand_all_functions ../../gcc/gcc/cgraphunit.c:2174
#9 0x10a12738 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2531
#10 0x10a1c0d8 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2591
#11 0x10a1c0d8 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2621
#12 0x11ad8ff8 in compile_file ../../gcc/gcc/toplev.c:492
#13 0x10225e34 in do_compile ../../gcc/gcc/toplev.c:2000
#14 0x10225e34 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2134
#15 0x10233994 in main ../../gcc/gcc/main.c:39
#16 0x3fffa84946fc in generic_start_main.isra.0 (/lib64/libc.so.6+0x246fc)

AddressSanitizer can not provide additional info.

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
or:

==6305==ERROR: AddressSanitizer: SEGV on unknown address 0x17d7d9d7d7d7d7da (pc
0x134b7cc0 bp 0xbebebebebebebebe sp 0x3fffd0e4aec0 T0)
==6305==The signal is caused by a UNKNOWN memory access.
#1 0x134bec60 in execute ../../gcc/gcc/gimple-ssa-store-merging.c:1514
#2 0x1172f160 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2465
#3 0x1173128c in execute_pass_list_1 ../../gcc/gcc/passes.c:2554
#4 0x117312bc in execute_pass_list_1 ../../gcc/gcc/passes.c:2555
#5 0x11731398 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2565
#2 0x1172f160 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2465
#3 0x1173128c in execute_pass_list_1 ../../gcc/gcc/passes.c:2554
#4 0x117312bc in execute_pass_list_1 ../../gcc/gcc/passes.c:2555
#5 0x11731398 in execute_pass_list(function*, opt_pass*)
../../gcc/gcc/passes.c:2565
#6 0x10a0cd24 in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2038
#7 0x10a12738 in expand_all_functions ../../gcc/gcc/cgraphunit.c:2174
#8 0x10a12738 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2531
#9 0x10a1c0d8 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2591
#10 0x10a1c0d8 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2621
#6 0x10a0cd24 in cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2038
#11 0x11ad8ff8 in compile_file ../../gcc/gcc/toplev.c:492
#7 0x10a12738 in expand_all_functions ../../gcc/gcc/cgraphunit.c:2174
#12 0x10225e34 in do_compile ../../gcc/gcc/toplev.c:2000
#8 0x10a12738 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2531
#13 0x10225e34 in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2134
#9 0x10a1c0d8 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2591
#10 0x10a1c0d8 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2621
#14 0x10233994 in main ../../gcc/gcc/main.c:39
#15 0x3fffb40946fc in generic_start_main.isra.0 (/lib64/libc.so.6+0x246fc)

[Bug c++/80075] [7 regression] ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Really caused by r163947, exposed by some new folding.  The issue is we do not
see if the LHS may throw for *p = {} in stmt_could_throw.  I have a patch.

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #21 from Xi Ruoyao  ---
Start from r227423.

Fix spawned function with lambda function

Make sure that the spawned function's arguments will not be pushed
into lambda function.

gcc/c-family/

2015-09-02  Balaji V. Iyer  

PR middle-end/60586
* c-common.h (cilk_gimplify_call_params_in_spawned_fn): New
prototype.
* c-gimplify.c (c_gimplify_expr): Added a call to the function
cilk_gimplify_call_params_in_spawned_fn.
* cilk.c (cilk_gimplify_call_params_in_spawned_fn): New function.
(gimplify_cilk_spawn): Removed EXPR_STMT and CLEANUP_POINT_EXPR
unwrapping.

gcc/cp/

2015-09-02  Balaji V. Iyer  

PR middle-end/60586
* cp-gimplify.c (cilk_cp_gimplify_call_params_in_spawned_fn): New
function.
(cp_gimplify_expr): Added a call to the function
cilk_cp_gimplify_call_params_in_spawned_fn.

gcc/testsuite/

2015-09-02  Balaji V. Iyer  

PR middle-end/60586
* c-c++-common/cilk-plus/CK/pr60586.c: New file.
* g++.dg/cilk-plus/CK/pr60586.cc: Likewise.

PR60586 makes GCC ICE on Florent's testcase.

[Bug middle-end/80053] Label with address taken should prevent duplication of containing basic block

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
(In reply to rguent...@suse.de from comment #4)
> To the value in the other BB/function.  This works if the jump
> targets are semantically compatible.  For function cloning it's
> probably hard to say as things like frame allocation may be
> incompatible.  For BB level it might be possible.

... but the whole point of the original testcase is to show that loop
unswitching makes targets incompatible?  Now I'm confused as to what you've
meant, because afaics what you describe is what already happens in gcc: when
the BB is cloned, exactly one of the copies retains the original label, which
remains to be used for initialization of 'lp'.

[Bug c++/80075] [7 regression] ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|7.0 |5.5

--- Comment #3 from Richard Biener  ---
Which also mean that the following generates wrong-code in not treating
*p = (struct s){} as possibly throwing since that revision.

struct s {
int i;
};

extern int use_memcpy;
extern void my_memcpy(void*, void*, int);

int
f (struct s* p)
{
  struct s a;

  try
{
  a = (struct s){};
  if (!use_memcpy)
*p = (struct s){};
  else
my_memcpy (p, &a, sizeof (struct s));
} catch (...)
  {
return 0;
  }
return 1;
}

[Bug middle-end/60586] [Cilk+] Parameters evaluation happens inside spawn worker

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||ryxi at stu dot xidian.edu.cn

--- Comment #4 from Xi Ruoyao  ---
According to Intel cilkplus spec

the parameter SHOULD be evaluated inside spawn worker.

See section 3.6 bullet [4]-[9].

Balaji's commit caused PR80038.  However without this commit, PR80038's
test case just ICE. More analysis required.

[Bug target/80080] New: S390: Isses with emitted cs-instructions for __atomic builtins.

[stli at linux dot vnet.ibm.com]

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

Bug ID: 80080
   Summary: S390: Isses with emitted cs-instructions for __atomic
builtins.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stli at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
Target: S390

For s390, I am now using the c11 atomic builtins in glibc.
There are now some issues with the emitted cs-instructions.
If __atomic_compare_exchange_n is used within a condition for if/while,
it is sometimes not using the condition code directly to jump away.
Instead it extracts the condition code to a general register via ipm followed
by
further instructions in order to compare it. Afterwards it jumps according to
this comparison.

int foo1 (int *mem)
{
  int val, newval;
  val = __atomic_load_n (mem, __ATOMIC_RELAXED);
  do
{
  newval = val | 123;
}
  while (!__atomic_compare_exchange_n (mem, &val, newval, 1, __ATOMIC_ACQUIRE,
   __ATOMIC_RELAXED));

  /*
 :
   0:   58 10 20 00 l   %r1,0(%r2)
   4:   18 31   lr  %r3,%r1
   6:   a5 3b 00 7b oill%r3,123
   a:   ba 13 20 00 cs  %r1,%r3,0(%r2)
   e:   b2 22 00 30 ipm %r3
  12:   8a 30 00 1c sra %r3,28
  16:   ec 36 ff f7 00 7e   cijne   %r3,0,4 
  1c:   a7 29 00 00 lghi%r2,0
  20:   07 fe   br  %r14
  22:   07 07   nopr%r7
  24:   07 07   nopr%r7
  26:   07 07   nopr%r7
   */
  return 0;
}



For __atomic_exchange_n, s390 has no special instruction and thus a cs-loop is
used. An extra register is needed to save the old-value instead of using the
"old"-register of cs-instruction which is updated if the new value is not
stored
to memory. This extra register is reloaded in every loop.

extern int bar (int *mem);
int foo2 (int *mem)
{
  int old = __atomic_exchange_n (mem, 0, __ATOMIC_ACQUIRE);
  if (old >= 2)
return bar (mem);

  /*
0028 :
  28:   a7 48 00 00 lhi %r4,0
  2c:   58 10 20 00 l   %r1,0(%r2)
  30:   18 31   lr  %r3,%r1
  32:   ba 14 20 00 cs  %r1,%r4,0(%r2)
  36:   a7 74 ff fd jne 30 
  3a:   ec 3c 00 06 01 7e   cijnh   %r3,1,46 
  40:   c0 f4 00 00 00 00   jg  40 
42: R_390_PC32DBL   bar+0x2
  46:   a7 29 00 00 lghi%r2,0
  4a:   07 fe   br  %r14
  4c:   07 07   nopr%r7
  4e:   07 07   nopr%r7
   */
  return 0;
}

In case of exchanging to a zero value, like above, the load-and-and instruction
can be used. Then only one register is needed for the new and old value and
there is no loop.


If the exchanged memory is a global variable, the address of it is loaded
within the loop instead of before the loop.

extern int foo3_mem;
int foo3 (void)
{
  return __atomic_exchange_n (&foo3_mem, 5, __ATOMIC_ACQUIRE);

  /*
0050 :
  50:   c4 1d 00 00 00 00   lrl %r1,50 
52: R_390_PC32DBL   foo3_mem+0x2
  56:   a7 38 00 05 lhi %r3,5
  5a:   18 21   lr  %r2,%r1
  5c:   c0 40 00 00 00 00   larl%r4,5c 
5e: R_390_PC32DBL   foo3_mem+0x2
  62:   ba 13 40 00 cs  %r1,%r3,0(%r4)
  66:   a7 74 ff fa jne 5a 
  6a:   b9 14 00 22 lgfr%r2,%r2
  6e:   07 fe   br  %r14
   */
}

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #22 from Xi Ruoyao  ---
PR 60586 is a false PR to an expected behaviour...  Unfortunately nobody
noticed that and someone "fixed" it.

But without r227423 GCC just ICE on the testcase.

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #23 from Xi Ruoyao  ---
Sorry.  I was too tired so I misunderstood r227423.

Now I am not sure whether it introduced the bug.  I'll test it with
NumericMonoid code.

[Bug middle-end/60586] [Cilk+] Parameters evaluation happens inside spawn worker

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #5 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #4)

> Balaji's commit caused PR80038.  However without this commit, PR80038's
> test case just ICE. More analysis required.

Sorry I misunderstood the commit log.  Ignore what I said.

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[lucdanton at free dot fr]

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

lucdanton at free dot fr changed:

   What|Removed |Added

 CC||lucdanton at free dot fr

--- Comment #6 from lucdanton at free dot fr ---
As a heads-up, deduction was possible when the constructor was a non-template:

std::basic_string_view sv = …;
// produces an std::basic_string
auto into_string = std::basic_string { sv };

That made it possible to concisely convert a string view to its 'natural'
string
type, even in a generic context. (Unless I'm mistaken there is nothing in the
current basic_string_view interface that would allow to do the same, e.g.
sv.to_string().)

Now that's it a constrained constructor template, it looks like deduction picks
an std::initializer_list constructor. So into_string ends up being an
std::basic_string.

Of course the only thing that is lost is conciseness, the user can resort to
any
of several other solutions.

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
I think that's when terminate_and_process_all_chains is called without any
chains having been detected. m_stores_head will not have a sensible value.

Returning early from terminate_and_process_all_chains if m_stores is empty
seems like a quick fix for this

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

Fixed patch, previous one caused some miscompile.  Testing in progress (ISTR
seeing some optimization testcases failing as well).

[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Is this a duplicate of PR79981 (and thus fixed in trunk)?

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Or perhaps just init it in the constructor:

diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index 5bdb4597d615..a6fd8ede467c 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -725,7 +725,7 @@ class pass_store_merging : public gimple_opt_pass
 {
 public:
   pass_store_merging (gcc::context *ctxt)
-: gimple_opt_pass (pass_data_tree_store_merging, ctxt)
+: gimple_opt_pass (pass_data_tree_store_merging, ctxt), m_stores_head ()
   {
   }

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #4)
> Or perhaps just init it in the constructor:
> 
> diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
> index 5bdb4597d615..a6fd8ede467c 100644
> --- a/gcc/gimple-ssa-store-merging.c
> +++ b/gcc/gimple-ssa-store-merging.c
> @@ -725,7 +725,7 @@ class pass_store_merging : public gimple_opt_pass
>  {
>  public:
>pass_store_merging (gcc::context *ctxt)
> -: gimple_opt_pass (pass_data_tree_store_merging, ctxt)
> +: gimple_opt_pass (pass_data_tree_store_merging, ctxt), m_stores_head ()
>{
>}

That would work too

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #24 from Xi Ruoyao  ---
The cilkplus spec described an "unsymmetrical" construct/destruct of temp
variables.  It seems difficult to implement in GCC.  I'm trying to find a
solution.

[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

--- Comment #2 from Andreas Krebbel  ---
(In reply to Richard Biener from comment #1)
> Is this a duplicate of PR79981 (and thus fixed in trunk)?

No it is a different problem. We are working on a fix.

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #25 from Xi Ruoyao  ---
I confirmed that r227423 broke NumericMonoid.

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
The patch causes some optimization regressions.

A different approach is to put the clobbers in non-conditional context -
something that is valid but with the clobber semantic cannot be done by the
middle-end.  Instead we can do this at gimplification time with, say,

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 246216)
+++ gcc/gimplify.c  (working copy)
@@ -6288,10 +6288,13 @@ gimplify_cleanup_point_expr (tree *expr_

 /* Insert a cleanup marker for gimplify_cleanup_point_expr.  CLEANUP
is the cleanup action required.  EH_ONLY is true if the cleanup should
-   only be executed if an exception is thrown, not on normal exit.  */
+   only be executed if an exception is thrown, not on normal exit.
+   If FORCE_UNCOND is true perform the cleanup unconditionally;  this is
+   only valid for clobbers.  */

 static void
-gimple_push_cleanup (tree var, tree cleanup, bool eh_only, gimple_seq *pre_p)
+gimple_push_cleanup (tree var, tree cleanup, bool eh_only, gimple_seq *pre_p,
+bool force_uncond = false)
 {
   gimple *wce;
   gimple_seq cleanup_stmts = NULL;
@@ -6301,7 +6304,8 @@ gimple_push_cleanup (tree var, tree clea
   if (seen_error ())
 return;

-  if (gimple_conditional_context ())
+  if (gimple_conditional_context ()
+  && ! force_uncond)
 {
   /* If we're in a conditional context, this is more complex.  We only
 want to run the cleanup if we actually ran the initialization that
@@ -6426,11 +6430,7 @@ gimplify_target_expr (tree *expr_p, gimp
NULL);
  TREE_THIS_VOLATILE (clobber) = true;
  clobber = build2 (MODIFY_EXPR, TREE_TYPE (temp), temp, clobber);
- if (cleanup)
-   cleanup = build2 (COMPOUND_EXPR, void_type_node, cleanup,
- clobber);
- else
-   cleanup = clobber;
+ gimple_push_cleanup (temp, clobber, false, pre_p, true);
}
  if (asan_poisoned_variables && dbg_cnt (asan_use_after_scope))
{

which brings down stack usage to GCC 5 levels (so is even better than the
other patch).

[Bug tree-optimization/80048] gcc/sese.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 17 11:03:32 2017
New Revision: 246217

URL: https://gcc.gnu.org/viewcvs?rev=246217&root=gcc&view=rev
Log:
2017-03-17  Richard Biener  

PR tree-optimization/80048
* sese.c (free_sese_info): Properly release rename_map and
copied_bb_map elements.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sese.c

[Bug other/80050] gcc/genmatch.c: PVS-Studio: V590

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/80053] Label with address taken should prevent duplication of containing basic block

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
I didnt' want to say you are wrong just had some thoughts that there may be
cases where cloning/copying is ok.

[Bug tree-optimization/80048] gcc/sese.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug other/80050] gcc/genmatch.c: PVS-Studio: V590

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 17 11:04:00 2017
New Revision: 246218

URL: https://gcc.gnu.org/viewcvs?rev=246218&root=gcc&view=rev
Log:
2017-03-17  Richard Biener  

PR middle-end/80050
* genmatch.c (parser::next): Remove pointless check for CPP_EOF.
(parser::peek): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #4 from Paolo Carlini  ---
Sorry about the regression. Marek, what about something like:

Index: except.c
===
--- except.c(revision 246216)
+++ except.c(working copy)
@@ -271,6 +271,8 @@ build_must_not_throw_expr (tree body, tree cond)
   cond = perform_implicit_conversion_flags (boolean_type_node, cond,
tf_warning_or_error,
LOOKUP_NORMAL);
+  if (processing_template_decl)
+   cond = fold_non_dependent_expr (cond);
   cond = cxx_constant_value (cond);
   if (integer_zerop (cond))
return body;

certainly works fine for the testcases at issue and also for variants like:

template int foo(T b)
{
  return __transaction_atomic noexcept(b) (0);
}

void bar()
{
  foo(true);
}

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Yeah, seems fine to me.  Although I don't think we need to check
processing_template_decl before fold_non_dependent_expr.

I'll test and post, thanks.

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Actually, it seems weird to call cxx_constant_value after
fold_non_dependent_expr has called maybe_constant_value.  :/

[Bug c++/80073] [7 Regression] ICE with virtual base

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r241187 - Implement P0017R1, C++17 aggregates with bases.

[Bug gcov-profile/80081] New: gcov-dump needs man page

[vries at gcc dot gnu.org]

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

Bug ID: 80081
   Summary: gcov-dump needs man page
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00925.html :
...
Bonus point if you also write the missing gcov-dump.texi (so we get a
manpage as well).
...

[Bug gcov-profile/80081] gcov-dump needs man page

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Options needing documentation:
...
$ gcov-dump --help
Usage: gcov-dump [OPTION] ... gcovfiles
Print coverage file contents
  -h, --help   Print this help
  -v, --versionPrint version number
  -l, --long   Dump record contents too
  -p, --positions  Dump record positions
  -w, --working-sets   Dump working set computed from summary

For bug reporting instructions, please see:
.
...

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Optimization regressions:

FAIL: g++.dg/pr64191.C  -std=gnu++11  scan-tree-dump-times cddce1 "CLOBBER" 1
FAIL: g++.dg/pr64191.C  -std=gnu++11  scan-tree-dump-times cddce1 "if" 0
FAIL: g++.dg/pr64191.C  -std=gnu++14  scan-tree-dump-times cddce1 "CLOBBER" 1
FAIL: g++.dg/pr64191.C  -std=gnu++14  scan-tree-dump-times cddce1 "if" 0
FAIL: g++.dg/pr64191.C  -std=gnu++98  scan-tree-dump-times cddce1 "CLOBBER" 1
FAIL: g++.dg/pr64191.C  -std=gnu++98  scan-tree-dump-times cddce1 "if" 0

it's a real regression in that the loop persists until the end of the
compilation.

I am now fully testing the alternative gimplification.

[Bug gcov-profile/80081] gcov-dump needs man page

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

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

[Bug c++/80075] [7 regression] ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 17 12:48:56 2017
New Revision: 246223

URL: https://gcc.gnu.org/viewcvs?rev=246223&root=gcc&view=rev
Log:
2017-03-17  Richard Biener  

PR middle-end/80075
* tree-eh.c (stmt_could_throw_1_p): Only handle gimple assigns.
Properly verify the LHS before the RHS possibly claims to be
handled.
(stmt_could_throw_p): Hande gimple conds fully here.  Clobbers
do not throw.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr80075.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c

[Bug c++/80075] [5/6 Regression] ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||7.0.1
Summary|[7 regression] ICE: |[5/6 Regression] ICE:
   |"statement marked for   |"statement marked for
   |throw, but doesn’t" with|throw, but doesn’t" with
   |-fnon-call-exceptions   |-fnon-call-exceptions

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.  The regression is the wrong-code one now and P2.

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
Yes. Judging by the comment before fold_non_dependent_expr (which I wrote
myself ;) it seems we could use instantiate_non_dependent_expr_sfinae (cond,
tf_none) instead?

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
I have MALLOC_PERTURB_ set and the issue causes gcc crashing all over the
place.  I'll commit the patch in Comment 4 -- it seems to fix it for me.

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar 17 13:14:42 2017
New Revision: 246224

URL: https://gcc.gnu.org/viewcvs?rev=246224&root=gcc&view=rev
Log:
PR tree-optimization/80079
* gimple-ssa-store-merging.c (class pass_store_merging): Initialize
m_stores_head.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c

[Bug tree-optimization/80079] [7 Regression] Conditional jump or move depends on uninitialised value(s): gimple-ssa-store-merging.c:768

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Should be fixed thus.

[Bug c++/80075] [5/6 Regression] ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor  ---
Thanks!

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Right, I think that's best.  I'm testing it.  Thanks!

[Bug target/80082] New: GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[prakhar.bahuguna at arm dot com]

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

Bug ID: 80082
   Summary: GCC incorrectly assumes Cortex-r[578] have 64-bit
single-copy atomic LDRD
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prakhar.bahuguna at arm dot com
  Target Milestone: ---

Created attachment 40992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40992&action=edit
Atomic load reproducer

GCC currently assumes that if your armv7* architecture has both arm and Thumb
division instructions then you have the LPAE extension. This causes the
compiler to assume that LDRD is single-copy atomic.

Cortex-R cores with ARM division are thus incorrectly treated as having LPAE.
This is a bug that leads to incorrect code that would likely to be difficult to
track down in the field (potential data corruption during contention).

Steps to reproduce:
* Compile atomic_load.c with arm-none-eabi-gcc -mcpu=cortex-r5 atomic_load.c -S
-O2 -o -
* Note that in the output, LDRD is used to load x instead of LDREXD, despite
LDRD not being single-copy atomic on Cortex-R profile. The same issue can be
reproduced for -mcpu=cortex-r7 and cortex-r8.

[Bug target/80082] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||arm
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug target/80082] [6/7 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

Summary|GCC incorrectly assumes |[6/7 regression] GCC
   |Cortex-r[578] have 64-bit   |incorrectly assumes
   |single-copy atomic LDRD |Cortex-r[578] have 64-bit
   ||single-copy atomic LDRD

--- Comment #1 from Richard Earnshaw  ---
Introduced by r233658; cortex-r5 support pre-dates that, so a regression in
gcc-6 and -7.

[Bug target/80082] [5/6/7 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

Summary|[6/7 regression] GCC|[5/6/7 regression] GCC
   |incorrectly assumes |incorrectly assumes
   |Cortex-r[578] have 64-bit   |Cortex-r[578] have 64-bit
   |single-copy atomic LDRD |single-copy atomic LDRD

--- Comment #2 from Richard Earnshaw  ---
It looks as though this patch was then backported onto older releases as well,
so GCC-5 also regressed.

[Bug target/80083] New: libgomp doacross2.f90 regtest fails with -mcpu=power9 -O1

[acsawdey at gcc dot gnu.org]

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

Bug ID: 80083
   Summary: libgomp doacross2.f90 regtest fails with -mcpu=power9
-O1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: meissner at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-* power9

This regression test fails but only with -O1 -mcpu=power9. Adding
-mno-vsx-small-integer makes it work but I don't know if that's just because it
perturbs the problem.

[Bug c++/80084] New: [7 regression] wrong code for decomposition declaration with debug iterator

[lucdanton at free dot fr]

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

Bug ID: 80084
   Summary: [7 regression] wrong code for decomposition
declaration with debug iterator
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr
  Target Milestone: ---

I managed to reduce to this testcase:

//
#include 
#include 

struct aggr {
std::vector::iterator val;
};

void decomp(aggr arg)
{
auto& [val] = arg;

// fires
assert( &val == &arg.val );
}

int main()
{
// inlined decomp
{
aggr arg {};
auto& [val] = arg;

// fine
assert( &val == &arg.val );
}

decomp(aggr {});
}
//--

The assertion in decomp fires when the program is compiled with e.g.:

g++-trunk -std=c++1z main.cpp -D_GLIBCXX_DEBUG

According to my bisecting, this change was introduced by r245638.

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[jan.smets at nokia dot com]

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

--- Comment #9 from Jan Smets  ---
The alternative patch to gimplify.c seems to run fine.
Thanks

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

[law at gcc dot gnu.org]

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

--- Comment #22 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 17 15:01:56 2017
New Revision: 246225

URL: https://gcc.gnu.org/viewcvs?rev=246225&root=gcc&view=rev
Log:
PR tree-optimization/71437
* tree-vrp.c (simplify_stmt_for_jump_threading): Lookup the
conditional in the hash table first.
(vrp_dom_walker::before_dom_children): Extract condition from
ASSERT_EXPR.  Record condition, its inverion and any implied
conditions as well.

PR tree-optimization/71437
* gcc.dg/tree-ssa/pr71437.c: New test.
* gcc.dg/tree-ssa/20040305-1.c: Test earlier dump.
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Adjust for jump threads
now caught by VRP, but which were previously caught by DOM.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71437.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040305-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
trunk/gcc/tree-vrp.c

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #23 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug c++/70515] Nested lambdas causing invalid captured pointers on some platforms

[gcc at norgg dot org]

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

Norgg  changed:

   What|Removed |Added

 CC||gcc at norgg dot org

--- Comment #4 from Norgg  ---
Created attachment 40993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40993&action=edit
gcc -v output for gcc 5.4.0

(In reply to Martin Sebor from comment #3)
> I also cannot reproduce it with 7.0 on powepc64le or with 5.x on x86_64. 
> Can you please list the processor architectures you see this problem on? 
> (Providing the output of gcc -v should help.)

I can still reproduce this on my x86_64 Ubuntu system, in both g++ 5.4.1 and
6.2.0, gcc -v output from each attached.

[Bug c++/70515] Nested lambdas causing invalid captured pointers on some platforms

[gcc at norgg dot org]

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

--- Comment #5 from Norgg  ---
Created attachment 40994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40994&action=edit
gcc -v output for gcc 6.2.0

[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 17 15:10:13 2017
New Revision: 246226

URL: https://gcc.gnu.org/viewcvs?rev=246226&root=gcc&view=rev
Log:
PR rtl-optimization/79910
* combine.c (record_used_regs): New static function.
(try_combine): Handle situations where there is an additional
instruction between I2 and I3 which needs to have a LOG_LINK
updated.

PR rtl-optimization/79910
* gcc.dg/torture/pr79910.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79910.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
Fixed by Bernd's patch on the trunk.

[Bug rtl-optimization/59811] [5 Regression] Huge increase in memory usage and compile time in combine

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Huge |[5 Regression] Huge
   |increase in memory usage|increase in memory usage
   |and compile time in combine |and compile time in combine

--- Comment #18 from Jeffrey A. Law  ---
WRT c#16 -- I must have totally missed the differences in checking
configurations!  The gcc-6 and the trunk are comparable to gcc-4.7 with this
test when the compilers are similarly configured (checking was also responsible
for the huge register allocator jump).  I'm pretty sure gcc-5 doesn't have the
appropriate improvements.

I'm removing the gcc-6 and gcc-7 regression markers.

gcc-bugs@gcc.gnu.org

[msebor at gcc dot gnu.org]

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

Bug ID: 80085
   Summary: missing -Wlogical-op on a superfluous second operand
of &&
   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 test case below, reduced from bug 80050 in GCC sources, shows a case of a
missing -Wlogical-op warning for the second operand of the && expression which
is trivially satisfied by the first operand.

$ cat u.c && gcc -S -Wall -Wextra -Wpedantic -Wlogical-op u.c
int f (int i)
{
  if (i == 123 && i != 456)
return 1;

  return 2;
}

[Bug other/80050] gcc/genmatch.c: PVS-Studio: V590

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80085

--- Comment #7 from Martin Sebor  ---
I've raised bug 80085 for the missing -Wlogical-op warning.

[Bug fortran/79795] [5/6/7 Regression] Fortran ICE in resolve_symbol starting with r163221

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

--- Comment #13 from Dominique d'Humieres  ---
Considering the traffic, confirmed!

gcc-bugs@gcc.gnu.org

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I think this is a dup, or at least I'd swear that I discussed this idea in the
BZ somewhere.  Until that's found, confirmed.

[Bug target/80082] [5/6/7 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Confirmed.
The problem is that these Cortex-R cores combined with the bit_adiv isa bit end
up having the same feature set as armv7ve as far as GCC can tell.

I think the best approach here is to create an isa_bit_lpae that's unique to
armv7ve (and higher A-profile arches)

[Bug target/80082] [5/6/7 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P1  |P2
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
P2 as the bug appears in a released compiler

[Bug c++/80084] [7 regression] wrong code for decomposition declaration with debug iterator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Possibly related to the debug iterator having non-trivial copy constructor
and/or destructor. I'm not sure why else it would fail only in debug mode.

N.B. you can use  and __gnu_debug::vector to use the same types
without _GLIBCXX_DEBUG, so you can mix std::vector and __gnu_debug::vector in
one translation unit (in case that helps analyse it).

[Bug rtl-optimization/80086] New: ICE: in extract_constrain_insn, at recog.c:2213 for the gcc.dg/vect/slp-perm-6.c test on MIPS

[tomtab at gcc dot gnu.org]

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

Bug ID: 80086
   Summary: ICE: in extract_constrain_insn, at recog.c:2213 for
the gcc.dg/vect/slp-perm-6.c test on MIPS
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomtab at gcc dot gnu.org
  Target Milestone: ---

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

gcc.dg/vect/slp-perm-6.c is failing on GCC 7 for mips-mti-elf (but not for
mips-mti-linux-gnu) with the following ICE:

t.c: In function ‘foo’:
t.c:40:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 309 166 295 2 (parallel [
(set (reg/f:DI 4 $4 [309])
(symbol_ref/u:DI ("*.LC10") [flags 0x2]))
(clobber (scratch:DI))
]) "t.c":25 289 {*lea64}
 (nil))
t.c:40:1: internal compiler error: in extract_constrain_insn, at recog.c:2213
0xddd4b9 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
gcc/gcc/rtl-error.c:108
0xddd51a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
gcc/gcc/rtl-error.c:119
0xd84c18 extract_constrain_insn(rtx_insn*)
gcc/gcc/recog.c:2213
0xc505c2 check_rtl
gcc/gcc/lra.c:2128
0xc51124 lra(_IO_FILE*)
gcc/gcc/lra.c:2546
0xbf8ddf do_reload
gcc/gcc/ira.c:5451
0xbf92da execute
gcc/gcc/ira.c:5635

I've attached a (slightly) reduced version of the test case.

Here's the command I'm using:
mips-mti-elf-gcc t.c -mabi=64 -mmsa -ftree-vectorize -O2 -S -o a.s

Robert Suchanek has taken a look at this and came up with a potential fix,
and Matthew Fortune has encountered a very similar problem recently.

[Bug tree-optimization/80087] New: missing -Wtautological-compare with non-constant operands

[msebor at gcc dot gnu.org]

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

Bug ID: 80087
   Summary: missing -Wtautological-compare with non-constant
operands
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The test case below, reduced from bug 80048, shows that GCC diagnoses only
trivial cases of pointless comparisons.  Enhancing the warning to (also) run
later, with the benefit of data flow analysis, as opposed to during parsing,
would make it possible to diagnose some of these less obvious bugs.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic a.c
void f (int);

void f1 (int n)
{
  if (n != n)   // warning, ok
f (n);

  int i = n;
  if (i != n)   // missing warning
f (i);

  for (int i = n; i != n; ++i)   // missing warning
f (i);
}

struct S { int *a, *b; };

void f2 (struct S *s)
{
  for (int *p = s->a; p != s->a; ++p)   // missing warning
f (*p);
}
a.c: In function ‘f1’:
a.c:5:9: warning: self-comparison always evaluates to false
[-Wtautological-compare]
   if (n != n)   // warning, ok
 ^~

[Bug tree-optimization/80087] missing -Wtautological-compare with non-constant operands

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug tree-optimization/80048] gcc/sese.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80087

--- Comment #4 from Martin Sebor  ---
I opened bug 80087 to consider enhancing -Wtautological-compare so as to detect
and diagnose this class of problems.

[Bug c++/78345] [5/6/7 Regression] ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: in cxx_eval_outermost_constant_expr, at cp/constexpr.c:4464)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/80084] [7 regression] wrong code for decomposition declaration with debug iterator

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I'll have a look tomorrow.

[Bug target/79951] ICE in extract_insn, at recog.c:2311 on ppc64le with -mno-cmpb

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
Author: pthaugen
Date: Fri Mar 17 16:42:29 2017
New Revision: 246228

URL: https://gcc.gnu.org/viewcvs?rev=246228&root=gcc&view=rev
Log:
PR target/79951
* config/rs6000/rs6000.md (copysign3_fcpsgn): Test
for VECTOR_UNIT_VSX_P (mode) too.
* gcc.target/powerpc/pr79951.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79951.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/79993] ICE in tree_to_uhwi, at tree.c:7344

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Roland Illig from comment #6)
> Could you perhaps make all 6 messages in that function follow the same
> syntax?

Will do

[Bug sanitizer/79993] ICE in tree_to_uhwi, at tree.c:7344

[mpolacek at gcc dot gnu.org]

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

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

commit d680c844a90ba12a0b12f7d206d697dc32d2cfee
Author: jason 
Date:   Thu May 9 16:43:43 2013 +

N3639 C++1y VLA diagnostics

* decl.c (grokdeclarator): Complain about reference, pointer, or
typedef to VLA.
(create_array_type_for_decl): Complain about array of VLA.
* pt.c (tsubst): Likewise.
* rtti.c (get_tinfo_decl): Talk about "array of runtime bound".
* semantics.c (finish_decltype_type): Complain about decltype of
VLA.
* typeck.c (cp_build_addr_expr_1): Complain about VLA.
(cxx_sizeof_or_alignof_type): Likewise.

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

before that:
pr78201.C:11:15: error: variable-sized object ‘a’ may not be initialized
   char a[e] = "";
   ^

[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|ICE in tree_to_uhwi, at |[5/6/7 Regression] ICE in
   |tree.c:7344 |tree_to_uhwi, at
   ||tree.c:7344

[Bug sanitizer/80018] ICE in expand_expr_addr_expr_1, at expr.c:7790 w/ -fsanitize=object-size

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/79960] [5/6 Regression] Class template partial specializations for const volatile types don't match

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] Class|[5/6 Regression] Class
   |template partial|template partial
   |specializations for const   |specializations for const
   |volatile types don't match  |volatile types don't match
  Known to fail|7.0 |

--- Comment #5 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/80073] [7 Regression] ICE with virtual base

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/80072] [7 Regression] ICE in gimple_build_assign_1 with -O3 -march=broadwell/skylake-avx512

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I'll have a look.

[Bug c++/70631] Warn about redundant comparisons with -Wlogical-op

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-17
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=60759,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69602,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71472
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  For a user's point of view I'd be inclined to view it as a bug
rather than an enhancement, but a review of the implementation suggests this
case just isn't handled.  I.e., the warning is working as intended and needs to
be enhanced to handle these expressions.

See also pr60759, pr69602, and pr71472 for other bugs/enhancements affecting
-Wlogical-op.

[Bug tree-optimization/80072] [7 Regression] ICE in gimple_build_assign_1 with -O3 -march=broadwell/skylake-avx512

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

gcc-bugs@gcc.gnu.org

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=60759,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69602,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71472
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
Bug 71472 seems pretty close but it's about ||.

Bug 69602 had some discussion recently but it's about what's viewed as a false
positive by some, while this one is a false negative.

I also found bug 60759 but that one is about implicit int to bool conversion,
so it's not quite the same either.

But I think I've finally found it: bug 70631.  Thus resolving as duplicate of
that one.

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

[Bug c++/70631] Warn about redundant comparisons with -Wlogical-op

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
*** Bug 80085 has been marked as a duplicate of this bug. ***

[Bug target/80052] typo in aarch64.opt: dummping

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri Mar 17 17:05:23 2017
New Revision: 246229

URL: https://gcc.gnu.org/viewcvs?rev=246229&root=gcc&view=rev
Log:
[aarch64] Fix typo in aarch64.opt (dummping -> dumping).

PR target/80052
* aarch64.opt(verbose-cost-dump): Fix typo.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.opt

[Bug target/80052] typo in aarch64.opt: dummping

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
Fixed.

[Bug c++/70515] Nested lambdas causing invalid captured pointers on some platforms

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Known to fail||5.3.1, 6.3.0, 7.0

--- Comment #6 from Martin Sebor  ---
Thank you.  I still can't reproduce the problem with -O0 but I do see a SIGSEGV
on x86_64 when I compile the test case with -O1 or higher, with all of GCC 5.x,
6.x, and 7.0.  Thus confirmed.

$ /ssd/build/gcc-6-branch/gcc/xg++ -B /ssd/build/gcc-6-branch/gcc -nostdinc++
-I
/ssd/build/gcc-6-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I /ssd/build/gcc-6-branch/x86_64-pc-linux-gnu/libstdc++-v3/include -I
/src/gcc/6-branch/libstdc++-v3/libsupc++ -I
/src/gcc/6-branch/libstdc++-v3/include/backward -I
/src/gcc/6-branch/libstdc++-v3/testsuite/util -L
/ssd/build/gcc-6-branch/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -std=gnu++1z
-g -O1 t.C && gdb -batch -q -ex r -ex bt a.out 

Program received signal SIGSEGV, Segmentation fault.
0x0040064c in ::operator() (__closure=0x7fffde68) at
t.C:9
9   auto lambda1 = [&]{ (*j)++; };
#0  0x0040064c in ::operator() (__closure=0x7fffde68) at
t.C:9
#1  ::operator() (__closure=0x7fffdea0,
__closure@entry=0x7fffde30) at t.C:10
#2  std::_Function_handler >::_M_invoke(const
std::_Any_data &) (__functor=...) at
/ssd/build/gcc-6-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/functional:1731
#3  0x004006bf in std::function::operator()() const
(this=0x7fffdea0) at
/ssd/build/gcc-6-branch/x86_64-pc-linux-gnu/libstdc++-v3/include/functional:2127
#4  main () at t.C:16

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #33 from Jeffrey A. Law  ---
Martin,

Richi's right. If you look at the .optimized dump you'll an huge number of
redundant conditionals.

We should compute b1 && b2 && b3 ... && b12 once and store the result into each
array element.

But the way we generate code for this can make it awful hard for the optimizers
to see the giant common subexpression.

If you look at the shape of the CFG and explore how to expose the various
redundancies, you'll see there's a cascading effect.  ie, you expose some,
simplify and new opportunities appear.

Jump threading had the ability to do this many years ago.  We kept iterating
DOM and forward jump threading until nothing changed.  But that was very
expensive relative to what was gained and we removed the iteration code.

There's various things in the pipeline that might (or might not) help this
specific BZ over time.  It's certainly in the back of my mind as we continue
the transition away from the forward equivalency table based jump threading to
the backward walking of the use-def chains.

The backwards approach holds a lot more promise  to address this BZ.  I'm
pretty sure the stuff planned would allow it to find all the threads in a
single pass.  The question of cost of the backwards walking and  block copying
necessary to isolate/expose the redundancies.

[Bug target/80083] libgomp doacross2.f90 regtest fails with -mcpu=power9 -O1

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Created attachment 40996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40996&action=edit
asm output