[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Christoph Reiter  ---
I can confirm that the patch from comment 4 fixes all the above cases, and also
emacs builds again.

Thanks again

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #11 from Thorsten Otto  ---
Confirmed, reverting that commit will prevent the error. Now the question is
how to find the real cause of the problem, since reverting that commit is most
likely not the solution. OTOH, it would be nice to know why the call to
emit_clobber() originally was done.

[Bug libstdc++/115059] New: Constraints/Mandates on the comparison operators of std::optional and std::variant are overly strict

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 115059
   Summary: Constraints/Mandates on the comparison operators of
std::optional and std::variant are overly strict
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

The following example should compile in C++23/26 (or some other modes where
explicit object parameters are available) due to CWG DR 2813
(https://cplusplus.github.io/CWG/issues/2813.html), given that
[optional.relops] and [variant.relops] only require the result to be
convertible to bool.

```
#include 
#include 

class PinnedBoolean {
private:
bool val_;

PinnedBoolean(const PinnedBoolean&) = delete;
PinnedBoolean& operator=(const PinnedBoolean&) = delete;

public:
constexpr explicit PinnedBoolean(bool b) noexcept : val_{b} {}
constexpr operator bool(this PinnedBoolean x) noexcept { return x.val_; }
};

static_assert(PinnedBoolean{true});

struct X {
friend constexpr PinnedBoolean operator==(X, X) noexcept { return
PinnedBoolean{true}; }
friend constexpr PinnedBoolean operator!=(X, X) noexcept { return
PinnedBoolean{false}; }
};

static_assert(std::optional{} == std::optional{});
static_assert(std::variant{} == std::variant{});
```

However, libc++ is currently applying stricter requirements
(https://godbolt.org/z/Mc3bse5h7).
Since CWG2813, both __boolean_testable and is_convertible_v are stricter than
the plain "convertible to", because the implicit conversion from the result
type to bool can be only well-formed for prvalues but not xvalues.

[Bug rtl-optimization/115056] [14/15 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Dale Weiler  ---
New test case without UB still exhibits the behavior

#include 
#include 
typedef union {
unsigned char as_bytes[64];
unsigned long long as_chunks[64 / sizeof(unsigned long long)];
} Block;
int main(int argc, char **argv) {
Block block;
int i = strlen(argv[0]), j = 0;
for (; j < i; j++) block.as_bytes[j] = argv[0][j];
block.as_bytes[j] = 0x01;
while (++j & 7) block.as_bytes[j] = 0;
if (j > 56) while (j < 64) block.as_bytes[j++] = 0;
while (j < 56) block.as_bytes[j++] = 0;
while (j < 64) block.as_bytes[j++] = 0x01;
for (j = 0; j < 8; j++) printf("%d\n", (int)block.as_chunks[j]);
}

[Bug target/115058] New: on target arm -mcpu=cortex-a78ae does not allow use pauth and dot product

[yanxiaoyong5 at gmail dot com via Gcc-bugs]

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

Bug ID: 115058
   Summary: on target arm -mcpu=cortex-a78ae does not allow use
pauth and dot product
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yanxiaoyong5 at gmail dot com
  Target Milestone: ---

my gcc version is:
COLLECT_GCC=aarch64-none-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/root/samba/ssdk/prebuilts/arm-gnu-toolchain-12.2.rel1-x86_64-aarch64-none-linux-gnu/bin/../libexec/gcc/aarch64-none-linux-gnu/12.2.1/lto-wrapper
目标：aarch64-none-linux-gnu
配置为：/data/jenkins/workspace/GNU-toolchain/arm-12/src/gcc/configure
--target=aarch64-none-linux-gnu --prefix=
--with-sysroot=/aarch64-none-linux-gnu/libc
--with-build-sysroot=/data/jenkins/workspace/GNU-toolchain/arm-12/build-aarch64-none-linux-gnu/install//aarch64-none-linux-gnu/libc
--with-bugurl=https://bugs.linaro.org/ --enable-gnu-indirect-function
--enable-shared --disable-libssp --disable-libmudflap --enable-checking=release
--enable-languages=c,c++,fortran
--with-gmp=/data/jenkins/workspace/GNU-toolchain/arm-12/build-aarch64-none-linux-gnu/host-tools
--with-mpfr=/data/jenkins/workspace/GNU-toolchain/arm-12/build-aarch64-none-linux-gnu/host-tools
--with-mpc=/data/jenkins/workspace/GNU-toolchain/arm-12/build-aarch64-none-linux-gnu/host-tools
--with-isl=/data/jenkins/workspace/GNU-toolchain/arm-12/build-aarch64-none-linux-gnu/host-tools
--enable-fix-cortex-a53-843419 --with-pkgversion='Arm GNU Toolchain 12.2.Rel1
(Build arm-12.24)'
线程模型：posix
Supported LTO compression algorithms: zlib
gcc 版本 12.2.1 20221205 (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24))

The TRM (Technical Reference Manual) for Cortex-A78AE states that Cortex-A78AE
supports PAuth and Dot-Product.
Armv8.4-A Dot Product instruction support
Armv8.3-A Pointer Authentication support

but when I use -mcpu=cortex-a78ae, Dot Product and Pointer authentication is
not supported.
Dot Product:
105: Error: selected processor does not support `sdot v19.4s,v2.16b,v3.16b'

Pointer authentication:
Error: selected processor does not support system register name 'apiakeyhi_el1'

[Bug rtl-optimization/115056] [14/15 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-13
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

[Bug rtl-optimization/115056] [14/15 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

--- Comment #9 from Sam James  ---
The issue is we need a program which no UB which has the bad symptoms.

I can fix it up but that doesn't mean it has the symptoms you originally saw
which made you report a bug.

[Bug rtl-optimization/115056] [14/15 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Dale Weiler  ---
Yeah, you can add another `while (j < 64) block.as_bytes[j] = 0;` to the end if
you want. I really should've done a better job reducing it so as not to create
uninitialized memory. You can also just memset the block at the start to all
zeros if you want.

[Bug rtl-optimization/115056] [14/15 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

--- Comment #7 from Sam James  ---
Isn't there still an uninitialised read?

```
$ valgrind /tmp/foo
[...]
==814922==
1886221359
1
0
0
0
0
0
==814922== Use of uninitialised value of size 8
==814922==at 0x48F7D3A: _itoa_word (_itoa.c:183)
==814922==by 0x49029A6: __printf_buffer (vfprintf-process-arg.c:155)
==814922==by 0x4904BD0: __vfprintf_internal (vfprintf-internal.c:1544)
==814922==by 0x49C55AE: __printf_chk (printf_chk.c:33)
==814922==by 0x10938D: main (/tmp/foo.c:16)
==814922==
```

with:
```
#include 
#include 
typedef union {
unsigned char as_bytes[64];
unsigned long long as_chunks[64 / sizeof(unsigned long long)];
} Block;
int main(int argc, char **argv) {
Block block;
int i = strlen(argv[0]), j = 0;
for (; j < i; j++) block.as_bytes[j] = argv[0][j];
block.as_bytes[j] = 0x01; // I removed this line
while (++j & 7) block.as_bytes[j] = 0;
if (j > 56) while (j < 64) block.as_bytes[j++] = 0;
while (j < 56) block.as_bytes[j++] = 0;
for (j = 0; j < 8; j++) printf("%d\n", (int)block.as_chunks[j]);
}
```

[Bug modula2/115057] New: TextIO.ReadRestLine raise an exception for insufficient buffer

[dramwang at 163 dot com via Gcc-bugs]

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

Bug ID: 115057
   Summary: TextIO.ReadRestLine raise an exception for
insufficient buffer
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: dramwang at 163 dot com
  Target Milestone: ---

For following code, `ReadRestLine` will raise an "attempting to read beyond end
of file" exception, which I think is incorrect:

```
MODULE test ;

IMPORT SeqFile, TextIO ;

VAR
  chan : SeqFile.ChanId ;
  line : ARRAY [0..5] OF CHAR ;
  results : SeqFile.OpenResults ;

BEGIN
  SeqFile.OpenRead (chan, "test.mod", SeqFile.read, results) ;
  TextIO.ReadRestLine (chan, line) ;
END test.
```

Tested on Debian 12, with GCC 15.0.0 20240509 (83fb5e6):

```
% gm2 test.mod && ./a.out
EXCEPTIONS.mod:65:56: In RAISE
EXCEPTIONS.mod:65:56:attempting to read beyond end of file
Aborted
```

[Bug rtl-optimization/115056] [14 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

--- Comment #6 from Sam James  ---
I was just about to comment that, thanks!

[Bug rtl-optimization/115056] [14 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Dale Weiler  ---
I should note that there is a byte in-between these two pieces of code I
removed

 for (; j < i; j++) block.as_bytes[j] = argv[0][j];
 block.as_bytes[j] = 0x01; // I removed this line
 while (++j & 7) block.as_bytes[j] = 0;

Just to make the repro smaller, but I guess that causes that one byte to be
uninitialized in this case. Adding it back doesn't change anything, but it
should be noted it exists here.

[Bug rtl-optimization/115056] [14 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

--- Comment #4 from Sam James  ---
With Clang, I get:
```
¢ clang /tmp/foo.c -o /tmp/foo
$ /tmp/foo
1886221359
0
0
0
0
0
0
-733536256
```
and
```
$ clang /tmp/foo.c -o /tmp/foo -fsanitize=address,undefined
$ /tmp/foo
1886221359
0
0
0
0
0
0
0
```

[Bug rtl-optimization/115056] [14 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

[weilercdale at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Dale Weiler  ---
> You don't have to share, but I find it useful to know where stuff was reduced 
> from. Was it a public library? If so, what? It is OK to not answer.

It's the inner part of the Tiger Hash cryptographic hash function. This one is
just my own implementation. This is a pretty standard construction of how the
function works so it would presumably affect any Tiger Hash implementation.

[Bug rtl-optimization/115056] [14 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

--- Comment #2 from Sam James  ---
(In reply to Dale Weiler from comment #0)
> I've isolated what appears to be an unsound __builtin_memset optimization
> applied by gcc 14.1.1 on a hash function in a cryptographic library where it
> writes one byte beyond the end of a buffer.

You don't have to share, but I find it useful to know where stuff was reduced
from. Was it a public library? If so, what? It is OK to not answer.

[Bug rtl-optimization/115056] [14 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   Keywords||wrong-code
Summary|Miscompilation triggering   |[14 regression]
   |-Wstringop-overflow and |Miscompilation (also
   |-Warray-bounds warning when |triggering
   |-O2 or higher   |-Wstringop-overflow and
   ||-Warray-bounds warning)
   ||when -O2 or higher

--- Comment #1 from Sam James  ---
Just to be clear as it might be easy to misread: the warnings are maybe a hint
about what's going on, and not the complaint here.

I can reproduce diff. results w/ 13 vs 14, not looked further yet.

[Bug rtl-optimization/115056] New: Miscompilation triggering -Wstringop-overflow and -Warray-bounds warning when -O2 or higher

[weilercdale at gmail dot com via Gcc-bugs]

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

Bug ID: 115056
   Summary: Miscompilation triggering -Wstringop-overflow and
-Warray-bounds warning when -O2 or higher
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weilercdale at gmail dot com
  Target Milestone: ---

I've isolated what appears to be an unsound __builtin_memset optimization
applied by gcc 14.1.1 on a hash function in a cryptographic library where it
writes one byte beyond the end of a buffer. The compiler thankfully reports two
warnings when it happens.

The isolated test case is small so I'll provide it inline

#include 
#include 
typedef union {
unsigned char as_bytes[64];
unsigned long long as_chunks[64 / sizeof(unsigned long long)];
} Block;
int main(int argc, char **argv) {
Block block;
int i = strlen(argv[0]), j = 0;
for (; j < i; j++) block.as_bytes[j] = argv[0][j];
while (++j & 7) block.as_bytes[j] = 0;
if (j > 56) while (j < 64) block.as_bytes[j++] = 0;
while (j < 56) block.as_bytes[j++] = 0;
for (j = 0; j < 8; j++) printf("%d\n", (int)block.as_chunks[j]);
}

Compiling this with -O2 produces the following warning

t.c: In function ‘main’:
t.c:12:56: warning: ‘__builtin_memset’ writing 8 bytes into a region of size 7
overflows the destination [-Wstringop-overflow=]
   12 | if (j > 56) while (j < 64) block.as_bytes[j++] = 0;
  |^~~
t.c:8:15: note: at offset [57, 63] into destination object ‘block’ of size 64
8 | Block block;
  |   ^

Compiling this with -O2 and -Wall produces the following warning

t.c: In function ‘main’:
t.c:12:56: warning: ‘__builtin_memset’ forming offset 64 is out of the bounds
[0, 64] of object ‘block’ with type ‘Block’ [-Warray-bounds=]
   12 | if (j > 56) while (j < 64) block.as_bytes[j++] = 0;
  |^~~
t.c:8:15: note: ‘block’ declared here
8 | Block block;
  |   ^

[Bug target/115054] __float128 and _Float16 use incorrect ABI on x86-64 MinGW

[tmgross at umich dot edu via Gcc-bugs]

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

--- Comment #5 from Trevor Gross  ---
Looks like bugz cut off part of the sysv quote, here for reference:

> Arguments of types __float128, _Decimal128 and __m128 are split
> into two halves. The least significant ones belong to class SSE, the most
> significant one to class SSEUP.

[Bug target/115054] __float128 and _Float16 use incorrect ABI on x86-64 MinGW

[tmgross at umich dot edu via Gcc-bugs]

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

--- Comment #4 from Trevor Gross  ---
To my knowledge, MSVC does not support or specify an ABI for 16- or 128-bit
IEEE floating point types, so I do suppose that either GCC or Clang could be
considered correct here.

SysV doesn't say anything about f16 but does clarify that f128 should be SSE:

> Arguments of types __float128, _Decimal128 and __m128 are split
into two halves. The least significant ones belong to class SSE, the most
significant one to class SSEUP

Falling back to what SysV says seems reasonable to me since MSVC doesn't
provide any guidance, and passing via xmm is better register use anyway. Is
there any reason not to match SysV and Clang here? One side needs to change,
the mismatch is causing problems with rt math symbols.

[Bug tree-optimization/115055] New: reassociation should use match-and-simplify

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

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

Bug ID: 115055
   Summary: reassociation should use match-and-simplify
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int c)
{
int b = a & c;
return (a == 0) & b;
}
```

This should be optimized to 0 but currently does not. 

There is a match pattern (via PR 111431) which is able to handle `a & (a == 0)`
into `0`. reassociation knows how to handle `a & a` but it seems like if while
doing reassociation, we should be to try to use match-and-simplify to simplify
the f here.

[Bug target/115054] __float128 and _Float16 use incorrect ABI on x86-64 MinGW

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

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

--- Comment #3 from Andrew Pinski  ---
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#parameter-passing

So it uses floating point as the type. But then it is vague on those kind of
type. Gcc treats _Float16 similar to how __m64 and __m128 are passed that is
via integer registers.

[Bug target/115054] __float128 and _Float16 use incorrect ABI on x86-64 MinGW

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

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

--- Comment #2 from Andrew Pinski  ---
Does Microsoft's abi documents this case?

If not then gcc is as correct here as clang is.

[Bug target/115054] __float128 and _Float16 use incorrect ABI on x86-64 MinGW

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

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

--- Comment #1 from Andrew Pinski  ---
What does msvc do?

[Bug target/115054] New: __float128 and _Float16 use incorrect ABI on x86-64 MinGW

[tmgross at umich dot edu via Gcc-bugs]

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

Bug ID: 115054
   Summary: __float128 and _Float16 use incorrect ABI on x86-64
MinGW
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tmgross at umich dot edu
  Target Milestone: ---

GCC appears to try to pass half and quad-precision floating point numbers
(_Float16 and __float128) using the integer calling convention on x86-64 MinGW.
They should get passed with the floating point CC in SSE registers, like other
floats, as is done by GCC x86-64 linux, Clang x86-64 linux, and Clang x86-64
MinGW.

Sample:

void f16_ext(_Float16);
void f16_entry(float _, _Float16 a) {
asm("nop # marker");
f16_ext(a);
}

void f32_ext(float);
void f32_entry(float _, float a) {
asm("nop # marker");
f32_ext(a);
}

void f64_ext(double);
void f64_entry(float _, double a) {
asm("nop # marker");
f64_ext(a);
}

void f128_ext(__float128);
void f128_entry(float _, __float128 a) {
asm("nop # marker");
f128_ext(a);
}

Incorrect output from GCC on x64 MinGW (O2):

f16_entry:
mov ecx, edx
nop # marker
jmp f16_ext
f32_entry:
movaps  xmm0, xmm1
nop # marker
jmp f32_ext
f64_entry:
movapd  xmm0, xmm1
nop # marker
jmp f64_ext
f128_entry:
sub rsp, 56
movdqa  xmm0, XMMWORD PTR [rdx]
nop # marker
lea rcx, 32[rsp]
movaps  XMMWORD PTR 32[rsp], xmm0
callf128_ext
nop
add rsp, 56
ret

Correct output from GCC on x64 Linux (O2):

f16_entry:
movaps  xmm0, xmm1
nop # marker
jmp f16_ext
f32_entry:
movaps  xmm0, xmm1
nop # marker
jmp f32_ext
f64_entry:
movapd  xmm0, xmm1
nop # marker
jmp f64_ext
f128_entry:
movdqa  xmm0, xmm1
nop # marker
jmp f128_ext

Correct output from Clang on both x64 Linux and x64 MinGW:

f16_entry:  # @f16_entry
movaps  xmm0, xmm1
nop # marker
jmp f16_ext # TAILCALL
f32_entry:  # @f32_entry
movaps  xmm0, xmm1
nop # marker
jmp f32_ext # TAILCALL
f64_entry:  # @f64_entry
movaps  xmm0, xmm1
nop # marker
jmp f64_ext # TAILCALL
f128_entry: # @f128_entry
movaps  xmm0, xmm1
nop # marker
jmp f128_ext# TAILCALL


Tested with GCC 13.1. Link: https://gcc.godbolt.org/z/hdojahes5

[Bug c++/115053] New: gcc crashed without back trace

[rungecc at gmail dot com via Gcc-bugs]

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

Bug ID: 115053
   Summary: gcc crashed without back trace
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rungecc at gmail dot com
  Target Milestone: ---

Minimal example(https://godbolt.org/z/qPKaYdj4o):

```c++
template < typename... Ts >
struct list {};

template < typename... Ts >
constexpr
bool ice = []( list x = {}) { 
return true;
}();

constexpr auto r = ice;
```

GCC just crashes, without any useful diagnostics or internal reports, possibly
runs into an infinite loop when it performs mangling (the crash of clang is
this type).

[Bug c++/115052] New: rejected lambda while capturing a constexpr array

[franckbehaghel_gcc at protonmail dot com via Gcc-bugs]

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

Bug ID: 115052
   Summary: rejected lambda while capturing a constexpr array
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: franckbehaghel_gcc at protonmail dot com
  Target Milestone: ---

The following code is fine :

constexpr int a1[] = { 1, 2};
int f_lambda_capturing_case1(int id)
{
   return [] (int i) { return a1[i];}(id);
}



But this one is rejected :

int f_lambda_capturing_case2(int id)
{
   constexpr int a2[] = { 1, 2};
   return [] (int i) { return a2[i];}(id);
}



In lambda function:
:12:31: error: 'a2' is not captured
   12 |return [] (int i) { return a2[i];}(id);
  |   ^~
:12:12: note: the lambda has no capture-default
   12 |return [] (int i) { return a2[i];}(id);
  |^
:11:18: note: 'constexpr const int a2 [2]' declared here
   11 |constexpr int a2[] = { 1, 2};



The second case seems also valid as it is just a change of scope.
Moreover it is accepted by clang.

regards,

[Bug rtl-optimization/115051] ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -O -finstrument-functions-once -finline-stringops -fprofile-use

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/113506] ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -Os -fno-tree-coalesce-vars -finline-stringops

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

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

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

[Bug rtl-optimization/115051] New: ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -O -finstrument-functions-once -finline-stringops -fprofile-use

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 115051
   Summary: ICE: RTL check: expected elt 2 type 'B', have '0' (rtx
barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -O
-finstrument-functions-once -finline-stringops
-fprofile-use
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 58184
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58184=edit
reduced testcase (from pr100519.c)

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O -finstrument-functions-once
-finline-stringops -fprofile-use testcase.c -w
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: RTL check: expected elt 2 type 'B',
have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495
   11 | }
  | ^
0x864446 rtl_check_failed_type1(rtx_def const*, int, int, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.cc:751
0x7b242f BLOCK_FOR_INSN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1495
0x7b5d1c BLOCK_FOR_INSN(rtx_def*)
/repo/gcc-trunk/gcc/emit-rtl.cc:4384
0x7b5d1c set_block_for_insn(rtx_insn*, basic_block_def*)
/repo/gcc-trunk/gcc/rtl.h:1500
0x7b5d1c add_insn_before(rtx_insn*, rtx_insn*, basic_block_def*)
/repo/gcc-trunk/gcc/emit-rtl.cc:4379
0xeaf750 emit_pattern_before_noloc
/repo/gcc-trunk/gcc/emit-rtl.cc:4647
0xdd034d commit_one_edge_insertion(edge_def*)
/repo/gcc-trunk/gcc/cfgrtl.cc:2106
0xdd5671 commit_edge_insertions()
/repo/gcc-trunk/gcc/cfgrtl.cc:2168
0xdb5b4b execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6959
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.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-380-20240511175912-g1b0919cd147-checking-yes-rtl-df-extra-nobootstrap-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/15.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r15-380-20240511175912-g1b0919cd147-checking-yes-rtl-df-extra-nobootstrap-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240509 (experimental) (GCC)

[Bug driver/80182] accidently invoked `gcc -lm -o file.c` which deletes file.c

[peter0x44 at disroot dot org via Gcc-bugs]

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

Peter Damianov  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Christoph Reiter  ---
Thanks! I can confirm that "-fno-fold-mem-offsets" works around the issue. I'll
test the proposed patch tomorrow.

In the meantime we've reduced another instance of this when building emacs, but
this time with "simpler" C code and without -fno-omit-frame-pointer:

```
// gcc -c -O2 repro.c -> internal compiler error: in seh_cfa_offset
// gcc -c -g3 -O2 -gdwarf-2 repro.c -> internal compiler error: in
dwarf2out_frame_debug_expr
void a() {
__builtin_unwind_init();
}
```

Adding this here for completeness.

[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

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

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

--- Comment #4 from Eric Botcazou  ---
Tentative fixlet:

diff --git a/gcc/fold-mem-offsets.cc b/gcc/fold-mem-offsets.cc
index 2e15b05529e..84b9623058b 100644
--- a/gcc/fold-mem-offsets.cc
+++ b/gcc/fold-mem-offsets.cc
@@ -491,7 +491,7 @@ fold_offsets (rtx_insn *insn, rtx reg, bool analyze, bitmap
foldable_insns)
 {
   rtx_insn *def = get_single_def_in_bb (insn, reg);

-  if (!def || GET_CODE (PATTERN (def)) != SET)
+  if (!def || RTX_FRAME_RELATED_P (def) || GET_CODE (PATTERN (def)) != SET)
 return 0;

   rtx dest = SET_DEST (PATTERN (def));

[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

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

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

--- Comment #3 from Eric Botcazou  ---
It's the -ffold-mem-offsets pass messing up with the prologue and the
frame-related instructions (so -fno-fold-mem-offsets is a workaround).

[Bug c++/115050] Segfault when compiled with -O0

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
Clang trunk UBSAN says:
```
/app/example.cpp:22:5: runtime error: constructor call on misaligned address
0x7ffe75477cbb for type 'Handler *', which requires 8 byte alignment
0x7ffe75477cbb: note: pointer points here
 00  62 52 4a fe c8 7b 00 00  01 00 00 00 00 00 00 00  67 6c 69 62 00 00 00 00 
01 00 00 00 00 00 00
  ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:22:5 
/app/example.cpp:22:5: runtime error: constructor call on misaligned address
0x7ffe75477cbb for type 'VTable', which requires 8 byte alignment
0x7ffe75477cbb: note: pointer points here
 00  62 52 4a fe c8 7b 00 00  01 00 00 00 00 00 00 00  67 6c 69 62 00 00 00 00 
01 00 00 00 00 00 00
  ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:22:5 
/app/example.cpp:8:7: runtime error: constructor call on misaligned address
0x7ffe75477cbb for type 'VTable *', which requires 8 byte alignment
0x7ffe75477cbb: note: pointer points here
 00  62 52 4a fe c8 7b 00 00  01 00 00 00 00 00 00 00  67 6c 69 62 00 00 00 00 
01 00 00 00 00 00 00
  ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:8:7 
/app/example.cpp:24:27: runtime error: constructor call on misaligned address
0x7ffe75477cc3 for type 'Testor', which requires 8 byte alignment
0x7ffe75477cc3: note: pointer points here
 68  5a 00 00 00 00 00 00 00  67 6c 69 62 00 00 00 00  01 00 00 00 00 00 00 00 
90 9d 42 fe c8 7b 00
  ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:24:27 
/app/example.cpp:11:13: runtime error: member call on misaligned address
0x7ffe75477cbb for type 'VTable *', which requires 8 byte alignment
0x7ffe75477cbb: note: pointer points here
 00  62 52 4a 60 4c 47 5d 68  5a 00 00 00 00 00 00 00  67 6c 69 62 00 00 00 00 
01 00 00 00 00 00 00
  ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:11:13 
/app/example.cpp:39:62: runtime error: member call on misaligned address
0x7ffe75477cbb for type 'VTable', which requires 8 byte alignment
0x7ffe75477cbb: note: pointer points here
 00  62 52 4a 60 4c 47 5d 68  5a 00 00 00 00 00 00 00  67 6c 69 62 00 00 00 00 
01 00 00 00 00 00 00
  ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:39:62 
/app/example.cpp:29:5: runtime error: member call on misaligned address
0x7ffe75477cbb for type 'Handler *', which requires 8 byte alignment
0x7ffe75477cbb: note: pointer points here
 00  62 52 4a 60 4c 47 5d 68  5a 00 00 00 00 00 00 00  67 6c 69 62 00 00 00 00 
01 00 00 00 00 00 00
  ^ 
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.cpp:29:5 
 caught! std::bad_exception
```

GCC's reports nothing though.

[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |14.2
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-12
Summary|ICE in seh_cfa_offset since |[14/15 regression] internal
   |14.1.0  |error in seh_cfa_offset
   ||with -O2
   ||-fno-omit-frame-pointer

--- Comment #2 from Eric Botcazou  ---
I can reproduce.

[Bug target/115010] m68k: invalid subl instruction generated

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #10 from Mikael Pettersson  ---
Reproduces with a cross to m68k-linux-gnu compiling the shortened test case
with -O2 -m68060. A git bisect between 13.2.0 and 14.1.0 identified the
following commit as introducing the misbehaviour:

d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd is the first new commit
commit d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd
Author: Roger Sayle 
Date:   Sun May 7 07:52:15 2023 +0100

Don't call emit_clobber in lower-subreg.cc's resolve_simple_move.

Possibly it just exposes a latent issue in the target code.

[Bug target/112959] install.tex needs updates on FreeBSD

[thierry at FreeBSD dot org via Gcc-bugs]

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

--- Comment #12 from Thierry Thomas  ---
(In reply to Gerald Pfeifer from comment #11)

> Thierry, what is your take, in particular related to building GNAT as it
> comes as part of upstream GCC?

AFAIK, no problem with these ports for the supported architectures.

But - this is not related to this PR - I tried to cross-compile for new archs,
without success ATM.

[Bug target/112959] install.tex needs updates on FreeBSD

[gerald at pfeifer dot com via Gcc-bugs]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 CC||thierry at FreeBSD dot org

--- Comment #11 from Gerald Pfeifer  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> What's there looks good to me.

Cool, thank you. I cherry picked the changes I made to the GCC 14 
branch, so they should be in the GCC 14.2 release.

> However, one issue mentioned in PR target/112959 is missing, namely the
> problem of getting a working Ada bootstrap compiler. I have no idea if
> gnat12 has been fixed since and is now able to build Ada on trunk/the
> gcc-14 branch.  Otherwise, the old GNAT 6.4.1 worked for me, but this
> isn't easy to find.

Looking at the lang/gnat12 and now lang/gcc13 ports and recent changes
including ones like

  commit 7d359e6b779d96d82f383e3aeee8259057b16df0
  Author: Thierry Thomas 
  Date:   Wed Dec 13 22:41:20 2023 +0100

lang/gnat12: bootstrap from previous assets by default

All assets have been built, and it is now possible to bootstrap without
lang/gcc6-aux!

(which was a few days after this report was filed) I am hopefully it would
work. However, I cannot guarantee.

I am temped to mark this report as RESOLVED based on my changes.

Thierry, what is your take, in particular related to building GNAT as it
comes as part of upstream GCC?

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:

https://gcc.gnu.org/g:80ccc90be4aee9f87f468e04c5b97d6b9583ae7e

commit r14-10198-g80ccc90be4aee9f87f468e04c5b97d6b9583ae7e
Author: Gerald Pfeifer 
Date:   Sun May 12 15:31:33 2024 +0200

doc: Describe limitations re Ada, D, and Go on FreeBSD

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: The Ada and D
run-time libraries are broken on i386 which also can affect
64-bit builds. Go is broken.

(cherry picked from commit ff98aab108a6a4e50a831e7cfc011c2131f8d19c)

[Bug target/112959] install.tex needs updates on FreeBSD

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:

https://gcc.gnu.org/g:80ccc90be4aee9f87f468e04c5b97d6b9583ae7e

commit r14-10198-g80ccc90be4aee9f87f468e04c5b97d6b9583ae7e
Author: Gerald Pfeifer 
Date:   Sun May 12 15:31:33 2024 +0200

doc: Describe limitations re Ada, D, and Go on FreeBSD

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: The Ada and D
run-time libraries are broken on i386 which also can affect
64-bit builds. Go is broken.

(cherry picked from commit ff98aab108a6a4e50a831e7cfc011c2131f8d19c)

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:

https://gcc.gnu.org/g:609f9699cd376dbb903d9a6761bdb1165831f796

commit r14-10197-g609f9699cd376dbb903d9a6761bdb1165831f796
Author: Gerald Pfeifer 
Date:   Sun May 12 15:30:18 2024 +0200

doc: FreeBSD no longer has a GNU toolchain in base

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: No longer refer
to GCC or binutils in base. Recommend bootstrap using binutils.

(cherry picked from commit 0695aba3e987f4bb06c95f29ff90a8a3234e1507)

[Bug target/112959] install.tex needs updates on FreeBSD

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:

https://gcc.gnu.org/g:609f9699cd376dbb903d9a6761bdb1165831f796

commit r14-10197-g609f9699cd376dbb903d9a6761bdb1165831f796
Author: Gerald Pfeifer 
Date:   Sun May 12 15:30:18 2024 +0200

doc: FreeBSD no longer has a GNU toolchain in base

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: No longer refer
to GCC or binutils in base. Recommend bootstrap using binutils.

(cherry picked from commit 0695aba3e987f4bb06c95f29ff90a8a3234e1507)

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:

https://gcc.gnu.org/g:7939f8823e20c8faed6ce5ac4614c558344a265f

commit r14-10196-g7939f8823e20c8faed6ce5ac4614c558344a265f
Author: Gerald Pfeifer 
Date:   Sun May 12 15:28:27 2024 +0200

doc: Remove old details on libunwind for ia64-*-hpux*

gcc:
PR target/69374
* doc/install.texi (Specific) : Remove details
on libunwind for GCC 3.4 and earlier.

(cherry picked from commit 81f7965e63028c1289ae3b1836750da74b01bc4a)

[Bug target/112959] install.tex needs updates on FreeBSD

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:

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

commit r14-10195-gcf43da54f876c4b965feaa5f499483b5f16ed269
Author: Gerald Pfeifer 
Date:   Sun Apr 28 14:59:14 2024 +0200

doc: Remove references to FreeBSD 7 and older

FreeBSD 7 has been end of life for years and current GCC most likely
would not build there anymore anyways.

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: Remove references to
FreeBSD 7 and older.

(cherry picked from commit 507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb)

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:

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

commit r14-10195-gcf43da54f876c4b965feaa5f499483b5f16ed269
Author: Gerald Pfeifer 
Date:   Sun Apr 28 14:59:14 2024 +0200

doc: Remove references to FreeBSD 7 and older

FreeBSD 7 has been end of life for years and current GCC most likely
would not build there anymore anyways.

gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: Remove references to
FreeBSD 7 and older.

(cherry picked from commit 507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb)

[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs

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

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #7)
> I happened to do an AIX build on cfarm119 - and looking at this, not sure
> why AIX is failing; although the LTO is handled in a different way in AIX,
> there are actually no instances of "ascii" in the assembler output - so I'd
> have expected it to pass "by accident".

and, indeed, testing on r15-384 on powerpc-ibm-aix7.3.1.0 the test passes.

[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs

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

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

--- Comment #7 from Iain Sandoe  ---
I happened to do an AIX build on cfarm119 - and looking at this, not sure why
AIX is failing; although the LTO is handled in a different way in AIX, there
are actually no instances of "ascii" in the assembler output - so I'd have
expected it to pass "by accident".

[Bug c++/115050] Segfault when compiled with -O0

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

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

--- Comment #1 from Andrew Pinski  ---
Note there is an alignment missing on the data field.

[Bug c++/115050] New: Segfault when compiled with -O0

[lobel.krivic at proton dot me via Gcc-bugs]

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

Bug ID: 115050
   Summary: Segfault when compiled with -O0
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lobel.krivic at proton dot me
  Target Milestone: ---

Created attachment 58183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58183=edit
the preprocessed file

The following source code:
```
#include 
#include 
#include 
#include 

///

class VTable
{
  public:
virtual void func(int x) = 0; // #1 this line affects behavior
virtual ~VTable() = default;
};

template 
class Handler final : public VTable
{
  private:
static constexpr int S = sizeof(void*);
std::byte _data[S];

  public:
template 
Handler(CArgs&&... args) {
static_assert(sizeof(T) <= S);
::new (&_data[0]) T(std::forward(args)...);
}

void func(int) { return; }

~Handler() { static_cast(static_cast(&_data[0]))->~T(); }
};

///

struct FBase
{
static constexpr int S = sizeof(void*) + sizeof(VTable);
std::byte _data[S];

~FBase() {
static_cast(static_cast(&_data[0]))->~VTable(); } // #2 this
line affects behavior
};

struct F : FBase
{
template 
F(T&& t) {
static_assert(sizeof(Handler>) <= S);
::new (&_data[0]) Handler>(std::forward(t));
}

~F() = default;
};

///

struct Testor
{
Testor() = default;
~Testor() = default;

Testor(const Testor& /*unused*/) { throw std::bad_exception(); }
};

///

#include 

int main() {

try {
Testor testor;
F f{testor};
}
catch (const std::bad_exception& e) {
std::cout << " caught! " << e.what() << std::endl;
}

return 0;
}
```

segfaults on runtime when compiled with -O0 but works when compiled with
-O1/O2/O3. This happens on all versions of gcc from 11.1 to 14.1 (clang does
not have this problem). -Wall and -Wextra do not report anything.
Here is the link to the source code: https://godbolt.org/z/5dWKEenMM

The complete command line that triggers the bug:
`g++ -O0 ./bug.cpp -o ./bug.out && ./bug.out`

Bug report that may be related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239


Output of `gcc -v`:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240113-r1/work/gcc-13-20240113/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gn
u --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_
64-pc-linux-gnu/13 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info --with-gxx-include-
dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13 --disable-silent-rules
--disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc
-linux-gnu/13/python --enable-languages=c,c++,fortran --enable-obsolete
--enable-secureplt --disable-werror --with-system-zlib --disable-nls
--disable-l
ibunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
13.2.1_p20240113-r1 p12' --with-gcc-major
-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch
--enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale
=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disa
ble-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --without-zstd --without-isl
--enable-default-pie --
enable-default-ssp --disable-fixincludes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.1 20240113 (Gentoo 13.2.1_p20240113-r1 p12)

[Bug c++/115049] New: Silent severe miscompilation around inline functions

[manx-bugzilla at problemloesungsmaschine dot de via Gcc-bugs]

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

Bug ID: 115049
   Summary: Silent severe miscompilation around inline functions
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manx-bugzilla at problemloesungsmaschine dot de
  Target Milestone: ---

Created attachment 58182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58182=edit
all mentioned attachments

Hello GCC team!


I am seeing severe miscompilation around inline functions with different
results across different translation units, ultimately leading to application
crashes.

I am running
```
$ x86_64-w64-mingw32-g++  --version
x86_64-w64-mingw32-g++.exe (Rev2, Built by MSYS2 project) 14.1.0
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
as shipped by MSYS2, and testing with the MINGW64 toolchain targeting amd64. I
can also reproduce with UCRT64 amd64, but so far not with MINGW32 targeting
x86. This is reproducible locally and on GitHub CI, so no system-specific
problem.

To reproduce, we need 2 translation units:
file1.cpp:
```

#include 

#include 

void Trigger1();

int main( int /*argc*/ , char * /*argv*/ [] ) {
Trigger1();
return 0;
}

static void Trigger2() {
std::ranlux48 prng{1};
std::uint16_t Data1 =
std::uniform_int_distribution{}(prng);
std::uint64_t Data2 =
std::uniform_int_distribution{}(prng);
static_cast(Data1);
static_cast(Data2);
}

using my_dummy_function = void (*)();

struct myDummy3 {
my_dummy_function func{nullptr};
myDummy3(my_dummy_function f)
: func(f)
{
}
};

myDummy3 dummy3{

};

```
file2.cpp:
```

#include 
#include 
#include 
#include 

#include 
#include 

#include 

template 
inline T my_random(std::ranlux48 & rng) {
using unsigned_T = T;
const unsigned int rng_bits = 48;
unsigned_T result = 0;
for (std::size_t entropy = 0; entropy < std::min(required_entropy_bits,
sizeof(T) * 8); entropy += rng_bits) {
if constexpr (rng_bits < (sizeof(T) * 8)) {
unsigned int shift_bits = rng_bits % (sizeof(T) * 8);
//fflush(stdout);  // <--- no crash
result = (result << shift_bits) ^
static_cast(rng());
} else {
result = static_cast(rng());
}
}
if constexpr (required_entropy_bits >= (sizeof(T) * 8)) {
return static_cast(result);
} else {
return static_cast(result & ((static_cast(1) <<
required_entropy_bits) - static_cast(1)));
}
}

class myDummy1 {
private:
std::ranlux48 m_PRNG;
std::uint16_t m_Trigger1a;
public:
myDummy1(std::unique_ptr & rd)
: m_PRNG(std::uniform_int_distribution{}(*rd))
, m_Trigger1a(m_PRNG())
{
}
};

void Trigger1();

void Trigger1() {
{
std::unique_ptr rd =
std::make_unique(1);
myDummy1 dummy1(rd);
}
{
std::ranlux48 * prng = new std::ranlux48(1);
const unsigned int trigger1b_size = 32;
std::vector trigger1b(trigger1b_size, 0);
for (unsigned int i = 0; i < trigger1b_size; i++) {
trigger1b[i] = my_random(*prng);
}
delete prng;
}
{
std::ranlux48 prng{1};
printf("%llu\n", static_cast(my_random(prng))); fflush(stdout);
printf("%llu\n", static_cast(my_random(prng))); fflush(stdout);
printf("%llu\n", static_cast(my_random(prng))); fflush(stdout);  // <--- crash
printf("%llu\n", static_cast(my_random(prng))); fflush(stdout);
}
}

```
and the compilation script:
compile.sh:
```
#!/usr/bin/env bash

x86_64-w64-mingw32-g++ -std=c++20 -fexceptions -frtti -mthreads -O2 -Wall
-Wextra -Wpedantic -DNOMINMAX -c file1.cpp -o file1.o
x86_64-w64-mingw32-g++ -std=c++20 -fexceptions -frtti -mthreads -O2 -Wall
-Wextra -Wpedantic -DNOMINMAX -c file2.cpp -o file2.o
x86_64-w64-mingw32-g++ -std=c++20 -fexceptions -frtti -mthreads -O2 -Wall
-Wextra -Wpedantic -DNOMINMAX -c file2-working.cpp -o file2-working.o

x86_64-w64-mingw32-g++ -std=c++20 -fexceptions -frtti -mthreads -O2 -Wall
-Wextra -Wpedantic -DNOMINMAX file1.o file2.o -latomic -lm -o test-broken.exe
x86_64-w64-mingw32-g++ -std=c++20 -fexceptions -frtti -mthreads -O2 -Wall
-Wextra -Wpedantic -DNOMINMAX file1.o file2-working.o -latomic -lm -o
test-working.exe

cp file1.o file1-trimmed.o
objcopy --remove-section

[Bug tree-optimization/114937] [11 regression] -ftree-vrp optimizes out range check before conditional increment

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Mikael Pettersson  ---
I ran a git bisect between 11.4.0 and 12.3.0, which identified the following as
fixing this test case:

2e96b5f14e4025691b57d2301d71aa6092ed44bc is the first new commit
commit 2e96b5f14e4025691b57d2301d71aa6092ed44bc
Author: Aldy Hernandez 
Date:   Tue Jun 15 12:32:51 2021 +0200

Backwards jump threader rewrite with ranger.

[Bug bootstrap/54179] please split insn-emit.c !

[brjd_epdjq36 at kygur dot com via Gcc-bugs]

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

--- Comment #41 from Brjd  ---
(In reply to Sam James from comment #40)
> That came up at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600#c29.

IMHO keeping the build at RAM<=1GB would be a good benchmark. Keeping these
million-line files might be wrong.I succeed at building it only with -j1. If
j>1, the build simply errors. I read comments that j>1 builds might be bad to
the drives too. If you know other possible ways to reduce RAM, please tell.

[Bug target/106060] Inefficient constant broadcast on x86_64

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||15.0
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Roger Sayle  ---
This has now been fixed on mainline for GCC 15.  There are still improvements
that can be made to vector constant materialization/initialization on x86_64,
but the issues/ideas described in this bugzilla PR are all now implemented. 
Thanks.

[Bug c++/115048] New: warning "operator delete called on pointer '' with nonzero offset"

[urisimchoni at gmail dot com via Gcc-bugs]

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

Bug ID: 115048
   Summary: warning "operator delete called on pointer ''
with nonzero offset"
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urisimchoni at gmail dot com
  Target Milestone: ---

Compiling the following code with gcc 14.1.0 and -O3 yields the warning:

/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/bits/new_allocator.h:172:33:
warning: 'void operator delete(void*, std::size_t)' called on pointer
'' with nonzero offset [1, 2147483647] [-Wfree-nonheap-object]


#include 

std::vector get_vec(int extra)
{
std::vector res;
res.reserve(extra);
res.push_back(7);
return res;
}


See also https://godbolt.org/z/rPr7KEhYa

This does not happen with 13.2.0, and does happen with trunk (according to
compiler explorer)

[Bug gcov-profile/115047] New: Inconsistent MC/DC reported by GCC and LLVM

[wentaoz5 at illinois dot edu via Gcc-bugs]

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

Bug ID: 115047
   Summary: Inconsistent MC/DC reported by GCC and LLVM
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wentaoz5 at illinois dot edu
  Target Milestone: ---

How to reproduce:

$ gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-latest/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-latest --enable-languages=c,c++
--enable-libstdcxx-debug --enable-libstdcxx-backtrace --disable-bootstrap
--disable-multilib --disable-libvtv --with-system-zlib --without-isl
--enable-multiarch
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240421 (experimental) (GCC) 

$ clang -v

Ubuntu clang version 18.1.3
(++20240322073153+ef6d1ec07c69-1~exp1~20240322193300.86)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-18/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ cat > test.c << EOF
void f(int a, int b, int c) { a && b || c; }
int main(void) {
f(0,0,1);
f(1,0,0);
return 0;
}
EOF
$ gcc --coverage -fcondition-coverage test.c -o test
$ ./test
$ gcov --conditions test.c
$ cat test.c.gcov

File 'test.c'
Lines executed:100.00% of 5
Condition outcomes covered:50.00% of 6
Creating 'test.c.gcov'

Lines executed:100.00% of 5
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
2:1:void f(int a, int b, int c) { a && b || c; }
condition outcomes covered 3/6
condition  0 not covered (true false)
condition  1 not covered (true)
1:2:int main(void) {
1:3:f(0,0,1);
1:4:f(1,0,0);
1:5:return 0;
-:6:}

$ clang -Wno-unused-value -fprofile-instr-generate -fcoverage-mapping
-fcoverage-mcdc test.c -o test
$ ./test
$ llvm-profdata merge default.profraw -o default.profdata
$ llvm-cov show --show-mcdc -instr-profile default.profdata test

1|  2|void f(int a, int b, int c) { a && b || c; }
  --
  |---> MC/DC Decision Region (1:31) to (1:42)
  |
  |  Number of Conditions: 3
  | Condition C1 --> (1:31)
  | Condition C2 --> (1:36)
  | Condition C3 --> (1:41)
  |
  |  Executed MC/DC Test Vectors:
  |
  | C1, C2, C3Result
  |  1 { T,  F,  F  = F  }
  |  2 { F,  -,  T  = T  }
  |
  |  C1-Pair: not covered
  |  C2-Pair: not covered
  |  C3-Pair: not covered
  |  MC/DC Coverage for Decision: 0.00%
  |
  --
2|  1|int main(void) {
3|  1|f(0,0,1);
4|  1|f(1,0,0);
5|  1|return 0;
6|  1|}

In this example, gcov believes condition "c" is covered but LLVM reports that
none of the conditions is covered.

[Bug target/114993] ICE when using bpf-unknown-g++

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

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

--- Comment #3 from Marc Poulhiès  ---
The gccrs cross compiler is not working because of the missing cargo/rustc dep,
disabling the frontend, so not a real issue.

[Bug fortran/84006] [11/12/13/14 Regression] ICE in storage_size() with CLASS entity

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[11/12/13/14/15 Regression] |[11/12/13/14 Regression]
   |ICE in storage_size() with  |ICE in storage_size() with
   |CLASS entity|CLASS entity
 CC||pault at gcc dot gnu.org

--- Comment #15 from Paul Thomas  ---
Fixed on mainline. Will backport in a month.

Paul

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Fixed on mainline.

Paul

[Bug fortran/100027] ICE on storage_size with polymorphic argument

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
Fixed on mainline. Thanks for the report and the patch. It's a pity that you
didn't reply to me that you couldn't or wouldn't do the commit :-(

Paul

[Bug fortran/100027] ICE on storage_size with polymorphic argument

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r15-386-gb9294757f82aae8de6d98c122cd4e3b98f685217
Author: Paul Thomas 
Date:   Sun May 12 06:59:45 2024 +0100

Fortran: Unlimited polymorphic intrinsic function arguments [PR84006]

2024-05-12  Paul Thomas  

gcc/fortran
PR fortran/84006
PR fortran/100027
PR fortran/98534
* iresolve.cc (gfc_resolve_transfer): Emit a TODO error for
unlimited polymorphic mold.
* trans-expr.cc (gfc_resize_class_size_with_len): Use the fold
even if a block is not available in which to fix the result.
(trans_class_assignment): Enable correct assignment of
character expressions to unlimited polymorphic variables using
lhs _len field and rse string_length.
* trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract
the class expression so that the unlimited polymorphic class
expression can be used in gfc_resize_class_size_with_len to
obtain the storage size for character payloads. Guard the use
of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC
to prevent the ICE. Also, invert the order to use the class
expression extracted from the argument.
(gfc_conv_intrinsic_transfer): In same way as 'storage_size',
use the _len field to obtaining the correct length for arg 1.
Add a branch for the element size in bytes of class expressions
with provision to make use of the unlimited polymorphic _len
field. Again, the class references are explicitly identified.
'mold_expr' was already declared. Use it instead of 'arg'. Do
not fix 'dest_word_len' for deferred character sources because
reallocation on assign makes use of it before it is assigned.

gcc/testsuite/
PR fortran/84006
PR fortran/100027
* gfortran.dg/storage_size_7.f90: New test.

PR fortran/98534
* gfortran.dg/transfer_class_4.f90: New test.

[Bug fortran/84006] [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r15-386-gb9294757f82aae8de6d98c122cd4e3b98f685217
Author: Paul Thomas 
Date:   Sun May 12 06:59:45 2024 +0100

Fortran: Unlimited polymorphic intrinsic function arguments [PR84006]

2024-05-12  Paul Thomas  

gcc/fortran
PR fortran/84006
PR fortran/100027
PR fortran/98534
* iresolve.cc (gfc_resolve_transfer): Emit a TODO error for
unlimited polymorphic mold.
* trans-expr.cc (gfc_resize_class_size_with_len): Use the fold
even if a block is not available in which to fix the result.
(trans_class_assignment): Enable correct assignment of
character expressions to unlimited polymorphic variables using
lhs _len field and rse string_length.
* trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract
the class expression so that the unlimited polymorphic class
expression can be used in gfc_resize_class_size_with_len to
obtain the storage size for character payloads. Guard the use
of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC
to prevent the ICE. Also, invert the order to use the class
expression extracted from the argument.
(gfc_conv_intrinsic_transfer): In same way as 'storage_size',
use the _len field to obtaining the correct length for arg 1.
Add a branch for the element size in bytes of class expressions
with provision to make use of the unlimited polymorphic _len
field. Again, the class references are explicitly identified.
'mold_expr' was already declared. Use it instead of 'arg'. Do
not fix 'dest_word_len' for deferred character sources because
reallocation on assign makes use of it before it is assigned.

gcc/testsuite/
PR fortran/84006
PR fortran/100027
* gfortran.dg/storage_size_7.f90: New test.

PR fortran/98534
* gfortran.dg/transfer_class_4.f90: New test.

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r15-386-gb9294757f82aae8de6d98c122cd4e3b98f685217
Author: Paul Thomas 
Date:   Sun May 12 06:59:45 2024 +0100

Fortran: Unlimited polymorphic intrinsic function arguments [PR84006]

2024-05-12  Paul Thomas  

gcc/fortran
PR fortran/84006
PR fortran/100027
PR fortran/98534
* iresolve.cc (gfc_resolve_transfer): Emit a TODO error for
unlimited polymorphic mold.
* trans-expr.cc (gfc_resize_class_size_with_len): Use the fold
even if a block is not available in which to fix the result.
(trans_class_assignment): Enable correct assignment of
character expressions to unlimited polymorphic variables using
lhs _len field and rse string_length.
* trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract
the class expression so that the unlimited polymorphic class
expression can be used in gfc_resize_class_size_with_len to
obtain the storage size for character payloads. Guard the use
of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC
to prevent the ICE. Also, invert the order to use the class
expression extracted from the argument.
(gfc_conv_intrinsic_transfer): In same way as 'storage_size',
use the _len field to obtaining the correct length for arg 1.
Add a branch for the element size in bytes of class expressions
with provision to make use of the unlimited polymorphic _len
field. Again, the class references are explicitly identified.
'mold_expr' was already declared. Use it instead of 'arg'. Do
not fix 'dest_word_len' for deferred character sources because
reallocation on assign makes use of it before it is assigned.

gcc/testsuite/
PR fortran/84006
PR fortran/100027
* gfortran.dg/storage_size_7.f90: New test.

PR fortran/98534
* gfortran.dg/transfer_class_4.f90: New test.