[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

[lili.cui at intel dot com via Gcc-bugs]

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

--- Comment #7 from cuilili  ---
Created attachment 52706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52706&action=edit
Add a heuristic for eliminate redundant load and store in inline pass.

Hi Richard,

Could you help take a look? This is my first time adding code in mid-end, hope
you can give me some advice, thank you!

I add a INLINE_HINT_eliminate_load_and_store hint in to inline pass. when
callee's memory access is caller's local memory parameter and access size is
greater than the target threshold, we will enable the hint. with the hint,
inlining_insns_auto will enlarge the bound. The target hook is only enabled for
x86 now.

With the patch applied
Icelake server: 538.imagic_r get 15.18% improvement for multicopy and 40.78%
improvement for single copy with no measurable changes for other benchmarks.

Casecadelake: 538.imagic_r get 12.4% improvement for multicopy with and code
size increased by 0.4%. With no measurable changes for other benchmarks.

Znver3 server: 538.imagic_r get 9.6% improvement for multicopy with and code
size increased by 0.5%. With no measurable changes for other benchmarks.

[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #45 from rguenther at suse dot de  ---
On Tue, 29 Mar 2022, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
> 
> --- Comment #43 from Hongtao.liu  ---
> One thing I found by experiments:
> Insert 64 vaddps %xmm18, %xmm19, %xmm20(no dependence between each other, just
> emulate for pipeline) before stalled load, stlf stall case is as fast as no
> stall cases on CLX. I guess this is "distance" you mean.

Yes - on the micro-architecture that's likely the point the data is
then available from L1-D.  The "distance" might depend on the store
workload (# of stores that can issue / retire / flush to L1 per cycle).

> Is there any existed structure in GCC I can get latency from entry to the load
> instruction?

There's the DFA description used by the instruction scheduler.  I'm
not familiar with that part of GCC but IIRC the dependence and DFA
query part should be sufficiently separate.  For OOO
uarchs we can compute a minimum distance based purely on frontend
cycles.  Doing better would need to look at instruction dependences.
I'm not sure if the CPUs we care about use forwarding possibilities
in the decision to OOO schedule loads/stores but IIRC store buffer
entries are allocated early at insn issue time and memory dependences
are taken into account.

Since we have no idea about the instruction sequence before function
entry going into too much detail will probably suffer from GIGO so
I'd resort to approximating the frontend side of the pipeline only
by some manual bean counting.

> And of course for loop with unknown trip count, latency can't be
> exactly estimated. Similar for cases when load is in join_bb, guess we need to
> calculate "average" latency among all possible predecessors?

I'd have simply stopped at backwards reachable blocks since whether
or not a load will forward from a store before function entry will
depend on the iteration number.

Likewise for CFG joins - I suppose one could conservatively assume
the shorter or longer path is taken, dependent on what side we want
to err on (maybe look at the edge probabilities even and choose the
most probable incoming path length).

[Bug analyzer/105092] New: ICE in get_region_for_local, at analyzer/region.cc:874

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105092
   Summary: ICE in get_region_for_local, at analyzer/region.cc:874
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++ 12.0.1 20220327 snapshot (g:08e69332881f8d28ce8b559ffba1900ae5c0d5ee) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/gomp/depend-iterator-3.C, w/ -fanalyzer -fopenmp:

struct S {
  S () {}
};

template 
struct U {
  T c[10];
  U () {
#pragma omp task affinity (iterator (i = 0 : 10 : 1): c[i])
;
  }
};

U v;

% g++-12.0.1 -fanalyzer -fopenmp -c r3zw7jzh.C
during IPA pass: analyzer
r3zw7jzh.C: In constructor 'U::U() [with T = S]':
r3zw7jzh.C:9:38: internal compiler error: in get_region_for_local, at
analyzer/region.cc:874
9 | #pragma omp task affinity (iterator (i = 0 : 10 : 1): c[i])
  |  ^
0x89a98a ana::frame_region::get_region_for_local(ana::region_model_manager*,
tree_node*, ana::region_model_context const*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/region.cc:874
0x157a169 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/region-model.cc:2136
0x157a169 ana::region_model::get_lvalue(tree_node*, ana::region_model_context*)
const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/region-model.cc:2147
0x15801e6 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/region-model.cc:1040
0x155665f ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/engine.cc:1361
0x1559a43 ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/engine.cc:3755
0x155aa3a ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/engine.cc:3198
0x155d101 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/engine.cc:5777
0x155e02e ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/engine.cc:5851
0x154ccb8 execute
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220327/work/gcc-12-20220327/gcc/analyzer/analyzer-pass.cc:87

[Bug tree-optimization/105080] [12 Regression] Bugus -Wformat-truncation

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/105080] [12 Regression] Bugus -Wformat-truncation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:28c5df79300ab354cbc381aab200f7c2bd0331ad

commit r12-7870-g28c5df79300ab354cbc381aab200f7c2bd0331ad
Author: Richard Biener 
Date:   Mon Mar 28 14:55:49 2022 +0200

tree-optimization/105080 - make sure SCEV is available for ranger

When doing format diagnostics at -O0 we should make sure to make
SCEV available to avoid false positives due to ranges we otherwise
can trivially compute.

2022-03-28  Richard Biener  

PR tree-optimization/105080
* tree-ssa-strlen.cc (printf_strlen_execute): Always init
loops and SCEV.

* gcc.dg/pr105080.c: New testcase.

[Bug c++/105035] [11 Regression] tree check: expected field_decl, have identifier_node in operand_equal_p, at fold-const.c:3335 since r11-5181-g0862d007b564eca8

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9735-gcb2520db3a35758affc7b90b8fefe927fc972516
Author: Jakub Jelinek 
Date:   Thu Mar 24 12:23:51 2022 +0100

fold-const: Handle C++ dependent COMPONENT_REFs in operand_equal_p
[PR105035]

As mentioned in the PR, operand_equal_p already contains some hacks so that
it can be called already on pre-instantiation C++ trees from templates,
but the recent change to compare DECL_FIELD_OFFSET in the COMPONENT_REF
case broke this.  Many such COMPONENT_REFs are already punted on earlier
because they have NULL TREE_TYPE, but in this case the code knows what
type they have but still uses an IDENTIFIER_NODE as second operand
of COMPONENT_REF (I think SCOPE_REF is something that could be used too).

The following patch looks at those DECL_FIELD_*OFFSET fields only if
both field[01] args are FIELD_DECLs and otherwise keeps it to the
earlier OP_SAME (1) check that guards this whole block.

2022-03-24  Jakub Jelinek  

PR c++/105035
* fold-const.c (operand_equal_p) : If either
field0 or field1 is not a FIELD_DECL, return false.

* g++.dg/warn/Wduplicated-cond2.C: New test.

(cherry picked from commit 8698ff67cdff4364c8adad2921ed532359a155ec)

[Bug c++/104994] extern thread_local declaration rejected in constexpr

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:51b5fa6b4257850c99094f2cf7ece949b00a7826

commit r11-9734-g51b5fa6b4257850c99094f2cf7ece949b00a7826
Author: Jakub Jelinek 
Date:   Thu Mar 24 10:12:25 2022 +0100

c++: extern thread_local declarations in constexpr [PR104994]

C++14 to C++20 apparently should allow extern thread_local declarations in
constexpr functions, however useless they are there (because accessing
such vars is not valid in a constant expression, perhaps sizeof/decltype).
P2242 changed that for C++23 to passing through declaration but
https://cplusplus.github.io/CWG/issues/2552.html
has been filed for it yesterday.

2022-03-24  Jakub Jelinek  

PR c++/104994
* constexpr.c (potential_constant_expression_1): Don't diagnose
extern
thread_local declarations.
* decl.c (start_decl): Likewise.

* g++.dg/cpp23/constexpr-nonlit7.C: New test.

(cherry picked from commit 72124f487ccb5c8065dd5f7b8fba254600b7e611)

[Bug middle-end/104971] [9/10/11 Regression] Optimisation for __builtin_ia32_readeflags corrupts the stack

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9733-gbe64c349e7312a4e89c569d42c4e2284610d4908
Author: Jakub Jelinek 
Date:   Sat Mar 19 13:53:12 2022 +0100

i386: Don't emit pushf;pop for __builtin_ia32_readeflags_u* with unused lhs
[PR104971]

__builtin_ia32_readeflags_u* aren't marked const or pure I think
intentionally, so that they aren't CSEd from different regions of a
function
etc. because we don't and can't easily track all dependencies between
it and surrounding code (if somebody looks at the condition flags, it is
dependent on the vast majority of instructions).
But the builtin itself doesn't have any side-effects, so if we ignore the
result of the builtin, there is no point to emit anything.

There is a LRA bug that miscompiles the testcase which this patch makes
latent, which is certainly worth fixing too, but IMHO this change
(and maybe ix86_gimple_fold_builtin too which would fold it even earlier
when it looses lhs) is worth it as well.

2022-03-19  Jakub Jelinek  

PR middle-end/104971
* config/i386/i386-expand.c
(ix86_expand_builtin) : If ignore,
don't push/pop anything and just return const0_rtx.

* gcc.target/i386/pr104971.c: New test.

(cherry picked from commit b60bc913cca7439d29a7ec9e9a7f448d8841b43c)

[Bug tree-optimization/101515] [11 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9732-gf70464efbfa9469c57ac75b9aa5a62a2cff4f1fe
Author: Jakub Jelinek 
Date:   Sat Mar 19 08:40:47 2022 +0100

c-family: Fix up ICE during pretty-printing of PMF related expression
[PR101515]

The intent of r11-6729 is that it prints something that helps user to
figure
out what exactly is being accessed.
When we find a unique non-static data member that is being accessed, even
when we can't fold it nicely, IMNSHO it is better to print
  ((sometype *)&var)->field
or
  (*(sometype *)&var).field
instead of
  *(fieldtype *)((char *)&var + 56)
because the user doesn't know what is at offset 56, we shouldn't ask user
to decipher structure layout etc.

One question is if we could return something better for the
TYPE_PTRMEMFUNC_FLAG
RECORD_TYPE members here (something that would print it more
naturally/readably
in a C++ way), though the fact that the routine is in c-family makes it
harder.

Another one is whether we shouldn't punt for FIELD_DECLs that don't have
nicely printable name of its containing scope, something like:
if (tree scope = get_containing_scope (field))
  if (TYPE_P (scope) && TYPE_NAME (scope) == NULL_TREE)
break;
return cop;
or so.  This patch implements that.

Note the returned cop is a COMPONENT_REF where the first argument has a
nicely printable type name (x with type sp), but sp's TYPE_MAIN_VARIANT
is the unnamed TYPE_PTRMEMFUNC_FLAG.  So another possibility would be if
we see such a problem for the FIELD_DECL's scope, check if
TYPE_MAIN_VARIANT
of the first COMPONENT_REF's argument is equal to that scope and in that
case use TREE_TYPE of the first COMPONENT_REF's argument as the scope
instead.

2022-03-19  Jakub Jelinek  

PR c++/101515
* c-pretty-print.c (c_fold_indirect_ref_for_warn): For C++ don't
return COMPONENT_REFs with FIELD_DECLs whose containing scope can't
be printed.

* g++.dg/warn/pr101515.C: New test.

(cherry picked from commit 2663d18356b0a62f5a800c7e5596d814cd3c2c41)

[Bug tree-optimization/100834] False positive of -Wstringop-overflow= with -Os

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18

commit r11-9731-g91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18
Author: Jakub Jelinek 
Date:   Fri Mar 18 18:58:06 2022 +0100

Allow (void *) 0xdeadbeef accesses without warnings [PR99578]

Starting with GCC11 we keep emitting false positive -Warray-bounds or
-Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
style accesses (or memory/string routines to such pointers).
This is a standard programming style supported by all C/C++ compilers
I've ever tried, used mostly in kernel or DSP programming, but sometimes
also together with mmap MAP_FIXED when certain things, often I/O registers
but could be anything else too are known to be present at fixed
addresses.

Such INTEGER_CST addresses can appear in code either because a user
used it like that (in which case it is fine) or because somebody used
pointer arithmetics (including &((struct whatever *)NULL)->field) on
a NULL pointer.  The middle-end warning code wrongly assumes that the
latter case is what is very likely, while the former is unlikely and
users should change their code.

The following patch adds a min-pagesize param defaulting to 4KB,
and treats INTEGER_CST addresses smaller than that as assumed results
of pointer arithmetics from NULL while addresses equal or larger than
that as expected user constant addresses.  For GCC 13 we can
represent results from pointer arithmetics on NULL using
&MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs.

2022-03-18  Jakub Jelinek  

PR middle-end/99578
PR middle-end/100680
PR tree-optimization/100834
* params.opt (--param=min-pagesize=): New parameter.
* builtins.c (compute_objsize_r) : Use maximum
object size instead of zero for pointer constants equal or larger
than min-pagesize.

* gcc.dg/tree-ssa/pr99578-1.c: New test.
* gcc.dg/pr99578-1.c: New test.
* gcc.dg/pr99578-2.c: New test.
* gcc.dg/pr99578-3.c: New test.
* gcc.dg/pr100680.c: New test.
* gcc.dg/pr100834.c: New test.

(cherry picked from commit 32ca611c42658948f1b8883994796f35e8b4e74d)

[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18

commit r11-9731-g91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18
Author: Jakub Jelinek 
Date:   Fri Mar 18 18:58:06 2022 +0100

Allow (void *) 0xdeadbeef accesses without warnings [PR99578]

Starting with GCC11 we keep emitting false positive -Warray-bounds or
-Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
style accesses (or memory/string routines to such pointers).
This is a standard programming style supported by all C/C++ compilers
I've ever tried, used mostly in kernel or DSP programming, but sometimes
also together with mmap MAP_FIXED when certain things, often I/O registers
but could be anything else too are known to be present at fixed
addresses.

Such INTEGER_CST addresses can appear in code either because a user
used it like that (in which case it is fine) or because somebody used
pointer arithmetics (including &((struct whatever *)NULL)->field) on
a NULL pointer.  The middle-end warning code wrongly assumes that the
latter case is what is very likely, while the former is unlikely and
users should change their code.

The following patch adds a min-pagesize param defaulting to 4KB,
and treats INTEGER_CST addresses smaller than that as assumed results
of pointer arithmetics from NULL while addresses equal or larger than
that as expected user constant addresses.  For GCC 13 we can
represent results from pointer arithmetics on NULL using
&MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs.

2022-03-18  Jakub Jelinek  

PR middle-end/99578
PR middle-end/100680
PR tree-optimization/100834
* params.opt (--param=min-pagesize=): New parameter.
* builtins.c (compute_objsize_r) : Use maximum
object size instead of zero for pointer constants equal or larger
than min-pagesize.

* gcc.dg/tree-ssa/pr99578-1.c: New test.
* gcc.dg/pr99578-1.c: New test.
* gcc.dg/pr99578-2.c: New test.
* gcc.dg/pr99578-3.c: New test.
* gcc.dg/pr100680.c: New test.
* gcc.dg/pr100834.c: New test.

(cherry picked from commit 32ca611c42658948f1b8883994796f35e8b4e74d)

[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18

commit r11-9731-g91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18
Author: Jakub Jelinek 
Date:   Fri Mar 18 18:58:06 2022 +0100

Allow (void *) 0xdeadbeef accesses without warnings [PR99578]

Starting with GCC11 we keep emitting false positive -Warray-bounds or
-Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
style accesses (or memory/string routines to such pointers).
This is a standard programming style supported by all C/C++ compilers
I've ever tried, used mostly in kernel or DSP programming, but sometimes
also together with mmap MAP_FIXED when certain things, often I/O registers
but could be anything else too are known to be present at fixed
addresses.

Such INTEGER_CST addresses can appear in code either because a user
used it like that (in which case it is fine) or because somebody used
pointer arithmetics (including &((struct whatever *)NULL)->field) on
a NULL pointer.  The middle-end warning code wrongly assumes that the
latter case is what is very likely, while the former is unlikely and
users should change their code.

The following patch adds a min-pagesize param defaulting to 4KB,
and treats INTEGER_CST addresses smaller than that as assumed results
of pointer arithmetics from NULL while addresses equal or larger than
that as expected user constant addresses.  For GCC 13 we can
represent results from pointer arithmetics on NULL using
&MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs.

2022-03-18  Jakub Jelinek  

PR middle-end/99578
PR middle-end/100680
PR tree-optimization/100834
* params.opt (--param=min-pagesize=): New parameter.
* builtins.c (compute_objsize_r) : Use maximum
object size instead of zero for pointer constants equal or larger
than min-pagesize.

* gcc.dg/tree-ssa/pr99578-1.c: New test.
* gcc.dg/pr99578-1.c: New test.
* gcc.dg/pr99578-2.c: New test.
* gcc.dg/pr99578-3.c: New test.
* gcc.dg/pr100680.c: New test.
* gcc.dg/pr100834.c: New test.

(cherry picked from commit 32ca611c42658948f1b8883994796f35e8b4e74d)

[Bug c++/104568] [10/11 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:18f5bc87bc2eef70991b9c93d1265a7d0ebed58b

commit r11-9730-g18f5bc87bc2eef70991b9c93d1265a7d0ebed58b
Author: Jakub Jelinek 
Date:   Fri Mar 18 18:49:23 2022 +0100

c++: Fix up constexpr evaluation of new with zero sized types [PR104568]

The new expression constant expression evaluation right now tries to
deduce how many elts the array it uses for the heap or heap [] vars
should have (or how many elts should its trailing array have if it has
cookie at the start).  As new is lowered at that point to
(some_type *) ::operator new (size)
or so, it computes it by subtracting cookie size if any from size, then
divides the result by sizeof (some_type).
This works fine for most types, except when sizeof (some_type) is 0,
then we divide by zero; size is then equal to cookie_size (or if there
is no cookie, to 0).
The following patch special cases those cases so that we don't divide
by zero and also recover the original outer_nelts from the expression
by forcing the size not to be folded in that case but be explicit
0 * outer_nelts or cookie_size + 0 * outer_nelts.

Note, we have further issues, we accept-invalid various cases, for both
zero sized elt_type and even non-zero sized elts, we aren't able to
diagnose out of bounds POINTER_PLUS_EXPR like:
constexpr bool
foo ()
{
  auto p = new int[2];
  auto q1 = &p[0];
  auto q2 = &p[1];
  auto q3 = &p[2];
  auto q4 = &p[3];
  delete[] p;
  return true;
}
constexpr bool a = foo ();
That doesn't look like a regression so I think we should resolve that for
GCC 13, but there are 2 problems.  Figure out why
cxx_fold_pointer_plus_expression doesn't deal with the &heap []
etc. cases, and for the zero sized arrays, I think we really need to
preserve
whether user wrote an array ref or pointer addition, because in the
&p[3] case if sizeof(p[0]) == 0 we know that if it has 2 elements it is
out of bounds, while if we see p p+ 0 the information if it was
p + 2 or p + 3 in the source is lost.
clang++ seems to handle it fine even in the zero sized cases or with
new expressions.

2022-03-18  Jakub Jelinek  

PR c++/104568
* init.c (build_new_constexpr_heap_type): Remove FULL_SIZE
argument and its handling, instead add ITYPE2 argument.  Only
support COOKIE_SIZE != NULL.
(build_new_1): If size is 0, change it to 0 * outer_nelts if
outer_nelts is non-NULL.  Pass type rather than elt_type to
maybe_wrap_new_for_constexpr.
* constexpr.c (build_new_constexpr_heap_type): New function.
(cxx_eval_constant_expression) :
If elt_size is zero sized type, try to recover outer_nelts from
the size argument to operator new/new[] and pass that as
arg_size to build_new_constexpr_heap_type.  Pass ctx,
non_constant_p and overflow_p to that call too.

* g++.dg/cpp2a/constexpr-new22.C: New test.

(cherry picked from commit 0a0c2c3f06227d46b5e9542dfdd4e0fd2d67d894)

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1861b9a9f13c6406a2eb146b2da0a41d044f

commit r11-9729-g1861b9a9f13c6406a2eb146b2da0a41d044f
Author: Jakub Jelinek 
Date:   Thu Mar 17 18:49:00 2022 +0100

libatomic: Improve 16-byte atomics on Intel AVX [PR104688]

As mentioned in the PR, the latest Intel SDM has added:
"Processors that enumerate support for Intel® AVX (by setting the feature
flag CPUID.01H:ECX.AVX[bit 28])
guarantee that the 16-byte memory operations performed by the following
instructions will always be
carried out atomically:
⢠MOVAPD, MOVAPS, and MOVDQA.
⢠VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128.
⢠VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with EVEX.128
and k0 (masking disabled).
(Note that these instructions require the linear addresses of their memory
operands to be 16-byte
aligned.)"

The following patch deals with it just on the libatomic library side so
far,
currently (since ~ 2017) we emit all the __atomic_* 16-byte builtins as
library calls since and this is something that we can hopefully backport.

The patch simply introduces yet another ifunc variant that takes priority
over the pure CMPXCHG16B one, one that checks AVX and CMPXCHG16B bits and
on non-Intel clears the AVX bit during detection for now (if AMD comes
with the same guarantee, we could revert the config/x86/init.c hunk),
which implements 16-byte atomic load as vmovdqa and 16-byte atomic store
as vmovdqa followed by mfence.

2022-03-17  Jakub Jelinek  

PR target/104688
* Makefile.am (IFUNC_OPTIONS): Change on x86_64 to -mcx16 -mcx16.
(libatomic_la_LIBADD): Add $(addsuffix _16_2_.lo,$(SIZEOBJS)) for
x86_64.
* Makefile.in: Regenerated.
* config/x86/host-config.h (IFUNC_COND_1): For x86_64 define to
both AVX and CMPXCHG16B bits.
(IFUNC_COND_2): Define.
(IFUNC_NCOND): For x86_64 define to 2 * (N == 16).
(MAYBE_HAVE_ATOMIC_CAS_16, MAYBE_HAVE_ATOMIC_EXCHANGE_16,
MAYBE_HAVE_ATOMIC_LDST_16): Define to IFUNC_COND_2 rather than
IFUNC_COND_1.
(HAVE_ATOMIC_CAS_16): Redefine to 1 whenever IFUNC_ALT != 0.
(HAVE_ATOMIC_LDST_16): Redefine to 1 whenever IFUNC_ALT == 1.
(atomic_compare_exchange_n): Define whenever IFUNC_ALT != 0
on x86_64 for N == 16.
(__atomic_load_n, __atomic_store_n): Redefine whenever IFUNC_ALT ==
1
on x86_64 for N == 16.
(atomic_load_n, atomic_store_n): New functions.
* config/x86/init.c (__libat_feat1_init): On x86_64 clear bit_AVX
if CPU vendor is not Intel.

(cherry picked from commit 1d47c0512a265d4bb3ab9e56259fd1e4f4d42c75)

[Bug target/104910] [10/11 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9728-g9c3225c8b7c7f74a53aaae6ed5b6463b55bf7a92
Author: Jakub Jelinek 
Date:   Wed Mar 16 11:04:16 2022 +0100

aarch64: Fix up RTL sharing bug in aarch64_load_symref_appropriately
[PR104910]

We unshare all RTL created during expansion, but when
aarch64_load_symref_appropriately is called after expansion like in the
following testcases, we use imm in both HIGH and LO_SUM operands.
If imm is some RTL that shouldn't be shared like a non-sharable CONST,
we get at least with --enable-checking=rtl a checking ICE, otherwise might
just get silently wrong code.

The following patch fixes that by copying it if it can't be shared.

2022-03-16  Jakub Jelinek  

PR target/104910
* config/aarch64/aarch64.c (aarch64_load_symref_appropriately):
Copy
imm rtx.

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

(cherry picked from commit 952155629ca1a4dfe7c7b26e53d118a9b853ed4a)

[Bug rtl-optimization/104814] [10/11 Regression] ifcvt: Deleting live variable in IF-CASE-2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:17de662ec26786053caab2cea34c76814352ea4d

commit r11-9727-g17de662ec26786053caab2cea34c76814352ea4d
Author: Jakub Jelinek 
Date:   Tue Mar 15 09:12:03 2022 +0100

ifcvt: Punt if not onlyjump_p for find_if_case_{1,2} [PR104814]

find_if_case_{1,2} implicitly assumes conditional jumps and rewrites them,
so if they have extra side-effects or are say asm goto, things don't work
well, either the side-effects are lost or we could ICE.
In particular, the testcase below on s390x has there a doloop instruction
that decrements a register in addition to testing it for non-zero and
conditionally jumping based on that.

The following patch fixes that by punting for !onlyjump_p case, i.e.
if there are side-effects in the jump instruction or it isn't a plain PC
setter.

Also, it assumes BB_END (test_bb) will be always non-NULL, because basic
blocks with 2 non-abnormal successor edges should always have some
instruction
at the end that determines which edge to take.

2022-03-15  Jakub Jelinek  

PR rtl-optimization/104814
* ifcvt.c (find_if_case_1, find_if_case_2): Punt if test_bb doesn't
end with onlyjump_p.  Assume BB_END (test_bb) is always non-NULL.

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

(cherry picked from commit a2645cd8fb33b36d737b310e26f4c47401305c7b)

[Bug c/104711] Unnecessary -Wshift-negative-value warning

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9726-gddc0d2593fb4d2eb432e24018d36dd3f337a8138
Author: Jakub Jelinek 
Date:   Wed Mar 9 09:15:28 2022 +0100

c, c++, c-family: -Wshift-negative-value and -Wshift-overflow* tweaks for
-fwrapv and C++20+ [PR104711]

As mentioned in the PR, different standards have different definition
on what is an UB left shift.  They all agree on out of bounds (including
negative) shift count.
The rules used by ubsan are:
C99-C2x ((unsigned) x >> (uprecm1 - y)) != 0 then UB
C++11-C++17 x < 0 || ((unsigned) x >> (uprecm1 - y)) > 1 then UB
C++20 and later everything is well defined
Now, for C++20, I've in the P1236R1 implementation added an early
exit for -Wshift-overflow* warning so that it never warns, but apparently
-Wshift-negative-value remained as is.  As it is well defined in C++20,
the following patch doesn't enable -Wshift-negative-value from -Wextra
anymore for C++20 and later, if users want for compatibility with C++17
and earlier get the warning, they still can by using -Wshift-negative-value
explicitly.
Another thing is -fwrapv, that is an extension to the standards, so it is
up
to us how exactly we define that case.  Our ubsan code treats
TYPE_OVERFLOW_WRAPS (type0) and cxx_dialect >= cxx20 the same as only
diagnosing out of bounds shift count and nothing else and IMHO it is most
sensical to treat -fwrapv signed left shifts the same as C++20 treats
them, https://eel.is/c++draft/expr.shift#2
"The value of E1 << E2 is the unique value congruent to E1×2^E2 modulo 2^N,
where N is the width of the type of the result.
[Note 1: E1 is left-shifted E2 bit positions; vacated bits are zero-filled.
â end note]"
with no UB dependent on the E1 values.  The UB is only
"The behavior is undefined if the right operand is negative, or greater
than or equal to the width of the promoted left operand."
Under the hood (except for FEs and ubsan from FEs) GCC middle-end doesn't
consider UB in left shifts dependent on the first operand's value, only
the out of bounds shifts.

While this change isn't a regression, I'd think it is useful for GCC 12,
it doesn't add new warnings, but just removes warnings that aren't
appropriate.

2022-03-09  Jakub Jelinek  

PR c/104711
gcc/
* doc/invoke.texi (-Wextra): Document that -Wshift-negative-value
is enabled by it only for C++11 to C++17 rather than for C++03 or
later.
(-Wshift-negative-value): Similarly (except here we stated
that it is enabled for C++11 or later).
gcc/c-family/
* c-opts.c (c_common_post_options): Don't enable
-Wshift-negative-value from -Wextra for C++20 or later.
* c-ubsan.c (ubsan_instrument_shift): Adjust comments.
* c-warn.c (maybe_warn_shift_overflow): Use TYPE_OVERFLOW_WRAPS
instead of TYPE_UNSIGNED.
gcc/c/
* c-fold.c (c_fully_fold_internal): Don't emit
-Wshift-negative-value warning if TYPE_OVERFLOW_WRAPS.
* c-typeck.c (build_binary_op): Likewise.
gcc/cp/
* constexpr.c (cxx_eval_check_shift_p): Use TYPE_OVERFLOW_WRAPS
instead of TYPE_UNSIGNED.
* typeck.c (cp_build_binary_op): Don't emit
-Wshift-negative-value warning if TYPE_OVERFLOW_WRAPS.
gcc/testsuite/
* c-c++-common/Wshift-negative-value-1.c: Remove
dg-additional-options, instead in target selectors of each
diagnostic
check for exact C++ versions where it should be diagnosed.
* c-c++-common/Wshift-negative-value-2.c: Likewise.
* c-c++-common/Wshift-negative-value-3.c: Likewise.
* c-c++-common/Wshift-negative-value-4.c: Likewise.
* c-c++-common/Wshift-negative-value-7.c: New test.
* c-c++-common/Wshift-negative-value-8.c: New test.
* c-c++-common/Wshift-negative-value-9.c: New test.
* c-c++-common/Wshift-negative-value-10.c: New test.
* c-c++-common/Wshift-overflow-1.c: Remove
dg-additional-options, instead in target selectors of each
diagnostic
check for exact C++ versions where it should be diagnosed.
* c-c++-common/Wshift-overflow-2.c: Likewise.
* c-c++-common/Wshift-overflow-5.c: Likewise.
* c-c++-common/Wshift-overflow-6.c: Likewise.
* c-c++-common/Wshift-overflow-7.c: Likewise.
* c-c++-common/Wshift-overflow-8.c: New test.
* c-c++-common/Wshift-overflow-9.c: New test.
* c-c++-common/Wshift-overflow-10.c: New test.
* c-c++-common/Wshift-overflow-11.c: New test.
   

[Bug c++/104806] Weird error message: did you mean "__dt "

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9725-gb7c0962d0c7882b8c019363257c8b632d6c11d5e
Author: Jakub Jelinek 
Date:   Tue Mar 8 21:41:21 2022 +0100

c++: Don't suggest cdtor or conversion op identifiers in spelling hints
[PR104806]

On the following testcase, we emit "did you mean '__dt '?" in the error
message.  "__dt " shows there because it is dtor_identifier, but we
shouldn't suggest those to the user, they are purely internal and can't
be really typed by the user because of the final space in it.

2022-03-08  Jakub Jelinek  

PR c++/104806
* search.c (lookup_field_fuzzy_info::fuzzy_lookup_field): Ignore
identifiers with space at the end.

* g++.dg/spellcheck-pr104806.C: New test.

(cherry picked from commit e480c3c06d20874fd7504bfdcca0b829f8000389)

[Bug target/104775] [9/10/11 Regression] Failure to assemble on s390x with -fsanitize=undefined

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:2ef4d28e59e3117dd1457e9ad08b7e1b48ab9830

commit r11-9724-g2ef4d28e59e3117dd1457e9ad08b7e1b48ab9830
Author: Jakub Jelinek 
Date:   Mon Mar 7 11:14:04 2022 +0100

s390: Fix up *cmp_and_trap_unsigned_int constraints [PR104775]

The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
insn not being accepted by assembler.
My rough understanding is that in the RSY-b insn format the spot
in other formats used for index registers is used instead for M3 what
kind of comparison it is, so this patch follows what other similar
instructions use for constraint (i.e. one without index register).

2022-03-07  Jakub Jelinek  

PR target/104775
* config/s390/s390.md (*cmp_and_trap_unsigned_int): Use
S constraint instead of T in the last alternative.

* gcc.target/s390/pr104775.c: New test.

(cherry picked from commit 2472dcaa8cb9e02e902f83d419c3ee7e0f3d9041)

[Bug rtl-optimization/104589] [11 Regression] Emitted binary code changes when -g is enabled at -O0 -flto and optimize attribute since r11-3026-gfea13fcd0da03535

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:7737259ceaa490a1cc75415efa00f3631a7e17df

commit r11-9723-g7737259ceaa490a1cc75415efa00f3631a7e17df
Author: Jakub Jelinek 
Date:   Wed Mar 2 10:48:14 2022 +0100

cfgrtl: Fix up -g vs. -g0 code generation -flto differences in
fixup_reorder_chain [PR104589]

This is similar to PR104237 and similarly to that, no testcase included
for the testsuite, as we don't have a framework to compile/link with
-g -flto and -g0 -flto and compare -fdump-final-insns= results from
the lto1 compilations.

With -flto, whether two location_t compare equal or not and just
express the same location is a lottery.

2022-03-02  Jakub Jelinek  

PR rtl-optimization/104589
* cfgrtl.c (fixup_reorder_chain): Use loc_equal instead of direct
INSN_LOCATION comparison with goto_locus.

(cherry picked from commit 2e1b00367abaf8b6dbb47fd8518d9ac69c326a06)

[Bug tree-optimization/104675] [9/10/11 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9722-g1a2772a3fe41bc0c33c4620540dae0103dcf7289
Author: Jakub Jelinek 
Date:   Fri Feb 25 21:25:12 2022 +0100

match.pd: Further complex simplification fixes [PR104675]

Mark mentioned in the PR further 2 simplifications that also ICE
with complex types.
For these, eventually (but IMO GCC 13 materials) we could support it
for vector types if it would be uniform vector constants.
Currently integer_pow2p is true only for INTEGER_CSTs and COMPLEX_CSTs
and we can't use bit_and etc. for complex type.

2022-02-25  Jakub Jelinek  
Marc Glisse  

PR tree-optimization/104675
* match.pd (t * 2U / 2 -> t & (~0 / 2), t / 2U * 2 -> t & ~1):
Restrict simplifications to INTEGRAL_TYPE_P.

* gcc.dg/pr104675-3.c : New test.

(cherry picked from commit f62115c9b770a66c5378f78a2d5866243d560573)

[Bug target/104681] [9/10/11 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9721-gb59d29392774b115bea0066b4ad1eb2b959a3a2b
Author: Jakub Jelinek 
Date:   Fri Feb 25 18:58:48 2022 +0100

rs6000: Use rs6000_emit_move in movmisalign expander [PR104681]

The following testcase ICEs, because for some strange reason it decides to
use
movmisaligntf during expansion where the destination is MEM and source is
CONST_DOUBLE.  For normal mov expanders the rs6000 backend uses
rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG
and a few other things, but for movmisalign nothing enforced this.
The middle-end documents that movmisalign shouldn't fail, so we can't
force that through predicates or condition on the expander.

2022-02-25  Jakub Jelinek  

PR target/104681
* config/rs6000/vector.md (movmisalign): Use
rs6000_emit_move.

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

(cherry picked from commit 3885a122f817a1b6dca4a84ba9e020d5ab2060af)

[Bug target/104674] [11 Regression] i686 sse2: The two results of __divmoddi4 are mixed up

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9720-gacb9ea44fcceea0a54a89c7f94af4338c10759ef
Author: Jakub Jelinek 
Date:   Fri Feb 25 12:06:52 2022 +0100

i386: Use a new temp slot kind for splitter to floatdi2_i387_with_xmm
[PR104674]

As mentioned in the PR, the following testcase is miscompiled for similar
reasons as the already fixed PR78791 - we use SLOT_TEMP slots in various
places during expansion and during expansion we can guarantee that the
lifetime of those temporary slot doesn't overlap.  But the following
splitter uses SLOT_TEMP too and in between expansion and split1 there is
a possibility that something extends the lifetime of SLOT_TEMP created
slots across an instruction that will be split by this splitter.

The following patch fixes it by using a new temp slot kind to make sure
it doesn't reuse a SLOT_TEMP that could be live across the instruction.

2022-02-25  Jakub Jelinek  

PR target/104674
* config/i386/i386.h (enum ix86_stack_slot): Add
SLOT_FLOATxFDI_387.
* config/i386/i386.md (splitter to floatdi2_i387_with_xmm):
Use
SLOT_FLOATxFDI_387 rather than SLOT_TEMP.

* gcc.target/i386/pr104674.c: New test.

(cherry picked from commit eabf7bbe601f2c0d87bd0a1012d7a602df2037da)

[Bug tree-optimization/104675] [9/10/11 Regression] ICE: in expand_expr_real_2, at expr.cc:9773 at -O with __real__ + __imag__ extraction

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1305c28bc0665504643ff364595b7d6bb222745d

commit r11-9719-g1305c28bc0665504643ff364595b7d6bb222745d
Author: Jakub Jelinek 
Date:   Fri Feb 25 10:55:17 2022 +0100

match.pd: Don't create BIT_NOT_EXPRs for COMPLEX_TYPE [PR104675]

We don't support BIT_{AND,IOR,XOR,NOT}_EXPR on complex types,
&/|/^ are just rejected for them, and ~ is parsed as CONJ_EXPR.
So, we should avoid simplifications which turn valid complex type
expressions into something that will ICE during expansion.

2022-02-25  Jakub Jelinek  

PR tree-optimization/104675
* match.pd (-A - 1 -> ~A, -1 - A -> ~A): Don't simplify for
COMPLEX_TYPE.

* gcc.dg/pr104675-1.c: New test.
* gcc.dg/pr104675-2.c: New test.

(cherry picked from commit 758671b88b78d7629376b118ec6ca6bcfbabbd36)

[Bug tree-optimization/104601] [11 Regression] Invalid branch elimination at -O2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9718-gd29a0b50687dc42e17dc4a4fe335afafefeada4e
Author: Jakub Jelinek 
Date:   Thu Feb 24 15:29:02 2022 +0100

sccvn: Fix visit_reference_op_call value numbering of vdefs [PR104601]

The following testcase is miscompiled, because -fipa-pure-const discovers
that bar is const, but when sccvn during fre3 sees
  # .MEM_140 = VDEF <.MEM_96>
  *__pred$__d_43 = _50 (_49);
where _50 value numbers to &bar, it value numbers .MEM_140 to
vuse_ssa_val (gimple_vuse (stmt)).  For const/pure calls that return
a SSA_NAME (or don't have lhs) that is fine, those calls don't store
anything, but if the lhs is present and not an SSA_NAME, value numbering
the vdef to anything but itself means that e.g. walk_non_aliased_vuses
won't consider the call, but the call acts as a store to its lhs.
When it is ignored, sccvn will return whatever has been stored to the
lhs earlier.

I've bootstrapped/regtested an earlier version of this patch, which did the
if (!lhs && gimple_call_lhs (stmt))
  changed |= set_ssa_val_to (vdef, vdef);
part before else if (vnresult->result_vdef), and that regressed
+FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo (" 1
+FAIL: gcc.dg/pr51879-16.c scan-tree-dump-times pre "foo2 (" 1
so this updated patch uses result_vdef there as before and only otherwise
(which I think must be the const/pure case) decides based on whether the
lhs is non-SSA_NAME.

2022-02-24  Jakub Jelinek  

PR tree-optimization/104601
* tree-ssa-sccvn.c (visit_reference_op_call): For calls with
non-SSA_NAME lhs value number vdef to itself instead of e.g. the
vuse value number.

* g++.dg/torture/pr104601.C: New test.

(cherry picked from commit 9251b457eb8df912f2e8203d0ee8ab300c041520)

[Bug lto/104617] Bug in handling of 64k+ sections

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:4e046995094df30be16e37f639efe77887197a22

commit r11-9717-g4e046995094df30be16e37f639efe77887197a22
Author: Jakub Jelinek 
Date:   Tue Feb 22 11:32:08 2022 +0100

libiberty: Fix up debug.temp.o creation if *.o has 64K+ sections [PR104617]

On
 #define A(n) int foo1##n(void) { return 1##n; }
 #define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6)
A(n##7) A(n##8) A(n##9)
 #define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6)
B(n##7) B(n##8) B(n##9)
 #define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6)
C(n##7) C(n##8) C(n##9)
 #define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6)
D(n##7) D(n##8) D(n##9)
 E(0) E(1) E(2) D(30) D(31) C(320) C(321) C(322) C(323) C(324) C(325)
 B(3260) B(3261) B(3262) B(3263) A(32640) A(32641) A(32642)
testcase with
./xgcc -B ./ -c -g -fpic -ffat-lto-objects -flto  -O0 -o foo1.o foo1.c
-ffunction-sections
./xgcc -B ./ -shared -g -fpic -flto -O0 -o foo1.so foo1.o
/tmp/ccTW8mBm.debug.temp.o: file not recognized: file format not recognized
(testcase too slow to be included into testsuite).
The problem is clearly reported by readelf:
readelf: foo1.o.debug.temp.o: Warning: Section 2 has an out of range
sh_link value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 5 has an out of range
sh_link value of 65321
readelf: foo1.o.debug.temp.o: Warning: Section 10 has an out of range
sh_link value of 65323
readelf: foo1.o.debug.temp.o: Warning: [ 2]: Link field (65321) should
index a symtab section.
readelf: foo1.o.debug.temp.o: Warning: [ 5]: Link field (65321) should
index a symtab section.
readelf: foo1.o.debug.temp.o: Warning: [10]: Link field (65323) should
index a string section.
because simple_object_elf_copy_lto_debug_sections doesn't adjust sh_info
and
sh_link fields in ElfNN_Shdr if they are in between SHN_{LO,HI}RESERVE
inclusive.  Not adjusting those is incorrect though, SHN_{LO,HI}RESERVE
range is only relevant to the 16-bit fields, mainly st_shndx in ElfNN_Sym
where if one needs >= SHN_LORESERVE section number, SHN_XINDEX should be
used instead and .symtab_shndx section should contain the real section
index, and in ElfNN_Ehdr e_shnum and e_shstrndx fields, where if >=
SHN_LORESERVE value is needed it should put those into
Shdr[0].sh_{size,link}.  But, sh_{link,info} are 32-bit fields which can
contain any section index.

Note, as simple-object-elf.c mentions, binutils from 2.12 to 2.18 (so
before
2011) used to mishandle the > 63.75K sections case and assumed there is a
hole in between the sections, but what
simple_object_elf_copy_lto_debug_sections does wouldn't help in that case
for the debug temp object creation, we'd need to detect the case also in
that routine and take it into account in the remapping etc.  I think
it is not worth it given that it is over 10 years, if somebody needs
63.75K or more sections, better use more recent binutils.

2022-02-22  Jakub Jelinek  

PR lto/104617
* simple-object-elf.c (simple_object_elf_match): Fix up URL
in comment.
(simple_object_elf_copy_lto_debug_sections): Remap sh_info and
sh_link even if they are in the SHN_LORESERVE .. SHN_HIRESERVE
range (inclusive).

(cherry picked from commit 2f59f067610f22c3f2ec9b1516e24b85836676ed)

[Bug sanitizer/102656] [11 Regression] ICE on coroutines on -fsanitize=address -O1 since r11-1613-g788b962aa00959e8

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:92374fd237cdbdf4d2c08ffb216d2ebcc799dc4b

commit r11-9716-g92374fd237cdbdf4d2c08ffb216d2ebcc799dc4b
Author: Jakub Jelinek 
Date:   Sat Feb 19 09:03:57 2022 +0100

asan: Mark instrumented vars addressable [PR102656]

We ICE on the following testcase, because the asan1 pass decides to
instrument
  .x = 0;
and does that by
  _13 = &.x;
  .ASAN_CHECK (7, _13, 4, 4);
  .x = 0;
and later sanopt pass turns that into:
  _39 = (unsigned long) &.x;
  _40 = _39 >> 3;
  _41 = _40 + 2147450880;
  _42 = (signed char *) _41;
  _43 = *_42;
  _44 = _43 != 0;
  _45 = _39 & 7;
  _46 = (signed char) _45;
  _47 = _46 + 3;
  _48 = _47 >= _43;
  _49 = _44 & _48;
  if (_49 != 0)
goto ; [0.05%]
  else
goto ; [99.95%]

   [local count: 536864]:
  __builtin___asan_report_store4 (_39);

   [local count: 1073741824]:
  .x = 0;
The problem is during expansion,  isn't marked TREE_ADDRESSABLE,
even when we take its address in (unsigned long) &.x.

Now, instrument_derefs has code to avoid the instrumentation altogether
if we can prove the access is within bounds of an automatic variable in the
current function and the var isn't TREE_ADDRESSABLE (or we don't instrument
use after scope), but we do it solely for VAR_DECLs.

I think we should treat RESULT_DECLs exactly like that too, which is what
the following patch does.  I must say I'm unsure about PARM_DECLs, those
can
have different cases, either they are fully or partially passed in
registers, then if we take parameter's address, they are in a local copy
inside of a function and so work like those automatic vars.  But if they
are fully passed in memory, we typically just take address of the slot
and in that case they live in the caller's frame.  It is true we don't
(can't) put any asan padding in between the arguments, so all asan could
detect in that case is if caller passes fewer on stack arguments or smaller
arguments than callee accepts.  Anyway, as I'm unsure, I haven't added
PARM_DECLs to that case.

And another thing is, when we actually build_fold_addr_expr, we need to
mark_addressable the inner if it isn't addressable already.

2022-02-19  Jakub Jelinek  

PR sanitizer/102656
* asan.c (instrument_derefs): If inner is a RESULT_DECL and access
is
known to be within bounds, treat it like automatic variables.
If instrumenting access and inner is {VAR,PARM,RESULT}_DECL from
current function and !TREE_STATIC which is not TREE_ADDRESSABLE,
mark
it addressable.

* g++.dg/asan/pr102656.C: New test.

(cherry picked from commit 9e3bbb4a8024121eb0fa675cb1f074218c1345a6)

[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #44 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #43)
> One thing I found by experiments:
> Insert 64 vaddps %xmm18, %xmm19, %xmm20(no dependence between each other,
> just emulate for pipeline) before stalled load, stlf stall case is as fast
> as no stall cases on CLX. I guess this is "distance" you mean.
> 
But there's still event for STLF blocks, guess processor scheduler helps here.

[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #43 from Hongtao.liu  ---
One thing I found by experiments:
Insert 64 vaddps %xmm18, %xmm19, %xmm20(no dependence between each other, just
emulate for pipeline) before stalled load, stlf stall case is as fast as no
stall cases on CLX. I guess this is "distance" you mean.

Is there any existed structure in GCC I can get latency from entry to the load
instruction? And of course for loop with unknown trip count, latency can't be
exactly estimated. Similar for cases when load is in join_bb, guess we need to
calculate "average" latency among all possible predecessors?

[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly

[guojiufu at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jiu Fu Guo  ---
starting to process insn 14
  v:  1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60,
61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80,
81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99,
100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115,
116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131,
132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147,
148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163,
164, 165, 166, 167, 168, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203,
204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216
i = 32, index = 1
i = 33, index = 2
i = 34, index = 3
i = 35, index = 4
i = 36, index = 5
i = 37, index = 6
i = 38, index = 7
i = 39, index = 8
deferring deletion of insn with uid = 14.

[Bug rtl-optimization/105091] RTL dse1 remove stack mem storing incorrectly

[guojiufu at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jiu Fu Guo  ---
Checking the dumps from dse1, some "stack memory store" are deleted
incorrectly.

   12: %3:DI=call [`runtime.newobject'] argc:0
  REG_CALL_DECL `runtime.newobject'
   13: r117:DI=%3:DI
  REG_DEAD %3:DI
   14: [sfp:DI+0x20]=r117:DI
  REG_DEAD r117:DI
dse1 removes instruction 14.

[Bug target/104915] Miss optimization for vec_setv8hi_0

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
Created attachment 52705
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52705&action=edit
Patch pending for GCC13

[Bug rtl-optimization/105091] New: RTL dse1 remove stack mem storing incorrectly

[guojiufu at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 105091
   Summary: RTL dse1 remove stack mem storing incorrectly
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

Code is narrowed from math/big which passes at the early of r12(r12-656). 
With -fdisable-rtl-dse1, the case also passes. 

_testmain.go
package main

import "fmt"
import "testing"
import "testing/internal/testdeps"
import __os__ "os"

type Bits []int

func TestMulBits(t *testing.T) {
for _, test := range []struct {
x, y, want Bits
}{

{Bits{}, Bits{}, nil},
{Bits{0}, Bits{0}, Bits{0}},
} {
p := test.x
fmt.Printf("%v", p)
}
}

var tests = []testing.InternalTest {
{"TestMulBits", TestMulBits},
}
var benchmarks = []testing.InternalBenchmark{
}
var fuzzTargets = []testing.InternalFuzzTarget{
}
var examples = []testing.InternalExample{
}

func main() {
m := testing.MainStart(testdeps.TestDeps{}, tests, benchmarks,
fuzzTargets, examples)

__os__.Exit(m.Run())
}
-

> gccgo -O2 _testmain.go && ./a.out -test.v
=== RUN   TestMulBits
[35185086168544 32199672319005300 268454424 268599296 35185086167968 15 32
35185086167968 15 35184405205936 824635867296 15 35184393891632 0
35185086168112]--- FAIL: TestMulBits (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference
[recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x20d08280]

goroutine 17 [running]:
testing.tRunner..func3
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/testing/testing.go:1425
testing.tRunner..func1
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/testing/testing.go:1342
panic
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/runtime/panic.go:714
reflect.typedmemmove
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/runtime/mbarrier.go:197
reflect.packEface
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/reflect/value.go:123
reflect.valueInterface
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/reflect/value.go:930
reflect.Value.Interface
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/reflect/value.go:890
fmt.pp.printValue
/home/guojiufu/gcc/gcc-mainline-base/libgo/go/fmt/print.go:722



> gccgo -O2 _testmain.go -fdisable-rtl-dse1  && ./a.out -test.v
go1: note: disable pass rtl-dse1 for functions in the range of [0, 4294967295]
=== RUN   TestMulBits
[][0]--- PASS: TestMulBits (0.00s)
PASS

> gccgo -v
Using built-in specs.
COLLECT_GCC=/home/guojiufu/gcc/install/gcc-mainline-base-debug/bin/gccgo
COLLECT_LTO_WRAPPER=/home/guojiufu/gcc/install/gcc-mainline-base-debug/libexec/gcc/powerpc64le-unknown-linux-gnu/12.0.1/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/guojiufu/gcc/gcc-mainline-base/configure
--enable-languages=c,c++,go --with-cpu=native --enable-checking
--with-long-double-128
--prefix=/home/guojiufu/gcc/install/gcc-mainline-base-debug --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220318 (experimental) (GCC)


I encounter this on ppc64le and did not reproduce it x86_64.

[Bug c/84685] Designated initializers warning

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed for GCC 11+.

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/104944] [9/10 Regression] incorrect alignas(void) accepted (with warning if templated)

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
.

[Bug c++/104944] [9/10 Regression] incorrect alignas(void) accepted (with warning if templated)

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression] incorrect
   |incorrect alignas(void) |alignas(void) accepted
   |accepted (with warning if   |(with warning if templated)
   |templated)  |

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

[Bug c++/104284] [9/10 Regression] ICE: unexpected expression '' of kind implicit_conv_expr since r9-6073-ge8b3c1bc3ba22dcf

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
Summary|[9/10/11 Regression] ICE:   |[9/10 Regression] ICE:
   |unexpected expression   |unexpected expression
   |'' of kind   |'' of kind
   |implicit_conv_expr since|implicit_conv_expr since
   |r9-6073-ge8b3c1bc3ba22dcf   |r9-6073-ge8b3c1bc3ba22dcf
 Status|ASSIGNED|RESOLVED

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

[Bug c++/104108] [10 Regression] [c++17+] template alias inside template with static field of template class rejected since r10-6329-g423284053ec51832

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11 Regression] [c++17+] |[10 Regression] [c++17+]
   |template alias inside   |template alias inside
   |template with static field  |template with static field
   |of template class rejected  |of template class rejected
   |since   |since
   |r10-6329-g423284053ec51832  |r10-6329-g423284053ec51832
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug c++/102990] [9/10 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
   |tsubst_copy_and_build with  |tsubst_copy_and_build with
   |NSDMI and double to int |NSDMI and double to int
   |conversion  |conversion
 Status|ASSIGNED|RESOLVED

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

[Bug c++/101371] [9/10 Regression] constexpr expansions trigger internal Compiler Error

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Summary|[9/10/11 Regression]|[9/10 Regression] constexpr
   |constexpr expansions|expansions trigger internal
   |trigger internal Compiler   |Compiler Error
   |Error   |

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

[Bug c/84685] Designated initializers warning

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9715-g0fa9022aa30b9c4dde965a0406943c8c0af5eb54
Author: Marek Polacek 
Date:   Tue Mar 22 14:37:02 2022 -0400

c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

This patch fixes two kinds of wrong -Wmissing-field-initializers
warnings.  Our docs say that this warning "does not warn about designated
initializers", but we give a warning for

1) the array case:

  struct S {
struct N {
  int a;
  int b;
} c[1];
  } d = {
.c[0].a = 1,
.c[0].b = 1, // missing initializer for field 'b' of 'struct N'
  };

we warn because push_init_level, when constructing an array, clears
constructor_designated (which the warning relies on), and we forget
that we were in a designated initializer context.  Fixed by the
push_init_level hunk; and

2) the compound literal case:

  struct T {
int a;
int *b;
int c;
  };

  struct T t = { .b = (int[]){1} }; // missing initializer for field 'c' of
'struct T'

where set_designator properly sets constructor_designated to 1, but the
compound literal causes us to create a whole new initializer_stack in
start_init, which clears constructor_designated.  Then, after we've parsed
the compound literal, finish_init flushes the initializer_stack entry,
but doesn't restore constructor_designated, so we forget we were in
a designated initializer context, which causes the bogus warning.  (The
designated flag is also tracked in constructor_stack, but in this case,
we didn't perform push_init_level between set_designator and start_init
so it wasn't saved anywhere.)

PR c/82283
PR c/84685

gcc/c/ChangeLog:

* c-typeck.c (struct initializer_stack): Add 'designated' member.
(start_init): Set it.
(finish_init): Restore constructor_designated.
(push_init_level): Set constructor_designated to the value of
constructor_designated in the upper constructor_stack.

gcc/testsuite/ChangeLog:

* gcc.dg/Wmissing-field-initializers-1.c: New test.
* gcc.dg/Wmissing-field-initializers-2.c: New test.
* gcc.dg/Wmissing-field-initializers-3.c: New test.
* gcc.dg/Wmissing-field-initializers-4.c: New test.
* gcc.dg/Wmissing-field-initializers-5.c: New test.

(cherry picked from commit 4b7d9f8f51bd96d290aac230c71e501fcb6b21a6)

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

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

commit r11-9715-g0fa9022aa30b9c4dde965a0406943c8c0af5eb54
Author: Marek Polacek 
Date:   Tue Mar 22 14:37:02 2022 -0400

c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

This patch fixes two kinds of wrong -Wmissing-field-initializers
warnings.  Our docs say that this warning "does not warn about designated
initializers", but we give a warning for

1) the array case:

  struct S {
struct N {
  int a;
  int b;
} c[1];
  } d = {
.c[0].a = 1,
.c[0].b = 1, // missing initializer for field 'b' of 'struct N'
  };

we warn because push_init_level, when constructing an array, clears
constructor_designated (which the warning relies on), and we forget
that we were in a designated initializer context.  Fixed by the
push_init_level hunk; and

2) the compound literal case:

  struct T {
int a;
int *b;
int c;
  };

  struct T t = { .b = (int[]){1} }; // missing initializer for field 'c' of
'struct T'

where set_designator properly sets constructor_designated to 1, but the
compound literal causes us to create a whole new initializer_stack in
start_init, which clears constructor_designated.  Then, after we've parsed
the compound literal, finish_init flushes the initializer_stack entry,
but doesn't restore constructor_designated, so we forget we were in
a designated initializer context, which causes the bogus warning.  (The
designated flag is also tracked in constructor_stack, but in this case,
we didn't perform push_init_level between set_designator and start_init
so it wasn't saved anywhere.)

PR c/82283
PR c/84685

gcc/c/ChangeLog:

* c-typeck.c (struct initializer_stack): Add 'designated' member.
(start_init): Set it.
(finish_init): Restore constructor_designated.
(push_init_level): Set constructor_designated to the value of
constructor_designated in the upper constructor_stack.

gcc/testsuite/ChangeLog:

* gcc.dg/Wmissing-field-initializers-1.c: New test.
* gcc.dg/Wmissing-field-initializers-2.c: New test.
* gcc.dg/Wmissing-field-initializers-3.c: New test.
* gcc.dg/Wmissing-field-initializers-4.c: New test.
* gcc.dg/Wmissing-field-initializers-5.c: New test.

(cherry picked from commit 4b7d9f8f51bd96d290aac230c71e501fcb6b21a6)

[Bug c++/104944] [9/10/11 Regression] incorrect alignas(void) accepted (with warning if templated)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

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

commit r11-9714-gfe641f6a44959ff8b9d9f7af11b8b806c5f1375a
Author: Marek Polacek 
Date:   Wed Mar 23 17:12:29 2022 -0400

c++: alignas and alignof void [PR104944]

I started looking into this PR because in GCC 4.9 we were able to
detect the invalid

  struct alignas(void) S{};

but I broke it in r210262.

It's ill-formed code in C++:
[dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
the same effect as alignas(alignof(type-id))", and [expr.align]/1:
"The operand shall be a type-id representing a complete object type,
or an array thereof, or a reference to one of those types." and void
is not a complete type.

It's also invalid in C:
6.7.5: _Alignas(type-name) is equivalent to _Alignas(_Alignof(type-name))
6.5.3.4: "The _Alignof operator shall not be applied to a function type
or an incomplete type."

We have a GNU extension whereby we treat sizeof(void) as 1, but I assume
it doesn't apply to alignof, at least in C++.  However, __alignof__(void)
is still accepted with a -Wpedantic warning.

We still say "invalid application of 'alignof'" rather than 'alignas' in
the
void diagnostic, but I felt that fixing that may not be suitable as part of
this patch.  The "incomplete type" diagnostic still always prints
'__alignof__'.

PR c++/104944

gcc/cp/ChangeLog:

* typeck.c (cxx_sizeof_or_alignof_type): Diagnose alignof(void).
(cxx_alignas_expr): Call cxx_sizeof_or_alignof_type with
complain == true.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alignas20.C: New test.

(cherry picked from commit d0b938a7612fb7acf1f181da9577235c83ede59e)

[Bug c++/104284] [9/10/11 Regression] ICE: unexpected expression '' of kind implicit_conv_expr since r9-6073-ge8b3c1bc3ba22dcf

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:2a2b944c18936f9dfa880e8ff54906cfe90e89e8

commit r11-9713-g2a2b944c18936f9dfa880e8ff54906cfe90e89e8
Author: Marek Polacek 
Date:   Thu Mar 17 14:39:37 2022 -0400

c++: ICE with template code in constexpr [PR104284]

Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.

It happens because we're performing build_vec_init while processing
a template, which calls get_temp_regvar which creates an INIT_EXPR.
This INIT_EXPR's RHS contains an rvalue conversion so we create an
IMPLICIT_CONV_EXPR.  Its operand is not type-dependent and the whole
INIT_EXPR is not type-dependent.  So we call build_non_dependent_expr
which, with -fchecking=2, calls fold_non_dependent_expr.  At this
point the expression still has an IMPLICIT_CONV_EXPR, which ought to
be handled in instantiate_non_dependent_expr_internal.  However,
tsubst_copy_and_build doesn't handle INIT_EXPR; it will just call
tsubst_copy which does nothing when args is null.  So we fail to
replace the IMPLICIT_CONV_EXPR and ICE.

The problem is that we call build_vec_init in a template in the
first place.  We can avoid doing so by checking p_t_d before
calling build_aggr_init in check_initializer.

PR c++/104284

gcc/cp/ChangeLog:

* decl.c (check_initializer): Don't call build_aggr_init in
a template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-104284-1.C: New test.
* g++.dg/cpp1y/constexpr-104284-2.C: New test.
* g++.dg/cpp1y/constexpr-104284-3.C: New test.
* g++.dg/cpp1y/constexpr-104284-4.C: New test.

(cherry picked from commit 9fdac7e16c940fb6264e6ddaf99c761f1a64a054)

[Bug c++/104108] [10/11 Regression] [c++17+] template alias inside template with static field of template class rejected since r10-6329-g423284053ec51832

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:58e08fb6ffd0842c7b813eb7122fe8660df33bf1

commit r11-9712-g58e08fb6ffd0842c7b813eb7122fe8660df33bf1
Author: Marek Polacek 
Date:   Tue Mar 8 13:55:15 2022 -0500

c++: Wrong error with alias template in class tmpl [PR104108]

In r10-6329 I tried to optimize the number of calls to v_d_e_p in
convert_nontype_argument by remembering whether the expression was
value-dependent in a bool flag.  I did that wrongly assuming that its
value-dependence will not be changed by build_converted_constant_expr.
This testcase shows that it can: b_c_c_e gets a VAR_DECL for m_parameter,
which is not value-dependent, but we're converting it to "const int &"
so it returns

  (const int &)(const int *) &m_parameter

which suddenly becomes value-dependent because of the added ADDR_EXPR:
has_value_dependent_address is now true because m_parameter's context S
is dependent.  With this bug in place, we went to the second branch here:

  if (TYPE_REF_OBJ_P (TREE_TYPE (expr)) && val_dep_p)
/* OK, dependent reference.  We don't want to ask whether a DECL is
   itself value-dependent, since what we want here is its address. 
*/;
  else
{
  expr = build_address (expr);

  if (invalid_tparm_referent_p (type, expr, complain))
return NULL_TREE;
}

wherein build_address created a bad tree and then i_t_r_p complained.

PR c++/104108

gcc/cp/ChangeLog:

* pt.c (convert_nontype_argument): Recompute
value_dependent_expression_p after build_converted_constant_expr.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-74.C: New test.

(cherry picked from commit d54ce4641ed10208be36fd514cae8ff1153c)

[Bug c++/102990] [9/10/11 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

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

commit r11-9711-g6ba2a7e7474135b717c344030b114ffd6ad8ed7a
Author: Marek Polacek 
Date:   Tue Mar 22 18:42:27 2022 -0400

c++: FIX_TRUNC_EXPR in tsubst [PR102990]

This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().

The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it
was introduced in r181478, but it did the wrong thing, whereupon it
was turned into gcc_unreachable () in r258821 (see this thread:
).

In a template, we should never create a FIX_TRUNC_EXPR (that's what
conv_unsafe_in_template_p is for).  But in this test we are NOT in
a template when we call digest_nsdmi_init which ends up calling
convert_like, converting 1.0e+0 to int, so convert_to_integer_1
gives us a FIX_TRUNC_EXPR.

But then when we get to parsing f's parameters, we are in a template
when processing decltype(Helpers{}), and since r268321, when the
compound literal isn't instantiation-dependent and the type isn't
type-dependent, finish_compound_literal falls back to the normal
processing, so it calls digest_init, which does fold_non_dependent_init
and since the FIX_TRUNC_EXPR isn't dependent, we instantiate and
therefore crash in tsubst_copy_and_build.

The fateful call to fold_non_dependent_init comes from massage_init_elt,
We shouldn't be calling f_n_d_i on the result of get_nsdmi.  This we can
avoid by eschewing calling f_n_d_i on CONSTRUCTORs; their elements have
already been folded.

PR c++/102990

gcc/cp/ChangeLog:

* typeck2.c (massage_init_elt): Avoid folding CONSTRUCTORs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template22.C: New test.
* g++.dg/cpp0x/nsdmi-template23.C: New test.

(cherry picked from commit f0530882d99abc410bb080051aa04e5cea848f18)

[Bug c++/101371] [9/10/11 Regression] constexpr expansions trigger internal Compiler Error

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-9710-gda47a84e277c7fbeebbf9c1e7dc1e8ba3277fe53
Author: Marek Polacek 
Date:   Tue Jul 13 17:16:54 2021 -0400

c++: constexpr array reference and value-initialization [PR101371]

This PR gave me a hard time: I saw multiple issues starting with
different revisions.  But ultimately the root cause seems to be
the following, and the attached patch fixes all issues I've found
here.

In cxx_eval_array_reference we create a new constexpr context for the
CP_AGGREGATE_TYPE_P case, but we also have to create it for the
non-aggregate case.  In this test, we are evaluating

  ((B *)this)->a = rhs->a

which means that we set ctx.object to ((B *)this)->a.  Then we proceed
to evaluate the initializer, rhs->a.  For *rhs, we eval rhs, a PARM_DECL,
for which we have (const B &) &c.arr[0] in the hash table.  Then
cxx_fold_indirect_ref gives us c.arr[0].  c is evaluated to {.arr={}} so
c.arr is {}.  Now we want c.arr[0], so we end up in
cxx_eval_array_reference
and since we're initializing from {}, we call build_value_init which
gives us an AGGR_INIT_EXPR that calls 'constexpr B::B()'.  Then we
evaluate this AGGR_INIT_EXPR and since its first argument is dummy,
we take ctx.object instead.  But that is the wrong object, we're not
initializing ((B *)this)->a here.  And so we wound up with an
initializer for A, and then crash in cxx_eval_component_reference:

  gcc_assert (DECL_CONTEXT (part) == TYPE_MAIN_VARIANT (TREE_TYPE
(whole)));

where DECL_CONTEXT (part) is B (as it should be) but the type of whole
was A.

So create a new object, if there already was one, and the element type
is not a scalar.

PR c++/101371

gcc/cp/ChangeLog:

* constexpr.c (cxx_eval_array_reference): Create a new .object
and .ctor for the non-aggregate non-scalar case too when
value-initializing.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-101371-2.C: New test.
* g++.dg/cpp1y/constexpr-101371.C: New test.

(cherry picked from commit a42f8120442cf3ba25d621bed857b5be19019d0c)

[Bug analyzer/105087] fanalyzer double free false positive with vasprintf

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed on trunk for GCC 12 by the above commit.

Please let me know if you run into other false positives building parted with
-fanalyzer.

[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV since r12-7809-g5f6197d7c197f9d2

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/105087] fanalyzer double free false positive with vasprintf

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:3734527dfa0d10a50aee2f088d3732fd65bf

commit r12-7869-g3734527dfa0d10a50aee2f088d3732fd65bf
Author: David Malcolm 
Date:   Mon Mar 28 20:41:23 2022 -0400

analyzer: ensure that we purge state when reusing a conjured_svalue
[PR105087]

PR analyzer/105087 describes a false positive from
-Wanalyzer-double-free in which the analyzer erroneously considers two
successive inlined vasprintf calls to have allocated the same pointer.

The root cause is that the result written back from vasprintf is a
conjured_svalue, and that we normally purge state when reusing a
conjured_svalue, but various places in the code were calling
region_model_manager::get_or_create_conjured_svalue but failing to
then call region_model::purge_state_involving on the result.

This patch fixes things by moving responsibility for calling
region_model::purge_state_involving into
region_model_manager::get_or_create_conjured_svalue, so that it is
always called when reusing a conjured_svalue, fixing the false positive.

gcc/analyzer/ChangeLog:
PR analyzer/105087
* analyzer.h (class conjured_purge): New forward decl.
* region-model-asm.cc (region_model::on_asm_stmt): Add
conjured_purge param to calls binding_cluster::on_asm and
region_model_manager::get_or_create_conjured_svalue.
* region-model-impl-calls.cc
(call_details::get_or_create_conjured_svalue): Likewise for call
to region_model_manager::get_or_create_conjured_svalue.
(region_model::impl_call_fgets): Remove call to
region_model::purge_state_involving, as this is now done
implicitly by call_details::get_or_create_conjured_svalue.
(region_model::impl_call_fread): Likewise.
(region_model::impl_call_strchr): Pass conjured_purge param to
call to region_model_manager::get_or_create_conjured_svalue.
* region-model-manager.cc (conjured_purge::purge): New.
(region_model_manager::get_or_create_conjured_svalue): Add
param "p".  Use it to purge state when reusing an existing
conjured_svalue.
* region-model.cc (region_model::on_call_pre): Replace call to
region_model::purge_state_involving with passing conjured_purge
to region_model_manager::get_or_create_conjured_svalue.
(region_model::handle_unrecognized_call): Pass conjured_purge to
store::on_unknown_fncall.
* region-model.h
(region_model_manager::get_or_create_conjured_svalue): Add param
"p".
* store.cc (binding_cluster::on_unknown_fncall): Likewise.  Pass
it on to region_model_manager::get_or_create_conjured_svalue.
(binding_cluster::on_asm): Likewise.
(store::on_unknown_fncall): Add param "p" and pass it on to
binding_cluster::on_unknown_fncall.
* store.h (binding_cluster::on_unknown_fncall): Add param p.
(binding_cluster::on_asm): Likewise.
(store::on_unknown_fncall): Likewise.
* svalue.h (class conjured_purge): New.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/pr105087-1.c: New test.
* gcc.dg/analyzer/pr105087-2.c: New test.
* gcc.dg/analyzer/vasprintf-1.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105074] [12 Regression] -fanalyzer ICEs on gnutls-3.7.3: cgraph_node::get_edge(gimple*) SIGSEGV since r12-7809-g5f6197d7c197f9d2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1203e8f7880c9751ece5f5302e413b20f4608a00

commit r12-7868-g1203e8f7880c9751ece5f5302e413b20f4608a00
Author: David Malcolm 
Date:   Mon Mar 28 20:40:16 2022 -0400

analyzer: fix ICE with incorrect lookup of cgraph node [PR105074]

gcc/analyzer/ChangeLog:
PR analyzer/105074
* region.cc (ipa_ref_requires_tracking): Drop "context_fndecl",
instead using the ref->referring to get the cgraph node of the
caller.
(symnode_requires_tracking_p): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/105074
* gcc.dg/analyzer/pr105074.c: New test.
* gcc.dg/analyzer/untracked-1.c (extern_fn_char_ptr): New decl.
(test_13): New.

Signed-off-by: David Malcolm 

[Bug middle-end/103597] [12 Regression] False -Wimplicit-fallthrough= involving macro since r12-5638-ga3e75c1491cd2d50

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Marek Polacek  ---
(In reply to Jason Merrill from comment #6)
> I'm marking this as middle-end; as mentioned in the commit message, I
> removed the folding from the front-end because it was interfering with a
> middle-end experiment richi was doing.  I'm also fine with reverting the
> change.

No worries, I have a middle-end patch now.

[Bug analyzer/105087] fanalyzer double free false positive with vasprintf

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from David Malcolm  ---
Am testing a fix.

[Bug tree-optimization/105090] New: BFI instructions are not generated on arm-none-eabi-g++

[andrew.jeddeloh at gmail dot com via Gcc-bugs]

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

Bug ID: 105090
   Summary: BFI instructions are not generated on
arm-none-eabi-g++
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.jeddeloh at gmail dot com
  Target Milestone: ---

Created attachment 52704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52704&action=edit
.ii file for test case

The following code could generate a BFI instruction but does not. Clang will
generate one.

#include 
uint32_t emplace(uint32_t into, uint32_t what) {
constexpr uint32_t shift = 5;
constexpr uint32_t width = 4;
constexpr uint32_t mask = ((1 << width) - 1) << shift;
return (into & ~mask) | ((what << shift) & mask);
}

you can write equivalent C code and get the same problem.

gcc 8.5 and clang generate:
bfi r0, r1, #5, #4
bx  lr

Whereas 9.3+ generates:
lslsr1, r1, #5
and r1, r1, #480
bic r0, r0, #480
orrsr0, r0, r1
bx  lr

These are compiled with arm-none-eabi-gcc -Wall -Wextra -mcpu=cortex-m4 -O3 -c
Compile output is silent. Attached is .ii
I also tried O2, O1 and Os.

See problem with godbolt: https://godbolt.org/z/57h5Yd9ov

A lot of embedded development involves setting certain chunks of memory mapped
registers like this and would greatly benefit from this being fixed. 

GCC version info from my computer:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/11.2.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-11.2.0/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib
--with-newlib --with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Arch Repository)



Possibly related but I'm not sure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85628

[Bug sanitizer/105084] ASAN false positive on global-buffer-overflow

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #3 from Li Shaohua  ---
Thanks a lot for your explanation. That makes sense to me :).

[Bug tree-optimization/105086] [12 Regression] Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
Ranger VRP doesn't simulate edges the same way VRP does. It looks like VRP
simulates the back edge twice and the second time notes that the MAX value is
greater than it was before and "projects" the max to +INF to avoid further
simulations and thus executing every instance of the loop. 

This allows it to refine the range in the loop better, which ranger VRP isn't
doing as it is still doing a DOM walk and doesn't revisit the node. ANd I
haven't added any sort of similar "projection" logic to the back edge
processing.

I have an alternate question.  it looks like when we utilize scev to pick up
ranges we just give up if scev_probably_wraps_p() is true.

Analyzing # of iterations of loop 1
  exit condition 1 < [4294967273, + , 1]
  bounds on difference of bases: 4294967272 ... 4294967272
  result:
# of iterations 23, bounded by 23

Statement (exit)if (a_1 > 1)
is executed at most 23 (bounded by 23) + 1 times in loop 1.

but we neglect to create range for the PHI. We should be able to properly
create a  range for this from the SCEV info rather than giving up?  It would be
[0,0][4294967273, 4294967295]. 

And even with the old value_range we could use anti-range and produce
~[1, 4294967272]?

Is there a practical reason we don't look any closer at wrap cases to see if
they are "simple wraps" or not?  I think that would also solve this issue.

[Bug c++/59426] __has_trivial_{copy/assign} behavior differs from documentation

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |12.0
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/59426] __has_trivial_{copy/assign} behavior differs from documentation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:83a21c993449a32b98916814ed8ca237b3276912

commit r12-7863-g83a21c993449a32b98916814ed8ca237b3276912
Author: Jason Merrill 
Date:   Mon Mar 28 15:32:30 2022 -0400

c++: Fix __has_trivial_* docs [PR59426]

These have been misdocumented since C++98 POD was split into C++11 trivial
and standard-layout in r149721.

PR c++/59426

gcc/ChangeLog:

* doc/extend.texi: Refer to __is_trivial instead of __is_pod.

[Bug c++/103291] [11 Regression] #pragma gcc visibility is lost for external decls declared inside a function

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug c++/102123] [11 Regression] Internal Compiler Error occurs during template deduction in use with templates as template parameters

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug c++/103968] [11 Regression] ICE and segfault when instantiating template with lvalue ref argument and nested template type

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/102045] [11 regression] constructor is not being instantiated

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/104847] [11 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed

[Bug analyzer/105087] fanalyzer double free false positive with vasprintf

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from David Malcolm  ---
#include "analyzer-decls.h"

extern void inner_alloc (void **);

void * __attribute__((noinline))
outer_alloc (void)
{
  void *result;
  inner_alloc (&result);
  return result;
}

void test_1 (void)
{
  void *p, *q;

  p = outer_alloc ();
  q = outer_alloc ();
  __analyzer_eval (p == q); // bug: analyzer thinks this is true
}

[Bug c++/103769] [11 Regression] checking ICE in hashtab_chk_error with alias template and pack expansion after r11-7931

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed.

[Bug analyzer/105087] fanalyzer double free false positive with vasprintf

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from David Malcolm  ---
#include "analyzer-decls.h"

extern void *inner_alloc (void);

void * __attribute__((noinline))
outer_alloc (void)
{
  return inner_alloc ();
}

void test_1 (void)
{
  void *p, *q;

  p = outer_alloc ();
  q = outer_alloc ();
  __analyzer_eval (p == q); // analyzer correctly thinks this is unknown
}

[Bug c++/104107] [9/10 Regression] parsing crashes on class template instantiation since r9-6853-g17838af989014f5e

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression] parsing
   |parsing crashes on class|crashes on class template
   |template instantiation  |instantiation since
   |since   |r9-6853-g17838af989014f5e
   |r9-6853-g17838af989014f5e   |

--- Comment #7 from Jason Merrill  ---
and for 11.3.

[Bug c++/104107] [9/10/11 Regression] parsing crashes on class template instantiation since r9-6853-g17838af989014f5e

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:450e82794245c49248711f1479c491d84cb46c57

commit r11-9708-g450e82794245c49248711f1479c491d84cb46c57
Author: Jason Merrill 
Date:   Thu Feb 10 17:57:38 2022 -0500

c++: TTP in member alias template [PR104107]

In the first testcase, coerce_template_template_parms was adding too much
of
outer_args when coercing to match P's template parameters, so that when
substituting into the 'const T&' parameter we got an unrelated template
argument for T.  We should only add outer_args when the argument template
is
a nested template.

PR c++/104107
PR c++/95036

gcc/cp/ChangeLog:

* pt.c (coerce_template_template_parms): Take full parms.
Avoid adding too much of outer_args.
(coerce_template_template_parm): Adjust.
(template_template_parm_bindings_ok_p): Adjust.
(convert_template_argument): Adjust.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-ttp2.C: New test.
* g++.dg/cpp1z/ttp2.C: New test.

[Bug c++/95036] [9/10/11 Regression] ICE with variadic template template parameters

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:450e82794245c49248711f1479c491d84cb46c57

commit r11-9708-g450e82794245c49248711f1479c491d84cb46c57
Author: Jason Merrill 
Date:   Thu Feb 10 17:57:38 2022 -0500

c++: TTP in member alias template [PR104107]

In the first testcase, coerce_template_template_parms was adding too much
of
outer_args when coercing to match P's template parameters, so that when
substituting into the 'const T&' parameter we got an unrelated template
argument for T.  We should only add outer_args when the argument template
is
a nested template.

PR c++/104107
PR c++/95036

gcc/cp/ChangeLog:

* pt.c (coerce_template_template_parms): Take full parms.
Avoid adding too much of outer_args.
(coerce_template_template_parm): Adjust.
(template_template_parm_bindings_ok_p): Adjust.
(convert_template_argument): Adjust.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-ttp2.C: New test.
* g++.dg/cpp1z/ttp2.C: New test.

[Bug c++/99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since r11-7011-g6e0a231a4aa2407b

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-9707-g3bf2e1bfc9858516e028137b313e4c689b0c8cd4
Author: Jason Merrill 
Date:   Fri Mar 25 11:26:06 2022 -0400

c++: ICE with alias in pack expansion [PR103769]

This was breaking because when we stripped the 't' typedef in s...>
to be s, the TYPE_MAIN_VARIANT of "Args..." was still
"t...", because type pack expansions are treated as types.  Fixed by
using the right function to copy a "type".

PR c++/99445
PR c++/103769

gcc/cp/ChangeLog:

* tree.c (strip_typedefs): Use build_distinct_type_copy.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic-alias5.C: New test.

[Bug c++/104847] [11 Regression] ICE in write_unqualified_name, at cp/mangle.cc:1406

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:07d7e8b8ae2879241207631fcaeaa83e5e85a240

commit r11-9706-g07d7e8b8ae2879241207631fcaeaa83e5e85a240
Author: Jason Merrill 
Date:   Sat Mar 26 20:10:19 2022 -0400

c++: mangling union{1} in template [PR104847]

My implementation of union non-type template arguments in r11-2016 broke
braced casts of union type, because they are still in syntactic
(undigested)
form.

PR c++/104847

gcc/cp/ChangeLog:

* mangle.c (write_expression): Don't write a union designator when
undigested.

gcc/testsuite/ChangeLog:

* g++.dg/abi/mangle-union1.C: New test.

[Bug c++/103769] [11 Regression] checking ICE in hashtab_chk_error with alias template and pack expansion after r11-7931

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-9707-g3bf2e1bfc9858516e028137b313e4c689b0c8cd4
Author: Jason Merrill 
Date:   Fri Mar 25 11:26:06 2022 -0400

c++: ICE with alias in pack expansion [PR103769]

This was breaking because when we stripped the 't' typedef in s...>
to be s, the TYPE_MAIN_VARIANT of "Args..." was still
"t...", because type pack expansions are treated as types.  Fixed by
using the right function to copy a "type".

PR c++/99445
PR c++/103769

gcc/cp/ChangeLog:

* tree.c (strip_typedefs): Use build_distinct_type_copy.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic-alias5.C: New test.

[Bug c++/102045] [11 regression] constructor is not being instantiated

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:14146bb58f279659279cd189bf95c3b0cb5fe1ac

commit r11-9705-g14146bb58f279659279cd189bf95c3b0cb5fe1ac
Author: Jason Merrill 
Date:   Sat Mar 26 20:38:54 2022 -0400

c++: missing aggregate base ctor [PR102045]

When make_base_init_ok changes a call to a complete constructor into a call
to a base constructor, we were never marking the base ctor as used, so it
didn't get emitted.

PR c++/102045

gcc/cp/ChangeLog:

* call.c (make_base_init_ok): Call make_used.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/aggr-base12.C: New test.

[Bug c++/103968] [11 Regression] ICE and segfault when instantiating template with lvalue ref argument and nested template type

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:97390a9914672f5ce73c169b3ae7fd4bba25c2fe

commit r11-9704-g97390a9914672f5ce73c169b3ae7fd4bba25c2fe
Author: Jason Merrill 
Date:   Sun Mar 27 00:28:30 2022 -0400

c++: member alias declaration [PR103968]

Here, we were wrongly thinking that (const Options&)Widget::c_options is
not value-dependent because neither the type nor the (value of) c_options
are dependent, but since we're binding it to a reference we also need to
consider that it has a value-dependent address.

PR c++/103968

gcc/cp/ChangeLog:

* pt.c (value_dependent_expression_p): Check
has_value_dependent_address for conversion to reference.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-mem1.C: New test.

[Bug c++/102123] [11 Regression] Internal Compiler Error occurs during template deduction in use with templates as template parameters

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-9703-ge952290874d6b99946dc02e125c0fb0e9b13a1e3
Author: Jason Merrill 
Date:   Sat Mar 26 23:54:22 2022 -0400

c++: CTAD and member alias template [PR102123]

When building a deduction guide from the Test constructor, we need to
rewrite the use of _dummy into a dependent reference, i.e.
Test::template
_dummy.  We were using SCOPE_REF for both type and non-type templates; we
need to use UNBOUND_CLASS_TEMPLATE for type templates.

PR c++/102123

gcc/cp/ChangeLog:

* pt.c (tsubst_copy): Use make_unbound_class_template for rewriting
a type template reference.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction110.C: New test.

[Bug c++/103291] [11 Regression] #pragma gcc visibility is lost for external decls declared inside a function

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:10dcd13ff7a9f0fbbae8749929e8808792c76395

commit r11-9702-g10dcd13ff7a9f0fbbae8749929e8808792c76395
Author: Jason Merrill 
Date:   Sun Mar 27 09:44:59 2022 -0400

c++: visibility of local extern [PR103291]

When setting up the hidden namespace-scope decl for a local extern, we also
need to set its visibility.

PR c++/103291

gcc/cp/ChangeLog:

* name-lookup.c (push_local_extern_decl_alias): Call
determine_visibility.

gcc/testsuite/ChangeLog:

* g++.dg/ext/visibility/visibility-local-extern1.C: New test.

[Bug analyzer/105087] fanalyzer double free false positive with vasprintf

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2022-03-28
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug; confirmed.

FWIW it's treating all three of buf, bar, and baz as having the same
conjured_svalue (and, surprisingly, from the __builtin_va_end call due to it
treating args as having escaped at the vasprintf call).

EN 386:
preds: EN: 378
succs: EN: 396
callstring: [(SN: 17 -> SN: 2 in main)]
before (SN: 15 stmt: 1): 
free (bar_15);
48 | free(bar);
   | ^

rmodel:
stack depth: 2
  frame (index 1): frame: ‘run_test’@2
  frame (index 0): frame: ‘main’@1
clusters within root region
  cluster for: (*INIT_VAL(argv)): CONJURED(__builtin_va_end (&args);,
(*INIT_VAL(argv))) (ESCAPED) (TOUCHED)
clusters within frame: ‘main’@1
  cluster for: _3: CONJURED(_3 = run_test ();, _3)
clusters within frame: ‘run_test’@2
  cluster for: bar_15: CONJURED(__builtin_va_end (&args);, resultp)
  cluster for: baz_19: CONJURED(__builtin_va_end (&args);, resultp)
m_called_unknown_fn: TRUE
constraint_manager:
  equiv classes:
  constraints:
malloc: 
  0x4f72180: CONJURED(__builtin_va_end (&args);, resultp): freed (‘bar_15’)

Looks like I need to "teach" -fanalyzer about vasprintf (and va_start/end, for
that matter)

[Bug debug/105089] New: CTF for a defined extern variable is ambiguous

[ibhagat at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 105089
   Summary: CTF for a defined extern variable is ambiguous
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibhagat at gcc dot gnu.org
  Target Milestone: ---

$ cat extern.c
extern const char a[];
const char a[] = "testme";

$ gcc -gctf -dA -S extern.c

excerpt from extern.s:

.long   0x5 # objtinfo_var_type
.long   0x8 # objtinfo_var_type
.long   0xb # objtinfo_name
.long   0x1f# objtinfo_name
.long   0xb # ctv_name
.long   0x5 # ctv_typeidx
.long   0x1f# ctv_name
.long   0x8 # ctv_typeidx

There are TWO CTF variable records (two ctv_name, each with a ctv_typeidx). 
Further, two CTF objects records as well.

$ gcc -gctf -c extern.c
$ objdump --ctf=.ctf extern.o
shows:

  Variables:
a ->  8: const const char [7] (size 0x7) -> 7: const char [7] (size 0x7)
a ->  5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0)

  Types:
 1: char (size 0x1)
[0x0] (ID 0x1) (kind 1) char  (aligned at 0x1, format 0x3, offset:bits
0x0:0x8)
 2: const char (size 0x1) -> 1: char (size 0x1)
[0x0] (ID 0x2) (kind 12) const char  (aligned at 0x1)
 3: void (size 0x0)
[0x0] (ID 0x3) (kind 1) void  (aligned at 0x0, format 0x1, offset:bits
0x0:0x0)
 4: const char [0] (size 0x0)
[0x0] (ID 0x4) (kind 4) const char [0]  (aligned at 0x1)
 5: const const char [0] (size 0x0) -> 4: const char [0] (size 0x0)
[0x0] (ID 0x5) (kind 12) const const char [0]  (aligned at 0x1)
 6: long unsigned int (size 0x8)
[0x0] (ID 0x6) (kind 1) long unsigned int  (aligned at 0x8, format 0x0,
offset:bits 0x0:0x40)
 7: const char [7] (size 0x7)
[0x0] (ID 0x7) (kind 4) const char [7]  (aligned at 0x1)
 8: const const char [7] (size 0x7) -> 7: const char [7] (size 0x7)
[0x0] (ID 0x8) (kind 12) const const char [7]  (aligned at 0x1)

  Strings:
0: 
1: char
6: void
b: a
d: long unsigned int
1f: a
...

Note, two entries in the "Variables:" sub-section, and two strings "a" for the
variable name in the "Strings:" sub-section.

In the above case, the compiler must emit only one entry for the variable a
with type specified as const char [7].

Note that, CTF format cannot differentiate between a non-defining extern
variable declaration vs. a defining variable declaration (unlike DWARF). So,
emitting two CTF variable records, one for the non-defining decl and another
for the defining decl will create ambiguity for the linker/CTF reader.

[Bug c++/105067] [12 Regression] ICE: in operator[], at vec.h:889 since r12-7631-g9413bb55185b9e88

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed.

[Bug c++/105064] [10/11 Regression] requires crashes gcc

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression] requires
   |requires crashes gcc|crashes gcc

--- Comment #12 from Patrick Palka  ---
Fixed for GCC 12 so far.

[Bug c++/105067] [12 Regression] ICE: in operator[], at vec.h:889 since r12-7631-g9413bb55185b9e88

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:23e57329c6516a81a8d3eb21b365ca8a0ec0c41b

commit r12-7861-g23e57329c6516a81a8d3eb21b365ca8a0ec0c41b
Author: Patrick Palka 
Date:   Mon Mar 28 14:15:39 2022 -0400

c++: reject concept w/ multiple tparm lists [PR105067]

We weren't rejecting a concept declared with multiple template
parameter lists.

PR c++/105067

gcc/cp/ChangeLog:

* pt.cc (finish_concept_definition): Check that a concept is
declared with exactly one template parameter list.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-err4.C: New test.

[Bug c++/105064] [10/11/12 Regression] requires crashes gcc

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-7860-gecb4882e362e80a1bf172453ac9b366edbb4e89c
Author: Patrick Palka 
Date:   Mon Mar 28 14:15:16 2022 -0400

c++: constrained template friend matching ICE [PR105064]

Here during declaration matching for the two constrained template
friends, we crash from maybe_substitute_reqs_for because the second
friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called
indirectly from push_template_decl).

As far as I can tell, this situation happens only when declaring a
constrained template friend within a non-template class (as in the
testcase), in which case the substitution would be a no-op anyway.
So this patch rearranges maybe_substitute_reqs_for to gracefully
handle missing DECL_TEMPLATE_INFO by just skipping the substitution.

PR c++/105064

gcc/cp/ChangeLog:

* constraint.cc (maybe_substitute_reqs_for): Don't assume
DECL_TEMPLATE_INFO is available.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-friend9.C: New test.

[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path

[simon.marchi at polymtl dot ca via Gcc-bugs]

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

--- Comment #1 from Simon Marchi  ---
Looking at the .s, I see that gcc attempts to pass "/tmp/cwd/test.c" as the
name of the file at index 0:

  .file 0 "/home/simark" "/tmp/cwd/test.c"

If gas did put "/tmp/cwd/test.c" as the name in the line table header, it would
be fine.  But in the gas doc [1]:

> When emitting DWARF2 line number information, .file assigns filenames to the 
> .debug_line file name table. The syntax is:
> 
> .file fileno filename
> 
> The fileno operand should be a unique positive integer to use as the index of 
> the entry in the table. The filename operand is a C string literal enclosed 
> in double quotes. The filename can include directory elements. If it does, 
> then the directory will be added to the directory table and the basename will 
> be added to the file table. 

So, gas always only puts the basename as the name in the line table header,
that's why we end up with just "test.c".

[1] https://sourceware.org/binutils/docs/as/File.html#File

[Bug target/105068] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: ssse3_pshufbv16qi3)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r12-7859-gcccbb776589c1825de1bd2eefabb11d72ef28de8
Author: H.J. Lu 
Date:   Mon Mar 28 09:32:53 2022 -0700

x86: Also use Yw in *ssse3_pshufbv8qi3 clobber

PR target/105068
* config/i386/sse.md (*ssse3_pshufbv8qi3): Also replace "Yv" with
"Yw" in clobber.

[Bug debug/105088] New: Small DWARF 5 spec violation in line table when passing an absolute path

[simon.marchi at polymtl dot ca via Gcc-bugs]

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

Bug ID: 105088
   Summary: Small DWARF 5 spec violation in line table when
passing an absolute path
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

With:

$ gcc --version
gcc (GCC) 11.2.0
$ as --version
GNU assembler (GNU Binutils) 2.38


I have a source file at /tmp/cwd/test.c and compile it with:

$ gcc /tmp/cwd/test.c -g3 -O0 -gdwarf-5

The DW_AT_name of the CU is "/tmp/cwd/test.c":

<12>   DW_AT_name: (line_strp) (offset: 0xd): /tmp/cwd/test.c

The entry at index 0 in the file names table, in the line table header, is
"test.c":

0   (udata) 1   (line_strp) (offset: 0x16): test.c

In section 6.2.4 (The Line Number Program Header), bullet 20 (file_names),
DWARF5.pdf says:

> The first entry in the sequence is the primary source file whose file name
exactly matches that given in the DW_AT_name attribute in the compilation
unit debugging information entry.

The debug info produced by the toolchain therefore seems to not respect the
spec: the name of the primary source file in the line table header ("test.c")
does not match the DW_AT_name attribute in the compilation unit DIE
("/tmp/cwd/test.c").

[Bug tree-optimization/105086] [12 Regression] Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-28
Summary|Dead Code Elimination   |[12 Regression] Dead Code
   |Regression at -Os (trunk|Elimination Regression at
   |vs. 11.2.0) 25  |-Os (trunk vs. 11.2.0) 25

--- Comment #1 from Jakub Jelinek  ---
Started with r12-4871-g502ffb1f389011b28ee51815242c7397790802d5

[Bug analyzer/105087] New: fanalyzer double free false positive with vasprintf

[bcl at redhat dot com via Gcc-bugs]

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

Bug ID: 105087
   Summary: fanalyzer double free false positive with vasprintf
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bcl at redhat dot com
  Target Milestone: ---

Created attachment 52703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52703&action=edit
Minimal reproducer main.c

While building parted I've run into what seems like a bug. I've created a
minimal reproducer which I'll attach. In parted we have a wrapper around
vasprintf called zasprintf, and it looks like the analyzer doesn't understand
that vasprintf returns a new allocation on each call which is passed back out
of the function.

Compiling it with 'gcc -o main -g -fanalyzer -fdump-analyzer -Wall ./main.c'

results in a complaint that there is a double free of buf:

./main.c: In function ‘run_test’:
./main.c:48:5: warning: double-‘free’ of ‘bar’ [CWE-415]
[-Wanalyzer-double-free]
   48 | free(bar);
  | ^
  ‘main’: events 1-2
|
|   54 | int main(int argc, char **argv) {
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|   55 | return run_test();
|  |~~
|  ||
|  |(2) calling ‘run_test’ from ‘main’
|
+--> ‘run_test’: events 3-4
   |
   |   21 | int run_test() {
   |  | ^~~~
   |  | |
   |  | (3) entry to ‘run_test’
   |..
   |   29 | buf = zasprintf("i = %d", i);
   |  |   ~~
   |  |   |
   |  |   (4) calling ‘zasprintf’ from ‘run_test’
   |
   +--> ‘zasprintf’: events 5-7
  |
  |   11 | zasprintf (const char *format, ...)
  |  | ^
  |  | |
  |  | (5) entry to ‘zasprintf’
  |..
  |   18 |   return r < 0 ? NULL : resultp;
  |  |  ~~
  |  |   |
  |  |   (6) following ‘true’ branch
(when ‘r >= 0’)...
  |  |   (7) ...to here
  |
   <--+
   |
 ‘run_test’: events 8-9
   |
   |   29 | buf = zasprintf("i = %d", i);
   |  |   ^~
   |  |   |
   |  |   (8) returning to ‘run_test’ from ‘zasprintf’
   |..
   |   34 | bar = zasprintf("i = %d - %d", i, i - 13);
   |  |   ~~~
   |  |   |
   |  |   (9) calling ‘zasprintf’ from ‘run_test’
   |
   +--> ‘zasprintf’: events 10-12
  |
  |   11 | zasprintf (const char *format, ...)
  |  | ^
  |  | |
  |  | (10) entry to ‘zasprintf’
  |..
  |   18 |   return r < 0 ? NULL : resultp;
  |  |  ~~
  |  |   |
  |  |   (11) following ‘true’ branch
(when ‘r >= 0’)...
  |  |   (12) ...to here
  |
   <--+
   |
 ‘run_test’: events 13-14
   |
   |   34 | bar = zasprintf("i = %d - %d", i, i - 13);
   |  |   ^~~
   |  |   |
   |  |   (13) returning to ‘run_test’ from ‘zasprintf’
   |..
   |   40 | baz = zasprintf("No i's here");
   |  |   
   |  |   |
   |  |   (14) calling ‘zasprintf’ from ‘run_test’
   |
   +--> ‘zasprintf’: events 15-17
  |
  |   11 | zasprintf (const char *format, ...)
  |  | ^
  |  | |
  |  | (15) entry to ‘zasprintf’
  |..
  |   18 |   return r < 0 ? NULL : resultp;
  |  |  ~~
  |  |   |
  |  |   (16) following ‘true’ branch
(when ‘r >= 0’)...
  |  |   (17) ...to here
  |
   <--+
   |
 ‘run_test’: events 18-20
   |
   |   40 

[Bug tree-optimization/105086] New: Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

[yann at ywg dot ch via Gcc-bugs]

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

Bug ID: 105086
   Summary: Dead Code Elimination Regression at -Os (trunk vs.
11.2.0) 25
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at ywg dot ch
  Target Milestone: ---

Created attachment 52702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52702&action=edit
The case presented.

cat case.c #25
void foo();
int main() {
  unsigned a = -23;
  for (; a >= 2; ++a)
if (a == 55)
  foo();
}

`gcc-0127fb1b78a36a7b228d4b3fe32eedfc8d273363 (trunk) -Os` can not eliminate
`foo` but `gcc-releases/gcc-11.2.0 -Os` can.

`gcc-0127fb1b78a36a7b228d4b3fe32eedfc8d273363 (trunk) -Os -S -o /dev/stdout
case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movl$-23, %eax
.L6:
cmpl$55, %eax
je  .L10
incl%eax
jne .L6
xorl%eax, %eax
ret
.L10:
pushq   %rax
.cfi_def_cfa_offset 16
.L7:
xorl%eax, %eax
callfoo
movl$56, %eax
.L2:
incl%eax
je  .L12
cmpl$55, %eax
jne .L2
jmp .L7
.L12:
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -


`gcc-releases/gcc-11.2.0 -Os -S -o /dev/stdout case.c`
- OUTPUT -
main:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret
-- END OUTPUT -


Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=502ffb1f389011b28ee51815242c7397790802d5

- Build information -
- 0127fb1b78a36a7b228d4b3fe32eedfc8d273363 (trunk)
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/compiler_cache/gcc-0127fb1b78a36a7b228d4b3fe32eedfc8d273363
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220328 (experimental) (GCC)

- releases/gcc-11.2.0
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/compiler_cache/gcc-01a9836c07053b3286b2259d6b628c7583413f55
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)

[Bug testsuite/105085] New: Excess errors from new test case gcc.dg/analyzer/untracked-1.c in r12-7809-g5f6197d7c197f9

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 105085
   Summary: Excess errors from new test case
gcc.dg/analyzer/untracked-1.c in
r12-7809-g5f6197d7c197f9
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:5f6197d7c197f9d2b7fb2e1a19dac39a023755e8, r12-7809-g5f6197d7c197f9
make  -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/untracked-1.c"
FAIL: gcc.dg/analyzer/untracked-1.c (test for excess errors)
# of expected passes13
# of unexpected failures1


FAIL: gcc.dg/analyzer/untracked-1.c (test for excess errors)
Excess errors:
cc1: warning: track '*.LC1': yes

Author: David Malcolm 
Date:   Thu Mar 24 20:58:10 2022 -0400

analyzer: add region::tracked_p to optimize state objects [PR104954]

[Bug target/104818] Duplicate word "version" in option -mptx description

[vries at gcc dot gnu.org via Gcc-bugs]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #2 from Tom de Vries  ---
Fixed in aforementioned commit.

[Bug target/104818] Duplicate word "version" in option -mptx description

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

https://gcc.gnu.org/g:0127fb1b78a36a7b228d4b3fe32eedfc8d273363

commit r12-7858-g0127fb1b78a36a7b228d4b3fe32eedfc8d273363
Author: Tom de Vries 
Date:   Mon Mar 28 17:55:49 2022 +0200

[nvptx] Improve help description of misa and mptx

Currently we have:
...
$ gcc --target-help 2>&1 | egrep "misa|mptx"
  -misa=  Specify the version of the ptx ISA to use.
  -mptx=  Specify the version of the ptx version to
use.
  Known PTX ISA versions (for use with the -misa= option):
  Known PTX versions (for use with the -mptx= option):
...

As reported in PR104818, the "version of the ptx version" doesn't make much
sense.

Furthermore, the description of misa (and 'Known ISA versions') is
misleading
because it does not specify the version of the PTX ISA, but rather the PTX
ISA
target architecture.

Fix this by printing instead:
...
$ gcc --target-help 2>&1 | egrep "misa|mptx"
  -misa=  Specify the PTX ISA target architecture to
use.
  -mptx=  Specify the PTX ISA version to use.
  Known PTX ISA target architectures (for use with the -misa= option):
  Known PTX ISA versions (for use with the -mptx= option):
...

Tested on nvptx.

gcc/ChangeLog:

2022-03-28  Tom de Vries  

PR target/104818
* config/nvptx/gen-opt.sh (ptx_isa): Improve help text.
* config/nvptx/nvptx-gen.opt: Regenerate.
* config/nvptx/nvptx.opt (misa, mptx, ptx_version): Improve help
text.
* config/nvptx/t-nvptx (s-nvptx-gen-opt): Add missing dependency on
gen-opt.sh.

[Bug target/105068] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: ssse3_pshufbv16qi3)

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
 Depends on||99321

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 12 and GCC 11.3.  Won't backport to GCC 10 branch since this fix
depends on the PR 99321 fix.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
[Bug 99321] [11 Regression] ICE: in extract_constrain_insn, at recog.c:2670:
insn does not satisfy its constraints: {*uminv16qi3} since
r11-7121-g37876976b0511ec9

[Bug tree-optimization/105078] Maybe wrong *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE

[siddhesh at gcc dot gnu.org via Gcc-bugs]

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Siddhesh Poyarekar  ---
OK then, this one is a WONTFIX too, the libQt6 version of the function should
reliably produce the intended effect qtbase needs.

[Bug middle-end/104787] [12 Regression] False positive -Wreturn-type since r12-5638-ga3e75c1491cd2d50

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |middle-end

--- Comment #2 from Jason Merrill  ---
Changing to middle-end, as discussed in PR103597.

[Bug debug/103597] [12 Regression] False -Wimplicit-fallthrough= involving macro since r12-5638-ga3e75c1491cd2d50

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |debug

--- Comment #6 from Jason Merrill  ---
I'm marking this as middle-end; as mentioned in the commit message, I removed
the folding from the front-end because it was interfering with a middle-end
experiment richi was doing.  I'm also fine with reverting the change.

[Bug sanitizer/105084] ASAN false positive on global-buffer-overflow

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jakub Jelinek  ---
Neither is false positive, both are real bugs in your test programs.
The fact that on the second testcase a violation isn't reported at -O0 and is
at -O2 depends on the ordering of the global variables (we emit a then b for
-O0 and b then a for -O2).
We only emit the red zones after each variable, not both before and after each
var, because that would waste too much memory especially in programs that use a
lot of translation units and very few global vars in each.
If all the translation units in a program (or shared library) are compiled with
-fsanitize=address, the net effect is that underflows for the first variable
(probably in each section variables are present) aren't detected, when mixing
-fsanitize=address and non-sanitized objects it can result in more underflows
not being detected.

[Bug tree-optimization/105078] Maybe wrong *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
No, IMHO we shouldn't look through that.
We should leave some way for Qt to actually implement what they want...
And doing the computation on uintptr_t certainly looks like that.

[Bug tree-optimization/105078] Maybe wrong *** buffer overflow detected ***: terminated with -D_FORTIFY_SOURCE

[siddhesh at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Siddhesh Poyarekar  ---
(In reply to Martin Liška from comment #4)
> Note the libQt6 version of the function looking approximately like this:
> 

This doesn't warn anymore (and doesn't crash either) because objsz cannot get
past the bit_and_expr:

  gimple_assign 
  gimple_assign 
  gimple_assign 
  gimple_call <__builtin_object_size, _2, start_13, 1>

However, ISTM from the remaining IR that thanks to the casts, it will see the
right size if it got past the bit_and_expr.

Jakub, should we recognize bit_and_expr in objsz for gcc13?

[Bug sanitizer/105084] ASAN false positive on global-buffer-overflow

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #1 from Li Shaohua  ---
Sorry, the triggering program should be the following:

$cat a.c
int a[] = {3};
int b = 7;

main() {
unsigned int *c = &b;
*c = a[-1];
}