[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=edit
gkd diff

[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=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 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 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/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/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.

gcc-11-20220212 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220212 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision b9e6e99907e16f5ad942e2bda8fe7b89d6191571

You'll find:

 gcc-11-20220212.tar.xz   Complete GCC

  SHA256=2800b549c9a6e7f5eb29f64611b9b7be1341bbca5d7dce6783616662151aaee2
  SHA1=7c12dfccd75678cf7df65cccae94406b5a326b52

Diffs from 11-20220205 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [wwwdocs PATCH] gcc-12: Mention -mno-direct-extern-access

[Gerald Pfeifer]

On Sat, 12 Feb 2022, H.J. Lu via Gcc-patches wrote:
> +  Always use GOT to access external data and function symbols via
> +  -mno-direct-extern-access.

Maybe say "global offset table (GOT)"?

And at first I was confused reading this, so I suggest something like

  "...when the new -mno-direct-extern-access command-line
  option is specified"

or 

  "New command-line option ... that ..." ?

Gerald

[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=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++/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 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 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 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/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/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 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=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

Re: "cannot convert to a pointer type" error repeated tens of times

[Marc Glisse]

On Sat, 12 Feb 2022, Andrea Monaco via Gcc wrote:


 #include 

 int
 main (void)
 {
   float a;

   curl_easy_setopt (NULL, 0, (void *) a);
 }


with "gcc -c bug.c" gives


 bug.c: In function ‘main’:
 bug.c:15:3: error: cannot convert to a pointer type
curl_easy_setopt (NULL, 0, (void *) a);
^~~~
 bug.c:15:3: error: cannot convert to a pointer type
 bug.c:15:3: error: cannot convert to a pointer type
 bug.c:15:3: error: cannot convert to a pointer type
 [...]
 bug.c:15:3: error: cannot convert to a pointer type
 In file included from /usr/include/x86_64-linux-gnu/curl/curl.h:2826,
  from bug.c:1:
 bug.c:15:3: error: cannot convert to a pointer type
curl_easy_setopt (NULL, 0, (void *) a);
^~~~
 bug.c:15:3: error: cannot convert to a pointer type
curl_easy_setopt (NULL, 0, (void *) a);
^~~~
 bug.c:15:3: error: cannot convert to a pointer type
curl_easy_setopt (NULL, 0, (void *) a);
^~~~


The error message is correct, but is repeated tens of times.
The function is declared this way in curl.h

 CURL_EXTERN CURLcode curl_easy_setopt(CURL *curl, CURLoption option,
 ...);


No, curl_easy_setopt is a macro. If you look at the preprocessed code, you 
get many statements doing the same wrong operation, and one warning for 
each of them.


(wrong list, should be gcc-help, or an issue on bugzilla)

--
Marc Glisse

"cannot convert to a pointer type" error repeated tens of times

[Andrea Monaco via Gcc]

Hello,


I may have hit a bug while using libcurl, a common library for network
operations, on gcc 8.3.0.


Building this program


  #include 

  int
  main (void)
  {
float a;

curl_easy_setopt (NULL, 0, (void *) a);
  }


with "gcc -c bug.c" gives


  bug.c: In function ‘main’:
  bug.c:15:3: error: cannot convert to a pointer type
 curl_easy_setopt (NULL, 0, (void *) a);
 ^~~~
  bug.c:15:3: error: cannot convert to a pointer type
  bug.c:15:3: error: cannot convert to a pointer type
  bug.c:15:3: error: cannot convert to a pointer type
  [...]
  bug.c:15:3: error: cannot convert to a pointer type
  In file included from /usr/include/x86_64-linux-gnu/curl/curl.h:2826,
   from bug.c:1:
  bug.c:15:3: error: cannot convert to a pointer type
 curl_easy_setopt (NULL, 0, (void *) a);
 ^~~~
  bug.c:15:3: error: cannot convert to a pointer type
 curl_easy_setopt (NULL, 0, (void *) a);
 ^~~~
  bug.c:15:3: error: cannot convert to a pointer type
 curl_easy_setopt (NULL, 0, (void *) a);
 ^~~~


The error message is correct, but is repeated tens of times.
The function is declared this way in curl.h

  CURL_EXTERN CURLcode curl_easy_setopt(CURL *curl, CURLoption option,
  ...);

but I couldn't replicate the bug by copying that line only.



Thanks,

Andrea Monaco

[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 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 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 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 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 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 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=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/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 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 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 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 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.

[wwwdocs PATCH] gcc-12: Mention -mno-direct-extern-access

[H.J. Lu via Gcc-patches]

---
 htdocs/gcc-12/changes.html | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index b6341fda..897de8ef 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -399,6 +399,9 @@ a work-in-progress.
   Add CS prefix to call and jmp to indirect thunk with branch target
   in r8-r15 registers via -mindirect-branch-cs-prefix.
   
+  Always use GOT to access external data and function symbols via
+  -mno-direct-extern-access.
+  
 
 
 
-- 
2.34.1

[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 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 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 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.

Re: [PATCH] x86: Update PR 35513 tests

[H.J. Lu via Gcc-patches]

On Fri, Feb 11, 2022 at 9:43 PM Hongtao Liu  wrote:
>
> On Thu, Feb 10, 2022 at 9:58 PM H.J. Lu via Gcc-patches
>  wrote:
> >
> > 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.
> This is for testcase fixup, and i think it should be ok.

I am checking it in.

Thanks.

> > ---
> >  gcc/testsuite/g++.target/i386/pr35513-1.C |  2 +-
> >  gcc/testsuite/g++.target/i386/pr35513-2.C |  2 +-
> >  gcc/testsuite/gcc.target/i386/pr35513-8.c |  2 +-
> >  gcc/testsuite/lib/target-supports.exp | 37 +++
> >  4 files changed, 40 insertions(+), 3 deletions(-)
> >
> > diff --git a/gcc/testsuite/g++.target/i386/pr35513-1.C 
> > b/gcc/testsuite/g++.target/i386/pr35513-1.C
> > index 6f8db37fb7c..daa615662c5 100644
> > --- a/gcc/testsuite/g++.target/i386/pr35513-1.C
> > +++ b/gcc/testsuite/g++.target/i386/pr35513-1.C
> > @@ -1,4 +1,4 @@
> > -// { dg-do run }
> > +// { dg-do run { target property_1_needed } }
> >  // { dg-options "-O2 -mno-direct-extern-access" }
> >
> >  #include 
> > diff --git a/gcc/testsuite/g++.target/i386/pr35513-2.C 
> > b/gcc/testsuite/g++.target/i386/pr35513-2.C
> > index 9143ff3f0a5..ecccdaeb666 100644
> > --- a/gcc/testsuite/g++.target/i386/pr35513-2.C
> > +++ b/gcc/testsuite/g++.target/i386/pr35513-2.C
> > @@ -1,4 +1,4 @@
> > -// { dg-do run  }
> > +// { dg-do run { target property_1_needed } }
> >  // { dg-options "-O2 -mno-direct-extern-access" }
> >
> >  class Foo
> > diff --git a/gcc/testsuite/gcc.target/i386/pr35513-8.c 
> > b/gcc/testsuite/gcc.target/i386/pr35513-8.c
> > index 7ba67de2156..d51f7efb353 100644
> > --- a/gcc/testsuite/gcc.target/i386/pr35513-8.c
> > +++ b/gcc/testsuite/gcc.target/i386/pr35513-8.c
> > @@ -1,4 +1,4 @@
> > -/* { dg-do assemble { target { *-*-linux* && { ! ia32 } } } } */
> > +/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
> >  /* { dg-require-effective-target maybe_x32 } */
> >  /* { dg-options "-mx32 -O2 -fno-pic -fexceptions 
> > -fasynchronous-unwind-tables -mno-direct-extern-access" } */
> >
> > diff --git a/gcc/testsuite/lib/target-supports.exp 
> > b/gcc/testsuite/lib/target-supports.exp
> > index 4463cc8d7ed..0d8a7df5026 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -30,6 +30,7 @@
> >  #
> >  # Assume by default that CONTENTS is C code.
> >  # Otherwise, code should contain:
> > +# "/* Assembly" for assembly code,
> >  # "// C++" for c++,
> >  # "// D" for D,
> >  # "! Fortran" for Fortran code,
> > @@ -57,6 +58,7 @@ proc check_compile {basename type contents args} {
> > set options ""
> >  }
> >  switch -glob -- $contents {
> > +   "*/* Assembly*" { set src ${basename}[pid].S }
> > "*! Fortran*" { set src ${basename}[pid].f90 }
> > "*// C++*" { set src ${basename}[pid].cc }
> > "*// D*" { set src ${basename}[pid].d }
> > @@ -11758,3 +11760,38 @@ proc check_effective_target_pytest3 { } {
> >  return 0;
> >  }
> >  }
> > +
> > +proc check_effective_target_property_1_needed { } {
> > +  return [check_no_compiler_messages_nocache property_1_needed executable {
> > +/* Assembly code */
> > +#ifdef __LP64__
> > +# define __PROPERTY_ALIGN 3
> > +#else
> > +# define __PROPERTY_ALIGN 2
> > +#endif
> > +
> > +   .section ".note.gnu.property", "a"
> > +   .p2align __PROPERTY_ALIGN
> > +   .long 1f - 0f   /* name length.  */
> > +   .long 4f - 1f   /* data length.  */
> > +   /* NT_GNU_PROPERTY_TYPE_0.   */
> > +   .long 5 /* note type.  */
> > +0:
> > +   .asciz "GNU"/* vendor name.  */
> > +1:
> > +   .p2align __PROPERTY_ALIGN
> > +   /* GNU_PROPERTY_1_NEEDED.  */
> > +   .long 0xb0008000/* pr_type.  */
> > +   .long 3f - 2f   /* pr_datasz.  */
> > +2:
> > +   /* GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.  */
> > +   .long 1
> > +3:
> > +   .p2align __PROPERTY_ALIGN
> > +4:
> > +   .text
> > +   .globl main
> > +main:
> > +   .byte 0
> > +  } ""]
> > +}
> > --
> > 2.34.1
> >
>
>
> --
> BR,
> Hongtao



-- 
H.J.

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

[Richard Biener via Gcc-patches]

> Am 12.02.2022 um 10:08 schrieb Jakub Jelinek via Gcc-patches 
> :
> 
> Hi!
> 
> With -fstack-check=generic __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.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Richard 
> 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.
> 
> --- gcc/asan.cc.jj2022-01-18 11:58:58.876992143 +0100
> +++ gcc/asan.cc2022-02-11 19:09:39.752065877 +0100
> @@ -63,6 +63,7 @@ along with GCC; see the file COPYING3.
> #include "fnmatch.h"
> #include "tree-inline.h"
> #include "tree-ssa.h"
> +#include "tree-eh.h"
> 
> /* AddressSanitizer finds out-of-bounds and use-after-free bugs
>with <2x slowdown on average.
> @@ -726,14 +727,24 @@ handle_builtin_alloca (gcall *call, gimp
>   gassign *g;
>   gcall *gg;
>   tree callee = gimple_call_fndecl (call);
> +  tree lhs = gimple_call_lhs (call);
>   tree old_size = gimple_call_arg (call, 0);
> -  tree ptr_type = gimple_call_lhs (call) ? TREE_TYPE (gimple_call_lhs (call))
> - : ptr_type_node;
> +  tree ptr_type = lhs ? TREE_TYPE (lhs) : ptr_type_node;
>   tree partial_size = NULL_TREE;
>   unsigned int align
> = DECL_FUNCTION_CODE (callee) == BUILT_IN_ALLOCA
>   ? 0 : tree_to_uhwi (gimple_call_arg (call, 1));
> 
> +  bool throws = false;
> +  edge e = NULL;
> +  if (stmt_can_throw_internal (cfun, call))
> +{
> +  if (!lhs)
> +return;
> +  throws = true;
> +  e = find_fallthru_edge (gsi_bb (*iter)->succs);
> +}
> +
>   if (hwasan_sanitize_allocas_p ())
> {
>   gimple_seq stmts = NULL;
> @@ -852,29 +863,54 @@ handle_builtin_alloca (gcall *call, gimp
>  build_int_cst (size_type_node, align));
>   tree new_alloca_with_rz = make_ssa_name (ptr_type, gg);
>   gimple_call_set_lhs (gg, new_alloca_with_rz);
> -  gsi_insert_before (iter, gg, GSI_SAME_STMT);
> +  if (throws)
> +{
> +  gimple_call_set_lhs (call, NULL);
> +  gsi_replace (iter, gg, true);
> +}
> +  else
> +gsi_insert_before (iter, gg, GSI_SAME_STMT);
> 
>   /* new_alloca = new_alloca_with_rz + align.  */
>   g = gimple_build_assign (make_ssa_name (ptr_type), POINTER_PLUS_EXPR,
>   new_alloca_with_rz,
>   build_int_cst (size_type_node,
>  align / BITS_PER_UNIT));
> -  gsi_insert_before (iter, g, GSI_SAME_STMT);
> +  gimple_stmt_iterator gsi = gsi_none ();
> +  if (throws)
> +{
> +  gsi_insert_on_edge_immediate (e, g);
> +  gsi = gsi_for_stmt (g);
> +}
> +  else
> +gsi_insert_before (iter, g, GSI_SAME_STMT);
>   tree new_alloca = gimple_assign_lhs (g);
> 
>   /* Poison newly created alloca redzones:
>   __asan_alloca_poison (new_alloca, old_size).  */
>   fn = builtin_decl_implicit (BUILT_IN_ASAN_ALLOCA_POISON);
>   gg = gimple_build_call (fn, 2, new_alloca, old_size);
> -  gsi_insert_before (iter, gg, GSI_SAME_STMT);
> +  if (throws)
> +gsi_insert_after (, gg, GSI_NEW_STMT);
> +  else
> +gsi_insert_before (iter, gg, GSI_SAME_STMT);
> 
>   /* Save new_alloca_with_rz value into last_alloca to use it during
>  allocas unpoisoning.  */
>   g = gimple_build_assign (last_alloca, new_alloca_with_rz);
> -  gsi_insert_before (iter, g, GSI_SAME_STMT);
> +  if (throws)
> +gsi_insert_after (, g, GSI_NEW_STMT);
> +  else
> +gsi_insert_before (iter, g, GSI_SAME_STMT);
> 
>   /* Finally, replace old alloca ptr with NEW_ALLOCA.  */
> -  replace_call_with_value (iter, new_alloca);
> +  if (throws)
> +{
> +  g = gimple_build_assign (lhs, new_alloca);
> +  gsi_insert_after (, g, GSI_NEW_STMT);
> +}
> +  else
> +replace_call_with_value (iter, new_alloca);
> }
> 
> /* Return the memory references contained in a gimple statement
> --- gcc/testsuite/gcc.dg/asan/pr104449.c.jj2022-02-11 19:23:05.085974426 
> +0100
> +++ gcc/testsuite/gcc.dg/asan/pr104449.c2022-02-11 19:26:20.537282682 
> +0100
> @@ -0,0 +1,12 @@
> +/* PR sanitizer/104449 */
> +/* { dg-do compile } */
> +/* { dg-options "-fexceptions -fsanitize=address -fstack-check=generic" } */
> +
> +void bar (int *);
> +
> +void
> +foo (void)
> +{
> +  int a[16];
> +  bar (a);
> +}
> --- gcc/testsuite/g++.dg/asan/pr104449.C.jj2022-02-11 19:25:22.035088372 
> +0100
> +++ gcc/testsuite/g++.dg/asan/pr104449.C2022-02-11 19:26:08.605447008 
> +0100
> @@ -0,0 +1,16 @@
> +// PR sanitizer/104449
> +// { dg-do compile }
> +// { dg-options "-fexceptions -fsanitize=address -fstack-check=generic" }

[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 = _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 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 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 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 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 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 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 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.

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

[Uros Bizjak via Gcc-patches]

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.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 6b97a2b0e50..cf246e74e57 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -1876,10 +1876,14 @@ type_natural_mode (const_tree type, const 
CUMULATIVE_ARGS *cum,
{
  machine_mode innermode = TYPE_MODE (TREE_TYPE (type));
 
- /* There are no XFmode vector modes.  */
+ /* There are no XFmode vector modes ...  */
  if (innermode == XFmode)
return mode;
 
+ /* ... and no decimal float vector modes.  */
+ if (DECIMAL_FLOAT_MODE_P (innermode))
+   return mode;
+
  if (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE)
mode = MIN_MODE_VECTOR_FLOAT;
  else
diff --git a/gcc/testsuite/gcc.target/i386/pr79754.c 
b/gcc/testsuite/gcc.target/i386/pr79754.c
new file mode 100644
index 000..27845c9d5b9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr79754.c
@@ -0,0 +1,7 @@
+/* PR target/79754 */
+/* { dg-do compile } */
+/* { dg-options "-Wno-psabi" } */
+
+typedef _Decimal32 V __attribute__ ((vector_size(16)));
+
+V fn1 (V a) { return a; }

[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] 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

Re: [PATCH] i386: Fix up cvtsd2ss splitter [PR104502]

[Uros Bizjak via Gcc-patches]

On Sat, Feb 12, 2022 at 10:02 AM Jakub Jelinek  wrote:
>
> Hi!
>
> 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.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 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.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/i386.md.jj  2022-01-18 11:58:59.142988343 +0100
> +++ gcc/config/i386/i386.md 2022-02-11 16:19:48.399518508 +0100
> @@ -4838,8 +4838,8 @@ (define_split
>   movddup is available.  */
>if (REG_P (operands[1]))
>  {
> -  if (!TARGET_SSE3
> - && REGNO (operands[0]) != REGNO (operands[1]))
> +  if ((!TARGET_SSE3 && REGNO (operands[0]) != REGNO (operands[1]))
> + || (EXT_REX_SSE_REG_P (operands[1]) && !TARGET_AVX512VL))
> {
>   rtx tmp = lowpart_subreg (DFmode, operands[0], SFmode);
>   emit_move_insn (tmp, operands[1]);
> --- gcc/testsuite/gcc.target/i386/pr104502.c.jj 2022-02-11 16:28:12.880556460 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr104502.c2022-02-11 16:29:42.358321630 
> +0100
> @@ -0,0 +1,31 @@
> +/* PR target/104502 */
> +/* { dg-do compile { target fstack_protector } } */
> +/* { dg-options "-O -flive-range-shrinkage -march=barcelona 
> -fstack-protector-all -mavx512f" } */
> +
> +typedef char __attribute__((__vector_size__ (8))) U;
> +typedef int __attribute__((__vector_size__ (8))) A;
> +typedef int __attribute__((__vector_size__ (16))) B;
> +typedef int __attribute__((__vector_size__ (32))) C;
> +typedef int __attribute__((__vector_size__ (64))) D;
> +typedef __float128 __attribute__((__vector_size__ (32))) F;
> +
> +char s;
> +U u;
> +A a;
> +int i;
> +C c;
> +double d;
> +
> +U
> +foo (U u0, A a0, B b0, B b1, C c0, C c1, C c2, C c3, A a1, A a2, F f0)
> +{
> +  C ca = c |= (short) (float) d;
> +  C cb = c0 + c1 + c2 + c3 + ca + (C) f0;
> +  U ua = s << (u & 4);
> +  B ba = ((union {C a; B b;}) cb).b + b0 + b1;
> +  U ub = ((union {B a; U b;}) ba).b +
> +u0 + u + ua + (U) a + (U) a + (U) a0 + (U) a1 + (U) a2;
> +  long long u64_r = i + d;
> +  char u8_r = u64_r;
> +  return ub + u8_r;
> +}
>
> Jakub
>

[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 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.

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

[Jakub Jelinek via Gcc-patches]

Hi!

With -fstack-check=generic __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.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

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.

--- gcc/asan.cc.jj  2022-01-18 11:58:58.876992143 +0100
+++ gcc/asan.cc 2022-02-11 19:09:39.752065877 +0100
@@ -63,6 +63,7 @@ along with GCC; see the file COPYING3.
 #include "fnmatch.h"
 #include "tree-inline.h"
 #include "tree-ssa.h"
+#include "tree-eh.h"
 
 /* AddressSanitizer finds out-of-bounds and use-after-free bugs
with <2x slowdown on average.
@@ -726,14 +727,24 @@ handle_builtin_alloca (gcall *call, gimp
   gassign *g;
   gcall *gg;
   tree callee = gimple_call_fndecl (call);
+  tree lhs = gimple_call_lhs (call);
   tree old_size = gimple_call_arg (call, 0);
-  tree ptr_type = gimple_call_lhs (call) ? TREE_TYPE (gimple_call_lhs (call))
-: ptr_type_node;
+  tree ptr_type = lhs ? TREE_TYPE (lhs) : ptr_type_node;
   tree partial_size = NULL_TREE;
   unsigned int align
 = DECL_FUNCTION_CODE (callee) == BUILT_IN_ALLOCA
   ? 0 : tree_to_uhwi (gimple_call_arg (call, 1));
 
+  bool throws = false;
+  edge e = NULL;
+  if (stmt_can_throw_internal (cfun, call))
+{
+  if (!lhs)
+   return;
+  throws = true;
+  e = find_fallthru_edge (gsi_bb (*iter)->succs);
+}
+
   if (hwasan_sanitize_allocas_p ())
 {
   gimple_seq stmts = NULL;
@@ -852,29 +863,54 @@ handle_builtin_alloca (gcall *call, gimp
  build_int_cst (size_type_node, align));
   tree new_alloca_with_rz = make_ssa_name (ptr_type, gg);
   gimple_call_set_lhs (gg, new_alloca_with_rz);
-  gsi_insert_before (iter, gg, GSI_SAME_STMT);
+  if (throws)
+{
+  gimple_call_set_lhs (call, NULL);
+  gsi_replace (iter, gg, true);
+}
+  else
+gsi_insert_before (iter, gg, GSI_SAME_STMT);
 
   /* new_alloca = new_alloca_with_rz + align.  */
   g = gimple_build_assign (make_ssa_name (ptr_type), POINTER_PLUS_EXPR,
   new_alloca_with_rz,
   build_int_cst (size_type_node,
  align / BITS_PER_UNIT));
-  gsi_insert_before (iter, g, GSI_SAME_STMT);
+  gimple_stmt_iterator gsi = gsi_none ();
+  if (throws)
+{
+  gsi_insert_on_edge_immediate (e, g);
+  gsi = gsi_for_stmt (g);
+}
+  else
+gsi_insert_before (iter, g, GSI_SAME_STMT);
   tree new_alloca = gimple_assign_lhs (g);
 
   /* Poison newly created alloca redzones:
   __asan_alloca_poison (new_alloca, old_size).  */
   fn = builtin_decl_implicit (BUILT_IN_ASAN_ALLOCA_POISON);
   gg = gimple_build_call (fn, 2, new_alloca, old_size);
-  gsi_insert_before (iter, gg, GSI_SAME_STMT);
+  if (throws)
+gsi_insert_after (, gg, GSI_NEW_STMT);
+  else
+gsi_insert_before (iter, gg, GSI_SAME_STMT);
 
   /* Save new_alloca_with_rz value into last_alloca to use it during
  allocas unpoisoning.  */
   g = gimple_build_assign (last_alloca, new_alloca_with_rz);
-  gsi_insert_before (iter, g, GSI_SAME_STMT);
+  if (throws)
+gsi_insert_after (, g, GSI_NEW_STMT);
+  else
+gsi_insert_before (iter, g, GSI_SAME_STMT);
 
   /* Finally, replace old alloca ptr with NEW_ALLOCA.  */
-  replace_call_with_value (iter, new_alloca);
+  if (throws)
+{
+  g = gimple_build_assign (lhs, new_alloca);
+  gsi_insert_after (, g, GSI_NEW_STMT);
+}
+  else
+replace_call_with_value (iter, new_alloca);
 }
 
 /* Return the memory references contained in a gimple statement
--- gcc/testsuite/gcc.dg/asan/pr104449.c.jj 2022-02-11 19:23:05.085974426 
+0100
+++ gcc/testsuite/gcc.dg/asan/pr104449.c2022-02-11 19:26:20.537282682 
+0100
@@ -0,0 +1,12 @@
+/* PR sanitizer/104449 */
+/* { dg-do compile } */
+/* { dg-options "-fexceptions -fsanitize=address -fstack-check=generic" } */
+
+void bar (int *);
+
+void
+foo (void)
+{
+  int a[16];
+  bar (a);
+}
--- gcc/testsuite/g++.dg/asan/pr104449.C.jj 2022-02-11 19:25:22.035088372 
+0100
+++ gcc/testsuite/g++.dg/asan/pr104449.C2022-02-11 19:26:08.605447008 
+0100
@@ -0,0 +1,16 @@
+// PR sanitizer/104449
+// { dg-do compile }
+// { dg-options "-fexceptions -fsanitize=address -fstack-check=generic" }
+
+void bar (int *);
+struct A { A (); ~A (); };
+
+void
+foo (int n)
+{
+  A b;
+  {
+int a[n];
+bar (a);
+  }
+}

Jakub

[PATCH] i386: Fix up cvtsd2ss splitter [PR104502]

[Jakub Jelinek via Gcc-patches]

Hi!

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.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

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.

--- gcc/config/i386/i386.md.jj  2022-01-18 11:58:59.142988343 +0100
+++ gcc/config/i386/i386.md 2022-02-11 16:19:48.399518508 +0100
@@ -4838,8 +4838,8 @@ (define_split
  movddup is available.  */
   if (REG_P (operands[1]))
 {
-  if (!TARGET_SSE3
- && REGNO (operands[0]) != REGNO (operands[1]))
+  if ((!TARGET_SSE3 && REGNO (operands[0]) != REGNO (operands[1]))
+ || (EXT_REX_SSE_REG_P (operands[1]) && !TARGET_AVX512VL))
{
  rtx tmp = lowpart_subreg (DFmode, operands[0], SFmode);
  emit_move_insn (tmp, operands[1]);
--- gcc/testsuite/gcc.target/i386/pr104502.c.jj 2022-02-11 16:28:12.880556460 
+0100
+++ gcc/testsuite/gcc.target/i386/pr104502.c2022-02-11 16:29:42.358321630 
+0100
@@ -0,0 +1,31 @@
+/* PR target/104502 */
+/* { dg-do compile { target fstack_protector } } */
+/* { dg-options "-O -flive-range-shrinkage -march=barcelona 
-fstack-protector-all -mavx512f" } */
+
+typedef char __attribute__((__vector_size__ (8))) U;
+typedef int __attribute__((__vector_size__ (8))) A;
+typedef int __attribute__((__vector_size__ (16))) B;
+typedef int __attribute__((__vector_size__ (32))) C;
+typedef int __attribute__((__vector_size__ (64))) D;
+typedef __float128 __attribute__((__vector_size__ (32))) F;
+
+char s;
+U u;
+A a;
+int i;
+C c;
+double d;
+
+U
+foo (U u0, A a0, B b0, B b1, C c0, C c1, C c2, C c3, A a1, A a2, F f0)
+{
+  C ca = c |= (short) (float) d;
+  C cb = c0 + c1 + c2 + c3 + ca + (C) f0;
+  U ua = s << (u & 4);
+  B ba = ((union {C a; B b;}) cb).b + b0 + b1;
+  U ub = ((union {B a; U b;}) ba).b +
+u0 + u + ua + (U) a + (U) a + (U) a0 + (U) a1 + (U) a2;
+  long long u64_r = i + d;
+  char u8_r = u64_r;
+  return ub + u8_r;
+}

Jakub

Re: [PATCH v2] MIPS: IPL is 8bit in Cause register if TARGET_MCU

[Maciej W. Rozycki]

On Fri, 11 Feb 2022, Jeff Law wrote:

> > If MIPS MCU extension is enable, the IPL section in Cause register
> > has been expand to 8bit instead of 6bit.
> > 
> > gcc/ChangeLog:
> > 
> > * config/mips/mips.cc (mips_expand_prologue):
> >   IPL is 8bit for MCU ASE.
> OK

 But this is still wrong AFAICT.

 The mask is applied to the CP0 Status register according to the comment, 
but the layout of the interrupt bit-field is different between the CP0 
Status and the CP0 Cause registers, so you can't just extract it from one 
of the two registers and directly apply to the other.

 I would like to know how this code has been verified.

  Maciej

Re: [PATCH] [PATCH,v4,1/1,AARCH64][PR102768] aarch64: Add compiler support for Shadow Call Stack

[Dan Li via Gcc-patches]

On 2/11/22 07:35, Richard Sandiford wrote:

Dan Li  writes:

On 2/11/22 01:53, Richard Sandiford wrote:

Dan Li  writes:

On 2/10/22 01:55, Richard Sandiford wrote:



And I think maybe we could handle this through three patches:
1.Keep current patch (a V5) unchanged for scs.
2.Add shrink-warpping for X30:
logically this might be a separate topic, and I think more testing
might be needed here (Well, I'm a little worried about if there might
be other effects, since I just read this part of the code roughly
yesterday).
3.Add scs push/pop to shrink-wrapping (and maybe we can do the same for
the PAC code in pro/epilogue, since it's also the operation of the X30).


Yeah, that's fair.

(Like I said earlier, I wasn't asking for the shrink-wrapping change.
It was just a note in passing.  But as you point out, the individual
shrink-wrapping support would be even more work than I'd imagined.)


Hi, Richard,
I have sent out the v5[1] and rebased it to mainline at the same time,
please let me know if there is anything else I need to do :)

[1].https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590311.html

Thanks,
Dan

[PATCH] [PATCH, v5, 1/1, AARCH64][PR102768] aarch64: Add compiler support for Shadow Call Stack

[Dan Li via Gcc-patches]

Shadow Call Stack can be used to protect the return address of a
function at runtime, and clang already supports this feature[1].

To enable SCS in user mode, in addition to compiler, other support
is also required (as discussed in [2]). This patch only adds basic
support for SCS from the compiler side, and provides convenience
for users to enable SCS.

For linux kernel, only the support of the compiler is required.

[1] https://clang.llvm.org/docs/ShadowCallStack.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768

Signed-off-by: Dan Li 

gcc/ChangeLog:

* config/aarch64/aarch64.cc (SLOT_REQUIRED):
Change wb_candidate[12] to wb_push_candidate[12].
(aarch64_layout_frame): Likewise, and
change callee_adjust when scs is enabled.
(aarch64_save_callee_saves):
Change wb_candidate[12] to wb_push_candidate[12].
(aarch64_restore_callee_saves):
Change wb_candidate[12] to wb_pop_candidate[12].
(aarch64_get_separate_components):
Change wb_candidate[12] to wb_push_candidate[12].
(aarch64_expand_prologue): Push x30 onto SCS before it's
pushed onto stack.
(aarch64_expand_epilogue): Pop x30 frome SCS, while
preventing it from being popped from the regular stack again.
(aarch64_override_options_internal): Add SCS compile option check.
(TARGET_HAVE_SHADOW_CALL_STACK): New hook.
* config/aarch64/aarch64.h (struct GTY): Add is_scs_enabled,
wb_pop_candidate[12], and rename wb_candidate[12] to
wb_push_candidate[12].
* config/aarch64/aarch64.md (scs_push): New template.
(scs_pop): Likewise.
* doc/invoke.texi: Document -fsanitize=shadow-call-stack.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: Add hook have_shadow_call_stack.
* flag-types.h (enum sanitize_code):
Add SANITIZE_SHADOW_CALL_STACK.
* opts.cc: Add shadow-call-stack.
* target.def: New hook.
* toplev.cc (process_options): Add SCS compile option check.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/shadow_call_stack_1.c: New test.
* gcc.target/aarch64/shadow_call_stack_2.c: New test.
* gcc.target/aarch64/shadow_call_stack_3.c: New test.
* gcc.target/aarch64/shadow_call_stack_4.c: New test.
* gcc.target/aarch64/shadow_call_stack_5.c: New test.
* gcc.target/aarch64/shadow_call_stack_6.c: New test.
* gcc.target/aarch64/shadow_call_stack_7.c: New test.
* gcc.target/aarch64/shadow_call_stack_8.c: New test.
---
V5:
- Modify part of wb_push_candidates to wb_pop_candidates.
- Rebase to the mainline (20220210).
V4:
- Added wb_[push|pop]_candidates[12] to ensure push/pop can
emit different registers.

V3:
- Change scs_push/pop to standard move patterns.
- Optimize scs_pop to avoid pop x30 twice when shadow stack is enabled.

 gcc/config/aarch64/aarch64.cc | 113 +-
 gcc/config/aarch64/aarch64.h  |  21 +++-
 gcc/config/aarch64/aarch64.md |  10 ++
 gcc/doc/invoke.texi   |  30 +
 gcc/doc/tm.texi   |   5 +
 gcc/doc/tm.texi.in|   2 +
 gcc/flag-types.h  |   2 +
 gcc/opts.cc   |   1 +
 gcc/target.def|   8 ++
 .../gcc.target/aarch64/shadow_call_stack_1.c  |   6 +
 .../gcc.target/aarch64/shadow_call_stack_2.c  |   6 +
 .../gcc.target/aarch64/shadow_call_stack_3.c  |  45 +++
 .../gcc.target/aarch64/shadow_call_stack_4.c  |  20 
 .../gcc.target/aarch64/shadow_call_stack_5.c  |  18 +++
 .../gcc.target/aarch64/shadow_call_stack_6.c  |  18 +++
 .../gcc.target/aarch64/shadow_call_stack_7.c  |  18 +++
 .../gcc.target/aarch64/shadow_call_stack_8.c  |  24 
 gcc/toplev.cc |  10 ++
 18 files changed, 326 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_3.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_4.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_5.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_6.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_7.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/shadow_call_stack_8.c

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index e3f18fbe7da..35f6f64f5b2 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -80,6 +80,7 @@
 #include "fractional-cost.h"
 #include "rtlanal.h"
 #include "tree-dfa.h"
+#include "asan.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -7443,8 +7444,8 @@ 

[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=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)