[Bug target/104511] New: [10/11/12 Regression] ICE: in emit_move_insn, at expr.cc:4010 with __builtin_convertvector() at -O

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104511
   Summary: [10/11/12 Regression] ICE: in emit_move_insn, at
expr.cc:4010 with __builtin_convertvector() at -O
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu

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

Compiler output:
$ powerpc64le-unknown-linux-gnu-gcc -O testcase.c -Wno-psabi
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:9:5: internal compiler error: in emit_move_insn, at expr.cc:4010
9 |   D d = __builtin_convertvector (f, D);
  | ^
0x64498b emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:4010
0xa9421a expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3994
0xa9421a expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4028
0xa99da8 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6069
0xa9c0b7 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6795
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7195-2022022825-g72f8d228aff-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/12.0.1/lto-wrapper
Target: powerpc64le-unknown-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
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7195-2022022825-g72f8d228aff-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220211 (experimental) (GCC)

[Bug middle-end/104504] spurious -Wswitch-unreachable warning with -ftrivial-auto-var-init=zero

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
At the C/C++ level certainly not, it could be
int foo(int x, int y) {
  switch (bar (x, y)) {
int y;
default:
  y = x * 2;
  return y;
  }
}
and the inner y shouldn't be in scope of the switch control expression.
Now, for this particular case, it surely could be handled like:
  auto tmp_ = bar (x, y);
  {
int y;
switch (tmp_) {
default:
  y = x * 2;
  return y;
}
  }
but I really don't understand why exactly this case should get extra special
care when
  switch (x) {
  case 4:
++y;
  case 5:
int y;
  default:
y = x * 2;
return y;
  }
can't easily.

[Bug libstdc++/104508] _GLIBCXX_ASSERTIONS gets ignored with clang with -std=c++2b

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Not a valid bug report: https://gcc.gnu.org/bugs

Not a GCC problem anyway.

[Bug c++/104512] New: [c++20] consteval constructor does not need to initialize all data members

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 104512
   Summary: [c++20] consteval constructor does not need to
initialize all data members
   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: ---

In the next program struct B has immediate consteval default constructor, which
does not initialize i field. Then this constructor is used to make a temporary
and its i field remains untouched:
```
struct B {
bool b = true;
int i;
consteval B() {}
};
static_assert( B{}.b );
```
Clang and MSVC are fine with it. But GCC complains:
 error: 'B{true}' is not a constant expression
7 | static_assert( B{}.b );
  |  ^
error: 'B()' is not a constant expression because it refers to an incompletely
initialized variable
Demo: https://gcc.godbolt.org/z/x4n6ezrhT

The requirement that "every non-variant non-static data member must be
initialized" in constexpr/consteval constructor is removed since c++20. Related
discussion: https://stackoverflow.com/a/71085832/7325599

[Bug target/79754] ICE in type_natural_mode with vector for DFP type

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r12-7211-gedadc7e0510b703d9727cf5ff68d55d84bb95def
Author: Uros Bizjak 
Date:   Sat Feb 12 10:53:49 2022 +0100

i386: Skip decimal float vector modes in type_natural_mode [PR79754]

2022-02-12  Uroš Bizjak  

gcc/ChangeLog:

PR target/79754
* config/i386/i386.cc (type_natural_mode):
Skip decimal float vector modes.

gcc/testsuite/ChangeLog:

PR target/79754
* gcc.target/i386/pr79754.c: New test.

[Bug c++/104512] [c++20] consteval constructor does not need to initialize all data members

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

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

--- Comment #1 from Andrew Pinski  ---
constexpr works but consteval does not.

Also I notice ICC rejects the consteval version but accepts the constexpr one.

[Bug target/104502] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670: insn does not satisfy its constraints with -O -flive-range-shrinkage -march=barcelona -fstack-protector-all -mavx5

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

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

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

https://gcc.gnu.org/g:0538d42cdd68f6b65d72ed7768f1d00ba44f8631

commit r12-7212-g0538d42cdd68f6b65d72ed7768f1d00ba44f8631
Author: Jakub Jelinek 
Date:   Sat Feb 12 11:17:41 2022 +0100

i386: Fix up cvtsd2ss splitter [PR104502]

The following testcase ICEs, because AVX512F is enabled, AVX512VL is not,
and the cvtsd2ss insn has %xmm0-15 as output operand and %xmm16-31 as
input operand.  For output operand %xmm16+ the splitter just gives up
in such case, but for such input it just emits vmovddup which requires
AVX512VL if either operand is EXT_REX_SSE_REG_P (when it is 128-bit).

The following patch fixes it by treating that case like the pre-SSE3
output != input case - move the input to output and do everything on
the output reg which is known to be < %xmm16.

2022-02-12  Jakub Jelinek  

PR target/104502
* config/i386/i386.md (cvtsd2ss splitter): If operands[1] is xmm16+
and AVX512VL isn't available, move operands[1] to operands[0]
first.

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

[Bug target/104502] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670: insn does not satisfy its constraints with -O -flive-range-shrinkage -march=barcelona -fstack-protector-all -mavx5

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/104513] New: [12 Regression] goto cdtor_label failures on arm since r12-5256

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

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

Bug ID: 104513
   Summary: [12 Regression] goto cdtor_label failures on arm since
r12-5256
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct A {
  int a1;
  short a2;
  short a3;
  long a4;
  constexpr A() : a1(), a2(), a3(), a4() { return; }
};
is rejected since r12-5256-g37326651b439bac55d96fb5a43f4daf25e401eda
on arm with:
mptPathString.ii: In constructor ‘constexpr A::A()’:
mptPathString.ii:6:44: error: ‘goto’ is not a constant expression
6 |   constexpr A() : a1(), a2(), a3(), a4() { return; }
  |^~
for -std=c++14 and higher.
Also,
struct S { constexpr S (int x) : s (x) {} constexpr ~S () { s = 5; return; s =
6; } int s; };
constexpr S s = 42;
is rejected with -std=c++20 and higher on all arches incorrectly, but this one
for much longer (GCC 10+).
finish_return_stmt does:
  if (DECL_DESTRUCTOR_P (current_function_decl)
  || (DECL_CONSTRUCTOR_P (current_function_decl)
  && targetm.cxx.cdtor_returns_this ()))
{
  /* Similarly, all destructors must run destructors for
 base-classes before returning.  So, all returns in a
 destructor get sent to the DTOR_LABEL; finish_function emits
 code to return a value there.  */
  return finish_goto_stmt (cdtor_label);
}
and so I think we need to mark the goto or label somehow to tell
potential_constant_expression that this is an artificial goto which is ok.

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Target||armv7hl-linux-gnueabi
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |12.0

[Bug libstdc++/104443] common_iterator::operator-> is not correctly implemented

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

--- Comment #2 from Jonathan Wakely  ---
I've submitted an LWG issue to change the standard, as returning a raw pointer
by reference is silly.

[Bug sanitizer/104449] [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #5 from Eric Botcazou  ---
> Confirmed. With -fstack-check=generic, __builtin_alloca_with_align is marked
> as being able to throw but asan decides to insert its annonations right
> after the builtin call instead of on the branch after the function call.

With any -fstack-check option to be exact:

  /* If we're checking the stack, `alloca' can throw.  */
  const int alloca_flags
= ECF_MALLOC | ECF_LEAF | (flag_stack_check ? 0 : ECF_NOTHROW);

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

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

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

--- Comment #1 from Jakub Jelinek  ---
--- gcc/cp/constexpr.cc.jj  2022-02-11 13:52:32.697425776 +0100
+++ gcc/cp/constexpr.cc 2022-02-12 13:51:21.000274390 +0100
@@ -9364,7 +9364,7 @@ potential_constant_expression_1 (tree t,
   {
tree *target = &TREE_OPERAND (t, 0);
/* Gotos representing break and continue are OK.  */
-   if (breaks (target) || continues (target))
+   if (breaks (target) || continues (target) || returns (target))
  {
*jump_target = *target;
return true;
fixes it, but am not sure if it is the right thing for constexpr dtors for
classes with base classes.

[Bug rtl-optimization/104484] -freorder-block-and-partition not splitting into sections with __builin_expect()

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #4 from Avi Kivity  ---
gcc could infer that the check for f2 and the call to very_heavy are cold, and
move that little block to a .cold section, whether or not very_heavy is cold.

[Bug tree-optimization/35513] Improve targetm.binds_local_p

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

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

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

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

commit r12-7213-g5c4258d7c78a92ab17c14dec1163d87fc42ff019
Author: H.J. Lu 
Date:   Thu Feb 10 05:42:49 2022 -0800

x86: Update PR 35513 tests

1. Require linker with GNU_PROPERTY_1_NEEDED support for PR 35513
run-time tests.
2. Compile pr35513-8.c to scan assembly code.

PR testsuite/104481
* g++.target/i386/pr35513-1.C: Require property_1_needed target.
* g++.target/i386/pr35513-2.C: Likewise.
* gcc.target/i386/pr35513-8.c: Change to compile.
* lib/target-supports.exp (check_compile): Support assembly code.
(check_effective_target_property_1_needed): New proc.

[Bug testsuite/104481] gcc.target/i386/pr35513-8.c and g++.target/i386/pr35513-[12].C testsuire failures

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

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

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

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

commit r12-7213-g5c4258d7c78a92ab17c14dec1163d87fc42ff019
Author: H.J. Lu 
Date:   Thu Feb 10 05:42:49 2022 -0800

x86: Update PR 35513 tests

1. Require linker with GNU_PROPERTY_1_NEEDED support for PR 35513
run-time tests.
2. Compile pr35513-8.c to scan assembly code.

PR testsuite/104481
* g++.target/i386/pr35513-1.C: Require property_1_needed target.
* g++.target/i386/pr35513-2.C: Likewise.
* gcc.target/i386/pr35513-8.c: Change to compile.
* lib/target-supports.exp (check_compile): Support assembly code.
(check_effective_target_property_1_needed): New proc.

[Bug testsuite/104481] gcc.target/i386/pr35513-8.c and g++.target/i386/pr35513-[12].C testsuire failures

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #11 from H.J. Lu  ---
Fixed.

[Bug c++/104514] New: add feature to create a pointer to a fixed address as constexpr

[goswin-v-b at web dot de via Gcc-bugs]

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

Bug ID: 104514
   Summary: add feature to create a pointer to a fixed address as
constexpr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goswin-v-b at web dot de
  Target Milestone: ---

In the embedded and micro controller world memory mapped registers are very
common. They can be declared as external object and fudged in using linker
scripts, which prevents a lot of optimizations. Or they can be declared as
pointers, in the most reduced form like this:

int *p = (int*)0x12345678;

My problem now is that this isn't a constexpr and can't be used in any
constexpr code:

foo.cc:1:20: error: ‘reinterpret_cast’ from integer to pointer
1 | constexpr int *p = (int*)0x12345678;
  |^~~~

While this is the right thing in general there should be a way to allow this
special case. A way to tell the compiler that an object exists at a fixed
address and still be a constexpr.

[Bug ada/99360] [12 regression] ICE in generalized iteration

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #9 from simon at pushface dot org ---
In gcc 12.0.1 of 20220128, we get

$ gnatmake -c -u -f iteration.adb
gcc -c iteration.adb
a-stream.ads:82:04: error: construct not allowed in configurable run-time mode
a-stream.ads:82:04: error: file s-putima.ads had semantic errors
a-stream.ads:82:04: error: entity "System.Put_Images.Put_Image_Unknown" not
available
s-putima.ads:63:53: error: "Long_Long_Long_Unsigned" not declared in
"Unsigned_Types"
gnatmake: "iteration.adb" compilation error

which means we no longer get the ICE. Instead, the compiler complains validly
that the old RTS files provided don’t provide the interfaces that the compiler
now needs.

Similarly for GCC 11.2.

So, I think this PR should be closed as fixed.

[Bug ada/99360] [12 regression] ICE in generalized iteration

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

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

Arnaud Charlet  changed:

   What|Removed |Added

   Target Milestone|11.3|12.0
 CC||charlet at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #10 from Arnaud Charlet  ---
Indeed, closing, thanks!

[Bug libstdc++/104508] _GLIBCXX_ASSERTIONS gets ignored with clang with -std=c++2b

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #1)
> Not a valid bug report: https://gcc.gnu.org/bugs
> 
> Not a GCC problem anyway.

Do you mean it is a clang problem?

[Bug middle-end/104504] spurious -Wswitch-unreachable warning with -ftrivial-auto-var-init=zero

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #4 from Kees Cook  ---
(Ah, I knew this had been reported before. I found it now...)
Duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2022-02-12

--- Comment #2 from Jakub Jelinek  ---
Created attachment 52426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52426&action=edit
gcc12-pr104513.patch

That seems to work fine, the base dtors are invoked from try ... finally as the
testcase in the patch shows.

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #4 from Kees Cook  ---
The kernel keeps gaining more of these cases, so it'll be important to get this
fixed:
https://lore.kernel.org/lkml/200fe5cb203ad5cc00c5c60b7ded2cd85c9b85ea.ca...@perches.com/

[Bug sanitizer/104449] [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic

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

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

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

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

commit r12-7214-gf0c7367b8802c47efaad87b1f2126fe6350d8b47
Author: Jakub Jelinek 
Date:   Sat Feb 12 19:17:44 2022 +0100

asan: Fix up address sanitizer instrumentation of __builtin_alloca* if it
can throw [PR104449]

With -fstack-check* __builtin_alloca* can throw and the asan
instrumentation of this builtin wasn't prepared for that case.
The following patch fixes that by replacing the builtin with the
replacement builtin and emitting any further insns on the fallthru
edge.

I haven't touched the hwasan code which most likely suffers from the
same problem.

2022-02-12  Jakub Jelinek  

PR sanitizer/104449
* asan.cc: Include tree-eh.h.
(handle_builtin_alloca): Handle the case when __builtin_alloca or
__builtin_alloca_with_align can throw.

* gcc.dg/asan/pr104449.c: New test.
* g++.dg/asan/pr104449.C: New test.

[Bug sanitizer/104449] [9/10/11 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression] ICE:
   |ICE: verify_gimple failed:  |verify_gimple failed: dead
   |dead statement in EH table  |statement in EH table with
   |with -fexceptions   |-fexceptions
   |-fsanitize=address  |-fsanitize=address
   |-fstack-check=generic   |-fstack-check=generic

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/104515] New: trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.

[gcc at rabensky dot com via Gcc-bugs]

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

Bug ID: 104515
   Summary: trivially-destructible destructors interfere with loop
optimization - maybe related to lifetime-dse.
   Product: gcc
   Version: og11 (devel/omp/gcc-11)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at rabensky dot com
  Target Milestone: ---

This issue started in GCC-9.1, but a change in GCC-11 made it worse.

It didn't exist in GCC-7.1-GCC-8.5

Short description:
-

When we have a loop that can be optimized out, calling the destructor for a
trivially-destructible type will prevent the optimization starting from GCC-9.1

These are loops that correctly optimized out in GCC-7.1 to GCC-8.5

This bug doesn't happen if we set -fno-lifetime-dse

Interestingly enough - a non-trivially-destructible destructor doesn't
necessarily prevent the optimization.

How this became worse in GCC-11:
---

In GCC-11 this also applies to calling the destructor of basic types (int, long
etc.)

So loops that optimized in GCC-7.1 to GCC-10.3 no longer optimize.

Short reproducing example:
-

NOTE: No `include`s are needed

```
using T = int;
struct Vec {
  T* end;
};
void pop_back_many(Vec& v, unsigned n) {
  for (unsigned i = 0; i < n; ++i) {
--v.end;
v.end->~T();
  }
}
```
compiled with `-O3 -Wall`

In GCC-7 to GCC-10, `pop_back_many` optimizes out the loop (becomes
`v.end-=n`).
In GCC-11, the loop remains.

See https://godbolt.org/z/vTexxhxP9

NOTE that adding `-fno-lifetime-dse` will re-enable the loop optimization.

Why this matters

This prevents optimization of a loop over `std::vector::pop_back()`, which
is a very common usecase!

Loops that optimize out in GCC-7.1 to GCC-10.3 will suddenly not optimize in
GCC-11.1/2, making existing code run MUCH slower! (O(n) instead of O(1))

NOTE: std::vector::resize is a lot slower than loop over pop_back. A loop
over pop_back is currently the most efficient way to do pop_back_many!

More complete reproducing example:
-

- We can replace the type `T` with a class that is trivially destructible.
**In that case, the problem exists in previous versions of GCC as well**

- We can replace the type `T` with a class that had user-supplied destructor.
**In that case, the loop correctly optimizes out if possible**

Actual examples:
https://godbolt.org/z/7WqTPq3cE

compiled with `-O3 -Wall`
```
template 
struct Vec {
  T* end;
};

template 
void pop_back_many(Vec& v, unsigned n) {
  for (unsigned i = 0; i < n; ++i) {
--v.end;
v.end->~T();
  }
}

struct TrivialDestruct {
~TrivialDestruct()=default;
};

struct NoopDestruct {
~NoopDestruct(){}
};

unsigned count=0;
struct CountDestruct {
~CountDestruct(){++count;}
};

// Here loop optimization fails in GCC-11.1-11.2
// But succeeds in GCC 7.1-10.3
//
// NOTE that adding -fno-lifetime-dse re-enabled the optimization
template void pop_back_many(Vec&, unsigned);
// Here loop optimization fails in GCC-9.1-11.2
// But succeeds in GCC 7.1-8.5
//
// NOTE that adding -fno-lifetime-dse re-enabled the optimization
template void pop_back_many(Vec&, unsigned);
// Here loop optimization succeeds in all versions
//
// NOTE that it's surprising that a no-op destructor can be optimized
// but a trivial destructor can't
template void pop_back_many(Vec&, unsigned);
// Here loop optimization succeeds in all version
//
// NOTE that it's surprising that a destructor with an action
// can be optimized, but a trivial destructor can't
template void pop_back_many(Vec&, unsigned);
```

[Bug middle-end/104504] spurious -Wswitch-unreachable warning with -ftrivial-auto-var-init=zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Andrew Pinski  ---
Dup of bug 102276.

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

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #5 from Andrew Pinski  ---
*** Bug 104504 has been marked as a duplicate of this bug. ***

[Bug c/104516] New: internal compiler error: in leaf_function_p, at final.c:4491

[rykong at tpg dot com.au via Gcc-bugs]

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

Bug ID: 104516
   Summary: internal compiler error: in leaf_function_p, at
final.c:4491
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rykong at tpg dot com.au
  Target Milestone: ---

Created attachment 52427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52427&action=edit
compiler output on screen

cross gcc compiler for m32c generated from gcc-11.2.0 produced the following
error when compiling an empty function:
during RTL pass: pro_and_epilogue
t.c: In function ‘testfun’:
t.c:3:1: internal compiler error: in leaf_function_p, at final.c:4491
3 | }
  | ^

t.i:
# 0 "t.c"
# 0 ""
# 0 ""
# 1 "t.c"
void testfun(void)
{
}

running on ubuntu 20.04
uname -a
Linux Phosphorus 5.13.0-28-generic #31~20.04.1-Ubuntu SMP Wed Jan 19 14:08:10
UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

[Bug target/104516] internal compiler error: in leaf_function_p, at final.c:4491

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 81804.

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

[Bug target/81804] m32c ICE during configure at leaf_function_p, at final.c:4317

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rykong at tpg dot com.au

--- Comment #2 from Andrew Pinski  ---
*** Bug 104516 has been marked as a duplicate of this bug. ***

[Bug target/81804] m32c ICE during configure at leaf_function_p, at final.c:4317

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Even though PR 83670 is newer, it has some anlysis (by me) in it. Just marking
this as a dup of bug 83670.

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

[Bug target/83670] [9/10/11/12 Regression] m32c ICE in leaf_function_p, at final.c:4368

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
*** Bug 81804 has been marked as a duplicate of this bug. ***

[Bug c++/104514] add feature to create a pointer to a fixed address as constexpr

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/102637] "Error: ‘reinterpret_cast’ is not a constant expression" when no reinterpret_cast is involved

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.6.4, 4.7.1, 4.8.1, 4.9.0,
   ||5.1.0, 6.1.0

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/103008] poor inlined builtin_fmod on x86_64

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Uroš Bizjak  ---
Created attachment 52428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52428&action=edit
Proposed patch

The attached patch implements:

fmod (a, p) = a - trunc (a/p) * p
drem (a, p) = a - roundeven (a/p) * p

using SSE4 round instruction (and uses fnma when available).

Timings with Polyhedron ac.f90 on IvyBridge-E, Fedora-34, glibc 2.33-21.fc34

-Ofast:
   6,150082000 seconds user

-Ofast -mno-80387:
  18,354654000 seconds user

-Ofast -msse4:
   5,722511000 seconds user

[Bug c/104505] ICE: SIGSEGV in c_pretty_printer::postfix_expression() on invalid code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-02-13
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c/104491] gcc: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #2 from Andrew Pinski  ---
Also please read https://gcc.gnu.org/bugs/ and add the requested information
from that page.

[Bug c/104510] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-13
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |c
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
It works with the C++ front-end:
float f;
typedef float t32 __attribute__((mode(SD)));
typedef float t64 __attribute__((mode(DD)));
t64 d;
int
foo (void)
{
  return d > (t32) (t64) f;
}

[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||5.1.0
Summary|ICE: 'verify_gimple'|[9/10/11/12 Regression]
   |failed: mismatching |ICE: 'verify_gimple'
   |comparison operand types in |failed: mismatching
   |verify_gimple_in_seq()  |comparison operand types in
   ||verify_gimple_in_seq()
  Known to work||4.9.0, 4.9.4
   Target Milestone|--- |9.5

--- Comment #2 from Andrew Pinski  ---
This is a regression from GCC 4.9.0 which produced the correct trees even:


In GCC 5+:
  return (_Decimal32) f < d;


While in GCC 4.9.x:
  return (_Decimal64) f < (_Decimal64) d;

[Bug debug/104517] New: '-fcompare-debug' failure w/ -O1 -fopenmp -fno-tree-ter

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 104517
   Summary: '-fcompare-debug' failure w/ -O1 -fopenmp
-fno-tree-ter
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure, openmp
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 52429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52429&action=edit
Testcase

gcc 12.0.1 20220206 snapshot (g:8eb329e963593342855b6072e5692659107337b7) fails
-fcompare-debug check when compiling the attached testcase, reduced from
gcc/testsuite/c-c++-common/gomp/clauses-1.c, w/ -O1 -fopenmp -fno-tree-ter:

% gcc-12.0.1 -O1 -fcompare-debug -fopenmp -fno-tree-ter -c isdtsldh.c
-save-temps
gcc-12.0.1: error: isdtsldh.c: '-fcompare-debug' failure

[Bug debug/104517] '-fcompare-debug' failure w/ -O1 -fopenmp -fno-tree-ter

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #1 from Arseny Solokha  ---
Created attachment 52430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52430&action=edit
gkd diff