[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled

[linkw at gcc dot gnu.org]

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

--- Comment #12 from Kewen Lin  ---

> Thanks for the explanation! I'll look at it after checking 2). IIUC, the
> advantage to eliminate stores here looks able to get those things which is
> fed to stores and stores' consumers bundled, then get more things SLP-ed if
> available?

Hmm, I think I was wrong, if both the feeding chain and consuming chain of the
stores are SLP-ed, later FRE would be able to fuse them.

[Bug gcov-profile/85351] [GCOV] Wrong coverage with exit() executed in a if statement within a called function

[i at maskray dot me]

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

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #5 from Fangrui Song  ---
I am a bit curious how GCC instruments such functions which may alter control
flows

* exit/execve/execl/etc
* fork
* functions which may throw or call any above functions

If you force a split basic block after such functions, you get counts correct
but you pay the costs that there is one more basic block and two more arcs. In
-fprofile-arcs you need to pay the instrumentation cost of one arc (after
taking into account of the Kirchhoff circuit law's spanning tree optimization).
If you assume every external function call may alter control flows, you pay
rather large overhead for things you probably care little (since I know some
underlying mechanism I don't trust line counts after special functions).

[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled

[linkw at gcc dot gnu.org]

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

--- Comment #11 from Kewen Lin  ---
(In reply to Richard Biener from comment #10)
> (In reply to Kewen Lin from comment #9)
> > (In reply to Richard Biener from comment #8)
> > > (In reply to Kewen Lin from comment #7)
> > > > Two questions in mind, need to dig into it further:
> > > >   1) from the assembly of scalar/vector code, I don't see any stores 
> > > > needed
> > > > into temp array d (array diff in pixel_sub_wxh), but when modeling we
> > > > consider the stores.
> > > 
> > > Because when modeling they are still there.  There's no good way around 
> > > this.
> > > 
> > 
> > I noticed the stores get eliminated during FRE.  Can we consider running FRE
> > once just before SLP? a bad idea due to compilation time?
> 
> Yeah, we already run FRE a lot and it is one of the more expensive passes.
> 
> Note there's one point we could do better which is the embedded SESE FRE
> run from cunroll which is only run before we consider peeling an outer loop
> and thus not for the outermost unrolled/peeled code (but the question would
> be from where / up to what to apply FRE to).  On x86_64 this would apply to
> the unvectorized but then unrolled outer loop from pixel_sub_wxh which feeds
> quite bad IL to the SLP pass (but that shouldn't matter too much, maybe it
> matters for costing though).

Thanks for the explanation! I'll look at it after checking 2). IIUC, the
advantage to eliminate stores here looks able to get those things which is fed
to stores and stores' consumers bundled, then get more things SLP-ed if
available?

> 
> I think I looked at this or a related testcase some time ago and split out
> some PRs (can't find those right now).  For example we are not considering
> to simplify
> 

> 
> the load permutations suggest that splitting the group into 4-lane pieces
> would avoid doing permutes but then that would require target support
> for V4QI and V4HI vectors.  At least the loads could be considered
> to be vectorized with strided-SLP, yielding 'int' loads and a vector
> build from 4 ints.  I'd need to analyze why we do not consider this.

Good idea! Curious that is there some port where int load can not work well on
1-byte aligned address like trap?

[Bug tree-optimization/97081] wrong code for rotate vectorization (x86 target)

[igor at tachyum dot com]

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

--- Comment #1 from Igor Shevlyakov  ---
vect_recog_rotate_pattern()

seems to be the culprit

[Bug tree-optimization/97081] New: wrong code for rotate vectorization (x86 target)

[igor at tachyum dot com]

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

Bug ID: 97081
   Summary: wrong code for rotate vectorization (x86 target)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor at tachyum dot com
  Target Milestone: ---

Created attachment 49231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49231=edit
testcase

incorrectly calculates left shift amount when breaking (a r>> sh) into (a <<
sh_l) | (a >> sh_r)

shr is calculated as (-sh & 31) while should be (-sh & 63)


.file   "t.c"
.text
.p2align 4
.globl  exec_VRORudi_i
.type   exec_VRORudi_i, @function
exec_VRORudi_i:
.LFB0:
.cfi_startproc
endbr64
andl$63, %edx
movdqu  (%rsi), %xmm1
movl%edx, %eax
movd%edx, %xmm0
negl%eax
movdqa  %xmm1, %xmm3
movl%eax, %ecx
psrlq   %xmm0, %xmm3
andl$31, %ecx
movq%rcx, %xmm2
psllq   %xmm2, %xmm1
por %xmm3, %xmm1
movups  %xmm1, (%rdi)
movdqu  16(%rsi), %xmm1
movdqa  %xmm1, %xmm3
psrlq   %xmm0, %xmm1
psllq   %xmm2, %xmm3
por %xmm3, %xmm1
movups  %xmm1, 16(%rdi)
ret
.cfi_endproc

[Bug tree-optimization/97075] [11 regression] powerpc64 vector tests fails after r11-3230

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org
   Last reconfirmed||2020-09-17

--- Comment #1 from Kewen Lin  ---
I'll take a look at this.

[Bug libbacktrace/97080] [11 regression] Errors in libbacktrace after r11-3196

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Ian Lance Taylor  ---
Thanks, should be fixed now.

[Bug libbacktrace/97080] [11 regression] Errors in libbacktrace after r11-3196

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:90c254565122fa5c02114698ce35ac46679c03b0

commit r11-3248-g90c254565122fa5c02114698ce35ac46679c03b0
Author: Ian Lance Taylor 
Date:   Wed Sep 16 17:03:52 2020 -0700

libbacktrace: use ELF symbol table if no debug info available

PR libbacktrace/97080
* fileline.c (backtrace_syminfo_to_full_callback): New function.
(backtrace_syminfo_to_full_error_callback): New function.
* elf.c (elf_nodebug): Call syminfo_fn if possible.
* internal.h (struct backtrace_call_full): Define.
(backtrace_syminfo_to_full_callback): Declare.
(backtrace_syminfo_to_full_error_callback): Declare.
* mtest.c (f3): Only check all[i] if data.index permits.

[Bug analyzer/96653] -Wanalyzer-too-complex on very large switch statement

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
(which is within my rough goal of -fanalyzer doubling your compile time in
return for more warnings)

[Bug analyzer/96653] -Wanalyzer-too-complex on very large switch statement

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
With a release build:

$ hyperfine -L ana "","-fanalyzer" "./xgcc -B. -S pr96653.c -O1 {ana}"
Benchmark #1: ./xgcc -B. -S pr96653.c -O1 
  Time (mean ± σ): 127.3 ms ±   0.7 ms[User: 111.3 ms, System: 14.8 ms]
  Range (min … max):   126.1 ms … 128.7 ms23 runs

Benchmark #2: ./xgcc -B. -S pr96653.c -O1 -fanalyzer
  Time (mean ± σ): 246.3 ms ±   1.2 ms[User: 221.9 ms, System: 22.6 ms]
  Range (min … max):   244.5 ms … 248.7 ms12 runs

Summary
  './xgcc -B. -S pr96653.c -O1 ' ran
1.94 ± 0.01 times faster than './xgcc -B. -S pr96653.c -O1 -fanalyzer'

[Bug analyzer/96653] -Wanalyzer-too-complex on very large switch statement

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
> The compile-time/memory blow-up should be fixed by above commit.
> 
> However, I had to add -Wno-analyzer-too-complex to the testcase.  Keeping
> this bug open to track that (updating bug title accordingly).

This is fixed by r11-3247-gfd111c419d146ee47c7df9a36a535e8d843d4802; marking as
resolved.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Also, I can probably cook up a more minimal reproducer - but it would be good
to track down the state-explosion issues: scaling up -fanalyzer to deal
effectively with real-world C code is a goal for me for GCC 11.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-09-16
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from David Malcolm  ---
(In reply to CVS Commits from comment #1)
> The master branch has been updated by David Malcolm :
> 
> https://gcc.gnu.org/g:b28491dc2d79763ecbff4f0b9f1f3e48a443be1d
> 
> commit r11-3245-gb28491dc2d79763ecbff4f0b9f1f3e48a443be1d
> Author: David Malcolm 
> Date:   Tue Aug 18 18:52:17 2020 -0400
> 
> analyzer: bulk merger/processing of runs of nodes at CFG join points

[...]

> The patch fixes a state explosion seen in bzip2.c seen when attempting
> to reproduce PR analyzer/95188, in a switch statement in a loop for
> argument parsing.  With this patch, the analyzer successfully
> consolidates the state after the argument parsing to a single exploded
> node.

[...]

As noted above, I'm currently not able to reproduce this bug.  My guess is that
there was a pre-existing failure to fully explore the program and we previously
were lucky to explore enough to trigger the bug, but at some point (probably
the reimplementation of state tracking of
r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d) the bug is now in the
unexplored section.

The above commit from comment #1 will help, but I'm still not able to reproduce
the bug.  Marking as ASSIGNED since the state-explosion issue ought to be
fixed, and I can at least reproduce that.

[Bug analyzer/96616] pr93032-mztools.c -Wanalyzer-too-complex warnings on some targets

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
(In reply to David Malcolm from comment #5)
> Updating title to reflect that the remaining work is fixing the
> -Wanalyzer-too-complex warnings that are showing up on some targets (at
> least arm, aarch64, and powerpc64, but not x86_64 as far as I can tell).

I believe that this was fixed by
r11-3245-gb28491dc2d79763ecbff4f0b9f1f3e48a443be1d
(aka "analyzer: bulk merger/processing of runs of nodes at CFG join points").

Marking this one as resolved.

[Bug analyzer/96653] -Wanalyzer-too-complex on very large switch statement

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:fd111c419d146ee47c7df9a36a535e8d843d4802

commit r11-3247-gfd111c419d146ee47c7df9a36a535e8d843d4802
Author: David Malcolm 
Date:   Wed Sep 16 09:22:06 2020 -0400

analyzer: fix state explosions due to SCC bug

Debugging the state explosion of the very large switch statement in
gcc.dg/analyzer/pr96653.c showed that the worklist was failing to
order the exploded nodes correctly; the in-edges at the join point
after the switch were not getting processed together, but were instead
being rocessed in smaller batches, bloating the exploded graph until the
per-point limit was reached.

The root cause turned out to be a bug in creating the strongly-connected
components for the supergraph: the code was considering interprocedural
edges as well as intraprocedural edges, leading to unpredictable
misorderings of the SCC and worklist, leading to bloating of the
exploded graph.

This patch fixes the SCC creation so it only considers intraprocedural
edges within the supergraph.  It also tweaks worklist::key_t::cmp to
give higher precedence to call_string over differences within a
supernode, since enodes with different call_strings can't be merges.
In practise, none of my test cases were affected by this latter change,
though it seems to be the right thing to do.

With this patch, the very large switch statement in
gcc.dg/analyzer/pr96653.c is handled in a single call to
exploded_graph::maybe_process_run_of_before_supernode_enodes:
   merged 358 in-enodes into 2 out-enode(s) at SN: 402
and that testcase no longer hits the per-program-point limits.

gcc/analyzer/ChangeLog:
* engine.cc (strongly_connected_components::strong_connect): Only
consider intraprocedural edges when creating SCCs.
(worklist::key_t::cmp): Add comment.  Treat call_string
differences as more important than differences of program_point
within a supernode.

gcc/testsuite/ChangeLog:
PR analyzer/96653
* gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c: Update
expected number of exploded nodes.
* gcc.dg/analyzer/malloc-vs-local-1a.c: Update expected number
of exploded nodes.
* gcc.dg/analyzer/pr96653.c: Remove -Wno-analyzer-too-complex.

[Bug analyzer/96616] pr93032-mztools.c -Wanalyzer-too-complex warnings on some targets

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:b28491dc2d79763ecbff4f0b9f1f3e48a443be1d

commit r11-3245-gb28491dc2d79763ecbff4f0b9f1f3e48a443be1d
Author: David Malcolm 
Date:   Tue Aug 18 18:52:17 2020 -0400

analyzer: bulk merger/processing of runs of nodes at CFG join points

Prior to this patch the analyzer worklist considered only one node or
two nodes at a time, processing and/or merging state individually or
pairwise.

This could lead to explosions of merger nodes at CFG join points,
especially after switch statements, which could have large numbers
of in-edges, and thus large numbers of merger exploded_nodes could
be created, exceeding the per-point limit and thus stopping analysis
with -Wanalyzer-too-complex.

This patch special-cases the handling for runs of consecutive
nodes in the worklist at a CFG join point, processing and merging
them all together.

The patch fixes a state explosion seen in bzip2.c seen when attempting
to reproduce PR analyzer/95188, in a switch statement in a loop for
argument parsing.  With this patch, the analyzer successfully
consolidates the state after the argument parsing to a single exploded
node.

In gcc.dg/analyzer/pr96653.c there is a switch statement with over 300
cases which leads to hitting the per-point limit.  With this patch
the consolidation code doesn't manage to merge all of them due to other
worklist-ordering bugs, and it still hits the per-point limits, but it
does manage some very long consolidations:
  merged 2 in-enodes into 2 out-enode(s) at SN: 403
  merged 2 in-enodes into 2 out-enode(s) at SN: 403
  merged 2 in-enodes into 1 out-enode(s) at SN: 11
  merged 29 in-enodes into 1 out-enode(s) at SN: 35
  merged 6 in-enodes into 1 out-enode(s) at SN: 41
  merged 31 in-enodes into 1 out-enode(s) at SN: 35
and with a followup patch to fix an SCC issue it manages:
  merged 358 in-enodes into 2 out-enode(s) at SN: 402

The patch appears to fix the failure on non-x86_64 of:
  gcc.dg/analyzer/pr93032-mztools.c (test for excess errors)
which is PR analyzer/96616.

Unfortunately, the patch introduces a memory leak false positive in
gcc.dg/analyzer/pr94851-1.c, but this appears to be a pre-existing bug
that was hidden by state-merging failures.

gcc/analyzer/ChangeLog:
* engine.cc (exploded_node::dump_dot): Show STATUS_BULK_MERGED.
(exploded_graph::process_worklist): Call
maybe_process_run_of_before_supernode_enodes.
(exploded_graph::maybe_process_run_of_before_supernode_enodes):
New.
(exploded_graph_annotator::print_enode): Show STATUS_BULK_MERGED.
* exploded-graph.h (enum exploded_node::status): Add
STATUS_BULK_MERGED.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/bzip2-arg-parse-1.c: New test.
* gcc.dg/analyzer/loop-n-down-to-1-by-1.c: Remove xfail.
* gcc.dg/analyzer/pr94851-1.c: Add xfail.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:b28491dc2d79763ecbff4f0b9f1f3e48a443be1d

commit r11-3245-gb28491dc2d79763ecbff4f0b9f1f3e48a443be1d
Author: David Malcolm 
Date:   Tue Aug 18 18:52:17 2020 -0400

analyzer: bulk merger/processing of runs of nodes at CFG join points

Prior to this patch the analyzer worklist considered only one node or
two nodes at a time, processing and/or merging state individually or
pairwise.

This could lead to explosions of merger nodes at CFG join points,
especially after switch statements, which could have large numbers
of in-edges, and thus large numbers of merger exploded_nodes could
be created, exceeding the per-point limit and thus stopping analysis
with -Wanalyzer-too-complex.

This patch special-cases the handling for runs of consecutive
nodes in the worklist at a CFG join point, processing and merging
them all together.

The patch fixes a state explosion seen in bzip2.c seen when attempting
to reproduce PR analyzer/95188, in a switch statement in a loop for
argument parsing.  With this patch, the analyzer successfully
consolidates the state after the argument parsing to a single exploded
node.

In gcc.dg/analyzer/pr96653.c there is a switch statement with over 300
cases which leads to hitting the per-point limit.  With this patch
the consolidation code doesn't manage to merge all of them due to other
worklist-ordering bugs, and it still hits the per-point limits, but it
does manage some very long consolidations:
  merged 2 in-enodes into 2 out-enode(s) at SN: 403
  merged 2 in-enodes into 2 out-enode(s) at SN: 403
  merged 2 in-enodes into 1 out-enode(s) at SN: 11
  merged 29 in-enodes into 1 out-enode(s) at SN: 35
  merged 6 in-enodes into 1 out-enode(s) at SN: 41
  merged 31 in-enodes into 1 out-enode(s) at SN: 35
and with a followup patch to fix an SCC issue it manages:
  merged 358 in-enodes into 2 out-enode(s) at SN: 402

The patch appears to fix the failure on non-x86_64 of:
  gcc.dg/analyzer/pr93032-mztools.c (test for excess errors)
which is PR analyzer/96616.

Unfortunately, the patch introduces a memory leak false positive in
gcc.dg/analyzer/pr94851-1.c, but this appears to be a pre-existing bug
that was hidden by state-merging failures.

gcc/analyzer/ChangeLog:
* engine.cc (exploded_node::dump_dot): Show STATUS_BULK_MERGED.
(exploded_graph::process_worklist): Call
maybe_process_run_of_before_supernode_enodes.
(exploded_graph::maybe_process_run_of_before_supernode_enodes):
New.
(exploded_graph_annotator::print_enode): Show STATUS_BULK_MERGED.
* exploded-graph.h (enum exploded_node::status): Add
STATUS_BULK_MERGED.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/bzip2-arg-parse-1.c: New test.
* gcc.dg/analyzer/loop-n-down-to-1-by-1.c: Remove xfail.
* gcc.dg/analyzer/pr94851-1.c: Add xfail.

[Bug libbacktrace/97080] New: [11 regression] Errors in libbacktrace after r11-3196

[seurer at gcc dot gnu.org]

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

Bug ID: 97080
   Summary: [11 regression] Errors in libbacktrace after r11-3196
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---

g:05f40bc4c116ba48843728201bc7290a5e518598, r11-3196

FAIL: backtrace_full noinline
FAIL: backtrace_simple noinline
FAIL: mtest_minidebug
FAIL: mtest_minidebug

There's not much detail in the log as to how these are run or what went wrong:

>From libbacktrace/test-suite.log:

=
   package-unused version-unused: ./test-suite.log
=

# TOTAL: 36
# PASS:  35
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: mtest_minidebug
=

test1: [0]: syminfo did not find name
test1: [1]: syminfo did not find name
test1: [2]: syminfo did not find name
test1: [0]: missing function name
test1: [1]: missing function name
test1: [2]: missing function name
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
FAIL: backtrace_full noinline
FAIL: backtrace_simple noinline
PASS: backtrace_syminfo variable
FAIL mtest_minidebug (exit status: 1)

[Bug tree-optimization/97079] New: [11 Regression] aarch64, SVE: ICE in SLP recognizer since r11-3148-g8d3767c30240c901a493d82d9d20f306b2f0152d

[acoplan at gcc dot gnu.org]

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

Bug ID: 97079
   Summary: [11 Regression] aarch64, SVE: ICE in SLP recognizer
since
r11-3148-g8d3767c30240c901a493d82d9d20f306b2f0152d
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

Since r11-3148-g8d3767c30240c901a493d82d9d20f306b2f0152d, AArch64 GCC ICEs with
-O2 -ftree-vectorize -march=armv8.2-a+sve on the following input:

void g(void);

int a[8][3];
int b;
void c(void) {
  int d[] = {7, 3};
  int *e = a[0];
  int f;
  b = 0;
  for (; b < 8; b++) {
f = 0;
for (; f < 3; f++)
  a[b][f] = 0;
  }
  g();
  *e = (long)d;
}

To reproduce:

$ aarch64-none-elf-gcc -c -march=armv8.2-a+sve -O2 -ftree-vectorize test.c
during GIMPLE pass: slp
test.c: In function 'c':
test.c:5:6: internal compiler error: Segmentation fault
5 | void c(void) {
  |  ^
0xd628ff crash_signal
/home/alecop01/toolchain/src/gcc/gcc/toplev.c:327
0x1a012ad contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/tree.h:3408
0x1a012ad vect_recog_mask_conversion_pattern
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:4262
0x19faf66 vect_pattern_recog_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:5339
0x1a0351f vect_pattern_recog(vec_info*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:5495
0x10a010e vect_slp_analyze_bb_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.c:3545
0x10a010e vect_slp_region
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.c:3648
0x10a010e vect_slp_bb(basic_block_def*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.c:3804
0x10a4888 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/97078] New: [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store

[jsm28 at gcc dot gnu.org]

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

Bug ID: 97078
   Summary: [11 Regression] ICE in set_rtl building glibc tests
with -ffloat-store
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: alpha*-*-* s390*-*-* sparc*-*-*

Created attachment 49230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49230=edit
preprocessed source

Compile the attached test (from the glibc testsuite) for alpha-linux-gnu with
-S -O2 -ffloat-store (you may need -mlong-double-128 as well depending on the
configuration of your cross compiler).  The following ICE was introduced by
commit a7d8dcdf2f3cf9a801e655f2eec3967a3a3ba666, "Fix dangling references in
thunks at -O0" (bisection done and preprocessed source generated for alpha; the
same ICE also appears building the glibc testsuite for s390 and 32-bit sparc,
likely with the same cause).

during RTL pass: expand
In file included from
/scratch/jmyers/glibc/many11/build/glibcs/alpha-linux-gnu/glibc/math/libm-test-support-ldouble.c:2:
./libm-test-support.c: In function 'print_float':
./libm-test-support.c:259:1: internal compiler error: in set_rtl, at
cfgexpand.c:199
0x734169 set_rtl
/scratch/jmyers/glibc/many11/src/gcc/gcc/cfgexpand.c:178
0x73a239 set_parm_rtl(tree_node*, rtx_def*)
/scratch/jmyers/glibc/many11/src/gcc/gcc/cfgexpand.c:1312
0x8ce172 assign_parm_setup_reg
/scratch/jmyers/glibc/many11/src/gcc/gcc/function.c:3379
0x8d1846 assign_parms
/scratch/jmyers/glibc/many11/src/gcc/gcc/function.c:3685
0x8d1846 expand_function_start(tree_node*)
/scratch/jmyers/glibc/many11/src/gcc/gcc/function.c:5129
0x74728f execute
/scratch/jmyers/glibc/many11/src/gcc/gcc/cfgexpand.c:6464
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-16

--- Comment #9 from Tobias Burnus  ---
See also thread at:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-September/thread.html#554054

Mentioned there RELATED PR:
  PR 80053 – similar issue related to label with address taken

[Bug c++/97077] New: Missed loop unrolling with range for over initializer list

[bmburstein at gmail dot com]

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

Bug ID: 97077
   Summary: Missed loop unrolling with range for over initializer
list
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmburstein at gmail dot com
  Target Milestone: ---

In the following code:

#include 

int foo(int);

int main() {
for(int i=0; i<5; ++i) {
foo(i);
}
for(int i : {0,1,2,3,4}) {
foo(i);
}
}

The 2 loops should probably produce identical output. However, the output I see
here https://godbolt.org/z/z1We36 (using the trunk from 2020-09-15) shows that
the first loop (the traditional one) is indeed unrolled as expected, but the
second one is not.

[Bug c++/79501] member deduction guide not recognized

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Expanded test for the second problem:

// PR c++/79501
// { dg-do compile { target c++17 } }

struct X {
  template
  struct B { T t; };

  // In C++20, should work even without this guide (P1816).
  template B(T) -> B;

  void foo () {
B{1};
  }
};

void
fn ()
{
  X x;
  x.foo ();
}

[Bug c/96126] conflicting attribute section accepted on redeclaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Martin Sebor  ---
Patch committed in r11-3239.

[Bug c/78666] conflicting attribute alloc_size accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 7.3.0, 8.2.0, 9.1.0
   Target Milestone|--- |11.0
 Resolution|--- |FIXED
  Known to work||11.0
 Status|NEW |RESOLVED

--- Comment #11 from Martin Sebor  ---
Fixed for GCC 11 in r11-3239.

[Bug c/78666] conflicting attribute alloc_size accepted

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:71ad0b5dde449ee1f6b755a99f5c52152e375835

commit r11-3239-g71ad0b5dde449ee1f6b755a99f5c52152e375835
Author: Martin Sebor 
Date:   Wed Sep 16 14:04:01 2020 -0600

Detect conflicts between incompatible uses of the same attribute (PR
c/78666).

Resolves:
PR c/78666 - conflicting attribute alloc_size accepted
PR c/96126 - conflicting attribute section accepted on redeclaration

gcc/c-family/ChangeLog:

PR c/78666
PR c/96126
* c-attribs.c (validate_attr_args): New function.
(validate_attr_arg): Same.
(handle_section_attribute): Call it.  Introduce a local variable.
(handle_alloc_size_attribute):  Same.
(handle_alloc_align_attribute): Same.

gcc/testsuite/ChangeLog:

PR c/78666
PR c/96126
* gcc.dg/attr-alloc_align-5.c: New test.
* gcc.dg/attr-alloc_size-13.c: New test.
* gcc.dg/attr-section.c: New test.
* c-c++-common/builtin-has-attribute-3.c: Add xfails due to
expected
warnings to be cleaned up.

[Bug c/96126] conflicting attribute section accepted on redeclaration

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:71ad0b5dde449ee1f6b755a99f5c52152e375835

commit r11-3239-g71ad0b5dde449ee1f6b755a99f5c52152e375835
Author: Martin Sebor 
Date:   Wed Sep 16 14:04:01 2020 -0600

Detect conflicts between incompatible uses of the same attribute (PR
c/78666).

Resolves:
PR c/78666 - conflicting attribute alloc_size accepted
PR c/96126 - conflicting attribute section accepted on redeclaration

gcc/c-family/ChangeLog:

PR c/78666
PR c/96126
* c-attribs.c (validate_attr_args): New function.
(validate_attr_arg): Same.
(handle_section_attribute): Call it.  Introduce a local variable.
(handle_alloc_size_attribute):  Same.
(handle_alloc_align_attribute): Same.

gcc/testsuite/ChangeLog:

PR c/78666
PR c/96126
* gcc.dg/attr-alloc_align-5.c: New test.
* gcc.dg/attr-alloc_size-13.c: New test.
* gcc.dg/attr-section.c: New test.
* c-c++-common/builtin-has-attribute-3.c: Add xfails due to
expected
warnings to be cleaned up.

[Bug c++/86403] Deduction guides not supported in local classes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Found a dup.

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

[Bug c++/79501] member deduction guide not recognized

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jeanmichael.celerier@gmail.
   ||com

--- Comment #2 from Marek Polacek  ---
*** Bug 86403 has been marked as a duplicate of this bug. ***

[Bug c++/79954] [C++17] Explicit deduction guide not rejected when defined outside inline namespace enclosing the type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Properly rejected now, fixed by r10-7236.

[Bug c++/83181] [C++17] Invalid deduction guide accepted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Still accepted.

[Bug c++/86346] internal compiler error related to duduction guides

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Fixed by r11-2748.

[Bug c++/86403] Deduction guides not supported in local classes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||mpolacek at gcc dot gnu.org
 Status|WAITING |NEW

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

[temp.deduct.guide]#3:
A deduction-guide shall be declared in the same scope as the corresponding
class template and, for a member class template, with the same access.

[Bug c++/88252] Deduction guide assume the constructor parameter is a forwarding reference if constructor defined outside class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-16
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug c++/94102] Variadic template deduction guide issue - error: 'In instantiation of'

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-09-16
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Fixed by r11-1571.

[Bug preprocessor/96935] [9/10 Regression] ICE in subspan, at input.h:69

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
   |subspan, at input.h:69  |subspan, at input.h:69

--- Comment #8 from Marek Polacek  ---
Fixed on trunk so far.

[Bug preprocessor/96935] [9/10/11 Regression] ICE in subspan, at input.h:69

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:31dd5cd6344bfbbe122fb512993b128e11236d35

commit r11-3238-g31dd5cd6344bfbbe122fb512993b128e11236d35
Author: Marek Polacek 
Date:   Wed Sep 16 09:27:29 2020 -0400

preprocessor: Fix ICE with too long line in fmtwarn [PR96935]

Here we ICE in char_span::subspan because the offset it gets is -1.
It's -1 because get_substring_ranges_for_loc gets a location whose
column was 0.  That only happens in testcases like the attached where
we're dealing with extremely long lines (at least 4065 chars it seems).
This does happen in practice, though, so it's not just a theoretical
problem (e.g. when building the SU2 suite).

Fixed by checking that the column get_substring_ranges_for_loc gets is
sane, akin to other checks in that function.

gcc/ChangeLog:

PR preprocessor/96935
* input.c (get_substring_ranges_for_loc): Return if start.column
is less than 1.

gcc/testsuite/ChangeLog:

PR preprocessor/96935
* gcc.dg/format/pr96935.c: New test.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org]

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

Bug 96295 Summary: [11 Regression] -Wmaybe-uninitialized warning for range 
operator with reference to an empty struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96295

   What|Removed |Added

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

[Bug tree-optimization/96295] [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r11-3237.

[Bug tree-optimization/96295] [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:8b75204b27cb2a296ac329d48918992b4053c61e

commit r11-3237-g8b75204b27cb2a296ac329d48918992b4053c61e
Author: Martin Sebor 
Date:   Wed Sep 16 13:23:31 2020 -0600

Work harder to avoid -Wuninitialized for objects of empty structs (PR
middle-end/96295).

Resolves:
PR middle-end/96295 - -Wmaybe-uninitialized warning for range operator with
reference to an empty struct

gcc/ChangeLog:

PR middle-end/96295
* tree-ssa-uninit.c (maybe_warn_operand): Work harder to avoid
warning for objects of empty structs

gcc/testsuite/ChangeLog:

PR middle-end/96295
* g++.dg/warn/Wuninitialized-11.C: New test.

[Bug c/95857] [8/9/10 Regression] Silencing an unused label warning with (void)& can make gcc segfault

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:62714a106493d0f1f22ff98c2dff2204f09cfcc0

commit r9-8903-g62714a106493d0f1f22ff98c2dff2204f09cfcc0
Author: Jakub Jelinek 
Date:   Thu Jul 2 11:38:20 2020 +0200

tree-cfg: Fix ICE with switch stmt to unreachable opt and forced labels
[PR95857]

The following testcase ICEs, because during the cfg cleanup, we see:
  switch (i$e_11)  [33.33%], case -3:  [33.33%], case
0:  [33.33%], case 2:  [33.33%]>
...
lab2:
  __builtin_unreachable ();
where lab2 is FORCED_LABEL.  The way it works, we go through the case
labels
and when we reach the first one that points to gimple_seq_unreachable*
basic block, we remove the edge (if any) from the switch bb to the bb
containing the label and bbs reachable only through that edge we've just
removed.  Once we do that, we must throw away all other cases that use
the same label (or some other labels from the same bb we've removed the
edge
to and the bb).  To avoid quadratic behavior, this is not done by walking
all remaining cases immediately before removing, but only when processing
them later.
For normal labels this works, fine, if the label is in a deleted bb, it
will
have NULL label_to_block and we handle that case, or, if the unreachable bb
has some other edge to it, only the edge will be removed and not the bb,
and again, find_edge will not find the edge and we only remove the case.
And if a label would be to some other block, that other block wouldn't have
been removed earlier because there would be still an edge from the switch
block.
Now, FORCED_LABEL (and I think DECL_NONLOCAL too) break this, because
those labels aren't removed, but instead moved to some surrounding basic
block.  So, when we later process those, when their gimple_seq_unreachable*
basic block is removed, label_to_block will return some unrelated block
(in the testcase the switch bb), so we decide to keep the case which
doesn't
seem to be unreachable, but we don't really have an edge from the switch
block to the block the label got moved to.

I thought first about punting in gimple_seq_unreachable* on
FORCED_LABEL/DECL_NONLOCAL labels, but that might penalize even code that
doesn't care, so this instead just makes sure that for
FORCED_LABEL/DECL_NONLOCAL labels that are being removed (and thus moved
randomly) we remember in a hash_set the fact that those labels should be
treated as removed for the purpose of the optimization, and later on
handle those labels that way.

2020-07-02  Jakub Jelinek  

PR tree-optimization/95857
* tree-cfg.c (group_case_labels_stmt): When removing an unreachable
base_bb, remember all forced and non-local labels on it and later
treat those as if they have NULL label_to_block.  Formatting fix.
Fix a comment typo.

* gcc.dg/pr95857.c: New test.

(cherry picked from commit 00f24f56732861d09a9716fa5b6b8a96c2289143)

[Bug target/96174] AVX-512 functions missing when compiled without optimization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:fdcb6dae610aba75e23c1fd2d31b491691e54091

commit r9-8904-gfdcb6dae610aba75e23c1fd2d31b491691e54091
Author: Jakub Jelinek 
Date:   Wed Jul 15 11:34:44 2020 +0200

fix _mm512_{,mask_}cmp*_p[ds]_mask at -O0 [PR96174]

The _mm512_{,mask_}cmp_p[ds]_mask and also _mm_{,mask_}cmp_s[ds]_mask
intrinsics have an argument which must have a constant passed to it
and so use an inline version only for ifdef __OPTIMIZE__ and have
a #define for -O0.  But the _mm512_{,mask_}cmp*_p[ds]_mask intrinsics
don't need a constant argument, they are essentially the first
set with the constant added to them implicitly based on the comparison
name, and so there is no #define version for them (correctly).
But their inline versions are defined in between the first and s[ds]
set and so inside of ifdef __OPTIMIZE__, which means that with -O0
they aren't defined at all.

This patch fixes that by moving those after the #ifdef __OPTIMIZE #else
use #define #endif block.

2020-07-15  Jakub Jelinek  

PR target/96174
* config/i386/avx512fintrin.h (_mm512_cmpeq_pd_mask,
_mm512_mask_cmpeq_pd_mask, _mm512_cmplt_pd_mask,
_mm512_mask_cmplt_pd_mask, _mm512_cmple_pd_mask,
_mm512_mask_cmple_pd_mask, _mm512_cmpunord_pd_mask,
_mm512_mask_cmpunord_pd_mask, _mm512_cmpneq_pd_mask,
_mm512_mask_cmpneq_pd_mask, _mm512_cmpnlt_pd_mask,
_mm512_mask_cmpnlt_pd_mask, _mm512_cmpnle_pd_mask,
_mm512_mask_cmpnle_pd_mask, _mm512_cmpord_pd_mask,
_mm512_mask_cmpord_pd_mask, _mm512_cmpeq_ps_mask,
_mm512_mask_cmpeq_ps_mask, _mm512_cmplt_ps_mask,
_mm512_mask_cmplt_ps_mask, _mm512_cmple_ps_mask,
_mm512_mask_cmple_ps_mask, _mm512_cmpunord_ps_mask,
_mm512_mask_cmpunord_ps_mask, _mm512_cmpneq_ps_mask,
_mm512_mask_cmpneq_ps_mask, _mm512_cmpnlt_ps_mask,
_mm512_mask_cmpnlt_ps_mask, _mm512_cmpnle_ps_mask,
_mm512_mask_cmpnle_ps_mask, _mm512_cmpord_ps_mask,
_mm512_mask_cmpord_ps_mask): Move outside of __OPTIMIZE__ guarded
section.

* gcc.target/i386/avx512f-vcmppd-3.c: New test.
* gcc.target/i386/avx512f-vcmpps-3.c: New test.

(cherry picked from commit 12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c)

[Bug middle-end/96459] OpenMP host teams reductions ignored

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:464ed899038051f80af1df7197e561f327502107

commit r9-8906-g464ed899038051f80af1df7197e561f327502107
Author: Jakub Jelinek 
Date:   Wed Aug 5 10:40:10 2020 +0200

openmp: Handle reduction clauses on host teams construct [PR96459]

As the new testcase shows, we weren't actually performing reductions on
host teams construct.  And fixing that revealed a flaw in the for-14.c
testcase.
The problem is that the tests perform also initialization and checking
around the
calls to the functions with the OpenMP constructs.  In that testcase, all
the
tests have been spawned from a teams construct but only the tested loops
were
distribute, which means the initialization and checking has been performed
redundantly and racily in each team.  Fixed by performing the
initialization
and checking outside of host teams and only do the calls to functions with
the tested constructs inside of host teams.

2020-08-05  Jakub Jelinek  

PR middle-end/96459
* omp-low.c (lower_omp_taskreg): Call lower_reduction_clauses even
in
for host teams.

* testsuite/libgomp.c/teams-3.c: New test.
* testsuite/libgomp.c-c++-common/for-2.h (OMPTEAMS): Define to
nothing
if not defined yet.
(N(test)): Use it before all N(f*) calls.
* testsuite/libgomp.c-c++-common/for-14.c (DO_PRAGMA, OMPTEAMS):
Define.
(main): Don't call all test_* functions from within
#pragma omp teams reduction(|:err), call them directly.

(cherry picked from commit 916c7a201a9a1dc94f2c056a773826a26d1daca9)

[Bug tree-optimization/96722] [8/9 Regression] Clobbers on NULL since r8-1519

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:acd97038dba34830520ed58915d509d21348b554

commit r9-8910-gacd97038dba34830520ed58915d509d21348b554
Author: Jakub Jelinek 
Date:   Tue Aug 25 13:49:40 2020 +0200

gimple: Ignore *0 = {CLOBBER} in path isolation [PR96722]

Clobbers of MEM_REF with NULL address are just fancy nops, something we
just
ignore and don't emit any code for it (ditto for other clobbers), they just
mark end of life on something, so we shouldn't infer from those that there
is some UB.

2020-08-25  Jakub Jelinek  

PR tree-optimization/96722
* gimple.c (infer_nonnull_range): Formatting fix.
(infer_nonnull_range_by_dereference): Return false for clobber
stmts.

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

(cherry picked from commit a5b15fcb954ba63d58f0daa700281aba33b5f24a)

[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:25542b27aa6a75ad0f7316c3767c957cce912fb7

commit r9-8912-g25542b27aa6a75ad0f7316c3767c957cce912fb7
Author: Jakub Jelinek 
Date:   Thu Sep 3 20:11:43 2020 +0200

c++: Disable -frounding-math during manifestly constant evaluation
[PR96862]

As discussed in the PR, fold-const.c punts on floating point constant
evaluation if the result is inexact and -frounding-math is turned on.
  /* Don't constant fold this floating point operation if the
 result may dependent upon the run-time rounding mode and
 flag_rounding_math is set, or if GCC's software emulation
 is unable to accurately represent the result.  */
  if ((flag_rounding_math
   || (MODE_COMPOSITE_P (mode) && !flag_unsafe_math_optimizations))
  && (inexact || !real_identical (, )))
return NULL_TREE;
Jonathan said that we should be evaluating them anyway, e.g. conceptually
as if they are done with the default rounding mode before user had a chance
to change that, and e.g. in C in initializers it is also ignored.
In fact, fold-const.c for C initializers turns off various other options:

/* Perform constant folding and related simplification of initializer
   expression EXPR.  These behave identically to "fold_buildN" but ignore
   potential run-time traps and exceptions that fold must preserve.  */

  int saved_signaling_nans = flag_signaling_nans;\
  int saved_trapping_math = flag_trapping_math;\
  int saved_rounding_math = flag_rounding_math;\
  int saved_trapv = flag_trapv;\
  int saved_folding_initializer = folding_initializer;\
  flag_signaling_nans = 0;\
  flag_trapping_math = 0;\
  flag_rounding_math = 0;\
  flag_trapv = 0;\
  folding_initializer = 1;

  flag_signaling_nans = saved_signaling_nans;\
  flag_trapping_math = saved_trapping_math;\
  flag_rounding_math = saved_rounding_math;\
  flag_trapv = saved_trapv;\
  folding_initializer = saved_folding_initializer;

So, shall cxx_eval_outermost_constant_expr instead turn off all those
options (then warning_sentinel wouldn't be the right thing to use, but
given
the 8 or how many return stmts in cxx_eval_outermost_constant_expr, we'd
need a RAII class for this.  Not sure about the folding_initializer, that
one is affecting complex multiplication and division constant evaluation
somehow.

2020-09-03  Jakub Jelinek  

PR c++/96862
* constexpr.c (cxx_eval_outermost_constant_expr): Temporarily
disable
flag_rounding_math during manifestly constant evaluation.

* g++.dg/cpp1z/constexpr-96862.C: New test.

(cherry picked from commit 6641d6d3fe79113f8d9f3ced355aea79bffda822)

[Bug c/96571] Bad "set but not used" warning with _Generic

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:d2472e513c6490b6e2832b07d08731df26e6dc06

commit r9-8909-gd2472e513c6490b6e2832b07d08731df26e6dc06
Author: Jakub Jelinek 
Date:   Tue Aug 18 07:51:58 2020 +0200

c: Fix -Wunused-but-set-* warning with _Generic [PR96571]

The following testcase shows various problems with -Wunused-but-set*
warnings and _Generic construct.  I think it is best to treat the selector
and the ignored expressions as (potentially) read, because when they are
parsed, the vars in there are already marked as TREE_USED.

2020-08-18  Jakub Jelinek  

PR c/96571
* c-parser.c (c_parser_generic_selection): Change match_found from
bool
to int, holding index of the match.  Call mark_exp_read on the
selector
expression and on expressions other than the selected one.

* gcc.dg/Wunused-var-4.c: New test.

(cherry picked from commit 6d42cbe5ad7a7b46437f2576c9920e44dc14b386)

[Bug fortran/93553] ICE in scan_omp_1_op, at omp-low.c:3485

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:cdc1ed0ceaf7e520164c262358ea6bfe89ff027c

commit r9-8907-gcdc1ed0ceaf7e520164c262358ea6bfe89ff027c
Author: Jakub Jelinek 
Date:   Sat Aug 8 11:10:30 2020 +0200

openmp: Handle clauses with gimple sequences in
convert_nonlocal_omp_clauses properly

If the walk_body on the various sequences of reduction, lastprivate and/or
linear
clauses needs to create a temporary variable, we should declare that
variable
in that sequence rather than outside, where it would need to be privatized
inside of
the construct.

2020-08-08  Jakub Jelinek  

PR fortran/93553
* tree-nested.c (convert_nonlocal_omp_clauses): For
OMP_CLAUSE_REDUCTION, OMP_CLAUSE_LASTPRIVATE and OMP_CLAUSE_LINEAR
save info->new_local_var_chain around walks of the clause gimple
sequences and declare_vars if needed into the sequence.

2020-08-08  Tobias Burnus  

PR fortran/93553
* testsuite/libgomp.fortran/pr93553.f90: New test.

(cherry picked from commit 676b5525e8333005bdc1c596ed086f1da27a450f)

[Bug debug/96729] [11 Regression] slow compile with `-g -O3` since r11-39-gf9e1ea10e657af9f

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:ace10c37de7c2f9f2d419337dc1f173c01f7ec7d

commit r9-8911-gace10c37de7c2f9f2d419337dc1f173c01f7ec7d
Author: Jakub Jelinek 
Date:   Wed Aug 26 10:30:15 2020 +0200

dwarf2out: Fix up dwarf2out_next_real_insn caching [PR96729]

The addition of NOTE_INSN_BEGIN_STMT and NOTE_INSN_INLINE_ENTRY notes
reintroduced quadratic behavior into dwarf2out_var_location.
This function needs to know the next real instruction to which the var
location note applies, but the way final_scan_insn is called outside of
final.c main loop doesn't make it easy to look up the next real insn in
there (and for non-dwarf it is even useless).  Usually next real insn is
only a few notes away, but we can have hundreds of thousands of consecutive
notes only followed by a real insn.  dwarf2out_var_location to avoid the
quadratic behavior contains a cache, it remembers the next note and when it
is called again on that loc_note, it can use the previously computed
dwarf2out_next_real_insn result, rather than walking the insn chain once
again.  But, for NOTE_INSN_{BEGIN_STMT,INLINE_ENTRY} dwarf2out_var_location
is not called while the code puts into the cache those notes, which means
if
we have e.g. in the worst case NOTE_INSN_VAR_LOCATION and
NOTE_INSN_BEGIN_STMT notes alternating, the cache is not really used.

The following patch fixes it by looking up the next NOTE_INSN_VAR_LOCATION
if any.  While the lookup could be perhaps done together with looking for
the next real insn once (e.g. in dwarf2out_next_real_insn or its copy),
there are other dwarf2out_next_real_insn callers which don't need/want that
behavior and if there are more than two NOTE_INSN_VAR_LOCATION notes
followed by the same real insn, we need to do that "find next
NOTE_INSN_VAR_LOCATION" walk anyway.

On the testcase from the PR this patch speeds it 2.8times, from 0m0.674s
to 0m0.236s (why it takes for the reporter more than 60s is unknown).

2020-08-26  Jakub Jelinek  

PR debug/96729
* dwarf2out.c (dwarf2out_next_real_insn): Adjust function comment.
(dwarf2out_var_location): Look for next_note only if next_real is
non-NULL, in that case look for the first non-deleted
NOTE_INSN_VAR_LOCATION between loc_note and next_real, if any.

(cherry picked from commit ca1afa261d03c9343dff1208325f87d9ba69ec7a)

[Bug c/96545] ICE in get_atomic_generic_size

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:67627293b4fe2b230c6c32484752adb49f713315

commit r9-8908-g67627293b4fe2b230c6c32484752adb49f713315
Author: Jakub Jelinek 
Date:   Tue Aug 11 16:46:49 2020 +0200

c-family: Fix ICE in get_atomic_generic_size [PR96545]

As the testcase shows, we would ICE if the type of the first argument of
various atomic builtins was pointer to (non-void) incomplete type, we would
assume that TYPE_SIZE_UNIT must be non-NULL.  This patch diagnoses it
instead.  And also changes the TREE_CODE != INTEGER_CST check to
!tree_fits_uhwi_p, as we use tree_to_uhwi after this and at least in theory
the int could be too large and not fit.

2020-08-11  Jakub Jelinek  

PR c/96545
* c-common.c (get_atomic_generic_size): Require that first
argument's
type points to a complete type and use tree_fits_uhwi_p instead of
just INTEGER_CST TREE_CODE check for the TYPE_SIZE_UNIT.

* c-c++-common/pr96545.c: New test.

(cherry picked from commit 7840b4dc05539cf5575b3e9ff57ff5f6c3da2cae)

[Bug middle-end/96426] __builtin_convertvector ICE without lhs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:3f804f63cde54ff94f35abd00953b050a4c861c7

commit r9-8905-g3f804f63cde54ff94f35abd00953b050a4c861c7
Author: Jakub Jelinek 
Date:   Tue Aug 4 11:33:18 2020 +0200

veclower: Don't ICE on .VEC_CONVERT calls with no lhs [PR96426]

.VEC_CONVERT is a const internal call, so normally if the lhs is not used,
we'd DCE it far before getting to veclower, but with -O0 (or perhaps
-fno-tree-dce and some other -fno-* options) it can happen.
But as the internal fn needs the lhs to know the type to which the
conversion is done (and I think that is a reasonable representation, having
some magic another argument and having to create constants with that type
looks overkill to me), we just should DCE those calls ourselves.
During veclower, we can't really remove insns, as the callers would be
upset, so this just replaces it with a GIMPLE_NOP.

2020-08-04  Jakub Jelinek  

PR middle-end/96426
* tree-vect-generic.c (expand_vector_conversion): Replace
.VEC_CONVERT
call with GIMPLE_NOP if there is no lhs.

* gcc.c-torture/compile/pr96426.c: New test.

(cherry picked from commit 95f5a3258dd8a9584f2b10304f79441ef2d4c64c)

[Bug middle-end/95903] gcc 10: wrong code with -fwrapv

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:a1eb6e41832816b671d3b945014f7e8255167470

commit r9-8902-ga1eb6e41832816b671d3b945014f7e8255167470
Author: Jakub Jelinek 
Date:   Sat Jun 27 12:38:23 2020 +0200

c-family: Use TYPE_OVERFLOW_UNDEFINED instead of !TYPE_UNSIGNED in
pointer_sum [PR95903]

For lp64 targets and int off ... ptr[off + 1]
is lowered in pointer_sum to *(ptr + ((sizetype) off + (sizetype) 1)).
That is fine when signed integer wrapping is undefined (and is not done
already if off has unsigned type), but changes behavior for -fwrapv, where
overflow is well defined.  Runtime test could be:
int
main ()
{
  char *p = __builtin_malloc (0x1UL);
  if (!p) return 0;
  char *q = p + 0x8000UL;
  int o = __INT_MAX__;
  q[o + 1] = 1;
  if (q[-__INT_MAX__ - 1] != 1) __builtin_abort ();
  return 0;
}
with -fwrapv or so, not included in the testsuite because it requires 4GB
allocation (with some other test it would be enough to have something
slightly above 2GB, but still...).

2020-06-27  Jakub Jelinek  

PR middle-end/95903
gcc/c-family/
* c-common.c (pointer_int_sum): Use TYPE_OVERFLOW_UNDEFINED instead
of
!TYPE_UNSIGNED check to see if we can apply distributive law and
handle
smaller precision intop operands separately.
gcc/testsuite/
* c-c++-common/pr95903.c: New test.

(cherry picked from commit 37995960984ea346dd9d168d332cd6f7adf0)

[Bug middle-end/95810] Spurious UBSan warning when computing the opposite of the absolute value of INT_MIN

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:6ff6c02695c9b6ae6e840422080f6d10449577b8

commit r9-8901-g6ff6c02695c9b6ae6e840422080f6d10449577b8
Author: Jakub Jelinek 
Date:   Wed Jun 24 10:40:02 2020 +0200

fold-const: Fix A <= 0 ? A : -A folding [PR95810]

We folded A <= 0 ? A : -A into -ABS (A), which is for signed integral types
incorrect - can invoke on INT_MIN UB twice, once on ABS and once on its
negation.

The following patch fixes it by instead folding it to (type)-ABSU (A).

2020-06-24  Jakub Jelinek  

PR middle-end/95810
* fold-const.c (fold_cond_expr_with_comparison): Optimize
A <= 0 ? A : -A into (type)-absu(A) rather than -abs(A).

* gcc.dg/ubsan/pr95810.c: New test.

(cherry picked from commit 01e10b0ee77e82cb331414c569e02dc7a2c4999e)

[Bug c++/94951] [8/9 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:eca1dbea010ba4c18ccec90bacbad5d8ec72c09f

commit r9-8897-geca1dbea010ba4c18ccec90bacbad5d8ec72c09f
Author: Jakub Jelinek 
Date:   Wed May 6 23:38:13 2020 +0200

c++: Avoid strict_aliasing_warning on dependent types or expressions
[PR94951]

The following testcase gets a bogus warning during build_base_path,
when cp_build_indirect_ref* calls strict_aliasing_warning with a dependent
expression.  IMHO calling get_alias_set etc. on dependent types feels wrong
to me, we should just defer the warnings in those cases until instantiation
and only handle the cases where neither type nor expr are dependent.

2020-05-06  Jakub Jelinek  

PR c++/94951
* typeck.c (cp_strict_aliasing_warning): New function.
(cp_build_indirect_ref_1, build_reinterpret_cast_1): Use
it instead of strict_aliasing_warning.

* g++.dg/warn/Wstrict-aliasing-bogus-tmpl.C: New test.

(cherry picked from commit d82414ebcf7716ea24688510594a2c464a105908)

[Bug c++/95328] structured binding of template type inside template function is reported as "incomplete class type"

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:8efa945b308307fd9b0313705f5826a8499de405

commit r9-8900-g8efa945b308307fd9b0313705f5826a8499de405
Author: Jakub Jelinek 
Date:   Thu May 28 23:40:54 2020 +0200

c++: Try to complete decomp types [PR95328]

Two years ago Paolo has added the
  else if (processing_template_decl && !COMPLETE_TYPE_P (type))
pedwarn (...);
lines into cp_finish_decomp.  For type dependent decl we punt much earlier,
but even for types which aren't type dependent COMPLETE_TYPE_P might be
false as this testcase shows, so this patch tries to complete_type first
(the reason for writing it that way is that it is then followed by another
else if and if complete_type returns error_mark_node, we shouldn't report
anything, as a bug should have been reported already.

2020-05-28  Jakub Jelinek  

PR c++/95328
* decl.c (cp_finish_decomp): Call complete_type before checking
COMPLETE_TYPE_P.

* g++.dg/cpp1z/decomp53.C: New test.

(cherry picked from commit 3d8d5ddb539a5254c7ef83414377f4c74c7701d4)

[Bug c/94842] [8/9 Regression] internal compiler error: in gimplify_label_expr, at gimplify.c:2573

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:b66139a3ba159473432edabb983c62219a28590d

commit r9-8894-gb66139a3ba159473432edabb983c62219a28590d
Author: Jakub Jelinek 
Date:   Thu Apr 30 21:48:30 2020 +0200

c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

If there are _Atomic side-effects in the parameter declarations
of non-nested function, when they are parsed, current_function_decl is
NULL, the create_artificial_label created labels during build_atomic* are
then adjusted by store_parm_decls through set_labels_context_r callback.
Unfortunately, if such thing happens in nested function parameter
declarations, while those decls are parsed current_function_decl is the
parent function (and am not sure it is a good idea to temporarily clear it,
some code perhaps should be aware it is in a nested function, or it can
refer to variables from the parent function etc.) and that means
store_param_decls through set_labels_context_r doesn't adjust anything.
As those labels are emitted in the nested function body rather than in the
parent, I think it is ok to override the context in those cases.

2020-04-30  Jakub Jelinek  

PR c/94842
* c-decl.c (set_labels_context_r): In addition to context-less
LABEL_DECLs adjust also LABEL_DECLs with context equal to
parent function if any.
(store_parm_decls): Adjust comment.

* gcc.dg/pr94842.c: New test.

(cherry picked from commit 61fb8963c22d91152a9c46a3512307bef3b3d7f7)

[Bug target/94820] [8/9 Regression] pr94780.c fails with ICE on aarch64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:029d813ddf3595bfc93bfb4afad645dd033d21bf

commit r9-8889-g029d813ddf3595bfc93bfb4afad645dd033d21bf
Author: Haijian Zhang 
Date:   Wed Apr 29 10:23:11 2020 +0200

pr94780.c fails with ICE on aarch64 [PR94820]

This is a simple fix for pr94820.
The PR was only fixed on i386, the same error was also reported on aarch64.
This function, because it is sometimes called even outside of function
bodies, uses create_tmp_var_raw rather than create_tmp_var.
But in order for that to work, when first referenced, the VAR_DECLs need to
appear in a TARGET_EXPR so that during gimplification
the var gets the right DECL_CONTEXT and is added to local decls. Without
that, e.g. tree-nested.c ICEs on those.

2020-04-29  Haijian Zhang  

PR target/94820
* config/aarch64/aarch64-builtins.c
(aarch64_atomic_assign_expand_fenv): Use TARGET_EXPR instead of
MODIFY_EXPR for first assignment to fenv_cr, fenv_sr and
new_fenv_var.

(cherry picked from commit d81bc2af7d2700888e414eb5a322ff5f5b0df0bb)

[Bug target/94832] AVX512 scatter/gather macros lack parentheses when unoptimized

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:f97bf9657cecaaf8afd14b43e5ca9be294ab870c

commit r9-8891-gf97bf9657cecaaf8afd14b43e5ca9be294ab870c
Author: Jakub Jelinek 
Date:   Wed Apr 29 17:30:22 2020 +0200

x86: Fix -O0 intrinsic *gather*/*scatter* macros [PR94832]

As reported in the PR, while most intrinsic -O0 macro argument uses
are properly wrapped in ()s or used in context where having a complex
expression passed as the argument doesn't pose a problem (e.g. when
macro argument use is in between commas, or between ( and comma, or
between comma and ) etc.), especially the gather/scatter macros don't do
this and if one passes to some macro e.g. x + y as argument, the
corresponding inline function would do cast on the argument, but
the macro does (int) ARG, then it is (int) x + y rather than (int) (x + y).

The following patch fixes those issues in *gather/*scatter*; additionally,
the AVX2 macros were passing incorrect mask of e.g.
(__v2df)_mm_set1_pd((double)(long long int) -1)
which is IMHO equivalent to
(__v2df){-1.0, -1.0}
when it really wants to pass __v2df vector with all bits set.
I've used what the inline functions use for those cases.

2020-04-29  Jakub Jelinek  

PR target/94832
* config/i386/avx2intrin.h (_mm_mask_i32gather_pd,
_mm256_mask_i32gather_pd, _mm_mask_i64gather_pd,
_mm256_mask_i64gather_pd, _mm_mask_i32gather_ps,
_mm256_mask_i32gather_ps, _mm_mask_i64gather_ps,
_mm256_mask_i64gather_ps, _mm_i32gather_epi64,
_mm_mask_i32gather_epi64, _mm256_i32gather_epi64,
_mm256_mask_i32gather_epi64, _mm_i64gather_epi64,
_mm_mask_i64gather_epi64, _mm256_i64gather_epi64,
_mm256_mask_i64gather_epi64, _mm_i32gather_epi32,
_mm_mask_i32gather_epi32, _mm256_i32gather_epi32,
_mm256_mask_i32gather_epi32, _mm_i64gather_epi32,
_mm_mask_i64gather_epi32, _mm256_i64gather_epi32,
_mm256_mask_i64gather_epi32): Surround macro parameter uses with
parens.
(_mm_i32gather_pd, _mm256_i32gather_pd, _mm_i64gather_pd,
_mm256_i64gather_pd, _mm_i32gather_ps, _mm256_i32gather_ps,
_mm_i64gather_ps, _mm256_i64gather_ps): Likewise.  Don't use
as mask vector containing -1.0 or -1.0f elts, but instead vector
with all bits set using _mm*_cmpeq_p? with zero operands.
* config/i386/avx512fintrin.h (_mm512_i32gather_ps,
_mm512_mask_i32gather_ps, _mm512_i32gather_pd,
_mm512_mask_i32gather_pd, _mm512_i64gather_ps,
_mm512_mask_i64gather_ps, _mm512_i64gather_pd,
_mm512_mask_i64gather_pd, _mm512_i32gather_epi32,
_mm512_mask_i32gather_epi32, _mm512_i32gather_epi64,
_mm512_mask_i32gather_epi64, _mm512_i64gather_epi32,
_mm512_mask_i64gather_epi32, _mm512_i64gather_epi64,
_mm512_mask_i64gather_epi64, _mm512_i32scatter_ps,
_mm512_mask_i32scatter_ps, _mm512_i32scatter_pd,
_mm512_mask_i32scatter_pd, _mm512_i64scatter_ps,
_mm512_mask_i64scatter_ps, _mm512_i64scatter_pd,
_mm512_mask_i64scatter_pd, _mm512_i32scatter_epi32,
_mm512_mask_i32scatter_epi32, _mm512_i32scatter_epi64,
_mm512_mask_i32scatter_epi64, _mm512_i64scatter_epi32,
_mm512_mask_i64scatter_epi32, _mm512_i64scatter_epi64,
_mm512_mask_i64scatter_epi64): Surround macro parameter uses with
parens.
* config/i386/avx512pfintrin.h (_mm512_prefetch_i32gather_pd,
_mm512_prefetch_i32gather_ps, _mm512_mask_prefetch_i32gather_pd,
_mm512_mask_prefetch_i32gather_ps, _mm512_prefetch_i64gather_pd,
_mm512_prefetch_i64gather_ps, _mm512_mask_prefetch_i64gather_pd,
_mm512_mask_prefetch_i64gather_ps, _mm512_prefetch_i32scatter_pd,
_mm512_prefetch_i32scatter_ps, _mm512_mask_prefetch_i32scatter_pd,
_mm512_mask_prefetch_i32scatter_ps, _mm512_prefetch_i64scatter_pd,
_mm512_prefetch_i64scatter_ps, _mm512_mask_prefetch_i64scatter_pd,
_mm512_mask_prefetch_i64scatter_ps): Likewise.
* config/i386/avx512vlintrin.h (_mm256_mmask_i32gather_ps,
_mm_mmask_i32gather_ps, _mm256_mmask_i32gather_pd,
_mm_mmask_i32gather_pd, _mm256_mmask_i64gather_ps,
_mm_mmask_i64gather_ps, _mm256_mmask_i64gather_pd,
_mm_mmask_i64gather_pd, _mm256_mmask_i32gather_epi32,
_mm_mmask_i32gather_epi32, _mm256_mmask_i32gather_epi64,
_mm_mmask_i32gather_epi64, _mm256_mmask_i64gather_epi32,
_mm_mmask_i64gather_epi32, _mm256_mmask_i64gather_epi64,
_mm_mmask_i64gather_epi64, _mm256_i32scatter_ps,
  

[Bug target/94832] AVX512 scatter/gather macros lack parentheses when unoptimized

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:ccee0511abf6e0bb679fa6b4941e5a71a6521b12

commit r9-8892-gccee0511abf6e0bb679fa6b4941e5a71a6521b12
Author: Jakub Jelinek 
Date:   Wed Apr 29 17:31:26 2020 +0200

x86: Fix -O0 remaining intrinsic macros [PR94832]

A few other macros seem to suffer from the same issue.  What I've done was:
cat gcc/config/i386/*intrin.h | sed -e ':x /\\$/ { N; s/\\\n//g ; bx }' \
| grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]].*(' | sed 's/[ 
]\+/ /g' \
> /tmp/macros
and then looking for regexps:
)[a-zA-Z]
) [a-zA-Z]
[a-zA-Z][-+*/%]
[a-zA-Z] [-+*/%]
[-+*/%][a-zA-Z]
[-+*/%] [a-zA-Z]
in the resulting file.

2020-04-29  Jakub Jelinek  

PR target/94832
* config/i386/avx512bwintrin.h (_mm512_alignr_epi8,
_mm512_mask_alignr_epi8, _mm512_maskz_alignr_epi8): Wrap macro
operands
used in casts into parens.
* config/i386/avx512fintrin.h (_mm512_cvt_roundps_ph,
_mm512_cvtps_ph,
_mm512_mask_cvt_roundps_ph, _mm512_mask_cvtps_ph,
_mm512_maskz_cvt_roundps_ph, _mm512_maskz_cvtps_ph,
_mm512_mask_cmp_epi64_mask, _mm512_mask_cmp_epi32_mask,
_mm512_mask_cmp_epu64_mask, _mm512_mask_cmp_epu32_mask,
_mm512_mask_cmp_round_pd_mask, _mm512_mask_cmp_round_ps_mask,
_mm512_mask_cmp_pd_mask, _mm512_mask_cmp_ps_mask): Likewise.
* config/i386/avx512vlbwintrin.h (_mm256_mask_alignr_epi8,
_mm256_maskz_alignr_epi8, _mm_mask_alignr_epi8,
_mm_maskz_alignr_epi8,
_mm256_mask_cmp_epu8_mask): Likewise.
* config/i386/avx512vlintrin.h (_mm_mask_cvtps_ph,
_mm_maskz_cvtps_ph,
_mm256_mask_cvtps_ph, _mm256_maskz_cvtps_ph): Likewise.
* config/i386/f16cintrin.h (_mm_cvtps_ph, _mm256_cvtps_ph):
Likewise.
* config/i386/shaintrin.h (_mm_sha1rnds4_epu32): Likewise.

(cherry picked from commit 0c8217b16f307c3eedce8f22354714938613f701)

[Bug debug/95080] [10 Regression] -fcompare-debug failure (length) with -Og -fcse-follow-jumps -fnon-call-exceptions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:9d01f91514f627590adc408ac9a35a7153123119

commit r9-8898-g9d01f91514f627590adc408ac9a35a7153123119
Author: Jakub Jelinek 
Date:   Wed May 13 11:22:37 2020 +0200

Fix -fcompare-debug issue in purge_dead_edges [PR95080]

The following testcase fails with -fcompare-debug, the bug used to be
latent
since introduction of -fcompare-debug.
The loop at the start of purge_dead_edges behaves differently between -g0
and -g - if the last insn is a DEBUG_INSN, then it skips not just
DEBUG_INSNs but also NOTEs until it finds some other real insn (or bb
head),
while with -g0 it will not skip any NOTEs, so if we have
real_insn
note
debug_insn // not present with -g0
then with -g it might remove useless REG_EH_REGION from real_insn, while
with -g0 it will not.

Yet another option would be not skipping NOTE_P in the loop; I couldn't
find
in history rationale for why it is done.

2020-05-13  Jakub Jelinek  

PR debug/95080
* cfgrtl.c (purge_dead_edges): Skip over debug and note insns even
if the last insn is a note.

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

(cherry picked from commit 18edc195442291525e04f0fa4d5ef972155117da)

[Bug target/94826] [8/9 regression] ICE in gcc.dg/pr94780.c after r10-7999

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:540e1de23a70360fe9b626df8420be704d02e3a7

commit r9-8890-g540e1de23a70360fe9b626df8420be704d02e3a7
Author: Jakub Jelinek 
Date:   Wed Apr 29 15:55:39 2020 +0200

rs6000: Fix rs6000_atomic_assign_expand_fenv [PR94826]

This is the rs6000 version of the earlier committed x86, aarch64 and arm
fixes, as create_tmp_var_raw is used because the C FE can call this outside
of function context, we need to make sure the first references to those
VAR_DECLs are through a TARGET_EXPR, so that it gets gimple_add_tmp_var
marked in whatever function it gets expanded in.  Without that DECL_CONTEXT
is NULL and the vars aren't added as local decls of the containing
function.

2020-04-29  Jakub Jelinek  

PR target/94826
* config/rs6000/rs6000.c (rs6000_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to
fenv_var, fenv_clear and old_fenv variables.  For fenv_addr
take address of TARGET_EXPR of fenv_var with void_node initializer.
Formatting fixes.

(cherry picked from commit c7137fcc7cbc1f1f14f9fed75adcc6bd8f1d418c)

[Bug middle-end/95108] [9 Regression] ICE in tree_fits_uhwi_p, at tree.c:7292

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:b78ea59edbd354fed914d0f8eb78109db7316ce8

commit r9-8899-gb78ea59edbd354fed914d0f8eb78109db7316ce8
Author: Jakub Jelinek 
Date:   Thu May 14 09:51:05 2020 +0200

openmp: Fix placement of 2nd+ preparation statement for PHIs in simd clone
lowering [PR95108]

For normal stmts, preparation statements are inserted before the stmt, so
if we need multiple,
they are in the correct order, but for PHIs we emit them after labels in
the entry successor
bb, and we used to emit them in the reverse order that way.

2020-05-14  Jakub Jelinek  

PR middle-end/95108
* omp-simd-clone.c (struct modify_stmt_info): Add after_stmt
member.
(ipa_simd_modify_stmt_ops): For PHIs, only add before first stmt in
entry block if info->after_stmt is NULL, otherwise add after that
stmt
and update it after adding each stmt.
(ipa_simd_modify_function_body): Initialize info.after_stmt.

* gcc.dg/gomp/pr95108.c: New test.

(cherry picked from commit d0fb9ffc1b8f3b86bbdf0e915cec2136141b329b)

[Bug target/94950] [8/9 regression] ICE in gcc.dg/pr94780.c on riscv64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:79002374e81588fa1052c21f3d397cf9ad61f97d

commit r9-8896-g79002374e81588fa1052c21f3d397cf9ad61f97d
Author: Jakub Jelinek 
Date:   Wed May 6 09:40:33 2020 +0200

riscv: Fix up riscv_atomic_assign_expand_fenv [PR94950]

Similarly to the fixes on many other targets, riscv needs to use
TARGET_EXPR
to avoid having the create_tmp_var_raw temporaries without proper
DECL_CONTEXT
and not mentioned in local decls.

2020-05-06  Jakub Jelinek  

PR target/94950
* config/riscv/riscv-builtins.c (riscv_atomic_assign_expand_fenv):
Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to
old_flags.

(cherry picked from commit 5454a13add37fa6a8eedbf9d2f6bdc63a7825e2c)

[Bug rtl-optimization/94873] [8/9 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:0f717ba5975ab42e1176db4cd2384f1862872519

commit r9-8895-g0f717ba5975ab42e1176db4cd2384f1862872519
Author: Jakub Jelinek 
Date:   Wed May 6 09:31:19 2020 +0200

combine: Don't replace SET_SRC with REG_EQUAL note content if SET_SRC has
side-effects [PR94873]

There were some discussions about whether REG_EQUAL notes are valid on
insns with a single
set which contains auto-inc-dec side-effects in the SET_SRC and the
majority thinks that
it should be valid.  So, this patch fixes the combiner to punt in that
case, because otherwise
the auto-inc-dec side-effects from the SET_SRC are lost.

2020-05-06  Jakub Jelinek  

PR rtl-optimization/94873
* combine.c (combine_instructions): Don't optimize using REG_EQUAL
note if SET_SRC (set) has side-effects.

* gcc.dg/pr94873.c: New test.

(cherry picked from commit 8982e39b46b1e4a4b09022ddebd758b77ab73bac)

[Bug c++/94742] [8/9 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:e9dbd80b5e62a126ccb40970f0fb233f7e0ac3a6

commit r9-8885-ge9dbd80b5e62a126ccb40970f0fb233f7e0ac3a6
Author: Jakub Jelinek 
Date:   Sat Apr 25 00:11:35 2020 +0200

c++: Avoid -Wreturn-type warning if a template fn calls noreturn template
fn [PR94742]

finish_call_expr already has code to set
current_function_returns_abnormally
if a template calls a noreturn function, but on the following testcase it
doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case
we didn't check noreturn at all and just assumed it could return.

2020-04-25  Jakub Jelinek  

PR c++/94742
* semantics.c (finish_call_expr): When looking if all overloads
are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs.

* g++.dg/warn/Wreturn-type-12.C: New test.

(cherry picked from commit 4ff685a8705e8ee55fa86e75afb769ffb0975aea)

[Bug tree-optimization/94621] [9 Regression] GCC 9.2.1 segfaults when compiling file with -O3 since r9-5354

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:5b23b0c44692cc5e4d5e726f96497bff73094e7b

commit r9-8880-g5b23b0c44692cc5e4d5e726f96497bff73094e7b
Author: Jakub Jelinek 
Date:   Fri Apr 17 09:07:49 2020 +0200

inliner: Don't ICE on NULL TYPE_DOMAIN [PR94621]

When I've added the VLA tweak for OpenMP to avoid error_mark_nodes in the
IL in
type, I forgot that TYPE_DOMAIN could be NULL.  Furthermore, as an
optimization,
this patch checks the hopefully cheapest condition that is very likely
false
most of the time (enabled only during OpenMP handling) first.

2020-04-17  Jakub Jelinek  

PR tree-optimization/94621
* tree-inline.c (remap_type_1): Don't dereference NULL TYPE_DOMAIN.
Move id->adjust_array_error_bounds check first in the condition.

* gcc.c-torture/compile/pr94621.c: New test.

(cherry picked from commit c58cb6ac6891886b7aa01c440ac71a5e7cbcba97)

[Bug target/94710] [8/9 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:15e2cca37186c848d12f4a0bb9ebcb8be32ed9de

commit r9-8884-g15e2cca37186c848d12f4a0bb9ebcb8be32ed9de
Author: Jakub Jelinek 
Date:   Thu Apr 23 21:57:50 2020 +0200

Shortcut identity VEC_PERM expansion [PR94710]

This PR is about the rs6000 backend emitting wrong assembly
for whole vector shift by 0, and while I think it is desirable
to fix the backend, I don't see a point why the expander should
try to emit that, whole vector shift by 0 is identity, we can just
return the operand.

2020-04-23  Jakub Jelinek  

PR target/94710
* optabs.c (expand_vec_perm_const): For shift_amt const0_rtx
just return v2.

(cherry picked from commit f51be2fb8653f81092f8158a0f0527275f86603b)

[Bug tree-optimization/94809] [8/9 Regression] Different results between gcc-9 and gcc-6

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:522022361984407ebc84cde22bdbd199261d0443

commit r9--g522022361984407ebc84cde22bdbd199261d0443
Author: Jakub Jelinek 
Date:   Tue Apr 28 11:26:56 2020 +0200

tree: Fix up TREE_SIDE_EFFECTS on internal calls [PR94809]

On the following testcase, match.pd during GENERIC folding
changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y),
but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on
the call.  There is the process_call_operands function that non-internal
call creation calls and it is usable for internal calls too,
e.g. TREE_SIDE_EFFECTS is derived from checking whether the
call has side-effects (non-ECF_{CONST,PURE}; we have those for internal
calls) and from whether any of the arguments has TREE_SIDE_EFFECTS.

2020-04-28  Jakub Jelinek  

PR tree-optimization/94809
* tree.c (build_call_expr_internal_loc_array): Call
process_call_operands.

* gcc.c-torture/execute/pr94809.c: New test.

(cherry picked from commit 34f6b14ff33e0c64b3a4a1a2cd871df715d69151)

[Bug c/94755] [9/10/11 Regression] internal compiler error: Segmentation fault

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:d6a341eb9170fdb21aee235142d1f09e6dc5c5cd

commit r9-8886-gd6a341eb9170fdb21aee235142d1f09e6dc5c5cd
Author: Jakub Jelinek 
Date:   Mon Apr 27 16:05:03 2020 +0200

c-family: Fix ICE on __builtin_speculation_safe_value () [PR94755]

When this builtin has no parameters, speculation_safe_value_resolve_call
returns BUILT_IN_NONE, but resolve_overloaded_builtin uselessly
dereferences the first param just to return error_mark_node immediately.

The following patch rearranges it so that we only read the first parameter
if fncode is not BUILT_IN_NONE.

2020-04-27  Jakub Jelinek  

PR c/94755
* c-common.c (resolve_overloaded_builtin): Return error_mark_node
for
fncode == BUILT_IN_NONE before initialization of first_param.

* c-c++-common/pr94755.c: New test.

(cherry picked from commit 26d76be7af6db75aaab662f4e93395f4ff8acb38)

[Bug c/94705] [8/9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in diag_attr_exclusions, at attribs.c:396 since r8-5161

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:934ede34973909eb15b678f88395d83be01433e7

commit r9-8883-g934ede34973909eb15b678f88395d83be01433e7
Author: Jakub Jelinek 
Date:   Thu Apr 23 09:54:14 2020 +0200

attribs: Don't diagnose attribute exclusions during error recovery
[PR94705]

On the following testcase GCC ICEs, because last_decl is error_mark_node,
and diag_attr_exclusions assumes that if it is not NULL, it must be a decl.

The following patch just doesn't diagnose attribute exclusions if the
other decl is erroneous (and thus we've already reported errors for it).

2020-04-23  Jakub Jelinek  

PR c/94705
* attribs.c (decl_attribute): Don't diagnose attribute exclusions
if last_decl is error_mark_node or has such a TREE_TYPE.

* gcc.dg/pr94705.c: New test.

(cherry picked from commit e2a71816b4949225498bec37e947293aa7f5841b)

[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:1777beb6b12983b946dae4177470a319693fc0dc

commit r9-8887-g1777beb6b12983b946dae4177470a319693fc0dc
Author: Jakub Jelinek 
Date:   Mon Apr 27 21:14:52 2020 +0200

x86: Fix up ix86_atomic_assign_expand_fenv [PR94780]

This function, because it is sometimes called even outside of function
bodies, uses create_tmp_var_raw rather than create_tmp_var.  But in order
for that to work, when first referenced, the VAR_DECLs need to appear in a
TARGET_EXPR so that during gimplification the var gets the right
DECL_CONTEXT and is added to local decls.  Without that, e.g. tree-nested.c
ICEs on those.

2020-04-27  Jakub Jelinek  

PR target/94780
* config/i386/i386.c (ix86_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to
sw_var, exceptions_var, mxcsr_orig_var and mxcsr_mod_var.

* gcc.dg/pr94780.c: New test.

(cherry picked from commit 9b8e9006bb35641865358e2df4f6b3ae185b239a)

[Bug c/94641] -Wpadded -fsanitize=undefined together cause warning on main()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:1e4a928134e8f17bbcae99f2bac2bbce73ef6f73

commit r9-8882-g1e4a928134e8f17bbcae99f2bac2bbce73ef6f73
Author: Jakub Jelinek 
Date:   Tue Apr 21 17:06:31 2020 +0200

ubsan: Avoid -Wpadded warnings [PR94641]

-Wpadded warnings aren't really useful for the artificial types that GCC
lays out for ubsan.

2020-04-21  Jakub Jelinek  

PR c/94641
* stor-layout.c (place_field, finalize_record_size): Don't emit
-Wpadded warning on TYPE_ARTIFICIAL rli->t.
* ubsan.c (ubsan_get_type_descriptor_type,
ubsan_get_source_location_type, ubsan_create_data): Set
TYPE_ARTIFICIAL.
* asan.c (asan_global_struct): Likewise.

* c-c++-common/ubsan/pr94641.c: New test.

(cherry picked from commit 73f8e9dca5ff891ed19001b213fd1f6ce31417e3)

[Bug tree-optimization/94524] [8/9 Regression] wrong code with vector modulo operation since r0-117580

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:780b2ab071391495690141c61604370d6cf7af49

commit r9-8877-g780b2ab071391495690141c61604370d6cf7af49
Author: Jakub Jelinek 
Date:   Wed Apr 8 21:22:05 2020 +0200

vect: Fix up lowering of TRUNC_MOD_EXPR by negative constant [PR94524]

The first testcase below is miscompiled, because for the division part
of the lowering we canonicalize negative divisors to their absolute value
(similarly how expmed.c canonicalizes it), but when multiplying the
division
result back by the VECTOR_CST, we use the original constant, which can
contain negative divisors.

Fixed by computing ABS_EXPR of the VECTOR_CST.  Unfortunately, fold-const.c
doesn't support const_unop (ABS_EXPR, VECTOR_CST) and I think it is too
late
in GCC 10 cycle to add it now.

Furthermore, while modulo by most negative constant happens to return the
right value, it does that only by invoking UB in the IL, because
we then expand division by that 1U+INT_MAX and say for INT_MIN % INT_MIN
compute the division as -1, and then multiply by INT_MIN, which is signed
integer overflow.  We in theory could do the computation in unsigned vector
types instead, but is it worth bothering.  People that are doing % INT_MIN
are either testing for standard conformance, or doing something wrong.
So, I've also added punting on % INT_MIN, both in vect lowering and vect
pattern recognition (we punt already for / INT_MIN).

2020-04-08  Jakub Jelinek  

PR tree-optimization/94524
* tree-vect-generic.c (expand_vector_divmod): If any elt of op1 is
negative for signed TRUNC_MOD_EXPR, multiply with absolute value of
op1 rather than op1 itself at the end.  Punt for signed modulo by
most negative constant.
* tree-vect-patterns.c (vect_recog_divmod_pattern): Punt for signed
modulo by most negative constant.

* gcc.c-torture/execute/pr94524-1.c: New test.
* gcc.c-torture/execute/pr94524-2.c: New test.

(cherry picked from commit f52eb4f988992d393c69ee4ab76f236dced80e36)

[Bug rtl-optimization/94618] [8/9 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:dea597314f4503228e23e887ddbb773cbf197093

commit r9-8881-gdea597314f4503228e23e887ddbb773cbf197093
Author: Jakub Jelinek 
Date:   Fri Apr 17 10:33:27 2020 +0200

Fix -fcompare-debug issue in delete_insn_and_edges [PR94618]

delete_insn_and_edges calls purge_dead_edges whenever deleting the last
insn
in a bb, whatever it is.  If it called it only for mandatory last insns
in the basic block (that may not be followed by DEBUG_INSNs, dunno if that
is control_flow_insn_p or something more complex), that wouldn't be a
problem, but as it calls it on any last insn and can actually do something
in the bb, if such an insn is followed by one more more DEBUG_INSNs and
nothing else in the same bb, we don't call purge_dead_edges with -g and do
call it with -g0.

On the testcase, there are two reg-to-reg moves with REG_EH_REGION notes
(previously memory accesses but simplified and yet not optimized), and the
second is followed by DEBUG_INSNs; the second move is delete_insn_and_edges
and after removing it, for -g0 purge_dead_edges removes the REG_EH_REGION
from the now last insn in the bb (the first reg-to-reg move), while
for -g it isn't called and things diverge from that quickly on.

Fixed by calling purdge_dead_edges even if we remove the last real insn
followed only by DEBUG_INSNs in the same bb.

2020-04-17  Jakub Jelinek  

PR rtl-optimization/94618
* cfgrtl.c (delete_insn_and_edges): Set purge not just when
insn is the BB_END of its block, but also when it is only followed
by DEBUG_INSNs in its block.

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

(cherry picked from commit c41884a09206be0e21cad7eea71b9754daa969d4)

[Bug c++/94571] Error: Expected comma or semicolon, comma found

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:a43981bb51fd0b8e68452faea6ec160cbea058e5

commit r9-8879-ga43981bb51fd0b8e68452faea6ec160cbea058e5
Author: Jakub Jelinek 
Date:   Thu Apr 16 07:19:57 2020 +0200

c++: Fix pasto in structured binding diagnostics [PR94571]

This snippet has been copied from the non-structured binding declaration
parsing later in the function, and while for non-structured bindings
it can be followed by comma or semicolon, structured bindings may be
only followed by semicolon.

Or, do we want to have a different message for the case when there is
a comma (and keep this corrected one only if there is something else)
that would explain better what is the bug (or add a fix-it hint)?
Marek said in the PR that clang++ reports
error: decomposition declaration must be the only declaration in its group

There is another thing Marek noted (though, something for different spot),
that diagnostic for auto x(1), [e,f] = test2; could also use a clearer
wording like the above (or a fix-it hint), but the question is if we should
assume [ after , as a structured binding or if we should do some tentative
parsing first to figure out if it looks like a structured binding.

2020-04-16  Jakub Jelinek  

PR c++/94571
* parser.c (cp_parser_simple_declaration): Fix up a pasto in
diagnostics.

* g++.dg/cpp1z/decomp51.C: New test.

(cherry picked from commit e4658c7dbbe88f742c96e5f58ee4a6d549d642ca)

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:489c62beef150f870d1755d3772bd2d0ce7344b4

commit r9-8878-g489c62beef150f870d1755d3772bd2d0ce7344b4
Author: Gustavo Romero 
Date:   Wed Apr 15 15:14:45 2020 +0200

selftest: Work around GCC 4.2 PR33916 bug by optimizing the ctor [PR89494]

GCC 4.2 due to PR33916 miscompiles temp_dump_context ctor, because it
doesn't
zero initialize the whole dump_context temporary on which it runs the
static
get method and during destruction of the temporary an uninitialized pointer
is deleted.

More recent GCC versions properly zero initialize it and ideally optimize
away
the construction/destruction of the temporary, as it isn't used for
anything,
but there is no reason to create the temporary, static member functions can
be called without an associated object.

2020-04-15  Gustavo Romero  

PR bootstrap/89494
* dumpfile.c (selftest::temp_dump_context::temp_dump_context):
Don't construct a dump_context temporary to call static method.

(cherry picked from commit c00568f376078129196740d83946d54dc5437401)

[Bug target/94438] [8/9 Regression] ICE: verify_gimple failed: position plus size exceeds size of referenced object in 'bit_field_ref' with -mavx512vbmi -mavx512vl

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:cb09410d3c61d325c64b17eabe9dfd1609cec1a6

commit r9-8876-gcb09410d3c61d325c64b17eabe9dfd1609cec1a6
Author: Jakub Jelinek 
Date:   Wed Apr 8 18:24:12 2020 +0200

i386: Don't use AVX512F integral masks for V*TImode [PR94438]

The ix86_get_mask_mode hook uses int mask for 512-bit vectors or
128/256-bit
vectors with AVX512VL (that is correct), and only for V*[SD][IF]mode if not
AVX512BW (also correct), but with AVX512BW it would stop checking the
elem_size altogether and pretend the hw has masking support for V*TImode
etc., which it doesn't.  That can lead to various ICEs later on.

2020-04-08  Jakub Jelinek  

PR target/94438
* config/i386/i386.c (ix86_get_mask_mode): Only use int mask for
elem_size
1, 2, 4 and 8.

* gcc.target/i386/avx512bw-pr94438.c: New test.
* gcc.target/i386/avx512vlbw-pr94438.c: New test.

(cherry picked from commit 8bf5faa9c463f0d53ffe835ba03d4502edfb959d)

[Bug sanitizer/94325] [8/9 Regression] UBSAN: "invalid vptr" false positive for virtual inheritance with -fno-sanitize-recover=all

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:175f052446556d32e887e1658a5a92c3c2f3a6f5

commit r9-8875-g175f052446556d32e887e1658a5a92c3c2f3a6f5
Author: Jakub Jelinek 
Date:   Wed Apr 8 15:30:16 2020 +0200

c++: Further fix for -fsanitize=vptr [PR94325]

For -fsanitize=vptr, we insert a NULL store into the vptr instead of just
adding a CLOBBER of this.  build_clobber_this makes the CLOBBER conditional
on in_charge (implicit) parameter whenever CLASSTYPE_VBASECLASSES, but when
adding this conditionalization to the -fsanitize=vptr code in PR87095,
I wanted it to catch some more cases when the class has
CLASSTYPE_VBASECLASSES,
but the vptr is still not shared with something else, otherwise the
sanitization would be less effective.
The following testcase shows that the chosen test that
CLASSTYPE_PRIMARY_BINFO
is non-NULL and has BINFO_VIRTUAL_P set wasn't sufficient,
the D class has still sizeof(D) == sizeof(void*) and thus contains just
a single vptr, but while in B::~B() this results in the vptr not being
cleared, in C::~C() this condition isn't true, as CLASSTYPE_PRIMARY_BINFO
in that case is B and is not BINFO_VIRTUAL_P, so it clears the vptr, but
the
D::~D() dtor after invoking C::~C() invokes A::~A() with an already cleared
vptr, which is then reported.
The following patch is just a shot in the dark, keep looking through
CLASSTYPE_PRIMARY_BINFO until we find BINFO_VIRTUAL_P, but it works on the
existing testcase as well as this new one.

2020-04-08  Jakub Jelinek  

PR c++/94325
* decl.c (begin_destructor_body): For CLASSTYPE_VBASECLASSES class
dtors, if CLASSTYPE_PRIMARY_BINFO is non-NULL, but not
BINFO_VIRTUAL_P,
look at CLASSTYPE_PRIMARY_BINFO of its BINFO_TYPE if it is not
BINFO_VIRTUAL_P, and so on.

* g++.dg/ubsan/vptr-15.C: New test.

(cherry picked from commit 4cf6b06cb5b02c053738e2975e3b7a4b3c577401)

[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Another, valid, where C++20 aggregate CTAD should work:

template
struct E {
  template 
  struct G {
T t;
  };

  void fn() { G{1}; }
};

void
g () {
  E e;
  e.fn ();
}

[Bug other/97076] New: clang-format file does not work for some C++11 code

[dmjpp at hotmail dot com]

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

Bug ID: 97076
   Summary: clang-format file does not work for some C++11 code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmjpp at hotmail dot com
  Target Milestone: ---

This is not a bug in GCC, but in the supporting files in contrib. The
clang-format file at the end has Standard: Cpp03. See
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/clang-format;h=7a4e96f64ca64a332ca5f945f08425c3a3e045c6;hb=HEAD#l150

I was writing a libstdc++ patch where I used the C++11 feature Unicode string
literals.

auto x = u"abc";

The clang format adds a space between the u and the quotation marks, making the
file invalid C++.

auto x = u "abc";

The fix is to change the standard to auto:

Standard: Auto

[Bug tree-optimization/97075] New: [11 regression] powerpc64 vector tests fails after r11-3230

[seurer at gcc dot gnu.org]

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

Bug ID: 97075
   Summary: [11 regression] powerpc64 vector tests fails after
r11-3230
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:052204fac580b21c967e57e6285d99a9828b8fac, r11-3230

FAIL: gcc.target/powerpc/p9-vec-length-epil-7.c scan-assembler-times
\\mstxvl\\M 10
FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-not \\mlxvx\\M
FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-not \\mstxvx\\M
FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-times \\mlxvl\\M
16
FAIL: gcc.target/powerpc/p9-vec-length-full-6.c scan-assembler-times
\\mstxvl\\M 16

For the second test case here is a diff of the assembler:

seurer@makalu-lp1:~/gcc/git/build/gcc-test$ diff
p9-vec-length-epil-7.s.r11-3229 p9-vec-length-epil-7.s.r11-3230
322,323c322,323
<   li 6,28
<   addis 7,2,.LC8@toc@ha
---
>   li 7,28
>   addis 8,2,.LC8@toc@ha
325d324
<   addis 10,2,.LANCHOR0@toc@ha
327,330c326,328
<   li 8,0
<   mtctr 6
<   addi 7,7,.LC8@toc@l
<   addi 10,10,.LANCHOR0@toc@l
---
>   li 10,0
>   mtctr 7
>   addi 8,8,.LC8@toc@l
333,335c331,333
<   lxv 32,0(7)
<   addis 7,2,.LANCHOR0+904@toc@ha
<   std 8,.LANCHOR0+904@toc@l(7)
---
>   lxv 32,0(8)
>   addis 8,2,.LANCHOR0+904@toc@ha
>   std 10,.LANCHOR0+904@toc@l(8)
343,349c341,343
<   addis 7,2,.LC9@toc@ha
<   li 8,8
<   addi 9,10,1360
<   addi 7,7,.LC9@toc@l
<   sldi 10,8,56
<   lxv 0,0(7)
<   stxvl 0,9,10
---
>   li 9,57
>   addis 10,2,.LANCHOR0+1360@toc@ha
>   std 9,.LANCHOR0+1360@toc@l(10)
368,369c362,363
<   li 6,28
<   addis 7,2,.LC8@toc@ha
---
>   li 7,28
>   addis 8,2,.LC8@toc@ha
371d364
<   addis 10,2,.LANCHOR0@toc@ha
373,376c366,368
<   li 8,0
<   mtctr 6
<   addi 7,7,.LC8@toc@l
<   addi 10,10,.LANCHOR0@toc@l
---
>   li 10,0
>   mtctr 7
>   addi 8,8,.LC8@toc@l
379,381c371,373
<   lxv 32,0(7)
<   addis 7,2,.LANCHOR0+1416@toc@ha
<   std 8,.LANCHOR0+1416@toc@l(7)
---
>   lxv 32,0(8)
>   addis 8,2,.LANCHOR0+1416@toc@ha
>   std 10,.LANCHOR0+1416@toc@l(8)
389,395c381,383
<   addis 7,2,.LC9@toc@ha
<   li 8,8
<   addi 9,10,1872
<   addi 7,7,.LC9@toc@l
<   sldi 10,8,56
<   lxv 0,0(7)
<   stxvl 0,9,10
---
>   li 9,57
>   addis 10,2,.LANCHOR0+1872@toc@ha
>   std 9,.LANCHOR0+1872@toc@l(10)
414,415c402,403
<   addis 6,2,.LC10@toc@ha
<   addis 7,2,.LC11@toc@ha
---
>   addis 6,2,.LC9@toc@ha
>   addis 7,2,.LC10@toc@ha
421,422c409,410
<   addi 6,6,.LC10@toc@l
<   addi 7,7,.LC11@toc@l
---
>   addi 6,6,.LC9@toc@l
>   addi 7,7,.LC10@toc@l
441c429
<   addis 7,2,.LC12@toc@ha
---
>   addis 7,2,.LC11@toc@ha
444c432
<   addi 7,7,.LC12@toc@l
---
>   addi 7,7,.LC11@toc@l
466,469c454,456
<   addis 7,2,.LC13@toc@ha
<   li 6,28
<   addis 8,2,.LC14@toc@ha
<   addis 10,2,.LANCHOR0@toc@ha
---
>   addis 8,2,.LC12@toc@ha
>   li 7,28
>   addis 10,2,.LC13@toc@ha
472,475c459,461
<   addi 7,7,.LC13@toc@l
<   mtctr 6
<   addi 8,8,.LC14@toc@l
<   addi 10,10,.LANCHOR0@toc@l
---
>   addi 8,8,.LC12@toc@l
>   mtctr 7
>   addi 10,10,.LC13@toc@l
477,480c463,466
<   lxv 0,0(7)
<   lxv 11,0(8)
<   addis 8,2,.LANCHOR0+2184@toc@ha
<   stfd 12,.LANCHOR0+2184@toc@l(8)
---
>   lxv 0,0(8)
>   lxv 11,0(10)
>   addis 10,2,.LANCHOR0+2184@toc@ha
>   stfd 12,.LANCHOR0+2184@toc@l(10)
488,494c474,477
<   addis 7,2,.LC15@toc@ha
<   li 8,8
<   addi 9,10,2640
<   addi 7,7,.LC15@toc@l
<   sldi 10,8,56
<   lxv 0,0(7)
<   stxvl 0,9,10
---
>   addis 9,2,.LC14@toc@ha
>   lfd 0,.LC14@toc@l(9)
>   addis 9,2,.LANCHOR0+2640@toc@ha
>   stfd 0,.LANCHOR0+2640@toc@l(9)

[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
The same ICE can be triggered with

template 
struct E {
  template 
  struct G {
T t;
G(T) { }
  };

  void fn() { G{1}; }
};

which started with r269093.

[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||segher at gcc dot gnu.org
   Last reconfirmed||2020-09-16

--- Comment #6 from Segher Boessenkool  ---
Confirmed.

Maaybe cse2 should do this?

[Bug analyzer/97074] New: -Wanalyzer-malloc-leak false positive when merging states

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 97074
   Summary: -Wanalyzer-malloc-leak false positive when merging
states
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

https://godbolt.org/z/5P3T8E

#include 

void *x, *y;

void test_1 (int flag)
{
  void *p = malloc (1024);
  if (flag)
x = p;
  else
y = p;
  __analyzer_dump ();
}

Has this false leak report:

t.c:13:1: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
   13 | }
  | ^
  ‘test_1’: events 1-2
|
|7 |   void *p = malloc (1024);
|  | ^
|  | |
|  | (1) allocated here
|..
|   13 | }
|  | ~
|  | |
|  | (2) ‘p’ leaks here; was allocated at (1)
|

__analyzer_dump shows that state merging leads to a merger of the x and y
values to unknown at the join-point:

rmodel:
stack depth: 1
  frame (index 0): frame: ‘test_1’@1
clusters within ::
  cluster for: x: UNKNOWN(void *)
  cluster for: y: UNKNOWN(void *)
clusters within frame: ‘test_1’@1
  cluster for: p_4: _ALLOCATED_REGION(8)
m_called_unknown_fn: FALSE
constraint_manager:
  equiv classes:
  constraints:
malloc: 
  global: start
  0x3d10590: _ALLOCATED_REGION(8): unchecked (malloc) (‘p_4’)

[Bug libstdc++/96958] Long Double in Hash Table policy forces soft-float calculations

[houdek.r...@fex-emu.org]

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

Ryan Houdek  changed:

   What|Removed |Added

 CC||houdek.r...@fex-emu.org

--- Comment #4 from Ryan Houdek  ---
Hello. Original creator of this fork here.
It would be nice to at least remove the long double requirement here, I
personally don't have much stock in the internal implementation details other
than that.
I believe other STL compliant hashable implementations end up doing something
using integers for their bucket calculations. So I guess it isn't strictly
necessary that it needs to even be double there.

In my particular case the long double implementation falls down a particularly
slow soft float path for me, so this has real performance implications. More so
than just the regular AArch64 soft float path.

Looking forward to this getting rectified.

[Bug c/97073] New: Miscompilation with -m32 -O1 -march=i686

[sirl at gcc dot gnu.org]

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

Bug ID: 97073
   Summary: Miscompilation with -m32 -O1 -march=i686
   Product: gcc
   Version: 8.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49229=edit
Testcase demonstrating the problem.

Hi,

the attached simple testcase aborts when compiled with every version since
gcc-7 (last tested r11-3232).
Compiled with gcc-6.3.1 the testcase doesn't abort.
Also adding either -fno-tree-ter or -msse2 prevents the abort.

[Bug analyzer/97072] New: -Wanalyzer-malloc-leak false positive when writing through some pointers

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 97072
   Summary: -Wanalyzer-malloc-leak false positive when writing
through some pointers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Initially seen when writing through an unknown_svalue pointer; this reproducer
captures similar behavior, albeit with a conjured_svalue pointer:

#include 

void unknown_fn_1 (void *);

void test_1 (int co, int y)
{
  void *p = malloc (1024);
  void **q;
  unknown_fn_1 ();
  *q = p;
}

t.c: In function ‘test_1’:
t.c:11:1: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
   11 | }
  | ^
  ‘test_1’: events 1-2
|
|7 |   void *p = malloc (1024);
|  | ^
|  | |
|  | (1) allocated here
|..
|   11 | }
|  | ~
|  | |
|  | (2) ‘p’ leaks here; was allocated at (1)
|

https://godbolt.org/z/WcMWda

The leak warning is a false positive, as p was written to *q.

[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug target/96139] Vector element extract mistypes long long int down to long int

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Will Schmidt
:

https://gcc.gnu.org/g:74c624523bdbe4329c7cb77bff222ac695e36c95

commit r8-10453-g74c624523bdbe4329c7cb77bff222ac695e36c95
Author: Will Schmidt 
Date:   Wed Sep 16 11:21:04 2020 -0500

[PATCH, rs6000] Fix vector long long subtype (PR96139)

Hi,
This corrects an issue with the powerpc vector long long subtypes.
As reported by SjMunroe, when building some code with -Wall, and
attempting to print an element of a "long long vector" with a
long long printf format string, we will report an error because
the vector sub-type was improperly defined as int.

When defining a V2DI_type_node we use a TARGET_POWERPC64 ternary to
define the V2DI_type_node with "vector long" or "vector long long".
We also need to specify the proper sub-type when we define the type.

Due to some file renames, This is a backport and rework of both
[PATCH, rs6000] Fix vector long long subtype (PR96139)
and
[PATCH, rs6000] Testsuite fixup pr96139 tests


PR target/96139

gcc/ChangeLog:
* config/rs6000/rs6000.c (rs6000_init_builtin): Update
V2DI_type_node
  and unsigned_V2DI_type_node definitions.

gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr96139-a.c: New test.
* gcc.target/powerpc/pr96139-b.c: New test.
* gcc.target/powerpc/pr96139-c.c: New test.

[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
// PR c++/97034

namespace N {
template  struct S {
  template  S(T, U);
};
} // namespace N
template  struct E {
  template  struct G { T t; };
  void fn() { G{N::S{'a', 1}}; }
};

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
Created attachment 49228
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49228=edit
Dumps for failing test-case (no collapse case)

(In reply to Tom de Vries from comment #7)
> Minimal example after commit 91347c3bbf7 "Fortran: OpenMP - fix simd with
> (last)private (PR97061)":
> ...
> ! { dg-do run } 
> 
> program main
>   implicit none
>   integer :: d1
>   !$omp target map(from: d1)
> 
>   !$omp teams distribute parallel do simd default(none) lastprivate(d1) 
> 
>   do d1 = 0, 31
>   end do
>   !$omp end target  
> 
>   if (d1 /= 32) stop 3
> end program
> ...

Corresponding dumps.

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
Minimal example after commit 91347c3bbf7 "Fortran: OpenMP - fix simd with
(last)private (PR97061)":
...
! { dg-do run } 
program main
  implicit none
  integer :: d1
  !$omp target map(from: d1)
  !$omp teams distribute parallel do simd default(none) lastprivate(d1) 
  do d1 = 0, 31
  end do
  !$omp end target  
  if (d1 /= 32) stop 3
end program
...

[Bug fortran/97061] [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #4 from Tobias Burnus  ---
FIXED.

[Bug gcov-profile/97069] Zero valued #line directive results in excessively large blocks of memory being allocated

[martin.ogden at arm dot com]

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

--- Comment #2 from Martin Ogden  ---
I appreciate `#line 0 "main.c"` doesn't make much sense, but according to
https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html, 0 is a valid input.

[Bug fortran/97061] [OpenMP] ICE in in omp_add_variable, at gimplify.c:6955

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:91347c3bbf788ede4af89f46206991c47fa8aceb

commit r11-3232-g91347c3bbf788ede4af89f46206991c47fa8aceb
Author: Tobias Burnus 
Date:   Wed Sep 16 16:23:13 2020 +0200

Fortran: OpenMP - fix simd with (last)private (PR97061)

gcc/fortran/ChangeLog:

PR fortran/97061
* trans-openmp.c (gfc_trans_omp_do): Handle simd with
(last)private.

gcc/testsuite/ChangeLog:

PR fortran/97061
* gfortran.dg/gomp/openmp-simd-6.f90: New test.

[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Related and more difficult case where the add is first and we'd want to
change the load of -3 to a load of 3 so we can CSE the 3 for the
multiplication.

double foo (double x)
{
  return (x + -3.) * 3.;
}

[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> REG_EQUAL notes aren't really needed for that, we have functions to query
> the values from the constant pool for loads from it.
> So guess it is a matter of looking at the constant pool entry, if the
> negation of it is already emitted and the current value is not, try if
> instruction with the negation can be recognized.
> If neither of the constant pool entries is emitted already, but both are
> present, it should try to canonicalize to one of them...

Note it's not mainly about optimizing the size of the constant pool but
to reduce the number of loads from it and eventually shrink code size.

[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
So on targets where the FP constant loads are separate insns the load of the
negated constant could be replaced by a (neg:DF ..) which might even be
profitable when not combined with the following add.  As said targets like
x86 might be more difficult in this regard though it looks like the
memory operands in this case only appear during LRA.

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
A void pointer is usually cast to one to a complete type that's then used to
access the object (e.g., bsearch).  But not every instance of every warning
should be expected to indicate a bug.  Most only suggest that there might be
one.  The documented purpose of GCC warnings is to "report constructions that
are not inherently erroneous but that are risky or suggest there may have been
an error."  This rare use is one such case.  It was considered when the warning
was designed and deemed an acceptable trade-off.  (The attribute was added to
help accommodate  it.)

If adding support for attribute access to the D front end isn't feasible to
mark up the function and avoid the warning that way, I would suggest removing
the const qualifier from the pointer (following the practice of the C++
standard garbage collector APIs) or providing an non-const overload. 
Alternatively, writing into a byte of the allocated memory will prevent the
warning as well.

[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
REG_EQUAL notes aren't really needed for that, we have functions to query the
values from the constant pool for loads from it.
So guess it is a matter of looking at the constant pool entry, if the negation
of it is already emitted and the current value is not, try if instruction with
the negation can be recognized.
If neither of the constant pool entries is emitted already, but both are
present, it should try to canonicalize to one of them...

[Bug rtl-optimization/97071] Fails to CSE / inherit constant pool load

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64le
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Right before combine we see the following, still nicely with REG_EQUAL notes

(insn 7 17 9 2 (set (reg:DF 119)
(mem/u/c:DF (unspec:DI [
(symbol_ref/u:DI ("*.LC0") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL) [0  S8 A64])) "t.c":3:20 533
{*movdf_hardfloat64}   
 (expr_list:REG_EQUAL (const_double:DF -3.0e+0 [-0x0.cp+2])
(nil)))
(insn 9 7 14 2 (set (reg:DF 121)
(mem/u/c:DF (unspec:DI [
(symbol_ref/u:DI ("*.LC2") [flags 0x82])
(reg:DI 2 2)
] UNSPEC_TOCREL) [0  S8 A64])) "t.c":3:20 533
{*movdf_hardfloat64}   
 (expr_list:REG_EQUAL (const_double:DF 3.0e+0 [0x0.cp+2])
(nil)))
(insn 14 9 15 2 (set (reg/i:DF 33 1)
(fma:DF (reg:DF 124)
(reg:DF 119)
(reg:DF 121))) "t.c":4:1 894 {*fmadf4_fpr}
 (expr_list:REG_DEAD (reg:DF 124)
(expr_list:REG_DEAD (reg:DF 121)
(expr_list:REG_DEAD (reg:DF 119)
(nil)

eventually the easiest pass to teach this to is fwprop though as it already
works DF DEF -> USE.  Alternatively PRE could make the subtract and/or the
negated value anticipated.