[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

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

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

--- Comment #20 from Jiu Fu Guo  ---
Created attachment 52114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52114&action=edit
testcases

With these test cases, invoke 'foo' in these cases 1000,000,000 times, to see
the runtime:
building 'constant' through 1 insn is fastest.
next faster is building const by 2 instructions, or loading from rodata, or
loading from toc.
building const by 3 instructions is slower than loading from rodata, building
const by 5 ins is slowest.

[Bug rtl-optimization/103900] New: ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103900
   Summary: ICE: in expand_expr_real_2, at expr.c:9771 with -O
-fno-tree-dce -fno-tree-dse
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-dce -fno-tree-dse testcase.c 
during RTL pass: expand
testcase.c: In function 'foo0':
testcase.c:11:1: internal compiler error: in expand_expr_real_2, at expr.c:9771
   11 | foo0() {
  | ^~~~
0x6c4ecd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.c:9771
0xe66f8f expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3967
0xe66f8f expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:4028
0xe6cd18 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6069
0xe6eea7 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ 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-6199-20220104114958-g05da96886ef-checking-yes-rtl-df-extra-nobootstrap-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
--disable-bootstrap --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-6199-20220104114958-g05da96886ef-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20220104 (experimental) (GCC)

[Bug c++/103868] ICE at end of coroutine when using asio

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

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

--- Comment #3 from Martin Liška  ---
Created attachment 52116
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52116&action=edit
Partially reduced test-case

The test-case fails with the following on master:

$ ./xgcc -B. /tmp/x.ii -c -std=c++20 -w
during RTL pass: expand
/tmp/x.ii: In function ‘void
malloy::test::client_ws_handler_coro(client_ws_handler_coro(malloy::error_code,
std::shared_ptr
>)::_ZN6malloy4test22client_ws_handler_coroILb0EEEN5boost4asio9awaitableIvNS3_15any_io_executorEEENS2_6system10error_codeESt10shared_ptrINS_9websocket10connectionILb1.Frame*)’:
/tmp/x.ii:1035:70: internal compiler error: in make_decl_rtl, at varasm.c:1446
 1035 |   auto size = co_await conn->read(*buffer, boost::asio::use_awaitable);
  |  ^
0x8f7d91 make_decl_rtl(tree_node*)
/home/marxin/Programming/gcc/gcc/varasm.c:1446
0xe7ede7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10550
0xe87d77 expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:301
0xe87d77 expand_expr_addr_expr_1
/home/marxin/Programming/gcc/gcc/expr.c:8427
0xe7e2c4 expand_expr_addr_expr
/home/marxin/Programming/gcc/gcc/expr.c:8548
0xe7e2c4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:11764
0xe8aa46 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/marxin/Programming/gcc/gcc/expr.c:6087
0xe8c25d expand_assignment(tree_node*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5819
0xd4b07a expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3930
0xd4b07a expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:4028
0xd5155c expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6069
0xd53727 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Note it uses coroutines and -fconcepts.

$ (gdb) p debug_tree(decl)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77462b28
fields 
public abstract external autoinline decl_3 decl_8 QI
/tmp/x.ii:982:7 align:16 warn_if_not_align:0 context 
full-name "constexpr boost::asio::detail::awaitable_frame::~awaitable_frame() noexcept ()"
not-really-extern chain >
context 
full-name "std::__n4861::coroutine_traits,
boost::system::error_code, std::shared_ptr
> >::promise_type"
X() X(constX&) this=(X&) n_parents=1 use_template=1 interface-unknown
pointer_to_this  chain >
addressable used read QI /tmp/x.ii:1035:70 size  unit-size 
align:8 warn_if_not_align:0>
$1 = void

[Bug c++/103868] ICE at end of coroutine when using asio

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection,|
   |needs-reduction |
 CC||iains at gcc dot gnu.org,
   ||ville.voutilainen at gmail dot 
com

--- Comment #4 from Martin Liška  ---
Likely started with r11-4386-g9e2256dcd481ffe3, it's rejected before the
revision.

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

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

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

--- Comment #80 from Martin Liška  ---
I've got access to a bdver2 machine, so I should be able to reproduce it.

[Bug c++/103901] New: A lambda with a new type in its body cannot be defined inside template parameter list

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103901
   Summary: A lambda with a new type in its body cannot be defined
inside template parameter list
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following valid struct template definition:
```
template 
struct B {};
```
is accepted by Clang and MSVC, but not by GCC that complains `error: definition
of 'struct::A' inside template parameter list`. Demo:
https://gcc.godbolt.org/z/f1dxGbPvs

Related discussion: https://stackoverflow.com/q/70571380/7325599

[Bug fortran/103898] [12 Regression] ICE: gimplification failed

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
(In reply to anlauf from comment #5)
> Started most likely with commit r12-3897 by Tobias.

Confirmed it started with r12-3897-g00f6de9c69119594.

[Bug rtl-optimization/103900] [12 Regression] ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse since r12-6173-g9ff206d3865df5cb

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-01-04
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW
Summary|ICE: in expand_expr_real_2, |[12 Regression] ICE: in
   |at expr.c:9771 with -O  |expand_expr_real_2, at
   |-fno-tree-dce -fno-tree-dse |expr.c:9771 with -O
   ||-fno-tree-dce -fno-tree-dse
   ||since
   ||r12-6173-g9ff206d3865df5cb
 CC||marxin at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #1 from Martin Liška  ---
Started with r12-6173-g9ff206d3865df5cb.

[Bug libstdc++/103629] [11/12 Regression] Possible miscompilation visible using pthread + exception

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-04
 Ever confirmed|0   |1
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW

--- Comment #19 from Richard Biener  ---
Seems confirmed at least.

[Bug c++/103631] [11/12 Regression] ICE in C++20 class NTTP + concept since r12-100-gbcd77b7b9f35bd5b

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0

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

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

--- Comment #5 from Eric Botcazou  ---
> Eric, could you kindly test the patch attached, and let me know if it fixes
> gfortran.dg/ieee/ieee_6.f90? Does it introduce any other failure?

The SPARC64/Linux machine of the Compile Farm apparently has network issues.

[Bug objc/103639] [11 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[11/12 Regression] switch   |[11 Regression] switch case
   |case with break in fast |with break in fast
   |enumeration loop generates  |enumeration loop generates
   |wrong code  |wrong code
  Known to work||12.0

[Bug rtl-optimization/103860] [9/10/11 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

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

https://gcc.gnu.org/g:801b2c880c8079934ac186ea1c31f3bf4af5aef3

commit r12-6202-g801b2c880c8079934ac186ea1c31f3bf4af5aef3
Author: Jakub Jelinek 
Date:   Tue Jan 4 10:12:17 2022 +0100

shrink-wrapping: Don't call can_get_prologue unnecessarily [PR103860]

On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote:
> > The following simple patch makes sure we call can_get_prologue even
after
> > the last former iteration when vec is already empty and only break from
> > the loop afterwards (and only if the updating of pro done because of
> > !can_get_prologue didn't push anything into vec again).

During the development of the above patch I've noticed that in many cases
we call can_get_prologue often on the same pro again and again and again,
we can have many basic blocks pushed into vec and if most of those don't
require pro updates, i.e.
  basic_block bb = vec.pop ();
  if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size))
while (!dominated_by_p (CDI_DOMINATORS, bb, pro))
isn't true, then pro is can_get_prologue checked for each bb in the vec.

The following simple patch just remembers which bb we've verified already
and verifies again only when pro changes.  Most of the patch is just
reindentation.

2022-01-04  Jakub Jelinek  

PR rtl-optimization/103860
* shrink-wrap.c (try_shrink_wrapping): Don't call can_get_prologue
uselessly for blocks for which it has been called already.

[Bug tree-optimization/103544] [11 Regression] compiler crashes when trying to vectorize loop

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

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

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

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

commit r12-6203-g1a15451da14410bf2bd6ec8f5baba1014638c67a
Author: Richard Biener 
Date:   Tue Jan 4 10:12:47 2022 +0100

tree-optimization/103864 - SLP reduction of reductions with conversions

This generalizes the fix for PR103544 to also cover reductions that
are not reduction chains and does not consider reductions wrapped in
sign conversions for SLP reduction handling.

2022-01-04  Richard Biener  

PR tree-optimization/103864
PR tree-optimization/103544
* tree-vect-slp.c (vect_analyze_slp_instance): Exclude
reductions wrapped in conversions from SLP handling.
(vect_analyze_slp): Revert PR103544 change.

* gcc.dg/vect/pr103864.c: New testcase.

[Bug tree-optimization/103864] [11/12 Regression] ICE in vect_transform_reduction, at tree-vect-loop.c:7389 since r10-4675-g05101d1b575a57ca26e4275e971da85a0dd1d52a

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

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

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

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

commit r12-6203-g1a15451da14410bf2bd6ec8f5baba1014638c67a
Author: Richard Biener 
Date:   Tue Jan 4 10:12:47 2022 +0100

tree-optimization/103864 - SLP reduction of reductions with conversions

This generalizes the fix for PR103544 to also cover reductions that
are not reduction chains and does not consider reductions wrapped in
sign conversions for SLP reduction handling.

2022-01-04  Richard Biener  

PR tree-optimization/103864
PR tree-optimization/103544
* tree-vect-slp.c (vect_analyze_slp_instance): Exclude
reductions wrapped in conversions from SLP handling.
(vect_analyze_slp): Revert PR103544 change.

* gcc.dg/vect/pr103864.c: New testcase.

[Bug tree-optimization/103864] [11 Regression] ICE in vect_transform_reduction, at tree-vect-loop.c:7389 since r10-4675-g05101d1b575a57ca26e4275e971da85a0dd1d52a

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[11/12 Regression] ICE in   |[11 Regression] ICE in
   |vect_transform_reduction,   |vect_transform_reduction,
   |at tree-vect-loop.c:7389|at tree-vect-loop.c:7389
   |since   |since
   |r10-4675-g05101d1b575a57ca2 |r10-4675-g05101d1b575a57ca2
   |6e4275e971da85a0dd1d52a |6e4275e971da85a0dd1d52a
  Known to fail|12.0|
  Known to work||12.0

[Bug middle-end/103643] [12 Regression][OpenMP] ICE in create_tmp_var, at gimple-expr.c:482 - via gimplify_omp_affinity

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103647] constant array comparison not always folded

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

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

--- Comment #3 from Richard Biener  ---
fab is a bit late for this part of memcmp folding I guess, I'd have expected
that to happen in generic folding like when we inline memcpy.  It seems it's
actually the strlen pass that inlines the compare.

[Bug c++/103902] New: Only the addition space between string-literal and identifier in a literal-operator-id will be accepted by GCC where the identifier is not in a basic character set

[xmh970252187 at gmail dot com via Gcc-bugs]

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

Bug ID: 103902
   Summary: Only the addition space between string-literal and
identifier in a literal-operator-id will be accepted
by GCC where the identifier is not in a basic
character set
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xmh970252187 at gmail dot com
  Target Milestone: ---

bool operator ""_Ã(unsigned long long){
   return true;
}

The above code is not accepted by GCC. It should be passed around by adding a
space between "" and _Ã. However, it is accepted by Clang, and it is not
necessary to add that space.

[Bug fortran/103662] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|TBAA problem in Fortran FE  |[12 Regression] TBAA
   |triggering in   |problem in Fortran FE
   |gfortran.dg/unlimited_polym |triggering in
   |orphic_3.f03|gfortran.dg/unlimited_polym
   ||orphic_3.f03
   Target Milestone|--- |12.0

--- Comment #7 from Richard Biener  ---
I'm marking it as a regression, note the "mistake" in the frontend generated
code is latent.

[Bug tree-optimization/103665] insert_trap in gimple-isolate-paths interferes badly with modref, pure-const and other optimizations

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

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

--- Comment #2 from Richard Biener  ---
Maybe we can simply use

  __builtin_trap[_mem] (&MEM[(union tree_node *)0B].base.code);

[Bug target/103900] [12 Regression] ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse since r12-6173-g9ff206d3865df5cb

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
Looks fixed, does not ICE for me with:

GNU C17 (GCC) version 12.0.0 20220104 (experimental) [master
r12-6200-g62c8b21d48a] (x86_64-pc-linux-gnu)

[Bug gcov-profile/103666] [11/12 Regression] compiling single-file programs with -fprofile-generate no longer leads to intended results since r11-627-g1dedc12d186a1108

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX
Summary|[11/12 Regression]  |[11/12 Regression]
   |compiling single-file   |compiling single-file
   |preprocessed programs with  |programs with
   |-fprofile-generate no   |-fprofile-generate no
   |longer leads to intended|longer leads to intended
   |results since   |results since
   |r11-627-g1dedc12d186a1108   |r11-627-g1dedc12d186a1108

--- Comment #2 from Richard Biener  ---
that's because the explicitely named linker output in the -fprofile-use case. 
A fix might be to separate compile and link step.  I don't think there's
anything special about using preprocessed source:

> cat t.c
int main(){}
> ./xgcc -B. t.c -fprofile-generate
> ./a.out 
> ./xgcc -B. t.c -fprofile-use -o a.out-use
t.c: In function 'main':
t.c:1:1: warning: '/tmp/obj/gcc/a.out-use-t.gcda' profile count data file not
found [-Wmissing-profile]
1 | int main(){}
  | ^~~
> ls *.gcda
a-t.gcda

I'd declare this as WONTFIX.  I've adjusted the C++ tester for tramp3d to use
an
explicit -dumpbase

[Bug c++/103672] [10/11/12 Regression] using with template class> causes internal compiler error

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |10.4

[Bug target/103900] [12 Regression] ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse since r12-6173-g9ff206d3865df5cb

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #2)
> Looks fixed, does not ICE for me with:

Maybe the fix for PR 103895 fixed this one also.

[Bug target/103900] [12 Regression] ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse since r12-6173-g9ff206d3865df5cb

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #2)
> Looks fixed, does not ICE for me with:
> 
> GNU C17 (GCC) version 12.0.0 20220104 (experimental) [master
> r12-6200-g62c8b21d48a] (x86_64-pc-linux-gnu)

Or rather it is the RTL checking which is causing the extra assert fail.

[Bug target/103900] [12 Regression] ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse since r12-6173-g9ff206d3865df5cb

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

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

--- Comment #5 from Martin Liška  ---
No, it still crashes with the current master (g:fbb592407c9):

$ gcc pr103900.c -c -O -fno-tree-dce -fno-tree-dse --save-temps --verbose
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: /home/marxin/Programming/gcc/configure
--enable-languages=c,c++,fortran,jit --prefix=/home/marxin/bin/gcc
--disable-multilib --enable-host-shared --disable-libsanitizer
--enable-valgrind-annotations --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20220104 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-O' '-fno-tree-dce' '-fno-tree-dse' '-save-temps'
'-v' '-mtune=generic' '-march=x86-64'
 /home/marxin/bin/gcc/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/cc1 -E -quiet -v
pr103900.c -mtune=generic -march=x86-64 -fno-tree-dce -fno-tree-dse -O
-fpch-preprocess -o pr103900.i
ignoring nonexistent directory
"/home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/12.0.0/include
 /usr/local/include
 /home/marxin/bin/gcc/include
 /home/marxin/bin/gcc/lib64/gcc/x86_64-pc-linux-gnu/12.0.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-O' '-fno-tree-dce' '-fno-tree-dse' '-save-temps'
'-v' '-mtune=generic' '-march=x86-64'
 /home/marxin/bin/gcc/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/cc1 -fpreprocessed
pr103900.i -quiet -dumpbase pr103900.c -dumpbase-ext .c -mtune=generic
-march=x86-64 -O -version -fno-tree-dce -fno-tree-dse -o pr103900.s
GNU C17 (GCC) version 12.0.0 20220104 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.2.1 20211124 [revision
7510c23c1ec53aa4a62705f0384079661342ff7b], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 12.0.0 20220104 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.2.1 20211124 [revision
7510c23c1ec53aa4a62705f0384079661342ff7b], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c265fe5ba5ef24bee29b1830921bb05e
during RTL pass: expand
pr103900.c: In function ‘foo0’:
pr103900.c:11:1: internal compiler error: in expand_expr_real_2, at expr.c:9771
   11 | foo0() {
  | ^~~~
0x6e2341 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/marxin/Programming/gcc/gcc/expr.c:9771
0xa3bf75 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3967
0xa3bf75 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:4028
0xa41dac expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6069
0xa43f77 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/103675] gather is a loss for floats and win for doubles at zen3

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #1 from Richard Biener  ---
I suppose more fine-grained control would be useful.  It's not clear to me
whether the tests cover V2DF and V4DF and V4SF and V8SF and whether the
win/not win correlates more to the number of elements than the element mode.

[Bug tree-optimization/103680] Jump threading and switch corrupts profile

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

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

--- Comment #4 from Richard Biener  ---
And for CFG cleanup there's no profile updating done when passes leave CFG
update to it by simplifying conditions to if (0) or if (1).  One could argue
that
"late" simplifications simply make the guessed profile bogus - for feedback
profiles the cut paths should have zero count already.

[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946

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

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

--- Comment #7 from Richard Biener  ---
-m[no-]fold-gimple is also a very badly named user option since it suggests
that 'fold' and 'gimple' are terms known to programmers.  I'm just guessing
it was added to avoid "inlining" intrinsics as GIMPLE, so
-m[no-]inline-intrinsics would have been more appropriate ;)  (or
-m[no-]optimize-intrinsics)

[Bug target/103900] [12 Regression] ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse since r12-6173-g9ff206d3865df5cb

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Martin Liška from comment #5)
> No, it still crashes with the current master (g:fbb592407c9):

Ah, the compiler is blindly trying to generate V2QI XOR due to missing
one_cmplv2qi2 pattern. I have a patch that implements V2QI logic insns that
fixes the ICE.

[Bug target/103900] [12 Regression] ICE: in expand_expr_real_2, at expr.c:9771 with -O -fno-tree-dce -fno-tree-dse since r12-6173-g9ff206d3865df5cb

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

--- Comment #7 from Uroš Bizjak  ---
Created attachment 52117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52117&action=edit
Patch that implements v2qi logic insns

[Bug libstdc++/103891] clang-13 fails to compile libstdc++'s std::variant>: error: attempt to use a deleted function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED
   See Also||https://github.com/llvm/llv
   ||m-project/issues/45614

--- Comment #3 from Jonathan Wakely  ---
This is a known bug (or unfinished feature) in Clang.

https://github.com/llvm/llvm-project/issues/45614

We're not going to work around it in libstdc++ because there is no feature test
macro that allows us to detect whether clang supports it, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2493r0.html for
details.

If/when GCC bumps the value of __cpp_concepts we can use that to make C++20
support in std::variant conditional on compiler support.

[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946

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

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

--- Comment #8 from Segher Boessenkool  ---
It is an internal (debugging) option.  It isn't documented in the manual, but
indeed it is not marked as Undocumented in rs6000.opt .

[Bug libstdc++/103891] clang-13 fails to compile libstdc++'s std::variant>: error: attempt to use a deleted function

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

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

--- Comment #4 from Jonathan Wakely  ---
I suppose we could just do:

--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -54,7 +54,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION

-#if __cplusplus >= 202002L && __cpp_concepts
+#if __cplusplus >= 202002L && __cpp_concepts && __GNUC__ >= 12
 // P2231R1 constexpr needs constexpr unions and constrained destructors.
 # define __cpp_lib_variant 202106L
 #else

And then improve it later if GCC updates __cpp_concepts

[Bug tree-optimization/103690] [12 Regression] ICE: in build2, at tree.c:4985 with -g -O2 -fno-tree-dce -fno-tree-dse -fno-tree-fre --param=max-jump-thread-duplication-stmts=94 since r12-2591-g2e96b5f

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Value numbering stmt = __trans_tmp_1_14 = _24 + 4;
Setting value number of __trans_tmp_1_14 to __trans_tmp_1_22 (changed)

what we do is avoiding useless work during elimination, not visiting if (0)
guarded code - those regions will have not up-to-date SSA form.

Block 14: BB5 found not executable

the issue is that PRE does

  /* Because we don't follow exactly the standard PRE algorithm, and decide not
 to insert PHI nodes sometimes, and because value numbering of casts isn't
 perfect, we sometimes end up inserting dead code.   This simple DCE-like
 pass removes any insertions we made that weren't actually used.  */
  simple_dce_from_worklist (inserted_exprs);

which eventually runs into those uses for expressions we inserted into those
unreachable blocks.

The issue is long latent I think.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #3 from Richard Biener  ---
Yes, folding debug stmts is OK but we usually don't do that unless we
substitute into them (so that's maybe why the issue pops up now).  It might be
wise to avoid folding debug stmts as a workaround.

Clearly the RANGE_EXPR the Fortran FE builds here is wrong, but as far as I
understand the testcase is invalid?

   real, parameter :: a(0) = 2.0

that's an array with zero elements which you initialize.

[Bug fortran/103692] [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
   Priority|P3  |P4

[Bug fortran/103693] [12 Regression] ICE in gfc_array_dimen_size(): Bad EXPR_ARRAY expr since r12-4967-gbcf3728abe848888

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |12.0

[Bug fortran/103694] [12 Regression] ICE in gfc_conv_expr_op, at fortran/trans-expr.c:3882 since r12-3993-gb19bbfb148250536

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P4

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0

[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

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P1
Summary|ICE: tree check: expected   |[12 Regression] ICE: tree
   |tree that contains 'decl|check: expected tree that
   |minimal' structure, have|contains 'decl minimal'
   |'array_ref' in  |structure, have 'array_ref'
   |finish_omp_clauses, at  |in finish_omp_clauses, at
   |cp/semantics.c:7928 since   |cp/semantics.c:7928 since
   |r12-5838-g6c0399378e77d029  |r12-5838-g6c0399378e77d029

[Bug fortran/103715] [9/10/11/12 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.5

[Bug fortran/103716] [10/11/12 Regression] ICE in gimplify_expr, at gimplify.c:15964 since r9-3803-ga5fbc2f36a291cbe

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #81 from David Binderman  ---
Created attachment 52118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52118&action=edit
preprocessed source code

Bug seems to have moved to unwind-dw2.c. Preprocessed source code attached.

[Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #82 from David Binderman  ---
(In reply to rguent...@suse.de from comment #79)
> OK, so can you - in a -march=bdver2 built tree (that then fails) - produce
> options-save.ii (preprocessed source) and attach that?  

Done.

> Can you try whether you get past the failure point when you add 
> -fno-tree-vectorize to just the options-save.o compilation?  

Flag doesn't help.

> Can you provide the -v output
> of the options-save.o compile so we get the exact cc1plus invocation?

Compile command is this:

/home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/
-B/home/dcb/gcc/results.20220104/x86_64-pc-linux-
gnu/bin/ -B/home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/lib/ -isystem
/home/dcb/gcc/results.20220104/x86_64
-pc-linux-gnu/include -isystem
/home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/sys-include   -fchecking=1
-g -
O3 -march=native -O2  -g -O3 -march=native -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-e
rror=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem
 ./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fn
o-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection
-mshstk -I. -I. -I../.././gcc -I../../
../trunk.git/libgcc -I../../../trunk.git/libgcc/.
-I../../../trunk.git/libgcc/../gcc -I../../../trunk.git/libgcc/
../include -I../../../trunk.git/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS  -MT un
wind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c -fno-tree-vectorize
../../../trunk.git/libgcc/unwind-dw2.c 
-fvisibility=hidden -DHIDE_EXPORTS 

cc1 command line is

 /home/dcb/gcc/working/./gcc/cc1 -quiet -v -I . -I . -I ../.././gcc -I
../../../trunk.git/libgcc -I ../../../trunk.git/libgcc/. -I
../../../trunk.git/libgcc/../gcc -I ../../../trunk.git/libgcc/../include -I
../../../trunk.git/libgcc/config/libbid -iprefix
/home/dcb/gcc/working/gcc/../lib/gcc/x86_64-pc-linux-gnu/12.0.0/ -isystem
/home/dcb/gcc/working/./gcc/include -isystem
/home/dcb/gcc/working/./gcc/include-fixed -MD unwind-dw2.d -MF unwind-dw2.dep
-MP -MT unwind-dw2.o -D IN_GCC -D USE_ELF_SYMVER -D IN_LIBGCC2 -D
USE_ELF_SYMVER -D ENABLE_DECIMAL_BID_FORMAT -D HAVE_CC_TLS -D USE_TLS -D
HIDE_EXPORTS -isystem
/home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/include -isystem
/home/dcb/gcc/results.20220104/x86_64-pc-linux-gnu/sys-include -isystem
./include ../../../trunk.git/libgcc/unwind-dw2.c -march=bdver2 -mmmx -mpopcnt
-msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mno-avx2 -msse4a -mfma4
-mxop -mfma -mno-avx512f -mbmi -mno-bmi2 -maes -mpclmul -mno-avx512vl
-mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf
-mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps
-mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni
-mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -mno-adx
-mabm -mno-cldemote -mno-clflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd
-mf16c -mno-fsgsbase -mfxsr -mno-hle -msahf -mlwp -mlzcnt -mno-movbe
-mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1
-mprfchw -mno-ptwrite -mno-rdpid -mno-rdrnd -mno-rdseed -mno-rtm -mno-serialize
-mno-sgx -mno-sha -mno-shstk -mtbm -mno-tsxldtrk -mno-vaes -mno-waitpkg
-mno-wbnoinvd -mxsave -mno-xsavec -mno-xsaveopt -mno-xsaves -mno-amx-tile
-mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl
-mno-avxvnni -mno-avx512fp16 --param l1-cache-size=16 --param
l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -quiet -dumpbase
unwind-dw2.c -dumpbase-ext .c -mlong-double-80 -mshstk -g -g -g -O3 -O2 -O3
-Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
-Wold-style-definition -version -fchecking=1 -fcf-protection=full
-fbuilding-libgcc -fno-stack-protector -fpic -fcf-protection=full -fexceptions
-fvisibility=hidden

[Bug tree-optimization/103723] zero extend not sunk out of the loop after IV-OPTS in the sink pass

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|zero extend not moved out   |zero extend not sunk out of
   |of the loop after IV-OPTS   |the loop after IV-OPTS in
   ||the sink pass

--- Comment #3 from Richard Biener  ---
Note there's pass_sink_code after IVOPTs which is what is designed to perform
sinking.  That is probably confused by seeing

   [local count: 1014686026]:
  # ivtmp.7_15 = PHI 
  _4 = (unsigned int) ivtmp.7_15;
  _3 = MEM[(const uint8_t *)buf_9(D) + ivtmp.7_15 * 1];
  _6 = MEM[(const uint8_t *)buf_back_11(D) + ivtmp.7_15 * 1];
  if (_3 == _6)
goto ; [94.50%]
  else
goto ; [5.50%]

   [local count: 55807731]:

   [local count: 114863531]:
  # len_test_14 = PHI 
  return len_test_14;

where it doesn't consider inserting on edges because usually the pred works
fine but here it's a no-op sink and splitting the edge might be profitable
because its a loop exit.

So the sinking pass needs tweaking for such case (but _not_ split the edge
in case the PHI use is on a simple merge)

[Bug tree-optimization/103725] [9/10/11/12 Regression] warning: assuming signed overflow does not occur when simplifying conditional to constant

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.5

--- Comment #3 from Richard Biener  ---
We've mostly pruned all the singed overflow diagnostics when touching stuff but
some are still there ...

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
To me it looks like the PR52329 change wasn't correct.  In particular, it
should have been using true as the second argument and not false and therefore
should have been removed in the r12-21-g0bf8cd9d5e8ac changes rather than kept.
If I modify the testcase from a(0) to a(2), then I see
pr103691.f90.037t.fre1:  # DEBUG D.4293 => &a[0]
and
pr103691.f90.038t.evrp:  # DEBUG D.4293 => &2.0e+0
The &2.0e+0 is just a wrong-debug, debug info was supposed to contain address
of
a, not address of some constant that happens to be in the first element of the
array.
fold_stmt_1 earlier has:
case GIMPLE_DEBUG:
  if (gimple_debug_bind_p (stmt))
{
  tree *val = gimple_debug_bind_get_value_ptr (stmt);
  if (*val
  && (REFERENCE_CLASS_P (*val)
  || TREE_CODE (*val) == ADDR_EXPR)
  && maybe_canonicalize_mem_ref_addr (val, true))
changed = true;
}
which I believe should perform whatever PR52329 was meant to deal with.
So I think
  else if (val
   && TREE_CODE (val) == ADDR_EXPR)
{
  tree ref = TREE_OPERAND (val, 0);
  tree tem = maybe_fold_reference (ref);
  if (tem)
{
  tem = build_fold_addr_expr_with_type (tem, TREE_TYPE (val));
  gimple_debug_bind_set_value (stmt, tem);
  changed = true;
}
}
should be just dropped.

[Bug tree-optimization/103690] [12 Regression] ICE: in build2, at tree.c:4985 with -g -O2 -fno-tree-dce -fno-tree-dse -fno-tree-fre --param=max-jump-thread-duplication-stmts=94 since r12-2591-g2e96b5f

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

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

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

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

commit r12-6208-gebc853deb7cc0487de9ef6e891a007ba853d1933
Author: Richard Biener 
Date:   Tue Jan 4 11:59:35 2022 +0100

tree-optimization/103690 - not up-to-date SSA and PRE DCE

This avoids running simple_dce_from_worklist on partially not up-to-date
SSA form (in unreachable code regions) by scheduling CFG cleanup
manually as is done anyway when tail-merging runs.

2022-01-04  Richard Biener  

PR tree-optimization/103690
* tree-pass.h (tail_merge_optimize): Adjust.
* tree-ssa-tail-merge.c (tail_merge_optimize): Pass in whether
to re-split critical edges, move CFG cleanup ...
* tree-ssa-pre.c (pass_pre::execute): ... here, before
simple_dce_from_worklist and delay freeing inserted_exprs from
...
(fini_pre): .. here.

[Bug tree-optimization/103690] [12 Regression] ICE: in build2, at tree.c:4985 with -g -O2 -fno-tree-dce -fno-tree-dse -fno-tree-fre --param=max-jump-thread-duplication-stmts=94 since r12-2591-g2e96b5f

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> To me it looks like the PR52329 change wasn't correct.  In particular, it
> should have been using true as the second argument and not false and
> therefore should have been removed in the r12-21-g0bf8cd9d5e8ac changes
> rather than kept.
> If I modify the testcase from a(0) to a(2), then I see
> pr103691.f90.037t.fre1:  # DEBUG D.4293 => &a[0]
> and
> pr103691.f90.038t.evrp:  # DEBUG D.4293 => &2.0e+0
> The &2.0e+0 is just a wrong-debug, debug info was supposed to contain
> address of
> a, not address of some constant that happens to be in the first element of
> the array.
> fold_stmt_1 earlier has:
> case GIMPLE_DEBUG:
>   if (gimple_debug_bind_p (stmt))
> {
>   tree *val = gimple_debug_bind_get_value_ptr (stmt);
>   if (*val
>   && (REFERENCE_CLASS_P (*val)
>   || TREE_CODE (*val) == ADDR_EXPR)
>   && maybe_canonicalize_mem_ref_addr (val, true))
> changed = true;
> }
> which I believe should perform whatever PR52329 was meant to deal with.
> So I think
>   else if (val
>&& TREE_CODE (val) == ADDR_EXPR)
> {
>   tree ref = TREE_OPERAND (val, 0);
>   tree tem = maybe_fold_reference (ref);
>   if (tem)
> {
>   tem = build_fold_addr_expr_with_type (tem, TREE_TYPE
> (val));
>   gimple_debug_bind_set_value (stmt, tem);
>   changed = true;
> }
> }
> should be just dropped.

Agreed.

[Bug fortran/103691] [12 Regression] ICE in get_array_ctor_element_at_index, at fold-const.c:13314 since r12-4694-gcb153222404e2e14

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

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

--- Comment #6 from Jakub Jelinek  ---
Ok, will test that change.
The FE should be probably also fixed to drop such initializers, there is no
point to have initializers for empty arrays.

[Bug tree-optimization/103761] [12 Regression] ICE in exact_div, at poly-int.h:2239 since r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/103763] [12 regression] gcc.target/powerpc/fold-vec-splat-floatdouble.c fails after r12-5988

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/103765] Missed arithmetic simplification for multiplication + division

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
extract_muldiv.  IMHO re-association should handle such stuff since
extract_muldiv would also handle ((x * 72) * y) / 3 IIRC.

But sure, the simple x * CST / CST case might be OK for match.pd

[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Version|unknown |12.0
 Resolution|--- |FIXED

--- Comment #20 from Richard Biener  ---
The division is now vectorized, your short testcase produces

t:
.LFB0:
.cfi_startproc
movss   f(%rip), %xmm4
movss   test+8(%rip), %xmm3
movqtest(%rip), %xmm0
mulss   %xmm4, %xmm3
movaps  %xmm4, %xmm1
shufps  $0xe0, %xmm1, %xmm1
mulps   %xmm1, %xmm0
movhps  .LC0(%rip), %xmm1
rcpps   %xmm1, %xmm2
sqrtss  %xmm3, %xmm3
mulps   %xmm2, %xmm1
sqrtps  %xmm0, %xmm0
divss   %xmm4, %xmm3
mulps   %xmm2, %xmm1
addps   %xmm2, %xmm2
subps   %xmm1, %xmm2
mulps   %xmm2, %xmm0
movlps  %xmm0, test(%rip)
movss   %xmm3, test+8(%rip)
ret

[Bug middle-end/103813] [11 Regression] Crash in decompose, at wide-int.h:984 fold-const since r11-5271-g4866b2f5db117f9e

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/103815] IVCann/IVOPTs changes induction variable so it is an addition but the need for shift is there and the result could have used for the (loop) exit compare

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
It's difficult for IVOPTs to handle this since CC are not modeled on GIMPLE.
'add' is also not an affine induction variable and thus is not considered
at all when representing the exit test.

[Bug tree-optimization/103821] [12 Regression] huge compile time (jump threading) at -O3 for simple code since r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #4 from Richard Biener  ---
I think the recent modref change made the function const.

And no, we shouldn't DSE any volatile store and generally we don't.  It's
probably some side-effect of modref that we do.  Using -fno-ipa-pure-const
"fixes" this bug with -Og:

 local analysis of void MyClass::call()/1
   NULL memory access; terminating BB
Function is locally const.
callgraph:

so it's caused by the recent change to mitigate path-isolation damage to
modref.

[Bug rtl-optimization/103837] [9/10/11 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/103850] missed optimization in AVX code

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #83 from Martin Liška  ---
I was able to reproduce that, analyzing it right now.

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

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

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

--- Comment #84 from Martin Liška  ---
Thanks David for help!

[Bug target/103850] missed optimization in AVX code

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

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

--- Comment #5 from Richard Biener  ---
Note the issue can be reproduced without -ffast-math as well where the
functions are nearly identical so I fear you are running into some
micro-architectural hazard.  Maybe


.L3:
vmovapd %ymm2, %ymm0
vmovapd %ymm3, %ymm1
.L2:
vbroadcastsd(%rsi), %ymm2
vbroadcastsd8(%rsi), %ymm4
addq$32, %rdx
addq$16, %rsi
vmovapd %ymm2, %ymm3
vfmadd132pd -32(%rsp), %ymm4, %ymm2
vfmadd132pd %ymm15, %ymm4, %ymm3
vbroadcastsd-24(%rdx), %ymm4
vfmadd132pd %ymm1, %ymm14, %ymm3
vmovapd %ymm1, %ymm14
vfmadd231pd %ymm1, %ymm4, %ymm11
vfmadd231pd %ymm0, %ymm4, %ymm7
vbroadcastsd-8(%rdx), %ymm4
vfmadd132pd %ymm0, %ymm13, %ymm2
vbroadcastsd-32(%rdx), %ymm13
vfmadd231pd %ymm1, %ymm4, %ymm9
vfmadd231pd %ymm0, %ymm4, %ymm5
vfmadd231pd %ymm1, %ymm13, %ymm12
vfmadd231pd %ymm0, %ymm13, %ymm8
vbroadcastsd-16(%rdx), %ymm13
vfmadd231pd %ymm1, %ymm13, %ymm10
vfmadd231pd %ymm0, %ymm13, %ymm6
vmovapd %ymm0, %ymm13
cmpq%rdx, %rax
jne .L3

is easier to handle since there's only one data dependence on the
addq $32, %rdx of the followup loads but for (slow)

.L8:
vmovapd %ymm2, %ymm0
vmovapd %ymm3, %ymm1
.L7:
vbroadcastsd8(%rdx), %ymm2
vbroadcastsd(%rdx), %ymm3
addq$16, %rsi
addq$32, %rdx
vbroadcastsd-8(%rsi), %ymm4
vfmadd231pd %ymm1, %ymm2, %ymm11
vfmadd231pd %ymm0, %ymm2, %ymm7
vbroadcastsd-8(%rdx), %ymm2
vfmadd231pd %ymm1, %ymm3, %ymm12
vfmadd231pd %ymm0, %ymm3, %ymm8
vbroadcastsd-16(%rdx), %ymm3
vfmadd231pd %ymm1, %ymm2, %ymm9
vfmadd231pd %ymm0, %ymm2, %ymm5
vbroadcastsd-16(%rsi), %ymm2
vfmadd231pd %ymm1, %ymm3, %ymm10
vfmadd231pd %ymm0, %ymm3, %ymm6
vmovapd %ymm2, %ymm3
vfmadd132pd -32(%rsp), %ymm4, %ymm2
vfmadd132pd %ymm15, %ymm4, %ymm3
vfmadd132pd %ymm1, %ymm14, %ymm3
vmovapd %ymm1, %ymm14
vfmadd132pd %ymm0, %ymm13, %ymm2
vmovapd %ymm0, %ymm13
cmpq%rsi, %rax
jne .L8

both increments impose dependences on the following loads.

[Bug rtl-optimization/103860] [9/10/11 Regression] wrong code at -O3 with -fPIC on x86_64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/103861] [i386] vectorize v2qi vectors

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

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

--- Comment #6 from Richard Biener  ---
Not fully fixed I guess?

[Bug debug/103874] [11/12 Regression] ICE in internal_error on riscv64 and -gsplit-dwarf

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
   Priority|P3  |P2

[Bug ipa/103875] Dead writes are not optimized out

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

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

--- Comment #2 from Richard Biener  ---
The clobber is gone at the point we inline pop(), CDDCE1 removes it because
the clobbered address computation is dead.

Eliminating unnecessary statements:
Deleting : *_4 ={v} {CLOBBER};

Deleting : _4 = &this_6(D)->data[_2];

IL before CDDCE:

   :
  _1 = this_6(D)->size;
  _2 = _1 + 18446744073709551615;
  this_6(D)->size = _2;
  _4 = &this_6(D)->data[_2];
  *_4 ={v} {CLOBBER};
  return;

[Bug target/103850] missed optimization in AVX code

[martin--- via Gcc-bugs]

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

--- Comment #6 from Martin Reinecke  ---
I would have expected that this does not make a significant difference,
assuming that speculative execution works and the branch predictor takes the
jump backwards at the loop's end. In that picture both versions of the loop
should look exactly the same.
But my knowledge about all this is admittedly really vague...

[Bug c++/103879] error: accessing value of variant::_Copy_ctor_base through a 'const variant' glvalue in a constant expression

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

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

--- Comment #6 from Patrick Palka  ---
Reduced C++14 rejects-valid testcase:

struct A {
  int n = 42;
};

struct B : A { };

struct C {
  B b;
};

constexpr int f() {
  C c;
  A& a = static_cast(c.b);
  B& b = static_cast(a);
  return b.n;
}

static_assert(f() == 42, "");

[Bug target/103861] [i386] vectorize v2qi vectors

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #6)
> Not fully fixed I guess?

Not yet. I have a bunch of follow-up patches for various operations.

[Bug ada/79724] GNAT tools do not respect --program-suffix and --program-prefix

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Francois-Xavier Coudert  ---
I checked the patch on all 4 possible cases with/without prefix and
with/without suffix. I confirm they all work as expected, with the patch. In
addition, I think the logic of the code is sane (although I have never written
any Ada in my life).

It would really help if we could get this in, it would enable us to ship Ada as
part of GCC in Homebrew.

[Bug preprocessor/45227] libcpp Makefile does not enable instrumentation

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

--- Comment #5 from Andi Kleen  ---
I think it was the method from the info file.

But I can't quite remember. If you cannot reproduce it I guess it's ok to
close. Maybe I made some mistake.

[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Priority|P2  |P3
   Target Milestone|11.0|11.3

--- Comment #2 from Jonathan Wakely  ---
This is not a bug.

Firstly, there's no testcase provided (as https://gcc.gnu.org/bugs says is
needed). Here's the missing testcase:

#include 
std::deque d;
auto n = d.begin() - d.begin();

Secondly, the command to reproduce the error is not provided, as the link also
says is needed. This "error" only happens with
-Werror=zero-as-null-pointer-constant -Wsystem-headers, so don't do that. This
is not even a warning unless you explicitly ask for it (it's not in -Wall or
-Wextra) and if you choose to make it an error, that's your fault.

We can't nullptr because the code needs to compile as C++98. We could use NULL
or __null, or Jakub suggested just _Map_pointer. I find all of those inferior
to 0 but I suppose we can change it.

[Bug libstdc++/103890] Generated baseline symbol file seems to have redundant lines

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
No, I don't think so.

[Bug tree-optimization/103800] [12 Regression] ICE in vectorizable_phi, at tree-vect-loop.c:7861 with -O3 since r12-5626-g0194d92c35ca8b3a

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

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

--- Comment #4 from Richard Biener  ---
So in this case we have an SLP tree for a merge PHI with scalar bools where
we do

t.c:10:12: note:   using boolean precision 32 for iftmp.1_168 = pretmp_175 !=
0;
t.c:10:12: note:   using boolean precision 16 for _177 = _176 != 0;
t.c:10:12: note:   using boolean precision 16 for iftmp.1_173 = PHI


but pattern detection doesn't have any code to insert compensation on PHI
edges.

We now detect the mismatch but I fell foul of thinking it can only happen for
non-bool vs. bool context ...

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #5 from hubicka at kam dot mff.cuni.cz ---
> I think the recent modref change made the function const.
> 
> And no, we shouldn't DSE any volatile store and generally we don't.  It's
> probably some side-effect of modref that we do.  Using -fno-ipa-pure-const
> "fixes" this bug with -Og:
> 
>  local analysis of void MyClass::call()/1
>NULL memory access; terminating BB
> Function is locally const.
> callgraph:
> 
> so it's caused by the recent change to mitigate path-isolation damage to
> modref.

The change indeed assumes that with -fdelete-null-pointer-checks the
access to NULL is invalid no matter if it is volatile or normal.  I
would expect code having exception handlers at address 0 to be always
built with -fno-delete-null-pointer-checks.

If we want to preserve user defined volaitle NULL, is there way to stick
another flag on the memory accesses synthetised by isolate-paths to mark
them as OK to be optimized this way?

[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I said - int(__x._M_node != _Map_pointer())
but indeed one doesn't know from looking at the code that it is comparison
against NULL.
Other options perhaps could be - (__x._M_node ? 1 : 0) or - 1 + !__x._M_node
or - !!__x._M_node
I'd hope the compiler treats all those the same, if not, we have something to
fix.

[Bug middle-end/103903] New: Loops handling r,g,b values are not vectorized to use power of 2 vectors even if they can

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

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

Bug ID: 103903
   Summary: Loops handling r,g,b values are not vectorized to use
power of 2 vectors even if they can
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is another textcase comming from Firefox's LightPixel. I am not sure if
this is duplicate, but I think it is quite common in programs dealing with RGB
values.

To match the vectorized code we would need to move from SLP vectorizing the 3
parallel computations to vectorising the loop.

struct a {float r,g,b;};
struct a src[10], dest[10];

void
test ()
{
  int i;
  for (i=0;i<10;i++)
  {
  dest[i].r/=src[i].g;
  dest[i].g/=src[i].g;
  dest[i].b/=src[i].b;
  }
}

is vectorized to do 3 operaitons at a time, while equivalent:

float src[30], dest[30];

void
test ()
{
  int i;
  for (i=0;i<30;i++)
  {
  dest[i]/=src[i];
  }
}

runs faster.

[Bug target/103686] ICE in rs6000_expand_new_builtin at rs6000-call.c:15946

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #9 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #8)
> It is an internal (debugging) option.  It isn't documented in the manual, but
> indeed it is not marked as Undocumented in rs6000.opt .

Will added this and the last time we talked, he said he added it mainly for
debugging purposes when he was adding some rs6000 specific gimple builtin
expansion code.  To his knowledge, we don't need/want this anymore, so I
believe the correct fix here is to just remove the option now (assuming it
really is undocumented).

[Bug c++/103904] New: [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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

Bug ID: 103904
   Summary: [defect fix] Please backport P2325R3 to 10 and 11
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Views are no longer required to be default-initializable [P2325R3]. This has
apparently been fixed on current trunk, but GCC11.2 and GCC10.3 still fail at
this example:

#include 

struct T : std::ranges::view_base
{
T() = delete;

char * begin() { return nullptr; }

char * end() { return nullptr; }

};

static_assert(std::ranges::range);
static_assert(std::ranges::view);


Since this change is quite significant and considered a defect-fix, could you
backport it to GCC10 and GCC11?

Thank you very much!

[Bug ada/79724] GNAT tools do not respect --program-suffix and --program-prefix

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

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

--- Comment #7 from Arnaud Charlet  ---
Understood, I'll work on it then, thanks for your help!

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

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

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

--- Comment #1 from Tamar Christina  ---
Looks like the change causes the simpler conditional to be detected by the
vectorizer as a masked operation, which in principle makes sense:

note:   vect_recog_mask_conversion_pattern: detected: iftmp.0_21 = x.1_14 > 255
? iftmp.0_19 : iftmp.0_20;
note:   mask_conversion pattern recognized: patt_43 = patt_42 ? iftmp.0_19 :
iftmp.0_20;
note:   extra pattern stmt: patt_40 = x.1_14 > 255;
note:   extra pattern stmt: patt_42 = () patt_40;

However not quite sure how the masking works on x86.  The additional statement
generated for patt_42 causes it to fail during vectorization:

note:   ==> examining pattern def statement: patt_42 = ()
patt_40;
note:   ==> examining statement: patt_42 = () patt_40;
note:   vect_is_simple_use: operand x.1_14 > 255, type of def: internal
note:   vect_is_simple_use: vectype vector(8) 
missed:   conversion not supported by target.
note:   vect_is_simple_use: operand x.1_14 > 255, type of def: internal
note:   vect_is_simple_use: vectype vector(8) 
note:   vect_is_simple_use: operand x.1_14 > 255, type of def: internal
note:   vect_is_simple_use: vectype vector(8) 
missed:   not vectorized: relevant stmt not supported: patt_42 =
() patt_40;
missed:  bad operation or unsupported loop bound.
note:  * Analysis  failed with vector mode V32QI

as there's no conversion patterns for `VEC_UNPACK_LO_EXPR` between bool and a
mask.

which explains why it works for AVX2 and AVX512BW. AVX512F doesn't seem to
allow any QI mode conversions [1] so it fails..

Not sure why it's doing the replacement without checking to see that the target
is able to vectorize the statements it generates later. Specifically it doesn't
check if what's returned by build_mask_conversion is supported or not.

My guess is because vectorizable_condition will fail anyway without the type of
the conditional being a vector boolean.

With -mavx512vl V32QI seems to generate in the pattern mask conversions between
vector (8)  and without it vector(32) . I
think some x86 person needs to give a hint here :)

[1] https://www.felixcloutier.com/x86/kunpckbw:kunpckwd:kunpckdq

[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #3)
> Other options perhaps could be - (__x._M_node ? 1 : 0)

That produces worse code (with a jump) at -O1

> or - 1 + !__x._M_node

Isn't that undefined for (x - y - 1 + !x) if x and y are both null?
We get (T*)0 - 1 + 1 which overflows twice.

> or - !!__x._M_node

I think that's what I'll go with, thanks.

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #1 from Jonathan Wakely  ---
It's a breaking change though, meaning that code that compiles now would not
compile after the backport. We generally avoid such things on the stable
release branches.

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Hannes Hauswedell from comment #0)
> Since this change is quite significant

That is the problem.

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #3 from Jonathan Wakely  ---
The relevant commit is r12-1606-g4b4f5666b4c2f3aab2a9f3d53d394e390b9b682d

I'm not entirely opposed to backporting it, but we should decide carefully.

[Bug tree-optimization/103800] [12 Regression] ICE in vectorizable_phi, at tree-vect-loop.c:7861 with -O3 since r12-5626-g0194d92c35ca8b3a

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

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

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

https://gcc.gnu.org/g:88e861655b3e59bc982ba22cd6e2e7348efae866

commit r12-6211-g88e861655b3e59bc982ba22cd6e2e7348efae866
Author: Richard Biener 
Date:   Tue Jan 4 15:49:50 2022 +0100

tree-optimization/103800 - sanity check more PHI vectorization

Bool pattern detection doesn't really handle PHIs well so we have
to be prepared for mismatched vector types in more cases than
originally thought.

2022-01-04  Richard Biener  

PR tree-optimization/103800
* tree-vect-loop.c (vectorizable_phi): Remove assert and
expand comment.

* gcc.dg/vect/bb-slp-pr103800.c: New testcase.

[Bug tree-optimization/103800] [12 Regression] ICE in vectorizable_phi, at tree-vect-loop.c:7861 with -O3 since r12-5626-g0194d92c35ca8b3a

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

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

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

Bug 103800 Summary: [12 Regression] ICE in vectorizable_phi, at 
tree-vect-loop.c:7861 with -O3 since r12-5626-g0194d92c35ca8b3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103800

   What|Removed |Added

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

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

[h2+bugs at fsfe dot org via Gcc-bugs]

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

--- Comment #4 from Hannes Hauswedell  ---
Well... we also try to avoid breaking changes in the standard ^^

The thing is that code that relies on the old definition will break one way or
another (and independent of compiler flags). The longer GCC compilers are being
shipped with the old behaviour, the more code will be broken, or not?
With GCC10 being in common distributions like Debian stable, we are actively
contributing to the old definition being around...

Since views were introduced in GCC10 (and are not an old and established
feature), I think that the situation here is different from for other "breaking
changes" and that we should quickly try to homogenize the GCC behaviour for as
many people as possible. I think that was also the reasoning for "allowing" the
change in the IS.

[Note that I was not strongly in favour of this change, I am just scared of
writing code that might change behaviour unknowingly soon ]

[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> We get (T*)0 - 1 + 1 which overflows twice.

GCC's ubsan doesn't diagnose this, but Clang's does.

[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning

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

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #4)
> > or - 1 + !__x._M_node
> 
> Isn't that undefined for (x - y - 1 + !x) if x and y are both null?
> We get (T*)0 - 1 + 1 which overflows twice.

You're right, it would need to be + (!__x.M_node - 1).

> > or - !!__x._M_node
> 
> I think that's what I'll go with, thanks.