[Bug target/104014] [12 Regression] r12-6538 breaks bootstrap with --with-arch=native --with-cpu=native

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
.

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug testsuite/104023] New: Bulk rename of C++ test files to one filename extension ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 104023
   Summary: Bulk rename of C++ test files to one filename
extension ?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I notice the following in the testsuite:

[/home/dcb/gcc/trunk.git/gcc/testsuite] $ find . -name \*.C -print | wc -l
18461
[/home/dcb/gcc/trunk.git/gcc/testsuite] $ find . -name \*.cc -print | wc -l
168
[/home/dcb/gcc/trunk.git/gcc/testsuite] $ find . -name \*.cpp -print | wc -l
23
[/home/dcb/gcc/trunk.git/gcc/testsuite] $ find . -name \*.cxx -print | wc -l
0
[/home/dcb/gcc/trunk.git/gcc/testsuite] $ 

Would it be a good idea to pick one filename extension for C++ testsuite files
and stick to it ?

Maybe moving to *.C would be cheap, but I notice that the main
parts of the compiler are moving to using *.cc, implying that 
over 18,000 files might have to be moved to *.cc

Just an idea. Given the amount of work involved, it might not be worth it.

[Bug tree-optimization/104018] Comparison against 0 propagates into other statement causing no-CSE from happening

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-14
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The "unfortunate" thing is that FRE1 figures out they are equal but there's
no SSA name available with the value to replace the PHI node with ... it needs
PRE hoisting to apply the CSE which is too late.

It's DOM doing the equivalence propagation btw. (I think DOM is even the only
pass doing this).

[Bug tree-optimization/104009] [12 Regression] r12-6030-g422f9eb7011b76c1 breaks kernel build

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Siddhesh Poyarekar
:

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

commit r12-6568-g17df585a3a6a852c71883cc2ff40e111a6875149
Author: Siddhesh Poyarekar 
Date:   Fri Jan 14 08:56:15 2022 +0530

tree-optimization/104009: Conservative underflow estimate in object size

Restrict negative offset computation only to dynamic object sizes, where
size expressions are accurate and not a maximum/minimum estimate and in
cases where negative offsets definitely mean an underflow, e.g. in
MEM_REF of the whole object with negative ofset in addr_object_size.

This ends up missing some cases where __builtin_object_size could have
come up with more precise results, so tests have been adjusted to
reflect that.

gcc/ChangeLog:

PR tree-optimization/104009
* tree-object-size.c (compute_builtin_object_size): Bail out on
negative offset.
(plus_stmt_object_size): Return maximum of wholesize and minimum
of 0 for negative offset.

gcc/testsuite/ChangeLog:

PR tree-optimization/104009
* gcc.dg/builtin-object-size-1.c (test10): New test.
* gcc.dg/builtin-object-size-3.c (test10): Likewise.
(test9): Expect zero size for negative offsets.
* gcc.dg/builtin-object-size-4.c (test8): Likewise.
* gcc.dg/builtin-object-size-5.c (test7): Drop test for
__builtin_object_size.

Signed-off-by: Siddhesh Poyarekar 

[Bug tree-optimization/104009] [12 Regression] r12-6030-g422f9eb7011b76c1 breaks kernel build

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #4 from Siddhesh Poyarekar  ---
I built a `make allyesconfig` kernel with this patch and trunk as of yesterday,
so fixed.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

--- Comment #1 from Andrew Pinski  ---
I think the testsuite only tests .C anyways. I am not in front of the computer
right now but you could check the .exp files to see if the other ones are
actually being tested.

[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Richard Biener  ---
Not sure if I can parse the assembly.  The rev quoted changes costing, so I
assume the rest is the same.  I see

t.c:5:20: missed:   not vectorized: relevant stmt not supported: _24 = _27 ==
_25;
t.c:5:13: note:   Building vector operands of 0x3411680 from scalars instead
t.c:5:13: note:   ==> examining statement: _22 = (int) _24;
t.c:5:13: missed:   type conversion to/from bit-precision unsupported.
t.c:5:20: missed:   not vectorized: relevant stmt not supported: _22 = (int)
_24;
t.c:5:13: note:   Building vector operands of 0x34115f8 from scalars instead

and so we end up with

t.c:5:13: note: * Analysis succeeded with vector mode V8QI
t.c:5:13: note: SLPing BB part
t.c:5:13: note: Costing subgraph:
t.c:5:13: note: node 0x3411570 (max_nunits=4, refcnt=1)
t.c:5:13: note: op template: *dest_15(D) = _22;
t.c:5:13: note: stmt 0 *dest_15(D) = _22;
t.c:5:13: note: stmt 1 *_45 = _46;
t.c:5:13: note: stmt 2 *_60 = _61;
t.c:5:13: note: stmt 3 *_8 = _9;
t.c:5:13: note: children 0x34115f8
t.c:5:13: note: node (external) 0x34115f8 (max_nunits=4, refcnt=1)
t.c:5:13: note: stmt 0 _22 = (int) _24;
t.c:5:13: note: stmt 1 _46 = (int) _44;
t.c:5:13: note: stmt 2 _61 = (int) _59;
t.c:5:13: note: stmt 3 _9 = (int) _7;
t.c:5:13: note: children 0x3411680
t.c:5:13: note: node (external) 0x3411680 (max_nunits=4, refcnt=1)
t.c:5:13: note: stmt 0 _24 = _27 == _25;
t.c:5:13: note: stmt 1 _44 = _41 == _43;
t.c:5:13: note: stmt 2 _59 = _56 == _58;
t.c:5:13: note: stmt 3 _7 = _4 == _6;
t.c:5:13: note: children 0x3411708 0x3411790
t.c:5:13: note: node 0x3411708 (max_nunits=2, refcnt=1)
t.c:5:13: note: op template: _27 = *a_13(D);
t.c:5:13: note: stmt 0 _27 = *a_13(D);
t.c:5:13: note: stmt 1 _41 = *_40;
t.c:5:13: note: stmt 2 _56 = *_55;
t.c:5:13: note: stmt 3 _4 = *_3;
t.c:5:13: note: node 0x3411790 (max_nunits=2, refcnt=1)
t.c:5:13: note: op template: _25 = *b_14(D);
t.c:5:13: note: stmt 0 _25 = *b_14(D);
t.c:5:13: note: stmt 1 _43 = *_42;
t.c:5:13: note: stmt 2 _58 = *_57;
t.c:5:13: note: stmt 3 _6 = *_5;
t.c:5:13: note: Cost model analysis:
_22 1 times scalar_store costs 1 in body
_46 1 times scalar_store costs 1 in body
_61 1 times scalar_store costs 1 in body
_9 1 times scalar_store costs 1 in body
_22 2 times unaligned_store (misalign -1) costs 2 in body
 1 times vec_construct costs 2 in prologue
 1 times vec_construct costs 2 in prologue
t.c:5:13: note: Cost model analysis for part in loop 0:
  Vector cost: 6
  Scalar cost: 4
t.c:5:13: missed: not vectorized: vectorization is not profitable.

but maybe I'm doing sth wrong since your assembler has the compare vectorized.

I'm doing, with a cc1 cross configured as

./src/trunk/configure --target=arm-none-linux-gnueabihf --with-float=hard
--with-cpu=cortex-a9 --with-fpu=neon-fp1

> ./cc1 -quiet t.c -I include -mcpu=cortex-a9 -mfpu=neon -O3

[Bug testsuite/104021] gcc.dg/vect/tsvc tests failures

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thanks for the patch, can you please commit it?

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

--- Comment #2 from Richard Biener  ---
it depends on the specific sub-harness which suffix is included in the globs
...

[Bug testsuite/104022] g++.dg/gcov/pr16855.C does not precleanup upon failures

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
The patch is pre-approved, please commit it.

[Bug target/104024] New: ICE in curr_insn_transform, at lra-constraints.c:4132

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

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

Bug ID: 104024
   Summary: ICE in curr_insn_transform, at lra-constraints.c:4132
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: krebbel at gcc dot gnu.org, segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64-linux-gnu

The following ICEs:

$ ppc64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-6.c
-O1 -mpower10-fusion -mpower10-fusion-2logical
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-1.h:1,
 from
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-6.c:5:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-6.c:
In function ‘t100_1add’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:28:1:
error: unable to generate reloads for:
   28 | }   \
  | ^
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:159:1:
note: in expansion of macro ‘T’
  159 | T (n, t, t, t, v1, v2, vr, b, o)
  | ^
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-1.h:4:1:
note: in expansion of macro ‘ST’
4 | ST (100, signed type, 2, 3, 5, U(s, add), 0) \
  | ^~
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-6.c:11:1:
note: in expansion of macro ‘TESTS’
   11 | TESTS (__int128, INT128_MIN, INT128_MAX)
  | ^
(insn 13 78 50 2 (parallel [
(set (reg:TI 128)
(and:TI (xor:TI (reg:TI 124)
(reg/v:TI 123 [ y ]))
(reg:TI 127)))
(clobber (reg:TI 147))
])
"/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-6.c":11:1
2690 {*fuse_vxor_vand}
 (expr_list:REG_UNUSED (reg:TI 147)
(expr_list:REG_DEAD (reg:TI 127)
(expr_list:REG_DEAD (reg/v:TI 123 [ y ])
(nil)
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:28:1:
internal compiler error: in curr_insn_transform, at lra-constraints.c:4132
   28 | }   \
  | ^
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow.h:159:1:
note: in expansion of macro ‘T’
  159 | T (n, t, t, t, v1, v2, vr, b, o)
  | ^
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-1.h:4:1:
note: in expansion of macro ‘ST’
4 | ST (100, signed type, 2, 3, 5, U(s, add), 0) \
  | ^~
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/torture/builtin-arith-overflow-6.c:11:1:
note: in expansion of macro ‘TESTS’
   11 | TESTS (__int128, INT128_MIN, INT128_MAX)
  | ^
0x5f1d79 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/rtl-error.c:108
0x5ea4c8 curr_insn_transform
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/lra-constraints.c:4132
0xa00cc5 lra_constraints(bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/lra-constraints.c:5161
0x9ef182 lra(_IO_FILE*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/lra.c:2336
0x9ab6a9 do_reload
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/ira.c:5934
0x9ab6a9 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64/build/gcc/ira.c:6120
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362

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

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

--- Comment #4 from Richard Biener  ---
Btw, you show V4SI vectorization but the analysis with this mode has the loads
unsupported for me:

t.c:5:13: note:   ==> examining statement: _27 = *a_13(D);
t.c:5:13: missed:   Aligned load, but unsupported type.
t.c:5:16: missed:   not vectorized: relevant stmt not supported: _27 =
*a_13(D);
t.c:5:13: note:   Building vector operands of 0x3411790 from scalars instead

and

t.c:5:13: note:   ==> examining statement: *dest_15(D) = _22;
t.c:5:13: note:   vect_is_simple_use: operand (int) _44, type of def: internal
t.c:5:13: note:   vect_is_simple_use: operand (int) _59, type of def: internal
t.c:5:13: note:   vect_is_simple_use: operand (int) _7, type of def: internal
t.c:5:13: missed:   unsupported unaligned access
t.c:5:13: missed:   not vectorized: relevant stmt not supported: *dest_15(D) =
_22;

please make sure to post _exact_ instructions on how to configure & invoke cc1,
the arm family is a mess and it's wasting my time each and every time I have to
dig into these kind of bugs :/

[Bug target/93127] PPC altivec vec_promote creates unnecessary xxpermdi instruction

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

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

HaoChen Gui  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||guihaoc at gcc dot gnu.org

--- Comment #4 from HaoChen Gui  ---
I committed a patch (r12-4987) which is related to this issue. But it doesn't
behave as the ticket expects. With the patch, vec_min/max is bound to
xv[min|max]dp when fast-math is not set. If fast-math is set, it can be folded
into scalar comparison. So with fast-math is set, the code could be
xsmaxdp 1,1,2
blr

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #3 from avieira at gcc dot gnu.org ---
Hi Kewen,

Thanks for the analysis. The param_vect_partial_vector_usage suggestion seems
valid, but that shouldn't be the root cause. 

 I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop
(unless the main loop was unrolled).

That is what the following code in vect_analyze_loop_2 is responsible for:
  /* If we're vectorizing an epilogue loop, the vectorized loop either needs
 to be able to handle fewer than VF scalars, or needs to have a lower VF
 than the main loop.  */
  if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
  && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
  && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
   LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
return opt_result::failure_at (vect_location,
   "Vectorization factor too high for"
   " epilogue loop.\n");

So PR103997 is looking at fixing the skipping, because we skip too much now.
You seem to be describing a case where it doesn't skip enough, but like I said
that should be dealt with the code above, so I have a feeling there may be some
confusion here.

I have a patch for the earlier bug at
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588330.html 
This is still under review whils we work out a better way of dealing with the
issue. Could you maybe check whether that fixes your failures? I'll start a
cross build for powerpc in the meantime to see if I can check out these tests. 

As for why I don't use LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P on the first loop
vinfo to skip epilogue modes, that's because it is possible to have a
non-predicated main loop with a predicated epilogue. The test I added for
aarch64 with that patch is a motivating case.

On another note, unfortunately LOOP_VINFO_EPIL_USING_PARTIAL_VECTORS_P only
'forces' the use of partial vectors it doesn't tell us whether it is possible
or not AFAIU, hence why I introduced that new function, that really only checks
whether the target is at all capable of partial vector generation, since if we
know it's not possible at all we can skip more modes and avoid unnecessary
analysis.

[Bug debug/104025] New: [12 Regression] '-fcompare-debug' failure with enabled warnings

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104025
   Summary: [12 Regression] '-fcompare-debug' failure with enabled
warnings
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fcompare-debug testcase.C
x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure
$ diff -u *gkd
...
@@ -31,11 +31,11 @@
 (note # 0 0 NOTE_INSN_FUNCTION_BEG)
 (insn # 0 0 2 (set (reg/f:DI 0 ax [86])
 (mem/f/c:DI (plus:DI (reg/f:DI 6 bp)
-(const_int -8 [0xfff8])) [ this+0 S8 A64]))
"testcase.C":14:16# {*movdi_internal}
+(const_int -8 [0xfff8])) [ this+0 S8 A64]))
"testcase.C":14:12# {*movdi_internal}
  (nil))
 (insn # 0 0 2 (set (reg:SI 1 dx [orig:82 _1 ] [82])
 (mem:SI (plus:DI (reg/f:DI 0 ax [86])
-(const_int 4 [0x4])) [ this_6(D)->c.i+0 S4 A32]))
"testcase.C":14:16# {*movsi_internal}
+(const_int 4 [0x4])) [ this_6(D)->c.i+0 S4 A32]))
"testcase.C":14:12# {*movsi_internal}
  (nil))
 (insn # 0 0 2 (set (reg/f:DI 0 ax [87])
 (mem/f/c:DI (plus:DI (reg/f:DI 6 bp)
$ x86_64-pc-linux-gnu-gcc -fcompare-debug testcase.C -w -c
(no output)


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-6567-20220114130226-gb77e3b4e458-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-6567-20220114130226-gb77e3b4e458-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20220114 (experimental) (GCC)

[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
adding -mfloat-abi=hard helps, but that vectorizes the loop (or the unrolled
loop with -fno-tree-loop-vectorize) as expected.

So I can't reproduce this.

[Bug c++/104013] Constructor for std::vector with single element initializer list defaults to length construction

[trekie10b at gmx dot de via Gcc-bugs]

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

Alexander Poeppel  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Alexander Poeppel  ---
Never mind. gcc produces the correct result. I had a weird interference with
nvcc, which I noticed when building the test case. So the bug is actually in
nvcc. Closing.

[Bug target/95737] PPC: Unnecessary extsw after negative less than

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

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

--- Comment #9 from HaoChen Gui  ---
Add a pattern to convert the plus mode to DI. 

+(define_insn_and_split "*my_split"
+  [(set (match_operand:DI 0 "gpc_reg_operand")
+   (sign_extend:DI (plus:SI (match_operand:SI 1 "ca_operand")
+(const_int -1]
+  ""
+  "#"
+  ""
+  [(parallel [(set (match_dup 0)
+  (plus:DI (match_dup 2)
+   (const_int -1)))
+ (clobber (match_dup 2))])]
+{
+  operands[2] = copy_rtx (operands[1]);
+  PUT_MODE (operands[2], DImode);
+})

With the patch, the "extsw" could be optimized out. I compared the performance
between P8 code (with the patch) and P9 code. The performance of P9 is better. 
ISA says that computation with CA causes additional latency. It should be true.
The only concern is P9 code uses more register.

[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|debug   |c++
   Target Milestone|--- |12.0

--- Comment #1 from Andrew Pinski  ---
Note the difference is in the column number 14:16 vs 14:12.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Yes, some of them are really considered, e.g.:

$ grep cc ./g++.dg/vect/*.exp
$srcdir/$subdir/{pr,simd}*.{c,cc,S} ]] "" $DEFAULT_VECTCFLAGS
$srcdir/$subdir/slp-pr*.{c,cc,S} ]] "" $VECT_SLP_CFLAGS

$ grep cpp ./gcc.target/avr/*exp
dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.{\[cCS\],cpp}]] \

But some of them are likely ignored.

I'm willing to rename .cpp and .cc files to .C, is it something we want to do?

[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489

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

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

--- Comment #18 from rsandifo at gcc dot gnu.org  
---
Again haven't really looked at this in detail, so could be wrong, but:

(In reply to rguent...@suse.de from comment #13)
> On Thu, 13 Jan 2022, rsandifo at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
> > 
> > --- Comment #9 from rsandifo at gcc dot gnu.org  > gnu.org> ---
> > (In reply to Richard Biener from comment #7)
> > > I think that is what we need to add.  We also don't have a good
> > > representation
> > > for "packing" of masks.
> > > 
> > > diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
> > > index 3ea905538e1..729a1d32612 100644
> > > --- a/gcc/tree-vect-patterns.c
> > > +++ b/gcc/tree-vect-patterns.c
> > > @@ -4679,8 +4679,10 @@ vect_recog_mask_conversion_pattern (vec_info 
> > > *vinfo,
> > >   rhs1_type);
> > > }
> > >  
> > > -  if (maybe_ne (TYPE_VECTOR_SUBPARTS (vectype1),
> > > -   TYPE_VECTOR_SUBPARTS (vectype2)))
> > > +  /* AVX512 style masks cannot be packed/unpacked.  */
> > > +  if (TYPE_PRECISION (TREE_TYPE (vectype2)) != 1
> > > + && maybe_ne (TYPE_VECTOR_SUBPARTS (vectype1),
> > > +  TYPE_VECTOR_SUBPARTS (vectype2)))
> > > tmp = build_mask_conversion (vinfo, rhs1, vectype1, stmt_vinfo);
> > >else
> > > tmp = rhs1;
> > Haven't had time to look at it properly yet, but my first impression
> > is that that's likely to regress SVE.  Packing and unpacking are
> > natural operations on boolean vector modes.
> 
> Sure, but we can't produce scalar code mimicking this for
> 1 bit element vectors.
Yeah, but at least in the SVE case, we're not aiming to do that.
The vector boolean type that we want to use is recorded in the
STMT_VINFO_VECTYPE of the conversion instead, and doesn't get
recomputed later.

Like you said in the earlier comment, the fact that we can't
do that on scalar code is why this needs to be a vector pattern.

(As discussed elsewhere, it would be good if we didn't commit
vector types early like this.  But in this case I don't think
we can rely on scalar code to model the conversion either.)

[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings since r12-6563-gb8ffa71e4271ae56

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1
 CC||anthonysharp15 at gmail dot 
com,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|[12 Regression] |[12 Regression]
   |'-fcompare-debug' failure   |'-fcompare-debug' failure
   |with enabled warnings   |with enabled warnings since
   ||r12-6563-gb8ffa71e4271ae56

--- Comment #2 from Martin Liška  ---
Started with r12-6563-gb8ffa71e4271ae56.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

--- Comment #4 from Martin Liška  ---
Oh no. We usually use .cpp/.cc extension as an additional file that is
intentionally skipped by a glob pattern:

$ head g++.target/i386/mv12.C
...
// { dg-additional-sources "mv12-aux.cc" }

or:

gcc/testsuite/g++.dg/asan/asan_test.C:#include "asan_str_test.cc"

[Bug middle-end/104026] New: [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

Bug ID: 104026
   Summary: [12 Regression] ICE in wide_int_to_tree_1, at
tree.c:1755  via tree-vect-loop-manip.c:673
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-gnu-linux
Target: amdgcn-amdhsa

Seems to be very new as the build yesterday still worked. Happens when
compiling newlib with the AMDGCN-targeting compiler:

newlib/libc/stdlib/ecvtbuf.c:268:1: internal compiler error: in
wide_int_to_tree_1, at tree.c:1755
  268 | ecvtbuf (double invalue,
  | ^~~
0x7f0966 wide_int_to_tree_1
src/gcc-mainline/gcc/tree.c:1755
0x12a41bc wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
src/gcc-mainline/gcc/tree.c:1867
0x12a41bc build_int_cst(tree_node*, poly_int<1u, long>)
src/gcc-mainline/gcc/tree.c:1507
0x1251bd7 vect_set_loop_controls_directly
src/gcc-mainline/gcc/tree-vect-loop-manip.c:673

[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings since r12-6563-gb8ffa71e4271ae56

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

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

--- Comment #3 from Andrew Pinski  ---
Obviously removing "&& warn_missing_template_keyword" will fix the
fcompare-debug but the question is which location is the more correct one?

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #1 from Tobias Burnus  ---
Breakpoint 4, vect_set_loop_controls_directly (...)
at src/gcc-mainline/gcc/tree-vect-loop-manip.c:672

673   gassign *minus = gimple_build_assign (adjusted_len, PLUS_EXPR,
674 rgc->controls[0],
675 build_int_cst
676 (TREE_TYPE
(rgc->controls[0]),
677  partial_load_bias));

The problem is the 'TREE_TYPE (rgc->controls[0])' which is as follows - and
build_int_cst does not seem to like to assign -72 to a vector type.

(gdb) p debug_tree(rgc->controls->m_vec->m_vecdata[0])
 
unit-size 

[Bug ada/104027] New: [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

Bug ID: 104027
   Summary: [12 Regression] libgnat-12.so requires executable
stack on x86_64-linux
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

while libgnat-11.so didn't (and some earlier too).
Seems the reason is a-nbnbig.o, which is empty and doesn't have .note.GNU-stack
section.
gnat1drv seems to exit (0) during the middle of compile_file, which means it
skips a big part of toplev.c (compile_file) cleanups, in particular
  targetm.asm_out.file_end ();
for this case.

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #4 from Kewen Lin  ---
Hi Andre,

Thanks for the detailed explanations all below!

(In reply to avieira from comment #3)
> Hi Kewen,
> 
> Thanks for the analysis. The param_vect_partial_vector_usage suggestion
> seems valid, but that shouldn't be the root cause.
> 
>  I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop
> (unless the main loop was unrolled).
> 
> That is what the following code in vect_analyze_loop_2 is responsible for:
>   /* If we're vectorizing an epilogue loop, the vectorized loop either needs
>  to be able to handle fewer than VF scalars, or needs to have a lower VF
>  than the main loop.  */
>   if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
>   && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
>   && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
>LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
> return opt_result::failure_at (vect_location,
>"Vectorization factor too high for"
>" epilogue loop.\n");
> 

For this failure rs6000 specific, this check does take effect, but it's too
late for this case. Since we already decide to re-try vector modes for epilogue
in vect_analyze_loop, the retrying generates one extra unexpected statement in
dumping file. Without the culprit commit, it doesn't have any re-tries.

According to the comments for the snippet with supports_partial_vectors, I
still feel the root cause of this failure is we don't set
supports_partial_vectors right on Power9. Since it's considered as true for
Power9 but actually no as the partial vector capability also respecting
param_vect_partial_vector_usage.

  if (!supports_partial_vectors
   && maybe_ge (GET_MODE_NUNITS (vector_modes[mode_i]),
first_vinfo_vf))

> So PR103997 is looking at fixing the skipping, because we skip too much now.
> You seem to be describing a case where it doesn't skip enough, but like I
> said that should be dealt with the code above, so I have a feeling there may
> be some confusion here.

It seems to me that the case on Power9 even doesn't have a chance to be decided
skipped or not. :)

> 
> I have a patch for the earlier bug at
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588330.html 
> This is still under review whils we work out a better way of dealing with
> the issue. Could you maybe check whether that fixes your failures? I'll
> start a cross build for powerpc in the meantime to see if I can check out
> these tests. 
> 

Thanks for the pointer, I just tried the patch and sorry that it didn't help
this failure on rs6000. If my understanding above is correct, it's expected
since the patch being reviewed just touched the code guarded with
!supports_partial_vectors, while this failed case on Power9 doesn't even enter
that block.

> As for why I don't use LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P on the first
> loop vinfo to skip epilogue modes, that's because it is possible to have a
> non-predicated main loop with a predicated epilogue. The test I added for
> aarch64 with that patch is a motivating case.
> 

Thanks for the clarification! On rs6000 it's default with
param_vect_partial_vector_usage 1 that the main loop won't use partial vector
but the epilogue can use, I'd expect the LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P
of main loop is true if the epilogue can use partial vector. It seems it's
different on aarch64.

[Bug libstdc++/103992] common_iterator(const common_iterator<_It2, _Sent2>& __x) uses new instead of construct_at

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-6572-gd67ba1dce9796bff177e52e2bbb68bfa2c69a884
Author: Jonathan Wakely 
Date:   Wed Jan 12 16:58:18 2022 +

libstdc++: Use std::construct_at in std::common_iterator [PR103992]

This should have been done as part of the LWG 3574 changes.

libstdc++-v3/ChangeLog:

PR libstdc++/103992
* include/bits/stl_iterator.h (common_iterator): Use
std::construct_at instead of placement new.
* testsuite/24_iterators/common_iterator/1.cc: Check copy
construction is usable in constant expressions.

[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489

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

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

--- Comment #19 from Richard Biener  ---
Ah, so the issue is missing -mavx512bw which means we end up with a AVX2 style
mask for V32QImode.  With -mavx512bw the code vectorizes fine.

I guess ix86_get_mask_mode is too restrictive here?

And indeed to build a AVX2 style mask vector from a AVX512 style mask vector
we'd need to use a ?:, not a simple conversion.  Unfortunately we don't support
vectorizing that:

t.c:10:21: note:   ==> examining statement: patt_42 = patt_40 ? -1 : 0;
t.c:10:21: note:   vect_is_simple_use: operand x.1_14 > 255, type of def:
internal
t.c:10:21: note:   vect_is_simple_use: vectype vector(8) 
t.c:10:21: note:   vect_is_simple_use: operand -1, type of def: constant
t.c:10:21: note:   vect_is_simple_use: operand 0, type of def: constant
t.c:8:6: missed:   not vectorized: relevant stmt not supported: patt_42 =
patt_40 ? -1 : 0;

or maybe we need to tweak the conversion vectorization for better support
of this case as noted in comment#10 ... but the code generated from that
AFAIU is to produce a HImode mask, not a V32QImode one which puts the fault
on ix86_get_mask_mode again.

[Bug target/101971] M68k: ICE: Tried to convert PC relative branch to absolute jump

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

Giulio Benetti  changed:

   What|Removed |Added

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

--- Comment #12 from Giulio Benetti  ---
The previous comment answers to this. So I close this bug.

Best regards

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 CC||charlet at gcc dot gnu.org,
   ||ebotcazou at gcc dot gnu.org,
   ||pmderodat at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Compiling a-nbnbig.o with additional -Wa,--noexecstack fixes it, but it is an
ugly workaround and would need to be done conditionally on the assembler
supporting it and on the target being a target where gcc normally emits
.note.GNU-stack.

[Bug c/104028] New: M68k: Error: value -16034 out of range

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

Bug ID: 104028
   Summary: M68k: Error: value -16034 out of range
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giulio.benetti at benettiengineering dot com
  Target Milestone: ---

When building package sg3_utils on buildroot we get this error:
```
/home/peko/autobuild/instance-0/output-1/host/bin/m68k-linux-gcc
-DHAVE_CONFIG_H -I. -I..  -iquote ../include -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Wall -W  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -Os -g2  -fno-dwarf2-cfi-asm  -Wl,-elf2flt=-r -static
-c -o sg_dd.o sg_dd.c
/tmp/cccfKmZB.s: Assembler messages:
/tmp/cccfKmZB.s:17093: Error: value -16034 out of range
/tmp/cccfKmZB.s:17093: Error: value of -16034 too large for field of 1 byte at
23149
make[3]: *** [Makefile:1176: sg_vpd.o] Error 1
```

To reproduce it:
```
# git clone git://git.busybox.net/buildroot
# cd buildroot
# git checkout feb9185fc185c1f76e3789b0dc521e3cf98c1ebb
# wget -O .config
http://autobuild.buildroot.net/results/c49300d12a209b18f41d389f092324592b881277/config
# make olddefconfig && make
```

I'm going to add the preprocessed files.

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #5 from avieira at gcc dot gnu.org ---
Thanks Kewen, that seems worrying, I'll have a look.

[Bug c/104028] M68k: Error: value -16034 out of range

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #1 from Giulio Benetti  ---
Created attachment 52188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52188&action=edit
Pre-processed sg_dd.c(sg_dd.i)

[Bug c/104028] M68k: Error: value -16034 out of range

[giulio.benetti at benettiengineering dot com via Gcc-bugs]

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

--- Comment #2 from Giulio Benetti  ---
Created attachment 52189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52189&action=edit
Pre-processed sg_dd.c(sg_dd.s)

[Bug libstdc++/103992] common_iterator(const common_iterator<_It2, _Sent2>& __x) uses new instead of construct_at

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed, thanks for the report

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org
   Target Milestone|--- |12.0

--- Comment #2 from Richard Biener  ---
possibly wants to use build_vector_from_val if an uniform constant is desired.

OTOH, does amdgcn really require the load bias stuff?

Can you attach preprocessed source for ecvtbuf.c and instructions to invoke cc1
on it?

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 52190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52190&action=edit
Patch which might fix the issue

I suspect it was caused by r12-5670-g8ba38e8c8b73 were we call:
Back_End.Gen_Or_Update_Object_File

It should have used a goto here instead of an exit.
The attached patch might be correct but I don't know Ada well enough.

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-14

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #3 from Tobias Burnus  ---
Input file is:
https://sourceware.org/git/?p=newlib-cygwin.git;a=history;f=newlib/libc/stdlib/ecvtbuf.c;hb=HEAD

Compiled with   amdgcn-amdhsa-gcc -g -O2 -ffunction-sections

I tried to reduce it – which kind of worked. Except: The resulting file did no
longer consistently ICE but only every 10th (or so) time.
Thus, I have not attached it. In any case, that indicates some memory
corruption issue.

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||kenner at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Indeed.  If the FE emitted something registered with the middle-end symtab,
best would be to remove those again, if not, just arranging for return into the
caller seems much better than exiting.  It isn't just .note.GNU-stack on Linux,
but
e.g. plugin hooks won't be called etc.

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
I think the patch in comment 2 is the correct fix (OK to commit).

(In reply to Kewen Lin from comment #4)
> (In reply to avieira from comment #3)
> > Hi Kewen,
> > 
> > Thanks for the analysis. The param_vect_partial_vector_usage suggestion
> > seems valid, but that shouldn't be the root cause.
> > 
> >  I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop
> > (unless the main loop was unrolled).
> > 
> > That is what the following code in vect_analyze_loop_2 is responsible for:
> >   /* If we're vectorizing an epilogue loop, the vectorized loop either needs
> >  to be able to handle fewer than VF scalars, or needs to have a lower VF
> >  than the main loop.  */
> >   if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
> >   && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> >   && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
> >LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
> > return opt_result::failure_at (vect_location,
> >"Vectorization factor too high for"
> >" epilogue loop.\n");
> > 
> 
> For this failure rs6000 specific, this check does take effect, but it's too
> late for this case. Since we already decide to re-try vector modes for
> epilogue in vect_analyze_loop, the retrying generates one extra unexpected
> statement in dumping file. Without the culprit commit, it doesn't have any
> re-tries.
Yeah, I think this just shows that it's a flaky test.  Does it really
matter that:

  permutation requires at least three vectors

is printed exactly once, rather than at least once?  It's inevitable
that we'll start printing more stuff when trying (and possibly failing)
to use other vectorisation strategies.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

[rdapp at linux dot ibm.com via Gcc-bugs]

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

rdapp at linux dot ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot ibm.com

--- Comment #4 from rdapp at linux dot ibm.com ---
This code path should only be active when the backend has len_load/len_store
patterns.

signed char partial_load_store_bias;

is new in the "middle" of loop_vect_info. Could this become
overwritten/corrupted by something?

[Bug target/98737] Atomic operation on x86 no optimized to use flags

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9896e96d4cae00d0f4d2b694284cb30bbd9c80fc

commit r12-6577-g9896e96d4cae00d0f4d2b694284cb30bbd9c80fc
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:04:59 2022 +0100

forwprop: Canonicalize atomic fetch_op op x to op_fetch or vice versa
[PR98737]

When writing the PR98737 fix, I've handled just the case where people
use __atomic_op_fetch (p, x, y) etc.
But some people actually use the other builtins, like
__atomic_fetch_op (p, x, y) op x.
The following patch canonicalizes the latter to the former and vice versa
when possible if the result of the builtin is a single use and if
that use is a cast with same precision, also that cast's lhs has a single
use.
For all ops of +, -, &, | and ^ we can do those
__atomic_fetch_op (p, x, y) op x -> __atomic_op_fetch (p, x, y)
(and __sync too) opts, but cases of INTEGER_CST and SSA_NAME x
behave differently.  For INTEGER_CST, typically - x is
canonicalized to + (-x), while for SSA_NAME we need to handle various
casts, which sometimes happen on the second argument of the builtin
(there can be even two subsequent casts for char/short due to the
promotions we do) and there can be a cast on the argument of op too.
And all ops but - are commutative.
For the other direction, i.e.
__atomic_op_fetch (p, x, y) rop x -> __atomic_fetch_op (p, x, y)
we can't handle op of & and |, those aren't reversible, for
op + rop is -, for - rop is + and for ^ rop is ^, otherwise the same
stuff as above applies.
And, there is another case, we canonicalize
x - y == 0 (or != 0) and x ^ y == 0 (or != 0) to x == y (or x != y)
and for constant y x + y == 0 (or != 0) to x == -y (or != -y),
so the patch also virtually undoes those canonicalizations, because
e.g. for the earlier PR98737 patch but even generally, it is better
if a result of atomic op fetch is compared against 0 than doing
atomic fetch op and compare it to some variable or non-zero constant.
As for debug info, for non-reversible operations (& and |) the patch
resets debug stmts if there are any, for -fnon-call-exceptions too
(didn't want to include debug temps right before all uses), but
otherwise it emits (on richi's request) the reverse operation from
the result as a new setter of the old lhs, so that later DCE fixes
up the debug info.

On the emitted assembly for the testcases which are fairly large,
I see substantial decreases of the *.s size:
-rw-rw-r--. 1 jakub jakub 116897 Jan 13 09:58 pr98737-1.svanilla
-rw-rw-r--. 1 jakub jakub  93861 Jan 13 09:57 pr98737-1.spatched
-rw-rw-r--. 1 jakub jakub  70257 Jan 13 09:57 pr98737-2.svanilla
-rw-rw-r--. 1 jakub jakub  67537 Jan 13 09:57 pr98737-2.spatched
There are some functions where due to RA we get one more instruction
than previously, but most of them are smaller even when not hitting
the PR98737 previous patch's optimizations.

2022-01-14  Jakub Jelinek  

PR target/98737
* tree-ssa-forwprop.c (simplify_builtin_call): Canonicalize
__atomic_fetch_op (p, x, y) op x into __atomic_op_fetch (p, x, y)
and __atomic_op_fetch (p, x, y) iop x into
__atomic_fetch_op (p, x, y).

* gcc.dg/tree-ssa/pr98737-1.c: New test.
* gcc.dg/tree-ssa/pr98737-2.c: New test.

[Bug c++/89074] valid pointer equality constexpr comparison rejected

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-6578-gd686d5d85c23451c03799dc55e456b73065f7333
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:07:49 2022 +0100

c++: Reject in constant evaluation address comparisons of start of one var
and end of another [PR89074]

The following testcase used to be incorrectly accepted.  The match.pd
optimization that uses address_compare punts on folding comparison
of start of one object and end of another one only when those addresses
are cast to integral types, when the comparison is done on pointer types
it assumes undefined behavior and decides to fold the comparison such
that the addresses don't compare equal even when they at runtime they
could be equal.
But C++ says it is undefined behavior and so during constant evaluation
we should reject those, so this patch adds !folding_initializer &&
check to that spot.

Note, address_compare has some special cases, e.g. it assumes that
static vars are never adjacent to automatic vars, which is the case
for the usual layout where automatic vars are on the stack and after
.rodata/.data sections there is heap:
  /* Assume that automatic variables can't be adjacent to global
 variables.  */
  else if (is_global_var (base0) != is_global_var (base1))
;
Is it ok that during constant evaluation we don't treat those as undefined
behavior, or shall that be with !folding_initializer && too?

Another special case is:
  if ((DECL_P (base0) && TREE_CODE (base1) == STRING_CST)
   || (TREE_CODE (base0) == STRING_CST && DECL_P (base1))
   || (TREE_CODE (base0) == STRING_CST
   && TREE_CODE (base1) == STRING_CST
   && ioff0 >= 0 && ioff1 >= 0
   && ioff0 < TREE_STRING_LENGTH (base0)
   && ioff1 < TREE_STRING_LENGTH (base1)
  /* This is a too conservative test that the STRING_CSTs
 will not end up being string-merged.  */
   && strncmp (TREE_STRING_POINTER (base0) + ioff0,
   TREE_STRING_POINTER (base1) + ioff1,
   MIN (TREE_STRING_LENGTH (base0) - ioff0,
TREE_STRING_LENGTH (base1) - ioff1)) != 0))
;
  else if (!DECL_P (base0) || !DECL_P (base1))
return 2;
Here we similarly assume that vars aren't adjacent to string literals
or vice versa.  Do we need to stick !folding_initializer && to those
DECL_P vs. STRING_CST cases?  Though, because of the return 2; for
non-DECL_P that would mean rejecting comparisons like &var == &"foobar"[3]
etc. which ought to be fine, no?  So perhaps we need to watch for
decls. vs. STRING_CSTs like for DECLs whether the address is at the start
or at the end of the string literal or somewhere in between (at least
for folding_initializer)?
And yet another chapter but probably unsolvable is comparison of
string literal addresses.  I think pedantically in C++
&"foo"[0] == &"foo"[0] is undefined behavior, different occurences of
the same string literals might still not be merged in some implementations.
But constexpr const char *s = "foo"; &s[0] == &s[0] should be well defined,
and we aren't tracking anywhere whether the string literal was the same one
or different (and I think other compilers don't track that either).

2022-01-14  Jakub Jelinek  

PR c++/89074
* fold-const.c (address_compare): Punt on comparison of address of
one object with address of end of another object if
folding_initializer.

* g++.dg/cpp1y/constexpr-89074-1.C: New test.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

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

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

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

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

commit r12-6579-gcbf06187d5f246634272e3d2892501563bff3d99
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:09:19 2022 +0100

c++: Avoid some -Wreturn-type false positives with const{expr,eval} if
[PR103991]

The changes done to genericize_if_stmt in order to improve
-Wunreachable-code* warning (which Richi didn't actually commit
for GCC 12) are I think fine for normal ifs, but for constexpr if
and consteval if we have two competing warnings.
The problem is that we replace the non-taken clause (then or else)
with void_node and keep the if (cond) { something } else {}
or if (cond) {} else { something }; in the IL.
This helps -Wunreachable-code*, if something can't fallthru but the
non-taken clause can, we don't warn about code after it because it
is still (in theory) reachable.
But if the non-taken branch can't fallthru, we can get false positive
-Wreturn-type warnings (which are enabled by default) if there is
nothing after the if and the taken branch can't fallthru either.

One possibility to fix this is revert at least temporarily
to the previous behavior for constexpr and consteval if, yes, we
can get false positive -Wunreachable-code* warnings but the warning
isn't present in GCC 12.
The patch below implements that for constexpr if which throws its
clauses very early (either during parsing or during instantiation),
and for consteval if it decides based on block_may_fallthru on the
non-taken (for constant evaluation only) clause - if the non-taken
branch may fallthru, it does what you did in genericize_if_stmt
for consteval if, if it can't fallthru, it uses the older way
of pretending there wasn't an if and just replacing it with the
taken clause.  There are some false positive risks with this though,
block_may_fallthru is optimistic and doesn't handle some statements
at all (like FOR_STMT, WHILE_STMT, DO_STMT - of course handling those
is quite hard).
For constexpr if (but perhaps for GCC 13?) we could try to
block_may_fallthru before we throw it away and remember it in some
flag on the IF_STMT, but am not sure how dangerous would it be to call
it on the discarded stmts.  Or if it is too dangerous e.g. just
remember whether the discarded block of consteval if wasn't present
or was empty, in that case assume fallthru, and otherwise assume
it can't fallthru (-Wunreachable-code possible false positives).

2022-01-14  Jakub Jelinek  

PR c++/103991
* cp-objcp-common.c (cxx_block_may_fallthru) : For
IF_STMT_CONSTEXPR_P with constant false or true condition only
check if the taken clause may fall through.
* cp-gimplify.c (genericize_if_stmt): For consteval if, revert
to r12-5638^ behavior if then_ block can't fall through.  For
constexpr if, revert to r12-5638^ behavior.

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

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #5 from Tobias Burnus  ---
(In reply to Richard Biener from comment #2)
> OTOH, does amdgcn really require the load bias stuff?

According to Andrew, it doesn't - it uses maskstore.

[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-6580-gac6a1181209b756882f89cdba6128565fad1a56e
Author: Jakub Jelinek 
Date:   Fri Jan 14 12:11:00 2022 +0100

libgfortran: Partly revert my r12-6498 change to fix Solaris build
[PR104006]

In r12-6498 I've added $(version_dep) to BUILT_SOURCES, previously
version_dep
on Linux used to be a file in $(srcdir), but with my changes it is a
generated
file in the object directory (preprocessed version of the $(srcdir) file)
and I thought generated files belong to BUILT_SOURCES so that they are
cleaned up etc.
For Linux that is fine, but it broke parallel builds on Solaris.
BUILT_SOURCES is a special variable for automake where automake ensures
that for make all, make check and make install all those $(BUILT_SOURCES)
are generated before actually starting building in parallel the various
object files.  That way we can avoid hacks like:
$(patsubst %.F90,%.lo,$(notdir $(filter %.F90,$(prereq_SRC: kinds.inc
c99_protos.inc
$(patsubst %.c,%.lo,$(notdir $(filter %.c,$(prereq_SRC: kinds.h
$(patsubst %.f90,%.lo,selected_real_kind.f90): selected_real_kind.inc
$(patsubst %.f90,%.lo,selected_int_kind.f90): selected_int_kind.inc
$(patsubst %.F90,%.lo,ieee_exceptions.F90): fpu-target.inc
$(patsubst %.F90,%.lo,ieee_arithmetic.F90): fpu-target.inc
ieee_exceptions.lo
$(patsubst %.c,%.lo,fpu.c): fpu-target.h
which makes those dependencies explicit but hides it from automake, so that
it
doesn't throw away its rules for those object files.
On Solaris, $(version_dep) contains gfortran.ver and gfortran.ver-sun.
gfortran.ver is like on Linux, it can be in $(BUILT_SOURCES), but
unfortunately
gfortran.ver-sun depends on all the object files being compiled already,
so if gfortran.ver-sun appears in $(BUILT_SOURCES), the BUILT_SOURCES
function
of ensuring the generated files are generated before building object files
is gone, almost everything is built before all-am is entered and there
are no explicit dependencies that e.g. *.F90 files depend on
kinds.inc etc.

So, this change reverts that mistake and instead adds $(version_dep) to
what is removed during make clean (clean-local in particular).

2022-01-14  Jakub Jelinek  

PR libfortran/104006
* Makefile.am (BUILT_SOURCES): Don't include $(version_dep).
(clean-local): Remove $(version_dep).
* Makefile.in: Regenerated.

[Bug libstdc++/91383] C++17 should remove some library feature deprecated in C++14

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-6581-gde196e5dd8ea4d0ed01a8c265afdd3676e27545b
Author: Jonathan Wakely 
Date:   Tue Jan 11 18:42:38 2022 +

libstdc++: Add attribute to features deprecated in C++17 [PR91260]

There are a lot of things in the C++ standard library which were
deprecated in C++11, and more in C++17.  Some of them were removed after
deprecation and are no longer present in the standard at all. We have
not removed these from libstdc++ because keeping them as non-standard
extensions is conforming, and avoids gratuitously breaking user code,
and in some cases we need to keep using them to avoid ABI changes. But
we should at least give a warning for using them. That has not been done
previously because of the library's own uses of them (e.g. the
std::iterator class template used as a base class).

This adds deprecated attributes to the relevant components, and then
goes through the whole library to add diagnostic pragmas where needed to
suppress warnings about our internal uses of them. The tests are updated
to either expect the additional warnings, or to suppress them where we
aren't interested in them.

libstdc++-v3/ChangeLog:

PR libstdc++/91260
PR libstdc++/91383
PR libstdc++/95065
* include/backward/binders.h (bind1st, bind2nd): Add deprecated
attribute.
* include/bits/refwrap.h (_Maybe_unary_or_binary_function):
Disable deprecated warnings for base classes.
(_Reference_wrapper_base): Likewise.
* include/bits/shared_ptr_base.h (_Sp_owner_less): Likewise.
* include/bits/stl_bvector.h (_Bit_iterator_base): Likewise.
* include/bits/stl_function.h (unary_function, binary_function):
Add deprecated attribute.
(unary_negate, not1, binary_negate, not2, ptr_fun)
(pointer_to_unary_function, pointer_to_binary_function)
(mem_fun_t, const_mem_fun_t, mem_fun_ref_t, const_mem_fun_ref_t)
(mem_fun1_t, const_mem_fun1_t, mem_fun_ref1_t)
(const_mem_fun1_ref_t, mem_fun, mem_fun_ref): Add deprecated
attributes.
* include/bits/stl_iterator.h: Disable deprecated warnings for
std::iterator base classes.
* include/bits/stl_iterator_base_types.h (iterator): Add
deprecated attribute.
* include/bits/stl_map.h (map::value_compare): Disable
deprecated warnings for base class.
* include/bits/stl_multimap.h (multimap::value_compare):
Likewise.
* include/bits/stl_raw_storage_iter.h (raw_storage_iterator):
Add deprecated attribute.
* include/bits/stl_tempbuf.h (get_temporary_buffer): Likewise.
* include/bits/stream_iterator.h: Disable deprecated warnings.
* include/bits/streambuf_iterator.h: Likewise.
* include/ext/bitmap_allocator.h: Remove unary_function base
classes.
* include/ext/functional: Disable deprecated warnings.
* include/ext/rope: Likewise.
* include/ext/throw_allocator.h: Likewise.
* include/std/type_traits (result_of): Add deprecated attribute.
* include/tr1/functional: Disable deprecated warnings.
* include/tr1/functional_hash.h: Likewise.
* testsuite/20_util/function_objects/binders/1.cc: Add
-Wno-disable-deprecations.
* testsuite/20_util/function_objects/binders/3113.cc: Likewise.
* testsuite/20_util/function_objects/constexpr.cc: Add
dg-warning.
* testsuite/20_util/raw_storage_iterator/base.cc: Likewise.
* testsuite/20_util/raw_storage_iterator/dr2127.cc: Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/raw_storage_iterator/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/reference_wrapper/24803.cc:
Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Enable for
C++20 and check for absence of nested types.
* testsuite/20_util/shared_ptr/comparison/less.cc: Remove
std::binary_function base class.
* testsuite/20_util/temporary_buffer.cc: Add dg-warning.
* testsuite/21_strings/basic_string/cons/char/69092.cc: Remove
std::iterator base class.
*
testsuite/24_iterators/back_insert_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/24

[Bug libstdc++/91260] std::unary_function and std::binary_function still exist in C++17

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-6581-gde196e5dd8ea4d0ed01a8c265afdd3676e27545b
Author: Jonathan Wakely 
Date:   Tue Jan 11 18:42:38 2022 +

libstdc++: Add attribute to features deprecated in C++17 [PR91260]

There are a lot of things in the C++ standard library which were
deprecated in C++11, and more in C++17.  Some of them were removed after
deprecation and are no longer present in the standard at all. We have
not removed these from libstdc++ because keeping them as non-standard
extensions is conforming, and avoids gratuitously breaking user code,
and in some cases we need to keep using them to avoid ABI changes. But
we should at least give a warning for using them. That has not been done
previously because of the library's own uses of them (e.g. the
std::iterator class template used as a base class).

This adds deprecated attributes to the relevant components, and then
goes through the whole library to add diagnostic pragmas where needed to
suppress warnings about our internal uses of them. The tests are updated
to either expect the additional warnings, or to suppress them where we
aren't interested in them.

libstdc++-v3/ChangeLog:

PR libstdc++/91260
PR libstdc++/91383
PR libstdc++/95065
* include/backward/binders.h (bind1st, bind2nd): Add deprecated
attribute.
* include/bits/refwrap.h (_Maybe_unary_or_binary_function):
Disable deprecated warnings for base classes.
(_Reference_wrapper_base): Likewise.
* include/bits/shared_ptr_base.h (_Sp_owner_less): Likewise.
* include/bits/stl_bvector.h (_Bit_iterator_base): Likewise.
* include/bits/stl_function.h (unary_function, binary_function):
Add deprecated attribute.
(unary_negate, not1, binary_negate, not2, ptr_fun)
(pointer_to_unary_function, pointer_to_binary_function)
(mem_fun_t, const_mem_fun_t, mem_fun_ref_t, const_mem_fun_ref_t)
(mem_fun1_t, const_mem_fun1_t, mem_fun_ref1_t)
(const_mem_fun1_ref_t, mem_fun, mem_fun_ref): Add deprecated
attributes.
* include/bits/stl_iterator.h: Disable deprecated warnings for
std::iterator base classes.
* include/bits/stl_iterator_base_types.h (iterator): Add
deprecated attribute.
* include/bits/stl_map.h (map::value_compare): Disable
deprecated warnings for base class.
* include/bits/stl_multimap.h (multimap::value_compare):
Likewise.
* include/bits/stl_raw_storage_iter.h (raw_storage_iterator):
Add deprecated attribute.
* include/bits/stl_tempbuf.h (get_temporary_buffer): Likewise.
* include/bits/stream_iterator.h: Disable deprecated warnings.
* include/bits/streambuf_iterator.h: Likewise.
* include/ext/bitmap_allocator.h: Remove unary_function base
classes.
* include/ext/functional: Disable deprecated warnings.
* include/ext/rope: Likewise.
* include/ext/throw_allocator.h: Likewise.
* include/std/type_traits (result_of): Add deprecated attribute.
* include/tr1/functional: Disable deprecated warnings.
* include/tr1/functional_hash.h: Likewise.
* testsuite/20_util/function_objects/binders/1.cc: Add
-Wno-disable-deprecations.
* testsuite/20_util/function_objects/binders/3113.cc: Likewise.
* testsuite/20_util/function_objects/constexpr.cc: Add
dg-warning.
* testsuite/20_util/raw_storage_iterator/base.cc: Likewise.
* testsuite/20_util/raw_storage_iterator/dr2127.cc: Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/raw_storage_iterator/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/reference_wrapper/24803.cc:
Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Enable for
C++20 and check for absence of nested types.
* testsuite/20_util/shared_ptr/comparison/less.cc: Remove
std::binary_function base class.
* testsuite/20_util/temporary_buffer.cc: Add dg-warning.
* testsuite/21_strings/basic_string/cons/char/69092.cc: Remove
std::iterator base class.
*
testsuite/24_iterators/back_insert_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/24_

[Bug libstdc++/95065] Remove std::bind1st and std::bind2nd when building in -std=c++17

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r12-6581-gde196e5dd8ea4d0ed01a8c265afdd3676e27545b
Author: Jonathan Wakely 
Date:   Tue Jan 11 18:42:38 2022 +

libstdc++: Add attribute to features deprecated in C++17 [PR91260]

There are a lot of things in the C++ standard library which were
deprecated in C++11, and more in C++17.  Some of them were removed after
deprecation and are no longer present in the standard at all. We have
not removed these from libstdc++ because keeping them as non-standard
extensions is conforming, and avoids gratuitously breaking user code,
and in some cases we need to keep using them to avoid ABI changes. But
we should at least give a warning for using them. That has not been done
previously because of the library's own uses of them (e.g. the
std::iterator class template used as a base class).

This adds deprecated attributes to the relevant components, and then
goes through the whole library to add diagnostic pragmas where needed to
suppress warnings about our internal uses of them. The tests are updated
to either expect the additional warnings, or to suppress them where we
aren't interested in them.

libstdc++-v3/ChangeLog:

PR libstdc++/91260
PR libstdc++/91383
PR libstdc++/95065
* include/backward/binders.h (bind1st, bind2nd): Add deprecated
attribute.
* include/bits/refwrap.h (_Maybe_unary_or_binary_function):
Disable deprecated warnings for base classes.
(_Reference_wrapper_base): Likewise.
* include/bits/shared_ptr_base.h (_Sp_owner_less): Likewise.
* include/bits/stl_bvector.h (_Bit_iterator_base): Likewise.
* include/bits/stl_function.h (unary_function, binary_function):
Add deprecated attribute.
(unary_negate, not1, binary_negate, not2, ptr_fun)
(pointer_to_unary_function, pointer_to_binary_function)
(mem_fun_t, const_mem_fun_t, mem_fun_ref_t, const_mem_fun_ref_t)
(mem_fun1_t, const_mem_fun1_t, mem_fun_ref1_t)
(const_mem_fun1_ref_t, mem_fun, mem_fun_ref): Add deprecated
attributes.
* include/bits/stl_iterator.h: Disable deprecated warnings for
std::iterator base classes.
* include/bits/stl_iterator_base_types.h (iterator): Add
deprecated attribute.
* include/bits/stl_map.h (map::value_compare): Disable
deprecated warnings for base class.
* include/bits/stl_multimap.h (multimap::value_compare):
Likewise.
* include/bits/stl_raw_storage_iter.h (raw_storage_iterator):
Add deprecated attribute.
* include/bits/stl_tempbuf.h (get_temporary_buffer): Likewise.
* include/bits/stream_iterator.h: Disable deprecated warnings.
* include/bits/streambuf_iterator.h: Likewise.
* include/ext/bitmap_allocator.h: Remove unary_function base
classes.
* include/ext/functional: Disable deprecated warnings.
* include/ext/rope: Likewise.
* include/ext/throw_allocator.h: Likewise.
* include/std/type_traits (result_of): Add deprecated attribute.
* include/tr1/functional: Disable deprecated warnings.
* include/tr1/functional_hash.h: Likewise.
* testsuite/20_util/function_objects/binders/1.cc: Add
-Wno-disable-deprecations.
* testsuite/20_util/function_objects/binders/3113.cc: Likewise.
* testsuite/20_util/function_objects/constexpr.cc: Add
dg-warning.
* testsuite/20_util/raw_storage_iterator/base.cc: Likewise.
* testsuite/20_util/raw_storage_iterator/dr2127.cc: Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/20_util/raw_storage_iterator/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/raw_storage_iterator/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/reference_wrapper/24803.cc:
Likewise.
* testsuite/20_util/reference_wrapper/typedefs.cc: Enable for
C++20 and check for absence of nested types.
* testsuite/20_util/shared_ptr/comparison/less.cc: Remove
std::binary_function base class.
* testsuite/20_util/temporary_buffer.cc: Add dg-warning.
* testsuite/21_strings/basic_string/cons/char/69092.cc: Remove
std::iterator base class.
*
testsuite/24_iterators/back_insert_iterator/requirements/base_classes.cc:
Likewise.
*
testsuite/24_

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #7 from avieira at gcc dot gnu.org ---
Yeah I'm with Richard on this one, I just checked and the generated assembly is
the same for before and after my patch, so this looks like a testism.


And yeah I agree, if we were to decide to unroll this for instance then you'd
likely see it being printed more too, since you would likely end up with the
epilogue using the same mode.

I'll suggest changing it to just testing the existance of that string, rather
than requring it N times.

Having said that, the fail will go away for this particular case with the param
change.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

Andrew Stubbs  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #6 from Andrew Stubbs  ---
amdgcn always uses 64-lane vectors, regardless of type, and relies on masking
to support anything smaller.

The len_store pattern seems to have been introduced in July 2020 which is more
recent than the last major work in the amdgcn backend.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #7 from Tobias Burnus  ---
(In reply to rdapp from comment #4)
> This code path should only be active when the backend has len_load/len_store
> patterns.
> signed char partial_load_store_bias;
> is new in the "middle" of loop_vect_info. Could this become
> overwritten/corrupted by something?

My impression is:
- VECT_PARTIAL_BIAS_UNSUPPORTED is not always set when it should
- If it is not set, it is has some random value (stack variable, malloc not
calloc,
  ...); Still 0 is common - and it might work by chance as there is
  'if (partial_load_bias != 0)' around the ICEing code.
  (Side note: VECT_PARTIAL_BIAS_UNSUPPORTED = 127 while 0 is a valid/supported
value).
- It probably only affects loops where vect_verify_full_masking
  + LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P are true
  (and vect_verify_loop_lens is false)

Caveat: I might be completely off here.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

[rdapp at linux dot ibm.com via Gcc-bugs]

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

--- Comment #8 from rdapp at linux dot ibm.com ---
I think you're right.  In one of the last iterations of the patch I moved

+  LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) = partial_load_bias;

after the unsupported check.  It is now only set to something meaningful if it
is not unsupported.

The following should help:

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 8748b1a5593..3c87920090b 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -1170,6 +1170,9 @@ vect_verify_loop_lens (loop_vec_info loop_vinfo)
   machine_mode len_store_mode = get_len_load_store_mode
 (loop_vinfo->vector_mode, false).require ();

+  LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) =
+VECT_PARTIAL_BIAS_UNSUPPORTED;
+
   signed char partial_load_bias = internal_len_load_store_bias
 (IFN_LEN_LOAD, len_load_mode);

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r12-6582-g6d51a9c6447bace21f860e70aed13c6cd90971bd
Author: Kewen Lin 
Date:   Fri Jan 14 07:02:10 2022 -0600

vect: Check partial vector param for supports_partial_vectors [PR104015]

As described in PR104015, the function partial_vectors_supported_p
mainly checks optabs for partial vectors support query, but we
still have one parameter param_vect_partial_vector_usage to control
the capability.

Power9 introduces vector with length instructions (for
len_load/len_store) but we don't enable partial vector on it by
default. It should be considered as not supporting partial vector by
default. This fix is to make the flag supports_partial_vectors check
param_vect_partial_vector_usage accordingly.

gcc/ChangeLog:

PR tree-optimization/104015
* tree-vect-loop.c (vect_analyze_loop): Check
param_vect_partial_vector_usage for supports_partial_vectors.

[Bug libstdc++/91260] std::unary_function and std::binary_function still exist in C++17

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED
   Target Milestone|--- |12.0

--- Comment #4 from Jonathan Wakely  ---
For GCC 12 those types will still exist (because as explained above, that is
allowed by the standard) but they will give -Wdeprecated warnings.

[Bug libstdc++/91383] C++17 should remove some library feature deprecated in C++14

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

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

--- Comment #11 from Jonathan Wakely  ---
For GCC 12 those types will still exist (because as explained above, that is
allowed by the standard) but they will give -Wdeprecated warnings.

[Bug libstdc++/95065] Remove std::bind1st and std::bind2nd when building in -std=c++17

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

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

--- Comment #3 from Jonathan Wakely  ---
For GCC 12 those features will still exist (because as explained above, that is
allowed by the standard) but they will give -Wdeprecated warnings.

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

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

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

--- Comment #9 from Kewen Lin  ---
(In reply to rsand...@gcc.gnu.org from comment #6)
> I think the patch in comment 2 is the correct fix (OK to commit).
> 

Thanks for the review and approval Richard!

I totally agree this test case can be fragile when facing different
vectorisation strategies, but I'm not sure if leaving the exact number
checkings still has a bit value since this case seems the only case to catch
the redundant re-try (at least on Power?), once we fix it not to check any
times, we might miss some sensitive coverage on some useless re-tries, though
the compiling time influence is very very tiny (seems not a big deal :)).

[Bug analyzer/104029] New: internal compiler error with -fanalyzer-checker=taint

[urs at akk dot org via Gcc-bugs]

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

Bug ID: 104029
   Summary: internal compiler error with -fanalyzer-checker=taint
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: urs at akk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 52191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52191&action=edit
preprocessed file

gcc-12 (GCC) 12.0.0 20220114 (experimental)
up to and incl. commit de196e5dd8ea4d0ed01a8c265afdd3676e27545b
configured with --program-suffix=-12 --enable-languages=c,lto --enable-lto
--disable-multilib
on x86_64-pc-linux-gnu

errors out when using

gcc-12 -DHAVE_CONFIG_H -I. -I../include -DLOCALEDIR=\"/usr/share/locale\"
-DDEBUG -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED -g
-std=c11 -O2 -Wextra -Wpedantic -pipe -Wall -Winline -Wshadow
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wbad-function-cast -Wnested-externs -Wcast-align -Wpointer-arith
-Waggregate-return -Wcast-qual -Wwrite-strings -Wundef -Wpacked -Wfloat-equal
-Wunused-macros -Wold-style-definition -Winit-self -Wmissing-include-dirs
-Wlogical-op -Wjump-misses-init -Wformat=2 -Wshift-overflow=2
-Wnull-dereference -Wduplicated-cond -Walloc-zero -Walloca
-Wstringop-overflow=2 -Wduplicated-branches -Wno-format-nonliteral
-Wno-stringop-truncation -Wno-format-truncation -fno-diagnostics-color
-fdiagnostics-generate-patch -fanalyzer -fanalyzer-checker=taint

with

compiling heapsort.o
during IPA pass: analyzer
./heapsort.c: In function ‘heapsort’:
./heapsort.c:169:15: internal compiler error: in alt_get_inherited_state, at
analyzer/sm-taint.cc:652
  169 | abase = (char *)vbase - size;
  | ~~^~

[Bug target/104028] M68k: Error: value -16034 out of range

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-reduction
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Reducing that right now..

[Bug target/104028] M68k: Error: value -16034 out of range

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-14

--- Comment #4 from Martin Liška  ---
Please provide output of m68k-linux-gcc with -v option.

[Bug analyzer/104029] internal compiler error with -fanalyzer-checker=taint

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Reduced test-case:

$ cat pr104029.c
char heapsort_size;

void
heapsort() { char abaseabase = -heapsort_size; }

$ gcc pr104029.c -fanalyzer -fanalyzer-checker=taint
during IPA pass: analyzer
pr104029.c: In function ‘heapsort’:
pr104029.c:4:19: internal compiler error: in alt_get_inherited_state, at
analyzer/sm-taint.cc:652
4 | heapsort() { char abaseabase = -heapsort_size; }
  |   ^~
0x81290a alt_get_inherited_state
/home/marxin/Programming/gcc/gcc/analyzer/sm-taint.cc:652
0x12f081b ana::sm_state_map::get_state(ana::svalue const*, ana::extrinsic_state
const&) const
/home/marxin/Programming/gcc/gcc/analyzer/program-state.cc:424
0x12f299f ana::program_state::can_purge_p(ana::extrinsic_state const&,
ana::svalue const*) const
/home/marxin/Programming/gcc/gcc/analyzer/program-state.h:254
0x12f299f ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::exploded_node*, ana::uncertainty_t*) const
/home/marxin/Programming/gcc/gcc/analyzer/program-state.cc:1151
0x12e03e4 ana::exploded_graph::process_node(ana::exploded_node*)
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:3719
0x12e0ffa ana::exploded_graph::process_worklist()
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:3137
0x12e331e ana::impl_run_checkers(ana::logger*)
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:5716
0x12e4333 ana::run_checkers()
/home/marxin/Programming/gcc/gcc/analyzer/engine.cc:5787
0x12d414c execute
/home/marxin/Programming/gcc/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug analyzer/104029] [12 Regression] ICE with -fanalyzer-checker=taint since r12-5230-gb9365b93212041f1

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|internal compiler error |[12 Regression] ICE with
   |with|-fanalyzer-checker=taint
   |-fanalyzer-checker=taint|since
   ||r12-5230-gb9365b93212041f1

--- Comment #2 from Martin Liška  ---
Started with r12-5230-gb9365b93212041f1.

[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux

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

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

--- Comment #4 from Arnaud Charlet  ---
Thanks for the report and investigation. The issue is actually caused by the
introduction of a "ghost" (empty for code generation purposes) unit
a-nbnbbig.ads, since the change you mentioned didn't change the existing call
to exit(0), the issue was already there before, just never triggered in
libgnat.so.

Patch looks good to me, if you get a successful build and check-ada, it's
preapproved.

[Bug c++/103705] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'array_ref' in finish_omp_clauses, at cp/semantics.c:7928 since r12-5838-g6c0399378e77d029

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Chung-Lin Tang :

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

commit r12-6584-gcd7484d05cd4b7a9d741fe8bf6c4525406ed7620
Author: Chung-Lin Tang 
Date:   Fri Jan 14 21:58:34 2022 +0800

openmp: Fix ICE in [PR103705]

Fix ICE for cases like:
  #pragma omp target update from(s[0].a[0:1])

where multiple ARRAY_REF nodes exist and require more than one peeling
during [c_]finish_omp_clauses.

PR c++/103705

gcc/c/ChangeLog:

* c-typeck.c (c_finish_omp_clauses): Also continue peeling off of
outer node for ARRAY_REFs.

gcc/cp/ChangeLog:

* semantics.c (finish_omp_clauses): Also continue peeling off of
outer node for ARRAY_REFs.

gcc/testsuite/ChangeLog:

* c-c++-common/gomp/pr103705.c: New test.

[Bug c++/99018] Comparing address of array element not considered a constant expression in certain contexts

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
GCC trunk accepts the first testcase ever since r12-6382.

(In reply to David Stone from comment #3)
> The error message looks suspiciously similar to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944. Perhaps it's the same
> bug?

Hmm yeah, it looks like the other testcases here are the same bug as PR85944.

[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account

[eike--- via Gcc-bugs]

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

--- Comment #4 from Rolf Eike Beer  ---
I have rebuilt gcc today, now at commit
b77e3b4e4589e56c01511fabdbaadb029cd47f5c.

Configuration line:

/var/tmp/portage/sys-devel/gcc-12.0.0_pre/work/gcc-12.0.0_pre/configure
--host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu --prefix=/usr
--bindir=/usr/sparc-unknown-linux-gnu/gcc-bin/12.0.0
--includedir=/usr/lib/gcc/sparc-unknown-linux-gnu/12.0.0/include
--datadir=/usr/share/gcc-data/sparc-unknown-linux-gnu/12.0.0
--mandir=/usr/share/gcc-data/sparc-unknown-linux-gnu/12.0.0/man
--infodir=/usr/share/gcc-data/sparc-unknown-linux-gnu/12.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/sparc-unknown-linux-gnu/12.0.0/include/g++-v12
--with-python-dir=/share/gcc-data/sparc-unknown-linux-gnu/12.0.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 12.0.0_pre,
commit b77e3b4e4589e56c01511fabdbaadb029cd47f5c --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--enable-default-pie --enable-default-ssp

I can still trigger the warning:

cd /tmp/cmtest/Source && /usr/bin/c++ -DCURL_STATICLIB -DLIBARCHIVE_STATIC
-D_FILE_OFFSET_BITS=64 -I/tmp/cmtest/Utilities -I/tmp/cmtest/Source
-I/home/buildbot/repos/CMake/Source
-I/home/buildbot/repos/CMake/Source/LexerParser
-I/home/buildbot/repos/CMake/Source/CTest
-I/home/buildbot/repos/CMake/Source/CPack -isystem
/home/buildbot/repos/CMake/Utilities/std -isystem
/home/buildbot/repos/CMake/Utilities -Wnon-virtual-dtor -Wcast-align
-Wchar-subscripts -Wall -W -Wshadow -Wpointer-arith -Wformat-security -Wundef
-g -std=c++17 -MD -MT
Source/CMakeFiles/CMakeLib.dir/cmLocalUnixMakefileGenerator3.cxx.o -MF
CMakeFiles/CMakeLib.dir/cmLocalUnixMakefileGenerator3.cxx.o.d -o
CMakeFiles/CMakeLib.dir/cmLocalUnixMakefileGenerator3.cxx.o -c
/home/buildbot/repos/CMake/Source/cmLocalUnixMakefileGenerator3.cxx
-Wformat-truncation=2

I still have the full gcc build log if that matters.

[Bug c++/85944] Address of temporary bound to a function parameter at global scope not considered constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
The problem seems to be that maybe_nonzero_address doesn't return true for all
temporaries, only those created at function scope, but here the temporary for
'S{}' is created at namespace scope.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Working on that.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Yeah, a lot of test directories rely on one extension for the test and another
for auxiliary sources.
Furthermore, e.g. for libraries inherited from upstreams, we should use
extensions those projects use rather than switching to something we choose.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

--- Comment #7 from Jakub Jelinek  ---
I'd say renaming the *.C in tests to something else would only bring pain and
no gain.

[Bug testsuite/104023] Bulk rename of C++ test files to one filename extension ?

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

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

--- Comment #8 from Martin Liška  ---
I have the following suggestion:

- require all C++ files in gcc/testsuite to have .C extension with the
following exceptions:

1) allow .cc and .cpp for tests of inherited projects (./gdc.test)
2) allow .cc extension for additional files not used directly, but require the
file ending with -aux.cc or -main.cc. Note quite some filenames do follow the
naming scheme

What do you think?

[Bug preprocessor/104030] New: -Wbidi-chars should not warn about UCNs

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 104030
   Summary: -Wbidi-chars should not warn about UCNs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

As discussed in the sub-thread starting at
 "Re:
[PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]",
-Wbidi-chars should not emit warnings when the problematic characters are
written as UCNs rather than verbatim.  For example, the line

> aText = u"\u202D" + aText;

found in the LibreOffice source code should not cause a warning (which couldn't
even be silenced with a local `#pragma GCC diagnostic ignored "-Wbidi-chars"`
due to bug 53431).

[Bug c++/104031] New: [12 regression] Global nested constructors generate invalid code.

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

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

Bug ID: 104031
   Summary: [12 regression] Global nested constructors generate
invalid code.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Extracted from original example of nix-2.4 where global constructors register
invalid primops. Single-file example:

// $ cat main.cc
#include 
#include 

struct Info {
std::vector args;
size_t arity = 0;
};

struct RegisterPrimOp
{
RegisterPrimOp(Info && info) __attribute__((noipa, noinline)) {
if (info.arity != 0)
__builtin_trap();
}
};

static RegisterPrimOp s_op({
.args = {"path"},
.arity = 0,
});

int main() {}

# ok:
$ g++-11.2.0 main.cc -o main -O2 && ./main
# bad:
$ g++-12.0.0 main.cc -o main -O2 && ./main
Illegal instruction (core dumped)

Using built-in specs.
COLLECT_GCC=/<>/gcc-12.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20220109 (experimental) (GCC)

Must be a recent regression. Possibly a close sibling of diagnostic false
positive: https://gcc.gnu.org/PR103984

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|-Wbidi-chars should not |[12 Regression]
   |warn about UCNs |-Wbidi-chars should not
   ||warn about UCNs
   Last reconfirmed||2022-01-14
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Mine then.  Regression because it rejects previously accepted code.

[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
Summary|[12 regression] Global  |[12 regression] Global
   |nested constructors |nested constructors
   |generate invalid code.  |generate invalid code since
   ||r12-6329-g4f6bc28fc7dd86bd
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Keywords||wrong-code

--- Comment #1 from Martin Liška  ---
Also started with r12-6329-g4f6bc28fc7dd86bd.

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #2 from Jakub Jelinek  ---
Either we drop the UCN support altogether, or make -Wbidi-chars a 2 level
warning, -Wbidi-chars mapping to -Wbidi-chars=1 which doesn't warn about UCNs
and
-Wbidi-chars=2 that does.
UCNs indeed don't have the problem that a user in an editor sees something
different than what it actually is (unless some editor interprets UCNs and
shows them as unicode chars), but one reason to warn about UCNs was to make
sure that even what the program prints doesn't suffer from such problems.  Of
course, if something like libreoffice (I bet) carefully ensures it is paired,
but constructs it from smaller separate literals, then it is fine.

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Or e.g. for identifiers with UCNs in them, if they aren't paired, then
as/ld/readelf/demangler at runtime etc. can show weird things.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-14
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
 Target|amdgcn-amdhsa   |amdgcn-amdhsa, aarch64

--- Comment #9 from ktkachov at gcc dot gnu.org ---
We're also seeing this on aarch64-none-elf with:
#include 

void execute(int *y);

void foo (int n) {
  int *b = (int *)malloc((n - 1) * sizeof(int));
  execute(b);

  int n1 = 1.0 / (n - 1);
  for (int i = 0; i < n - 1; i++) {
b[i] *= n1;
  }
}

compiled with -O2 -march=armv8-a+sve

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #4 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #2)
> Either we drop the UCN support altogether, or make -Wbidi-chars a 2 level
> warning, -Wbidi-chars mapping to -Wbidi-chars=1 which doesn't warn about
> UCNs and
> -Wbidi-chars=2 that does.

Exactly.  Except I'm not sure how well that will play with the rest of the
-Wbidi-chars= suboptions.  :/

Like,

-Wbidi-chars=any -Wbidi-chars=2

should probably warn about any bidi chars, including UCNs, but the latter
option might cause it to be just -Wbidi-chars=unpaired, but warn about UCNs.

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #5 from Marek Polacek  ---
So maybe add -Wbidi-chars-ucn, which is off by default.

[Bug analyzer/104029] [12 Regression] ICE with -fanalyzer-checker=taint since r12-5230-gb9365b93212041f1

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from David Malcolm  ---
Thanks for filing this; am working on a fix.

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

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

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

--- Comment #6 from Jakub Jelinek  ---
Or support -Wbidi-chars=unpaired,ucn or -Wbidi-chars=any,ucn ?

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #2)
> Of course, if something like libreoffice (I bet) carefully ensures it is
> paired, but constructs it from smaller separate literals, then it is fine.

(Or doesn't even need to ensure that e.g. a LRO is paired with a PDF, as my
understanding of  "Unicode
Bidirectional Algorithm" is that such an LRO doesn't require a matching PDF, in
which case its effect extends to the end of the paragraph, which appears to be
what the example LibreOffice code in comment 0 makes use of.)

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

[rdapp at linux dot ibm.com via Gcc-bugs]

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

--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 52192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52192&action=edit
Proposed patch

Could you try the proposed patch? Bootstraps cleanly for me and no regressions
on Power or x86.

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

[pmenzel+gcc at molgen dot mpg.de via Gcc-bugs]

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

--- Comment #21 from Paul Menzel  ---
Created attachment 52193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52193&action=edit
[SeaBIOS] [PATCH] smm: Suppress gcc array-bounds warnings

For the record, I attach Kevin’s patch used to work around the issue in
SeaBIOS.

[1]:
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/HLK3BHP2T3FN6FZ46BIPIK3VD5FOU74Z/

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #11 from Tobias Burnus  ---
(In reply to rdapp from comment #8)
> The following should help:

> @@ -1170,6 +1170,9 @@ vect_verify_loop_lens (loop_vec_info loop_vinfo)
> +  LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) =
> +VECT_PARTIAL_BIAS_UNSUPPORTED;

Unfortunately, this does not seem to help. If I place the debugger there,
it seems to call that function.


For the newlib testcase, I now get (in vect_set_loop_controls_directly):
(gdb) p partial_load_bias
$15 = 88

The value first pops up at:

Breakpoint 6, vect_create_loop_vinfo (loop=0x77c49578,
shared=0x7fffe250, info=0x7fffe130, main_loop_info=0x0) at
gcc-mainline/gcc/tree-vect-loop.c:1515
1515  loop_vec_info loop_vinfo = new _loop_vec_info (loop, shared);
(gdb) n
1516  LOOP_VINFO_NITERSM1 (loop_vinfo) = info->number_of_iterationsm1;
(gdb) p loop_vinfo->partial_load_store_bias 
$35 = 88 'X'

Wouldn't it make sense to add that value as initializer
to _loop_vec_info::_loop_vec_info?


Additionally, I have the feeling that vect_set_loop_controls_directly is also
supposed to be called for masked load/store not only for len_(store/load). But
I have not properly read the file.

If so, shouldn't in addition the condition
if (partial_load_bias != 0)
then be changed to
if (partial_load_bias != VECT_PARTIAL_BIAS_UNSUPPORTED && partial_load_bias
!= 0)
?

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #12 from Tobias Burnus  ---
(In reply to rdapp from comment #10)
> Created attachment 52192 [details]
> Proposed patch
> 
> Could you try the proposed patch? Bootstraps cleanly for me and no
> regressions on Power or x86.

It looks as if it is the same as in comment 8. If so, it does not seem to work.
Cf. comment 7.

[Bug middle-end/104026] [12 Regression] ICE in wide_int_to_tree_1, at tree.c:1755 via tree-vect-loop-manip.c:673

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

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

--- Comment #13 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #12)
> It looks as if it is the same as in comment 8. If so, it does not seem to
> work. Cf. comment 7.

I meant: cf. comment 11.

[Bug libstdc++/104032] New: Cannot move-assign a spanstream

[ensadc at mailnesia dot com via Gcc-bugs]

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

Bug ID: 104032
   Summary: Cannot move-assign a spanstream
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://godbolt.org/z/GxdYrYYrj


#include 

int main() {
std::ispanstream a(""), b("");
a = std::move(b);
}


In file included from :1:
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream: In
instantiation of 'std::basic_spanbuf<_CharT, _Traits>&
std::basic_spanbuf<_CharT, _Traits>::operator=(std::basic_spanbuf<_CharT,
_Traits>&&) [with _CharT = char; _Traits = std::char_traits]':
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream:258:24:
  required from here
/opt/compiler-explorer/gcc-trunk-20220114/include/c++/12.0.0/spanstream:89:7:
error: base operand of '->' has non-pointer type 'std::basic_spanbuf'
   89 |   basic_spanbuf(std::move(__rhs))->swap(*this);
  |   ^

[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Blocks||85741
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Martin Sebor  ---
I can reproduce the warning now with the command line options provided in
comment #4: -O0 and -Wformat-truncation=2 are needed to trigger it.  The
interaction of the warning with optimizations (or their absence) is documented
in the manual:

  When the exact number of bytes written by a format directive cannot be
determined at compile-time it is estimated based on heuristics that depend on
the level argument and on optimization. While enabling optimization will in
most cases improve the accuracy of the warning, it may also result in false
positives.

  -Wformat-truncation=2

Level 2 warns also about calls to bounded functions whose return value is
used and that might result in truncation given an argument of sufficient length
or magnitude. 

Not enabling optimization and using -Wformat-truncation=2 increases the chance
that the heuristic of assuming the argument with greatest magnitude (for %04d
it would be INT_MIN) will be used.  GCC still does some value and range
propagation even at -O0 but it doesn't inline function calls (like those to
std::string members) or do other optimizations that might otherwise help it
track data flow more accurately.  Regardless of optimization, the intent of
level 2 is to guide the programmer to provide a buffer that's big enough for
the largest possible output (i.e., you have to either prove to GCC that the
truncation isn't possible or handle it).  At level 1 it's more like the other
way around (GCC has to prove that the call will result in truncation in order
to warn, although there's some fuzziness here and some heuristics apply as
well).

In short, this is not a bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow

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

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

Bug 104012 Summary: [12 regression] -Wformat-truncation warnings not taking 
previous length check into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012

   What|Removed |Added

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

[Bug target/100085] Bad code for union transfer from __float128 to vector types

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

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #15 from Bill Schmidt  ---
This was fixed a while back in r12-1316 by Xiong Hu Luo.

[Bug tree-optimization/104012] [12 regression] -Wformat-truncation warnings not taking previous length check into account

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

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

--- Comment #6 from Martin Sebor  ---
To expand a bit on the fuzziness at level 1.  The logic is documented under the
-Wformat-overflow warning like so:

  Numeric arguments that are known to be bounded to a subrange of their type,
or string arguments whose output is bounded either by their directive’s
precision or by a finite set of string literals, are assumed to take on the
value within the range that results in the most bytes on output.

[Bug fortran/89069] ICE in select type with function returning class array pointer

[antony at cosmologist dot info via Gcc-bugs]

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

--- Comment #3 from Antony Lewis  ---
This bug is still valid as of  gcc 11.2.1 20220114


  15 | end module test
  |   1
internal compiler error: Segmentation fault
0x160a5b7 internal_error(char const*, ...)
???:0
0x764849 gfc_class_data_get(tree_node*)
???:0
0x7b0111 gfc_trans_block_construct(gfc_code*)
???:0
0x762224 gfc_generate_function_code(gfc_namespace*)
???:0
0x73c1d1 gfc_generate_module_code(gfc_namespace*)
???:0
0x6dd185 gfc_parse_file()
???:0

[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd

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

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

--- Comment #2 from Andrew Pinski  ---
I can remove std::string but not figure out how to remove std::vector yet:
#include 
#include 

struct string
{
  string(int){}
};

struct allocator
{
  allocator(){}
};

struct vector
{
  vector(allocator t = allocator{}){}
  vector(string, allocator t = allocator{}){}
  vector(std::initializer_list&, allocator t = allocator{}){}
};

#if 1
typedef std::vector t;
#else
typedef vector t;
#endif

struct Info {
t args;
int arity;
};

struct RegisterPrimOp
{
RegisterPrimOp(Info && info) __attribute__((noipa, noinline)) {
if (info.arity != 0)
__builtin_trap();
}
};

static RegisterPrimOp s_op({
.args = {1},
.arity = 0,
});

int main() {}