[Bug tree-optimization/113583] Main loop in 519.lbm not vectorized.

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #13 from JuzheZhong  ---
Ok. I found the optimized tree:


  _5 = 3.33314829616256247390992939472198486328125e-1 - _4;
  _8 = .FMA (_5, 1.229982236431605997495353221893310546875e-1, _4);

Let CST0 = 3.33314829616256247390992939472198486328125e-1,
CST1 = 1.229982236431605997495353221893310546875e-1

The expression is equivalent to the following:

_5 = CST0 - _4;
_8 = _5 * CST1 + 4;

That is:

_8 = (CST0 - _4) * CST1 + 4;

So, We should be able to re-associate it like Clang:

_8 = CST0 * CST1 - _4 * CST1 + 4; ---> _8 = CST0 * CST1 + _4 * (1 - CST1);

Since both CST0 * CST1 and 1 - CST1 can be pre-computed during compilation
time.

Let say CST2 = CST0 * CST1, CST3 = 1 - CST1, then we can re-associate as Clang:

_8 = FMA (_4, CST3, CST2).

Any suggestions for this re-association ?  Is match.pd the right place to do it
?

Thanks.

[Bug libstdc++/113792] error: '__size_t' was not declared in this scope

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

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

--- Comment #1 from Jonathan Wakely  ---
Using #include definitely won't work, that would just create a cycle between
the libstdc++ versions of stdlib.h and cstdlib, at least for all targets that
don't have stdlib.h in include-fixed.

[Bug tree-optimization/113796] [14 Regression] ifcvt does not remove range info before folding: Runtime mismatch at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv aarch64   |
Summary|[14 Regression] RISC-V  |[14 Regression] ifcvt does
   |rv64gcv vector: Runtime |not remove range info
   |mismatch at -O2 |before folding: Runtime
   ||mismatch at -O2

--- Comment #5 from Andrew Pinski  ---
Here is one that fails on x86_64 too:
```
signed char a[] = {0x80, 0x80,0x80,0x80};
int b;
signed char c;

int main() {
  for (; b < sizeof(a); b += 1)
  c = a[b] < 0 ?: a[b] >> 6;

  if (c == 1)
return 0;
  else
return 1;
}
```

Compile with `-O2 -fno-vect-cost-model` to see the issue.

[Bug tree-optimization/113796] [14 Regression] RISC-V rv64gcv vector: Runtime mismatch at -O2

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> ifcvt needs to something similar to what phiopt did in
> r14-2650-g8c79b49cd4fa74 .

Or ifcvt needs to remove the range info earlier ...
I have not looked into the ifcvt code to see which is the right approach.

But it was introduced by the same commit that introduced PR 110252 (which was
then fixed by the phiopt patch).

[Bug tree-optimization/113796] [14 Regression] RISC-V rv64gcv vector: Runtime mismatch at -O2

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

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

--- Comment #3 from Andrew Pinski  ---
Just an FYI :

[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O2
-static t65.c -march=armv9-a+sve2 -fno-vect-cost-model
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
;echo $?
1
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O2
-static t65.c -march=armv9-a+sve2
[apinski@xeond2 upstream-full-cross]$ ./install-qemu/bin/qemu-aarch64 a.out
;echo $?
0

[Bug tree-optimization/113796] [14 Regression] RISC-V rv64gcv vector: Runtime mismatch at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv   |riscv aarch64

--- Comment #2 from Andrew Pinski  ---
It can be reproduce on aarch64 with `-O2 -fno-vect-cost-model
-march=armv9-a+sve` too so it is at least a regression there too.

[Bug tree-optimization/113796] [14 Regression] RISC-V rv64gcv vector: Runtime mismatch at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110252
   Target Milestone|--- |14.0
Summary|[14] RISC-V rv64gcv vector: |[14 Regression] RISC-V
   |Runtime mismatch at -O2 |rv64gcv vector: Runtime
   ||mismatch at -O2
 CC||pinskia at gcc dot gnu.org
  Component|target  |tree-optimization
   Last reconfirmed||2024-02-07

--- Comment #1 from Andrew Pinski  ---
Confirmed, the issue is in ifcvt.

Before ifcvt we had:
```
  if (_1 >= 0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 563821836]:
  iftmp.1_9 = _1 >> 6;

   [local count: 955630226]:
  # iftmp.1_5 = PHI 
```
Which is fine.

Note the range for _1 is:
```
  # RANGE [irange] signed char [0, 1]
  iftmp.1_9 = _1 >> 6;
```

After ifcvt we get:
```
  iftmp.1_9 = _1 >> 6;
  _25 = _1 < 0;
  _4 = (signed charD.14) _25;
  # RANGE [irange] signed char [0, 1]
  iftmp.1_5 = _4 | iftmp.1_9;
```
Which is incorrect.

ifcvt needs to something similar to what phiopt did in r14-2650-g8c79b49cd4fa74
.

[Bug c/113795] armv8.1m-m.main+pacbti -mbranch-protection=standard -O2 compile error

[keithp at keithp dot com via Gcc-bugs]

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

keithp at keithp dot com  changed:

   What|Removed |Added

Version|13.2.1  |14.0

--- Comment #2 from keithp at keithp dot com  ---
Just reproduced this with version 14.0.1 (debian unstable
arm-linux-gnueabi-gcc-14 package)

[Bug target/113796] New: [14] RISC-V rv64gcv vector: Runtime mismatch at -O2

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 113796
   Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
signed char a[] = {0x80, 0};
int b;
signed char c;

int main() {
  for (; b < 1; b += 1)
  c = a[b] < 0 ?: a[b] >> 6;

  if (c == 1)
return 0;
  else
return 1;
}

Commands:
> /scratch/tc-testing/tc-feb-6/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O2 red.c -o user-config.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true 
> /scratch/tc-testing/tc-feb-6/build-rv64gcv/bin/qemu-riscv64 user-config.out
> echo $?
1

> /scratch/tc-testing/tc-feb-6/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O1 red.c -o user-config.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true 
> /scratch/tc-testing/tc-feb-6/build-rv64gcv/bin/qemu-riscv64 user-config.out
> echo $?
0

Godbolt:
https://godbolt.org/z/c7xrqx7Kz

Tested using r14-8834-gdb5c3f6d952 (not bisected).

Found using fuzzer.

[Bug c/113795] armv8.1m-m.main+pacbti -mbranch-protection=standard -O2 compile error

[keithp at keithp dot com via Gcc-bugs]

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

--- Comment #1 from keithp at keithp dot com  ---
compiler command:

arm-none-eabi-gcc \
-std=c18 \
-O2 \
-mthumb \
-march=armv8.1-m.main+pacbti+fp \
-mbranch-protection=standard \
-o \
bar.s \
-S \
bar.c

[Bug c/113795] New: armv8.1m-m.main+pacbti -mbranch-protection=standard -O2 compile error

[keithp at keithp dot com via Gcc-bugs]

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

Bug ID: 113795
   Summary: armv8.1m-m.main+pacbti -mbranch-protection=standard
-O2 compile error
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keithp at keithp dot com
  Target Milestone: ---

Created attachment 57348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57348=edit
Reasonably short test case.

A tail-call indirect branch is miscompiled in the attached example.

Without -mbranch-protection=standard:
```
.L2:
ldr r4, .L25+4
movsr0, #0
ldr r4, [r4, #24]
mov ip, r4
str r4, [sp, #4]
add sp, sp, #28
@ sp needed
pop {r4, r5, r6, r7, r8, r9, r10, fp, lr}
bx  ip
```
With -mbranch-protection=standard:
```
.L2:
movsr0, #0
ldr r4, .L25+4
ldr r4, [r4, #24]
str r4, [sp, #4]
add sp, sp, #24
@ sp needed
pop {r4, r5, r6, r7, r8, r9, r10, fp, ip, lr}
aut ip, lr, sp
bx  ip
```
Note that in the latter example, the `ip` register doesn't get copied from
`r4`, presumably because `ip` gets clobbered by the PAC operation. That leaves
the indirect branch at the end jumping to a random address.

[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #12 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #10)
> Oh, you mean the pow equality comparison.  I think you should study
> something about floating point, errors, why equality comparisons of floating
> point values are usually a bad idea etc.
> There is no gcc bug, just bad user expectations.

This is why gcc has the -Wfloat-equal warning flag, isn't it?

[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Arthur O'Dwyer  ---
(In reply to Marek Polacek from comment #5)
> IOW, this should be accepted in C++23 but isn't (clang++ accepts in C++23): 
> [...]

Correct, at least that's my intended interpretation. But the unexpected ICE was
more dramatic. :)
I'd be a tiny bit surprised if fixing `decltype(throw p)` actually closes the
only pathway to that ICE; but if it does, then awesome, I have no complaints.

[Bug tree-optimization/113583] Main loop in 519.lbm not vectorized.

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #12 from JuzheZhong  ---
Ok. I found it even without vectorization:

GCC is worse than Clang:

https://godbolt.org/z/addr54Gc6

GCC (14 instructions inside the loop):

fld fa3,0(a0)
fld fa5,8(a0)
fld fa1,16(a0)
fsub.d  fa4,ft2,fa3
addia0,a0,160
fadd.d  fa5,fa5,fa1
addia1,a1,160
addia5,a5,160
fmadd.d fa4,fa4,fa2,fa3
fnmsub.dfa5,fa5,ft1,ft0
fsd fa4,-160(a1)
fld fa4,-152(a0)
fadd.d  fa4,fa4,fa0
fmadd.d fa5,fa5,fa2,fa4
fsd fa5,-160(a5)

Clang (12 instructions inside the loop):

fld fa1, -8(a0)
fld fa0, 0(a0)
fld ft0, 8(a0)
fmadd.d fa1, fa1, fa4, fa5
fsd fa1, 0(a1)
fld fa1, 0(a0)
fadd.d  fa0, ft0, fa0
fmadd.d fa0, fa0, fa2, fa3
fadd.d  fa1, fa0, fa1
add a4, a1, a3
fsd fa1, -376(a4)
addia1, a1, 160
addia0, a0, 160

The critical things is that:

GCC has 

fsub.d  fa4,ft2,fa3
fadd.d  fa5,fa5,fa1
fmadd.d fa4,fa4,fa2,fa3
fnmsub.dfa5,fa5,ft1,ft0
fadd.d  fa4,fa4,fa0
fmadd.d fa5,fa5,fa2,fa4

6 floating-point operations.

Clang has:

fmadd.d fa1, fa1, fa4, fa5
fadd.d  fa0, ft0, fa0
fmadd.d fa0, fa0, fa2, fa3
fadd.d  fa1, fa0, fa1

Clang has 4.

2 more floating-point operations are very critical to the performance I think
since double floating-point operations are usually costly in real hardware.

[Bug tree-optimization/113731] [14 regression] ICE when building libbsd since r14-8768-g85094e2aa6dba7

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

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

Sam James  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #7 from Sam James  ---
*** Bug 113794 has been marked as a duplicate of this bug. ***

[Bug bootstrap/113794] [14 Regression] building the amdgcn-amdhsa offload compiler fails building newlib

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

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
 CC||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
dupe of PR113731 (and PR113771)

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

[Bug bootstrap/113794] New: [14 Regression] building the amdgcn-amdhsa offload compiler fails building newlib

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

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

Bug ID: 113794
   Summary: [14 Regression] building the amdgcn-amdhsa offload
compiler fails building newlib
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20240207, worked with 20240201 at least, building the
amdgcn-amdhsa offload compiler.

newlib fails to build with 

during GIMPLE pass: vect
In file included from ../../../../src-gcn/newlib/libc/string/memset.c:29:
/home/packages/gcc/14/gcc-14-14-20240207/src-gcn/newlib/libc/include/string.h:
In function 'memset':
/home/packages/gcc/14/gcc-14-14-20240207/src-gcn/newlib/libc/include/string.h:33:10:
internal compiler error: Segmentation fault
   33 | void *   memset (void *, int, size_t);
  |  ^~
0xcfa112 crash_signal
../../src-gcn/gcc/toplev.cc:317
0x7b63de9f050f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xf61fab gsi_prev(gimple_stmt_iterator*)
../../src-gcn/gcc/gimple-iterator.h:236
0xf61fab move_early_exit_stmts
../../src-gcn/gcc/tree-vect-loop.cc:11804
0xf61fab vect_transform_loop(_loop_vec_info*, gimple*)
../../src-gcn/gcc/tree-vect-loop.cc:11969
0xf9d8cb vect_transform_loops
../../src-gcn/gcc/tree-vectorizer.cc:1006
0xf9defd try_vectorize_loop_1
../../src-gcn/gcc/tree-vectorizer.cc:1152
0xf9defd try_vectorize_loop
../../src-gcn/gcc/tree-vectorizer.cc:1182
0xf9e374 execute
../../src-gcn/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

The bug is not reproducible, so it is likely a hardware or OS problem.
make[8]: *** [Makefile:26337: libc/string/libc_a-memset.o] Error 1
make[8]: *** Waiting for unfinished jobs

however, retrying the newlib build always fails with this issue

[Bug target/103910] openjdk17 causes ICE on -O3 -march=opteron -fcheck-new: during GIMPLE pass: aprefetch: in gimple_build_call, at gimple.c:267

[alx at kernel dot org via Gcc-bugs]

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

Alejandro Colomar  changed:

   What|Removed |Added

 CC||alx at kernel dot org

--- Comment #13 from Alejandro Colomar  ---
I personally build PCHs in my build systems, as a test that the header files
are self-contained.  It has proved useful to me.  But I could live without it
if you  insist on removing it.  Just a data point.

[Bug target/113766] ICE: in generate_insn, at config/riscv/riscv-vector-builtins.cc:4186 with (invalid?) __riscv_vfredosum_tu()

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-8834-gdb5c3f6d952bc3950d23c0a6be4e8ec9147ef752
Author: Pan Li 
Date:   Tue Feb 6 15:35:02 2024 +0800

RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args

There is one corn case when similar as below example:

void test (void)
{
  __riscv_vfredosum_tu ();
}

It will meet ICE because of the implement details of overloaded function
in gcc.  According to the rvv intrinisc doc, we have no such overloaded
function with empty args.  Unfortunately, we register the empty args
function as overloaded for avoiding conflict.  Thus, there will be actual
one register function after return NULL_TREE back to the middle-end,
and finally result in ICE when expanding.  For example:

1. First we registered void __riscv_vfredmax () as the overloaded function.
2. Then resolve_overloaded_builtin (this func) return NULL_TREE.
3. The functions register in step 1 bypass the args check as empty args.
4. Finally, fall into expand_builtin with empty args and meet ICE.

Here we report error when overloaded function with empty args.  For
example:

test.c: In function 'foo':
test.c:8:3: error: no matching function call to '__riscv_vfredosum_tu' with
empty args
8 |   __riscv_vfredosum_tu();
  |   ^~~~

Below test are passed for this patch.

* The riscv regression tests.

PR target/113766

gcc/ChangeLog:

* config/riscv/riscv-protos.h (resolve_overloaded_builtin): Adjust
the signature of func.
* config/riscv/riscv-c.cc (riscv_resolve_overloaded_builtin):
Ditto.
* config/riscv/riscv-vector-builtins.cc
(resolve_overloaded_builtin): Make
overloaded func with empty args error.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr113766-1.c: New test.
* gcc.target/riscv/rvv/base/pr113766-2.c: New test.

Signed-off-by: Pan Li 

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #18 from Li Pan  ---
Thanks for the confirmation.

Yes, it was before expand. I will prepare one PATCH for this, and it should
target for gcc-15 I bet.

[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102251,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87605

--- Comment #4 from Andrew Pinski  ---
related to PR 87605 and PR 102251

[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #3 from Andrew Pinski  ---
Little more reduced:
```
struct Foo {
  Foo();
  Foo(const Foo &);
  Foo(Foo &&) = delete;
};
Foo &();
void f(const Foo b) {
  true ? b : pp();
}
```

[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input

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

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

--- Comment #1 from Hans-Peter Nilsson  ---
There's a test-suite patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643667.html which is
currently in review-ping limbo.
I'm unassigning myself from this PR.  I won't work on the actual problem,
although I'll keep pinging the testsuite patch - which has merits on its own as
a guard if this PR is accidentally fixed, which is actually expected given the
nature of the underlying bug.

[Bug fortran/113793] New: malloc abort on character allocate with source argument

[manfred99 at gmx dot ch via Gcc-bugs]

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

Bug ID: 113793
   Summary: malloc abort on character allocate with source
argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manfred99 at gmx dot ch
  Target Milestone: ---

Allocating an allocatable character array, I get a malloc error
when the source argument is not properly padded:

  CHARACTER*30,allocatable :: a(:),b(:)
  ALLOCATE(a(100),source=" ")
  ALLOCATE(b(100),source=" ")
  END

yields:
malloc(): corrupted top size


When doing a lame indirection:
  CHARACTER*30,allocatable :: a(:),b(:)
  CHARACTER*30 :: c=" "
  ALLOCATE(a(100),source=c)
  ALLOCATE(b(100),source=c)
  END

everything is fine.
I don't know whether this is mandated by the standard, but the error
message is not very user friendly and hard to grasp.

I would have expected that the source argument is automatically padded
as with variable assignments and function call arguments.

[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

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

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

--- Comment #5 from Marek Polacek  ---
IOW, this should be accepted in C++23 but isn't (clang++ accepts in C++23):

struct AutoPtr {
AutoPtr() = default;
AutoPtr(AutoPtr&) {}
};

template auto f(T p, int) -> decltype(throw p, 1) = delete;
template void f(T p, long);

void
g ()
{
  f (AutoPtr (), 42);
}

[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

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

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

--- Comment #4 from Marek Polacek  ---
Um, that's not it.  Since

struct AutoPtr {
AutoPtr() = default;
AutoPtr(AutoPtr&) {}
};

template int
f (T p)
{
  throw p;
}

void
g ()
{
  f (AutoPtr ());
}

is rejected in C++23, we probably should have rejected the decltype(throw p, 1)
candidate and never get to the throw in the body of the function f.

[Bug libstdc++/113792] New: error: '__size_t' was not declared in this scope

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

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

Bug ID: 113792
   Summary: error: '__size_t' was not declared in this scope
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

I enabled building rust on hppa64-hp-hpux11.11 and hit this error:

/home/dave/gnu/gcc/objdir64/./prev-gcc/x
g++ -B/home/dave/gnu/gcc/objdir64/./prev-gcc/
-B/opt/gnu64/gcc/gcc-14/hppa64-hp-
hpux11.11/bin/ -nostdinc++
-B/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.1
1/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/
libstdc++-v3/libsupc++/.libs  -isystem
/home/dave/gnu/gcc/objdir64/prev-hppa64-h
p-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11  -isystem
/home/dave/gnu/gc
c/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/include  -isystem
/home/dave/gn
u/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hp
ux11.11/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux
11.11/libstdc++-v3/libsupc++/.libs -g -O2 -fno-checking   -c -o punct.o
../../..
/gcc/libgrust/libproc_macro_internal/punct.cc
In file included from
/home/dave/gnu/gcc/gcc-trunk/libstdc++-v3/include/c_global
/cstdlib:79,
 from ../../../gcc/libgrust/libproc_macro_internal/punct.cc:24:
/usr/include/stdlib.h:349:25: error: '__size_t' was not declared in this scope;
did you mean '__site_t'?
  349 | extern void *valloc(__size_t);
  | ^~~~
  | __site_t
make[4]: *** [: punct.o] Error 1
make[4]: Leaving directory
'/home/dave/gnu/gcc/objdir64/libgrust/libproc_macro_internal'
make[3]: *** [Makefile:421: all-recursive] Error 1

This is an #include_next problem.  We have the following in cstdlib:
// Need to ensure this finds the C library's  not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

stdlib.h is fixed on this target.  The #include_next pulled stdlib.h
from /usr/include instead of ./prev-gcc/include-fixed/stdlib.h.

Maybe the fix is to just use #include but I'm not sure.

There are a couple of other places which define
_GLIBCXX_INCLUDE_NEXT_C_HEADERS.

[Bug ipa/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

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

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

--- Comment #25 from Andrew Pinski  ---
PK_FinalTemplate constructor is doing:
this->AccessKey()

Where AccessKey is virtual function.

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #10)
> As discussed on IRC, probably the
> if (!__builtin_mul_overflow(__l._M_lo, __x, &__lo))
> optimization isn't a good idea, because most likely the compiler will in
> that case
> expand that to a full 64x64->128 multiplication plus testing that the upper
> 64 bits are or aren't zero, so computing everything this function needs and
> doing it again if there is overflow, without possibility to query what it
> computed.

Though, if it is common enough, one could try to optimize the __ll[0] == 0 &&
__xx[0] == 0 case, one can do then either 32x32->64 or 64x64->64 multiplication
and be done with it.  But if it is rare in random's usage, it would just make
the code larger.

[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

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

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

--- Comment #17 from Tamar Christina  ---
(In reply to Li Pan from comment #16)
> I have a try like below and finally have the Standard Name "SAT_ADD". Could
> you please help to double-check if my understanding is correct?
> 
> Given below example code below:
> 
> typedef unsigned int uint32_t;
> 
> uint32_t
> sat_add (uint32_t x, uint32_t y)
> {
>   return (x + y) | - ((x + y) < x);
> }
> 
> And then add one simpify to match.pd and define new DEF_INTERNAL_OPTAB_FN
> for it. Then we have the SAT_ADD representation after expand.
> 
> uint32_t sat_add (uint32_t x, uint32_t y)
> {
>   uint32_t _6;
> 
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _6 = .SAT_ADD (x_4(D), y_5(D)); [tail call]
>   return _6;
> ;;succ:   EXIT
> 
> }
> 
> If everything goes well, I will prepare the patch for it later. Thanks.

Yeah that's looks right, I assume above you mean before expand?

I believe saturating add is commutative but not associative, so you'd want to
add it to commutative_binary_fn_p in internal-fn.cc.

You may also want to provide some basic optimizations for it in match.pd such
as  .SAT_ADD (a, 0) = a. etc.

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
As discussed on IRC, probably the
if (!__builtin_mul_overflow(__l._M_lo, __x, &__lo))
optimization isn't a good idea, because most likely the compiler will in that
case
expand that to a full 64x64->128 multiplication plus testing that the upper 64
bits are or aren't zero, so computing everything this function needs and doing
it again if there is overflow, without possibility to query what it computed.

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #9 from Jonathan Wakely  ---
Oops yes!

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #8 from Jakub Jelinek  ---
if (!__l._M_hi)
  {
__l._M_lo %= __m;
return __l;
  }
auto __n = __l._M_hi ? __builtin_clzll(__l._M_hi)
   : 64 + __builtin_clzll(__l._M_lo);
So, on the __n initializer you already know that __l._M_hi is non-zero, no need
to test it again.  Sure, the compiler will optimize it, but the shorter the
method in the header the better.

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #57346|0   |1
is obsolete||

--- Comment #7 from Jonathan Wakely  ---
Created attachment 57347
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57347=edit
With Jakub's suggested changes

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
   |a/show_bug.cgi?id=106057|a/show_bug.cgi?id=101839

--- Comment #24 from Andrew Pinski  ---
Sorry I meant to link to PR 101839 instead. The commit for it has the wrong bug
#  in it :).

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #4)
> Why not just
> __l._M_hi += __builtin_uaddll_overflow(__l._M_lo, __c,
> &__l._M_lo);
> and similarly for subtraction?

No good reason - I'll change it.

> Is the reason for using the clang compat builtins instead of
> __builtin_{add,sub,mul}_overflow the compatibility with clang versions which
> don't
> support these?

Again, no reason, I was just using the ones specific to the type because all
the types are fixed.

Thanks for the suggestions.

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #57345|0   |1
is obsolete||

--- Comment #5 from Jonathan Wakely  ---
Created attachment 57346
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57346=edit
Improved operator%

[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-reduction |rejects-valid

--- Comment #2 from Marek Polacek  ---
template  struct remove_reference;
template  struct remove_reference<_Tp &> {
  typedef _Tp type;
};
template  typename remove_reference<_Tp>::type &(_Tp &&);
template  struct pair {
  _T2 second;
};
struct Foo {
  Foo();
  Foo(const Foo &);
  Foo(Foo &&) = delete;
};
struct _Node_const_iterator {
  const pair *operator->();
};
template  struct unordered_map {
  _Node_const_iterator find(int);
};
bool b;
template  class Map, typename... Args>
void getMapEntry(Map map, int key, Foo defval) {
  auto i = map.find(key);
  b ? i->second : move(defval);
}
int main() {
  unordered_map map;
  getMapEntry(map, 3, {});
}

[Bug c++/113788] Deducing this is broken with structured binding

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/113788] Deducing this is broken with structured binding

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:40485378ade83102d7aa30c317f5d6c90c1d232b

commit r14-8832-g40485378ade83102d7aa30c317f5d6c90c1d232b
Author: Jakub Jelinek 
Date:   Tue Feb 6 22:34:55 2024 +0100

c++: Disallow this specifier except for parameter declarations [PR113788]

The deducing this patchset added parsing of this specifier to
cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar
this[opt] only appears in the parameter-declaration non-terminal, so
rather than checking in all the callers of cp_parser_decl_specifier_seq
except for cp_parser_parameter_declaration that this specifier didn't
appear I think it is far easier and closer to what the standard says
to only parse this specifier when called from
cp_parser_parameter_declaration.

2024-02-06  Jakub Jelinek  

PR c++/113788
* parser.cc (CP_PARSER_FLAGS_PARAMETER): New enumerator.
(cp_parser_decl_specifier_seq): Parse RID_THIS only if
CP_PARSER_FLAGS_PARAMETER is set in flags.
(cp_parser_parameter_declaration): Or in CP_PARSER_FLAGS_PARAMETER
when calling cp_parser_decl_specifier_seq.

* g++.dg/parse/pr113788.C: New test.

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #1)
> Created attachment 57345 [details]
> Use 64-bit integers to do 128-bit arithmetic
> 
> This patch defines a custom type that implements the necessary 128-bit
> arithmetic for linear_congruential_engine without __int128.
> 
> It's an order of magnitude slower than using __int128 natively on x86_64,
> but it gives the right results.

if (__builtin_uaddll_overflow(__l._M_lo, __c, &__l._M_lo))
  __l._M_hi++;

Why not just
__l._M_hi += __builtin_uaddll_overflow(__l._M_lo, __c, &__l._M_lo);
and similarly for subtraction?
Is the reason for using the clang compat builtins instead of
__builtin_{add,sub,mul}_overflow the compatibility with clang versions which
don't
support these?

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #3 from Jonathan Wakely  ---
Based on that, I'm not sure what libc++ does is actually better than what
libstdc++ does today (i.e. refuse to compile if the results would be wrong).

I think the patch above would make sense though. I'm sure it could be
optimized, I was more concerned with getting the results right than with
performance.

The first loop in operator% could just be a single left shift by the difference
in the number of leading zeros between __l and __x. And halve() should just be
a right shift (and "halve" isn't a reserved name).

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Lewis Fox from comment #0)
> libc++'s
> implementation of linear_congruential_engine (though libc++ incorrectly uses
> Schrage's method).

I haven't checked what libc++ actually does, but it gives consistent results
for -m32 and -m64. However, apart from the first one, its results don't match
what libstdc++'s.

Libstdc++ and Boost give the same results:

864691128455147579
20120904253298372
499698276788149646
1283859513473858339
2211358525164835637
1565794316594927048
433037752037085551
3876224293909804757
842334705173512733
614226679431558764
3068544072891686009
780734117187050918
1963664848033545542
3791874062716605653
38634810437006
1377239172204792920
1808622055437870614
464217244571328665
2604268511046649463
2831603438105397950
3223716036697852745
784694016100218461
1453099037541982349
2259076772827085306
2590915097279144408
3831773502251465123
320081643915990134
2376324005742734684
2037587339862127157
893313058057432898
118956510249458009
973816490706440657
2982490375421836301
1236945357523402079
3905294429470053119
2304284986302062495
2454379621599061616
1553811809817066890
2904663527490058979
2904663527490058979
2904663527490058979
2904663527490058979
2904663527490058979
2904663527490058979
2904663527490058979
etc.

Libc++ gets stuck  oscillating between two values right away:

864691128455147579
1965622972376959002
4035225266123976763
1965622972376959002
4035225266123976763
1965622972376959002
4035225266123976763
1965622972376959002
4035225266123976763
1965622972376959002
4035225266123976763
1965622972376959002
4035225266123976763
1965622972376959002

[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available

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

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

--- Comment #1 from Jonathan Wakely  ---
Created attachment 57345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57345=edit
Use 64-bit integers to do 128-bit arithmetic

This patch defines a custom type that implements the necessary 128-bit
arithmetic for linear_congruential_engine without __int128.

It's an order of magnitude slower than using __int128 natively on x86_64, but
it gives the right results.

[Bug c++/113791] Incorrect handling of lvalue to rvalue conversion in ternary operator

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||needs-reduction
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-02-06

--- Comment #1 from Marek Polacek  ---
Confirmed.  Not a regression AFAICS.

[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

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

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

--- Comment #3 from Marek Polacek  ---
I have a patch for the ICE (build_throw doesn't have a complain param so we
wind up with "error reporting routines re-entered").

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

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

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

--- Comment #23 from Andrew Pinski  ---
This might be a divirtualization issue.

[Bug c++/113791] New: Incorrect handling of lvalue to rvalue conversion in ternary operator

[Mark_B53 at yahoo dot com via Gcc-bugs]

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

Bug ID: 113791
   Summary: Incorrect handling of lvalue to rvalue conversion in
ternary operator
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Mark_B53 at yahoo dot com
  Target Milestone: ---

#include 
#include 

template class Map, typename Key, typename T,
typename KeyP, typename... Args>
T getMapEntry(const Map& map, const KeyP& key, T&& defval) {
static_assert(std::is_convertible_v);
auto i = map.find(key);
return i != map.end() ? i->second : std::move(defval);
}

class Foo {
public:
Foo() { std::cout << __PRETTY_FUNCTION__ << '\n'; }
~Foo() { std::cout << __PRETTY_FUNCTION__ << '\n'; }
Foo(const Foo&) { std::cout << __PRETTY_FUNCTION__ << '\n'; }
Foo& operator=(const Foo&) { std::cout << __PRETTY_FUNCTION__ << '\n';
return *this; }
Foo(Foo&&) { std::cout << __PRETTY_FUNCTION__ << '\n'; }
Foo& operator=(Foo&&) { std::cout << __PRETTY_FUNCTION__ << '\n'; return
*this; }
};

int main() {
std::unordered_map map;
auto&& ret = getMapEntry(map, 123U, Foo{});
return 0;
}

GCC outputs:
Foo::Foo()
Foo::Foo(Foo&&)
Foo::~Foo()
Foo::~Foo()

Correct output:
Foo::Foo()
Foo::Foo(const Foo &)
Foo::~Foo()
Foo::~Foo()

Posted on https://stackoverflow.com/questions/77948860/

Maybe related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87605

[Bug rtl-optimization/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it

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

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

--- Comment #22 from Jonathan Wakely  ---
Created attachment 57344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57344=edit
Gzipped preprocessed source

With -O2 -fsantiize=unreachable this prints an error:

pubkey.h:2209:32: runtime error: execution reached an unreachable program point

That happens from the constructor at validat9.cpp:455 

#0 
CryptoPP::PK_FinalTemplate,
CryptoPP::DL_Algorithm_ECGDSA,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1, int>,
CryptoPP::DL_Keys_ECGDSA,
CryptoPP::DL_Algorithm_ECGDSA,
CryptoPP::DL_SignatureMessageEncodingMethod_DSA, CryptoPP::SHA1> >
>::PK_FinalTemplate (algorithm=..., this=0x7fffc7d0) at
/tmp/cryptopp/cryptlib.h:2626
#1  CryptoPP::Test::ValidateECGDSA (thorough=thorough@entry=true) at
validat9.cpp:455
#2  0x0043448f in CryptoPP::Test::Validate (alg=,
thorough=thorough@entry=true) at test.cpp:995
#3  0x0043a303 in CryptoPP::Test::scoped_main (argc=3,
argv=0x7fffd6b8) at test.cpp:401
#4  0x0043aaf3 in main (argc=, argv=) at
test.cpp:1094


I don't see anything obviously wrong with the code.

[Bug target/113790] New: [14 Regression][riscv64] ICE in curr_insn_transform, at lra-constraints.cc:4294 since r14-4944-gf55cdce3f8dd85

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113790
   Summary: [14 Regression][riscv64] ICE in curr_insn_transform,
at lra-constraints.cc:4294 since
r14-4944-gf55cdce3f8dd85
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: vmakarov at redhat dot com
  Target Milestone: ---
Target: riscv64

Compiling testcase gcc.c-torture/compile/20120727-2.c results in ICE since
r14-4944-gf55cdce3f8dd85.

$ cat 20120727-2.c
/* { dg-options "-mfpmath=387" { target { i?86-*-* x86_64-*-* } } } */

union {
  char *p;
  double d;
} u;

void
f (void)
{
  u.p = "";
  u.d += 1.1;
}


$ riscv64-linux-gnu-gcc 20120727-2.c -mno-explicit-relocs
-fno-omit-frame-pointer -Oz
20120727-2.c: In function ‘f’:
20120727-2.c:13:1: error: unable to generate reloads for:
   13 | }
  | ^
(insn 20 19 21 2 (set (mem/c:DI (plus:DI (reg/f:DI 65 frame)
(const_int -24 [0xffe8])) [4 %sfp+-8 S8 A64])
(reg:DI 143 [142])) "20120727-2.c":12:7 208 {*movdi_64bit}
 (expr_list:REG_DEAD (reg:DI 143 [142])
(nil)))
during RTL pass: reload
20120727-2.c:13:1: internal compiler error: in curr_insn_transform, at
lra-constraints.cc:4234
0x19851c4 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x1785645 curr_insn_transform
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:4234
0x17898ab lra_constraints(bool)
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:5432
0x17722e0 lra(_IO_FILE*, int)
/home/mjires/git/GCC/master/gcc/lra.cc:2442
0x171b25b do_reload
/home/mjires/git/GCC/master/gcc/ira.cc:5973
0x171b73c execute
/home/mjires/git/GCC/master/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ riscv64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=riscv64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/riscv64-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=riscv64-linux-gnu
--disable-bootstrap --enable-languages=c,c++ --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=riscv64-linux-gnu --disable-bootstrap --disable-multilib
--disable-libsanitizer --enable-checking target_alias=riscv64-linux-gnu
--enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240206 (experimental) (GCC)

[Bug driver/81358] libatomic not automatically linked with C11 code

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

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jeffrey Walton from comment #13)
> Add a mee too. When using sanitizers, like -fsanitize=undefined, the
> compiler driver is not adding the necessary libraries to link the program.

That's a rather vague claim. Which libraries are missing? Just libatomic?

[Bug target/113689] [11/12/13/14 Regression] wrong code with -fprofile -mcmodel=large when needing drap register since r11-6548

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

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

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

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

commit r14-8831-gf2a060820c24724bb48ee006d257c449e4d94b72
Author: H.J. Lu 
Date:   Tue Feb 6 10:57:24 2024 -0800

x86-64: Return 10_REG if there is no scratch register

If we can't find a scratch register for large model profiling, return
R10_REG.

PR target/113689
* config/i386/i386.cc (x86_64_select_profile_regnum): Return
R10_REG after sorry.

[Bug target/113689] [11/12/13/14 Regression] wrong code with -fprofile -mcmodel=large when needing drap register since r11-6548

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

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

--- Comment #11 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #10)
> 
> Just the second hunk.  I think with sorry call the compilation fails, so what
> you actually emit doesn't matter (one can see it with -pipe, sure).

Done.

[Bug target/113689] [11/12/13/14 Regression] wrong code with -fprofile -mcmodel=large when needing drap register since r11-6548

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

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #9)
> Like this?
> 
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index f02c6c02ac6..ed0b0e19985 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -22785,10 +22785,10 @@ x86_64_select_profile_regnum (bool r11_ok
> ATTRIBUTE_UNUSED)
>   && !REGNO_REG_SET_P (reg_live, i
>return i;
>  
> -  sorry ("no register available for profiling %<-mcmodel=large%s%>",
> +  sorry ("no register available for profiling %<-mcmodel=large%s%>, use
> r10",
> ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");
>  
> -  return INVALID_REGNUM;
> +  return R10_REG;
>  }
>  
>  /* Output assembler code to FILE to increment profiler label # LABELNO

Just the second hunk.  I think with sorry call the compilation fails, so what
you actually emit doesn't matter (one can see it with -pipe, sure).

[Bug target/113689] [11/12/13/14 Regression] wrong code with -fprofile -mcmodel=large when needing drap register since r11-6548

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

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

--- Comment #9 from H.J. Lu  ---
Like this?

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index f02c6c02ac6..ed0b0e19985 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -22785,10 +22785,10 @@ x86_64_select_profile_regnum (bool r11_ok
ATTRIBUTE_UNUSED)
  && !REGNO_REG_SET_P (reg_live, i
   return i;

-  sorry ("no register available for profiling %<-mcmodel=large%s%>",
+  sorry ("no register available for profiling %<-mcmodel=large%s%>, use r10",
ix86_cmodel == CM_LARGE_PIC ? " -fPIC" : "");

-  return INVALID_REGNUM;
+  return R10_REG;
 }

 /* Output assembler code to FILE to increment profiler label # LABELNO

[Bug target/113689] [11/12/13/14 Regression] wrong code with -fprofile -mcmodel=large when needing drap register since r11-6548

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Rainer Orth from comment #7)
> This patch broke Solaris/x86 (i386-pc-solaris2.11) bootstrap:
> 
> /vol/gcc/src/hg/master/local/gcc/config/i386/i386.cc: In function 'void
> x86_function_profiler(std::FILE*, int)':
> /vol/gcc/src/hg/master/local/gcc/config/i386/i386.cc:22838:40: error: array
> subscript -1 is below array bounds of 'const char* const [92]'
> [-Werror=array-bounds=]
> 22838 |   reg = hi_reg_name[scratch];
>   | ~~~^c-include=/vol/gcc/include
> /vol/gcc/src/hg/master/local/gcc/config/i386/i386.cc:138:26: note: while
> referencing 'hi_reg_name'  
> --with-target-bdw-gc-lib=/vol/gcc/lib,amd64=/vo  138 | static const char
> *const hi_reg_name[] = HI_REGISTER_NAMES;
>   |  ^~~

Guess for the case where we issue sorry we shouldn't return INVALID_REGNUM, but
R10_REG or any other, we acknowledged we aren't emitting correct assembly
already.

And, as I wrote earlier, I think if we did similar discovery at
pro_and_epilogue time and find we otherwise wouldn't have any registers for it
and would sorry at final time, it might be better to just pick some call used
register and forcibly save it even when it isn't strictly needed.  Then it
wouldn't sorry at final time anymore.

[Bug target/113689] [11/12/13/14 Regression] wrong code with -fprofile -mcmodel=large when needing drap register since r11-6548

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
This patch broke Solaris/x86 (i386-pc-solaris2.11) bootstrap:

/vol/gcc/src/hg/master/local/gcc/config/i386/i386.cc: In function 'void
x86_function_profiler(std::FILE*, int)':
/vol/gcc/src/hg/master/local/gcc/config/i386/i386.cc:22838:40: error: array
subscript -1 is below array bounds of 'const char* const [92]'
[-Werror=array-bounds=]
22838 |   reg = hi_reg_name[scratch];
  | ~~~^c-include=/vol/gcc/include
/vol/gcc/src/hg/master/local/gcc/config/i386/i386.cc:138:26: note: while
referencing 'hi_reg_name'  
--with-target-bdw-gc-lib=/vol/gcc/lib,amd64=/vo  138 | static const char *const
hi_reg_name[] = HI_REGISTER_NAMES;
  |  ^~~

[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #3)
> Unfortunately, it regresses a bit, say pr101026.f for example can be
> simplified to this:
> 
>   SUBROUTINE PASSB4 (CC,CH)
>   DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
>   END
> 
> which gives:
> 
> pr101026.f:4:19:
> 
> 4 |   DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
>   |   1
> Error: Variable ‘ido’ cannot appear in the expression at (1)
> pr101026.f:4:33:
> 
> 4 |   DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
>   | 1
> Error: Variable ‘ido’ cannot appear in the expression at (1)
> pr101026.f:4:25:
> 
> 4 |   DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
>   | 1
> Error: Variable ‘l1’ cannot appear in the expression at (1)
> pr101026.f:4:37:
> 
> 4 |   DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
>   | 1
> Error: Variable ‘l1’ cannot appear in the expression at (1)
> 
> 
> What I don't see is what makes the IDO and L1 variables acceptable in a
> specification expression.  It seems to me the errors above are valid.

FWIW, NAG and Intel agree with you.  With the original pr101026.f I get:

NAG:

Error: pr101026.f, line 4: IDO is not permitted in a specification expression
Error: pr101026.f, line 4: L1 is not permitted in a specification expression
Error: pr101026.f, line 4: IDO is not permitted in a specification expression
Error: pr101026.f, line 4: L1 is not permitted in a specification expression

Intel:

pr101026.f(4): error #6219: This variable, used in a specification expression,
must be a dummy argument, a COMMON block object, or an object accessible
through host or use association.   [IDO]
  DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
---^
pr101026.f(4): error #6219: This variable, used in a specification expression,
must be a dummy argument, a COMMON block object, or an object accessible
through host or use association.   [L1]
  DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
-^


Thus I suggest to fix the testcase by one of the options suggested above.

[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|ICE on P2266/C++23  |[13/14 Regression] ICE on
   |`decltype(throw x)` where x |P2266/C++23 `decltype(throw
   |is move-eligible parameter  |x)` where x is
   ||move-eligible parameter
   Target Milestone|--- |13.3
   Priority|P3  |P2

[Bug c++/113789] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-06
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Started with r13-2905

commit 772d532e0ba1e4b22c2b7d576e14b34ee929c093
Author: Marek Polacek 
Date:   Wed Aug 31 17:37:59 2022 -0400

c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

so mine.

[Bug c++/113789] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
>GCC 12 generates a call to `f(T, int)`. GCC 13 crashes with this output

THis is because the paper was not implemented before GCC 13; see the linked bug
reports for that.

[Bug c++/101165] [C++23] P2266R1 - Simpler implicit move

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/106882] passing X as 'this' argument discards qualifiers

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7

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

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

--- Comment #6 from Tamar Christina  ---
The reason for the miscompile popping up is this change from the previous patch

diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 109d4ce5192..df3eab2e8d5 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -725,8 +725,7 @@ vect_analyze_early_break_dependences (loop_vec_info
loop_vinfo)
 bounded by VF so accesses are within range.  We only need to check
the
 reads since writes are moved to a safe place where if we get there
we
 know they are safe to perform.  */
- if (DR_IS_READ (dr_ref)
- && !ref_within_array_bound (stmt, DR_REF (dr_ref)))
+ if (!ref_within_array_bound (stmt, DR_REF (dr_ref)))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,

but this should have bee safe, as the stores shouldn't be done until the point
we know for sure they would be safe to do.

the code out of the vectorizer looks ok to me.  Valgrind is saying we're
reading uninitialized values.  But those values I think come from a previous
look which sets them to 0. Or is supposed to.  So working my way up this giant
function.

[Bug c++/113789] New: ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 113789
   Summary: ICE on P2266/C++23 `decltype(throw x)` where x is
move-eligible parameter
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

P2266 "Simpler Implicit Move", adopted for C++23, intends that a move-eligible
`x` should be treated as an xvalue in the context of `throw x`. This means that
`throw x` should be ill-formed (SFINAE-friendly) when `x` isn't
move-constructible.

(This might be complicated by the GCC+Clang extension that permits move-only
types to be thrown even though the paper Standard technically prohibits that.)

That is, the test program in this blog post is expected to pass after P2266:
https://quuxplusone.github.io/blog/2021/03/18/sfinae-on-throw-x/#here-is-a-program-that-uses-sfin
Clang passes; GCC fails; MSVC and EDG don't seem to implement P2266 `throw`
yet.

But the real problem for GCC is that if you then use `throw x` inside the
function body after using `decltype(throw x)` in the function's return type,
the compiler ICEs!


// https://godbolt.org/z/YG16hE7zT
struct AutoPtr {
AutoPtr() = default;
AutoPtr(AutoPtr&) {}
};
template auto f(T p, int) -> decltype(throw p, 1) { throw p; }
template int f(T p, long) { return 2; }
int main() {
return f(AutoPtr(), 42);
}


The expected behavior (and Clang's behavior) is to call `f(T, long)`. GCC 12
generates a call to `f(T, int)`. GCC 13 crashes with this output (including
that leading single-quote):
'
internal compiler error: error reporting routines re-entered.
0x2648345 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x26494c5 error_at(unsigned int, char const*, ...)
???:0
0xa7d834 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xa7eb5b build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xb685e4 build_throw(unsigned int, tree_node*)
???:0
0xc95e47 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x267035c pp_format(pretty_printer*, text_info*, urlifier const*)
???:0
0x2673055 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x26481ca diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x26494c5 error_at(unsigned int, char const*, ...)
???:0
0xa7d834 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xa7eb5b build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xb685e4 build_throw(unsigned int, tree_node*)
???:0
0xc8b5c3 instantiate_decl(tree_node*, bool, bool)
???:0
0xcb56cb instantiate_pending_templates(int)
???:0
0xb54d39 c_parse_final_cleanups()
???:0
0xda8358 c_common_parse_file()
???:0

[Bug c++/113788] Deducing this is broken with structured binding

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 57343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57343=edit
gcc14-pr113788.patch

So far very lightly tested patch (just dg.exp='pr113788.C explicit-obj*.C').

[Bug tree-optimization/113678] SLP misses up vec_concat

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

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

--- Comment #3 from Andrew Pinski  ---
Note the SLP that happens in connection with the loop vectorizer actually does
a decent job ...

[Bug c++/113788] Deducing this is broken with structured binding

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Yeah, given that this[opt] is not in the grammar as declaration specifier but
only in parameter-declaration, I'd go with:
--- parser.cc.jj2   2024-01-17 10:34:45.337660930 +0100
+++ parser.cc   2024-02-06 18:31:35.587193903 +0100
@@ -2088,7 +2088,9 @@ enum
   /* When parsing of the noexcept-specifier should be delayed.  */
   CP_PARSER_FLAGS_DELAY_NOEXCEPT = 0x40,
   /* When parsing a consteval declarator.  */
-  CP_PARSER_FLAGS_CONSTEVAL = 0x80
+  CP_PARSER_FLAGS_CONSTEVAL = 0x80,
+  /* When parsing a parameter declaration.  */
+  CP_PARSER_FLAGS_PARAMETER = 0x100
 };

 /* This type is used for parameters and variables which hold
@@ -16342,7 +16344,7 @@ cp_parser_decl_specifier_seq (cp_parser*
   /* Special case for "this" specifier, indicating a parm is an xobj parm.
 The "this" specifier must be the first specifier in the declaration,
 after any attributes.  */
-  if (token->keyword == RID_THIS)
+  if (token->keyword == RID_THIS && (flags & CP_PARSER_FLAGS_PARAMETER))
{
  cp_lexer_consume_token (parser->lexer);
  if (token != first_specifier)
@@ -25607,7 +25609,7 @@ cp_parser_parameter_declaration (cp_pars
   /* Parse the declaration-specifiers.  */
   cp_token *decl_spec_token_start = cp_lexer_peek_token (parser->lexer);
   cp_parser_decl_specifier_seq (parser,
-   flags,
+   flags | CP_PARSER_FLAGS_PARAMETER,
_specifiers,
_class_or_enum);

[Bug c++/113788] Deducing this is broken with structured binding

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

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

--- Comment #2 from Marek Polacek  ---
Yes, seems that currently we only check that it's the first specifier:

  /* Special case for "this" specifier, indicating a parm is an xobj parm.
 The "this" specifier must be the first specifier in the declaration,
 after any attributes.  */
  if (token->keyword == RID_THIS)
{ 
  cp_lexer_consume_token (parser->lexer);
  if (token != first_specifier)

but I guess we should also check we're processing a parameter-declaration.

[Bug c++/113788] Deducing this is broken with structured binding

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

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

--- Comment #1 from Jakub Jelinek  ---
Seems it is far more cases where we allow it:
struct S { int a, b; };
struct U {
  void foo () { this int g = 1; }
};
this auto h = 1;

int
main ()
{
  S s = { 1, 2 };
  short t[3] = { 3, 4, 5 };
  this auto &[a, b] = s;
  this auto &[c, d, e] = t;
  this int f = 1;
  for (this auto  : t)
;
}

[Bug tree-optimization/113678] SLP misses up vec_concat

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

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

--- Comment #2 from Andrew Pinski  ---
Noticed the same with:
```
void f(unsigned char *a, unsigned char *b, unsigned char *c)
{
  unsigned char t[8];
  t[0] = a[0];
  t[1] = a[1];
  t[2] = a[2];
  t[3] = a[3];
  t[4] = b[0];
  t[5] = b[1];
  t[6] = b[2];
  t[7] = b[3];
  c[0] = t[0];
  c[1] = t[1];
  c[2] = t[2];
  c[3] = t[3];
  c[4] = t[4];
  c[5] = t[5];
  c[6] = t[6];
  c[7] = t[7];
}

```

Adding `-fno-tree-vectorize` gives the best code even.

[Bug c++/113788] Deducing this is broken with structured binding

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

[Bug tree-optimization/113677] Missing `VEC_PERM_EXPR <{a, CST}, CST, {0, 1, 2, ...}>` optimization

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

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

--- Comment #4 from Andrew Pinski  ---
Note it is not just about constants either.
Take:
```
#define vect64 __attribute__((vector_size(8) ))
#define vect128 __attribute__((vector_size(16) ))

vect128 unsigned int f(vect64 unsigned int a, vect64 unsigned int b)
{
  vect64 unsigned int zero={0, 0};
  return __builtin_shufflevector (a, b, 0, 1, 2, 3);
}
```

We get:
```
  _1 = {a_3(D), { 0, 0 }};
  _2 = {b_4(D), { 0, 0 }};
  _5 = VEC_PERM_EXPR <_1, _2, { 0, 1, 4, 5 }>;
```

Which obvious could be done to just:
`_5 = {a_3(D), b_4(D)};`

[Bug c++/94231] Invalid move constructor defaulted outside of class as deleted is accepted

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Hopefully fixed.

[Bug c++/94231] Invalid move constructor defaulted outside of class as deleted is accepted

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

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

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r14-8830-g1befe47f64bf0b964be90730e2cbef550cb6d2b7
Author: Marek Polacek 
Date:   Tue Feb 6 11:44:44 2024 -0500

c++: add fixed test [PR94231]

I was suprised to find out that r14-8759 fixed this accepts-invalid.

clang version 17.0.6 rejects the test as well; clang version 19.0.0git
crashes for which I opened
.

PR c++/94231

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/deleted17.C: New test.

[Bug c++/113788] New: Deducing this is broken with structured binding

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 113788
   Summary: Deducing this is broken with structured binding
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

GCC accepts the following:

struct S {
  int a, b;
};

int main() {
  S s = {1, 2};
  this auto& [a, b] = s;
  return b;
}

Thanks.

https://godbolt.org/z/34xTee6sx

[Bug c++/113786] cppcheck: return value from find_if not properly checked ?

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||87403
   Severity|normal  |enhancement
   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
I guess we could put [[gnu::returns_nonnull]] on those functions, but it
wouldn't help due to PR 86879.

This feels like something that belongs to static analysers, not a compiler.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #9 from Andrew Pinski  ---
  _57 = [(int *)0B + _56 + _55 * 1];
  *_57 = _14;

The fix for PR 110702 must not have been enough.

Or rather this part of the explanation was fully true:
```
The patch below
recognizes the fallback after the fact and transforms the
TARGET_MEM_REF memory reference into a LEA for which this form
isn't problematic:

  _24 = [(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4];
  _3 = *_24;
```

Maybe it was enough for GCC 13/12 branches but the trunk it was not.

[Bug tree-optimization/113756] [14 regression] Wrong code at -O2 on x86_64-linux-gnu since r14-2780-g39f117d6c87

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 57342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57342=edit
gcc14-pr113756.patch

Full untested patch.

[Bug tree-optimization/113756] [14 regression] Wrong code at -O2 on x86_64-linux-gnu since r14-2780-g39f117d6c87

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think the issue is that ABSU_EXPR is an unary operation with signed operand
and unsigned result.  And update_known_bitmask was using result rather than
operand sign to the operand's value/mask, so I think
--- gcc/range-op.cc.jj  2024-01-03 11:51:28.199777434 +0100
+++ gcc/range-op.cc 2024-02-06 16:51:55.549127825 +0100
@@ -435,8 +435,10 @@ update_known_bitmask (irange , tree_co
   bit_value_unop (code, sign, prec, _value, _mask,
  TYPE_SIGN (lh.type ()),
  TYPE_PRECISION (lh.type ()),
- widest_int::from (lh_bits.value (), sign),
- widest_int::from (lh_bits.mask (), sign));
+ widest_int::from (lh_bits.value (),
+   TYPE_SIGN (lh.type ())),
+ widest_int::from (lh_bits.mask (),
+   TYPE_SIGN (lh.type (;
   break;
 case GIMPLE_BINARY_RHS:
   bit_value_binop (code, sign, prec, _value, _mask,
ought to fix this.  Of course even better would be rewrite tree-ssa-cpp.cc to
use wide_int rather than widest_int, but I'm afraid that is stage1 material.

[Bug c++/113612] [13/14 Regression] ICE: SIGSEGV in get_template_info (pt.cc:378) or tree_check (tree.h:3611)

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

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

--- Comment #4 from Marek Polacek  ---
It was freed here in duplicate_decls:

#1  0x012f535d in ggc_free (p=0x7fffea210e10) at
/home/mpolacek/src/gcc/gcc/ggc-page.cc:1630
#2  0x00e971b2 in duplicate_decls (newdecl=, 
olddecl=, hiding=false, was_hidden=false)
at /home/mpolacek/src/gcc/gcc/cp/decl.cc:3334
#3  0x010a4bca in register_specialization (spec=, 
tmpl=, args=,
is_friend=false, hash=2199381591)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:1627
#4  0x010b46e8 in process_partial_specialization (decl=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:5422
#5  0x010b9420 in push_template_decl (decl=,
is_friend=false)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:6005
#6  0x00ea198b in start_decl (declarator=0x48c4eb0,
declspecs=0x7fffd080, initialized=1, 
attributes=, prefix_attributes=,
pushed_scope_p=0x7fffcf40)
at /home/mpolacek/src/gcc/gcc/cp/decl.cc:6108

[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #8 from Jan Hubicka  ---
I will take a look.  Mod-ref only reuses the code detecting errneous paths in
ssa-split-paths, so that code will get confused, too. It makes sense for ivopts
to compute difference of two memory allocations, but I wonder if that won't
also confuse PTA and other stuff, so perhaps we need way to exlicitely tag
memory location where such optimization happen? (to make it clear that original
base is lost, or keep track of it)

[Bug c++/113612] [13/14 Regression] ICE: SIGSEGV in get_template_info (pt.cc:378) or tree_check (tree.h:3611)

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

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

--- Comment #3 from Marek Polacek  ---
(gdb) up
#1  0x01120e27 in get_partial_spec_bindings (tmpl=, 
spec_tmpl=, args=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:25888
25888   = TI_ARGS (get_template_info (DECL_TEMPLATE_RESULT (spec_tmpl)));
(gdb) p spec_tmpl
$1 = 
(gdb) p DECL_TEMPLATE_RESULT (spec_tmpl)
$2 = 

[Bug c++/113612] [13/14 Regression] ICE: SIGSEGV in get_template_info (pt.cc:378) or tree_check (tree.h:3611) with invalid -fpreprocessed

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P4  |P2
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Keywords|error-recovery, |ice-on-valid-code
   |ice-on-invalid-code,|
   |needs-bisection |

--- Comment #2 from Marek Polacek  ---
clang++ compiles this, and so did we:

template  T t;
template  extern T *t;
template  T *t = t;

Started with r13-6380:

commit d3d205ab440886164b6de2be2a2efa10cac95b66
Author: Patrick Palka 
Date:   Tue Feb 28 15:05:30 2023 -0500

c++: non-dependent variable template-id [PR108848]

[Bug rtl-optimization/112875] [14 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.cc:670 with -Oz -frounding-math -fno-dce -fno-trapping-math -fno-tree-dce -fno-tree-dse -g

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #18 from Jakub Jelinek  ---
Hopefully fixed (don't have libc++ to try though).

[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-8828-gdf9f6b934886f51c0c07220d1ee38874b69646c7
Author: Jakub Jelinek 
Date:   Tue Feb 6 15:56:50 2024 +0100

aarch64: Fix build against libc++ in c++11 mode [PR113763]

std::pair ctor used in tiles constexpr variable is only constexpr in C++14
and later, it works with libstdc++ because it is marked constexpr there
even
in C++11 mode.

The following patch fixes it by using an unnamed local class instead of
std::pair, and additionally changes the first element from unsigned int to
unsigned char because 0xff has to fit into unsigned char on all hosts.

2024-02-06  Jakub Jelinek  

PR target/113763
* config/aarch64/aarch64.cc (aarch64_output_sme_zero_za): Change
tiles
element from std::pair to an unnamed struct.
Adjust uses of tile range variable.

[Bug c++/99387] ICE when mixing CNTTP with deduction guides

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

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

--- Comment #4 from Marek Polacek  ---
This PR seems to have been fixed by r12-6773:

commit 09845ad7569bac27c3a1dc7b410d9df764d2ca06
Author: Patrick Palka 
Date:   Thu Jan 20 09:25:49 2022 -0500

c++: CTAD inside alias template [PR91911, PR103672]

Note the Comment 1 test now compiles fine too.  clang++ rejects Comment 3 too.

[Bug c++/96090] noexcept operator of potentially-throwing defaulted function gives the wrong result

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed, I guess.

[Bug c++/94231] Invalid move constructor defaulted outside of class as deleted is accepted

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Seems to have been fixed by the very recent r14-8759.  I'll add the test.

[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #7 from Alex Coplan  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
> 
> Which means it is related to bug 110702 .
> 
> Again try -fno-ivopts . I suspect ivopts is producing some odd ir that is
> confusing modref here.

Yeah, it seems -fno-ivopts makes the execution test pass too (so -O
-fno-ivopts).

[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #5)
> My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896

Which means it is related to bug 110702 .

Again try -fno-ivopts . I suspect ivopts is producing some odd ir that is
confusing modref here.

[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2024-02-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|[14 Regression] Wrong code  |[12/13/14 Regression] Wrong
   |at -O with ipa-modref on|code at -O with ipa-modref
   |aarch64 |on aarch64
   Priority|P3  |P2
   Target Milestone|--- |12.4

--- Comment #5 from Jakub Jelinek  ---
My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896

[Bug tree-optimization/113787] [14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #4 from Alex Coplan  ---
Same with the head of the GCC 12 branch, but I agree it isn't a [14 Regression]
as I can reproduce the issue with basepoints/gcc-14, so maybe something was
backported to 12/13 that is making it latent on the branches?

[Bug tree-optimization/113787] [14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #3 from Alex Coplan  ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a 14 Regression?
> Seems r12-5166 works fine while r12-6600 already doesn't, so that would make
> it [12/13/14 Regression], no?

Well on the head of the GCC 13 branch the execution test seems to pass for me
and I see no difference with/without ipa-modref, I'll double check with GCC 12.

[Bug c++/86918] internal compiler error: unexpected expression 'v' of kind template_parm_index

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
The ICE was fixed by r13-1565-g7b90f07f778caa:

commit 7b90f07f778caa5e09f3dc20a8c3da1f4cf60c20
Author: Patrick Palka 
Date:   Thu Jul 7 16:46:29 2022 -0400

c++: generic targs and identity substitution [PR105956]

[Bug tree-optimization/113787] [14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

--- Comment #2 from Andrew Pinski  ---
Also try -fno-ivopts .

[Bug tree-optimization/113787] [14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Why do you think it is a 14 Regression?
Seems r12-5166 works fine while r12-6600 already doesn't, so that would make it
[12/13/14 Regression], no?

[Bug tree-optimization/113787] New: [14 Regression] Wrong code at -O with ipa-modref on aarch64

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

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

Bug ID: 113787
   Summary: [14 Regression] Wrong code at -O with ipa-modref on
aarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following testcase appears to be miscompiled on the trunk, on
aarch64-linux-gnu:

$ cat t.c
void foo(int x, int y, int z, int d, int *buf)
{
  for(int i = z; i < y-z; ++i)
for(int j = 0; j < d; ++j)
  /* buf[x(i+1) + j] = buf[x(i+1)-j-1] */
  buf[i*x+(x-z+j)] = buf[i*x+(x-z-1-j)];
}

void bar(int x, int y, int z, int d, int *buf)
{
  for(int i = 0; i < d; ++i)
for(int j = z; j < x-z; ++j)
  /* buf[j+(y+i)*x] = buf[j+(y-1-i)*x] */
  buf[j+(y-z+i)*x] = buf[j+(y-z-1-i)*x];
}

__attribute__((noipa))
void baz(int x, int y, int d, int *buf)
{
  foo(x, y, 0, d, buf);
  bar(x, y, 0, d, buf);
}

int main(void)
{
  int a[] = { 1, 2, 3 };
  baz (1, 2, 1, a);
  /* foo does:
 buf[1] = buf[0];
 buf[2] = buf[1];

 bar does:
 buf[2] = buf[1]; (no-op)
 so we should have { 1, 1, 1 }.  */
  for (int i = 0; i < 3; i++)
if (a[i] != 1)
  __builtin_abort ();
}
$ gcc t.c -O -fno-ipa-modref
$ ./a.out
$ gcc t.c -O
$ ./a.out
Aborted

The problem seems to be that the call to foo gets incorrectly optimized
out from baz when ipa-modref is enabled:

$ gcc -c -S -o /dev/null t.c -O -fno-ipa-modref -fdump-tree-optimized=good.tree
$ gcc -c -S -o /dev/null t.c -O -fdump-tree-optimized=bad.tree
$ diff -u good.tree bad.tree
--- good.tree   2024-02-06 13:23:36.080926703 +
+++ bad.tree2024-02-06 13:23:38.356916302 +
@@ -223,7 +223,6 @@
 void baz (int x, int y, int d, int * buf)
 {
[local count: 1073741824]:
-  foo (x_2(D), y_3(D), 0, d_4(D), buf_5(D));
   bar (x_2(D), y_3(D), 0, d_4(D), buf_5(D));
   return;

I can't seem to reproduce the issue with GCC 13 or on x86_64.