[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/117355] [15 regression] firebird miscompiled due to __builtin_dynamic_object_size difference at -O since r15-4396-g72ae35bbc90fea

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/117353] [15 regression] RISC-V: ICE when building libcrypt since r15-3228-g771256bcb9ddc4

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Target||riscv

[Bug target/117357] New: ICE: in extract_insn, at recog.cc:2882 (unrecognizable insn: UNSPEC_RSQRT) with -mfpmath=387 and __builtin_ia32_rsqrtf()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117357
   Summary: ICE: in extract_insn, at recog.cc:2882 (unrecognizable
insn: UNSPEC_RSQRT) with -mfpmath=387 and
__builtin_ia32_rsqrtf()
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -mfpmath=387 testcase.c 
testcase.c: In function 'foo':
testcase.c:5:1: error: unrecognizable insn:
5 | }
  | ^
(insn 7 6 8 2 (set (reg:SF 100)
(unspec:SF [
(reg:SF 105)
] UNSPEC_RSQRT)) "testcase.c":4:12 -1
 (nil))
during RTL pass: vregs
testcase.c:5:1: internal compiler error: in extract_insn, at recog.cc:2882
0x2dfc7fe internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:518
0xe81f0b fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1580
0x833fb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:109
0x834032 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:117
0x822b4b extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2882
0x1202ec0 instantiate_virtual_regs_in_insn
/repo/gcc-trunk/gcc/function.cc:1612
0x1202ec0 instantiate_virtual_regs
/repo/gcc-trunk/gcc/function.cc:1995
0x1202ec0 execute
/repo/gcc-trunk/gcc/function.cc:2042
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.

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

[Bug c++/117351] [14/15 Regression] ICE while reporting invalid template error

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/117358] ICE: in execute_todo, at passes.cc:2138 at -O2 and above with const attribute

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
You get what you ask for (related to that other similar bug).

But yeah, we shouldn't ICE.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-30
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

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

Proposed patch in testing.

[Bug bootstrap/117361] [15 Regression] GCC build fails with "gcc/opts-diagnostic.cc:599: test_output_arg_parsing: FAIL: ASSERT_STREQ (pt.get_diagnostic_text ()"

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Priority|P3  |P1

--- Comment #1 from Richard Biener  ---
I think selftests should run with some standard locale?

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

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

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

--- Comment #3 from Richard Biener  ---
asm() modifying the stack pointer are invalid.

[Bug bootstrap/117361] New: [15 Regression] GCC build fails with "gcc/opts-diagnostic.cc:599: test_output_arg_parsing: FAIL: ASSERT_STREQ (pt.get_diagnostic_text ()"

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

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

Bug ID: 117361
   Summary: [15 Regression] GCC build fails with
"gcc/opts-diagnostic.cc:599: test_output_arg_parsing:
FAIL: ASSERT_STREQ (pt.get_diagnostic_text ()"
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

That's due to commit  r15-4760-g0b73e9382ab51c
  diagnostics: support multiple output formats simultaneously [PR116613]

The problem is that 'error' might get translated if one happens to have LANG,
as I happened to have in one terminal.


Namely, with 'de_DE.UTF-8' bootstrapping fails with:

../../../repos/gcc/gcc/opts-diagnostic.cc:599: test_output_arg_parsing: FAIL:
ASSERT_STREQ (pt.get_diagnostic_text (), "PROGNAME: error: `-fOPTION=foo:':" "
expected KEY=VALUE-style parameter for format `foo'" " after `:';" " got `'\n")

 val1="PROGNAME: Fehler: `-fOPTION=foo:': expected KEY=VALUE-style parameter
for format `foo' after `:'; got `'
"

 val2="PROGNAME: error: `-fOPTION=foo:': expected KEY=VALUE-style parameter for
format `foo' after `:'; got `'
"

...


PROGNAME: interner Compiler-Fehler: in fail_formatted, bei selftest.cc:63
0x2833460 internal_error(char const*, ...)
../../../repos/gcc/gcc/diagnostic-global-context.cc:518
0xa7ccb1 fancy_abort(char const*, int, char const*)
../../../repos/gcc/gcc/diagnostic.cc:1693
0x2815496 selftest::fail_formatted(selftest::location const&, char const*, ...)
../../../repos/gcc/gcc/selftest.cc:63
0x2815541 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../../repos/gcc/gcc/selftest.cc:92
0x254aba0 internal_error(char const*, ...)
../../../repos/gcc/gcc/diagnostic-global-context.cc:518
0x99dbcf fancy_abort(char const*, int, char const*)
../../../repos/gcc/gcc/diagnostic.cc:1693
0x252cbd6 selftest::fail_formatted(selftest::location const&, char const*, ...)
../../../repos/gcc/gcc/selftest.cc:63
0x252cc81 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../../repos/gcc/gcc/selftest.cc:92
0x2804630 test_output_arg_parsing
../../../repos/gcc/gcc/opts-diagnostic.cc:599
0x251bd70 test_output_arg_parsing
../../../repos/gcc/gcc/opts-diagnostic.cc:599
0x27342ee selftest::run_tests()
../../../repos/gcc/gcc/selftest-run-tests.cc:109
0x2457a6e selftest::run_tests()
../../../repos/gcc/gcc/selftest-run-tests.cc:109
0x13bb3b9 toplev::run_self_tests()
../../../repos/gcc/gcc/toplev.cc:2270

[Bug c/117362] target() attribute applied to wrong function, or wrong check order in conjunction with interrupt() attribute

[cs at aibiot dot de via Gcc-bugs]

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

Christian Schmidt  changed:

   What|Removed |Added

 CC||cs at aibiot dot de

--- Comment #1 from Christian Schmidt  ---
This bug is related to 115263 which mentions the wrong documentation of the
general-regs-only attribute, but does not give any example for reproduction.

[Bug c/117363] New: ice during GIMPLE pass: ldist

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 117363
   Summary: ice during GIMPLE pass: ldist
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Sometime between g:e320846fec00aaa3 and g:91577f0c8d955bc6,
this C code

long negate_v1_0;
unsigned long negate___trans_tmp_1;
int *negate_v_1;
void negate() {
  negate___trans_tmp_1 = negate_v1_0 ? ~negate_v1_0 : negate_v1_0;
  long i = 0;
  for (; i < negate___trans_tmp_1; i++)
negate_v_1[i] = 0;
}

does this:

foundBugs $ ../results.20241028.asan.ubsan/bin/gcc -c -w -O2 bug1061.c
foundBugs $ ../results.20241030.asan.ubsan/bin/gcc -c -w -O2 bug1061.c
bitsobj.c: In function ‘calc1’:
bitsobj.c:846:53: error: type mismatch in binary expression
sizetype

long int

sizetype

_165 = _87 - _180;
during GIMPLE pass: ldist
bitsobj.c:846:53: internal compiler error: verify_gimple failed
0x2332d1d internal_error(char const*, ...)
   
/home/dcb40b/gcc/working/gcc/../../trunk/gcc/diagnostic-global-context.cc:518
0xf63832 verify_gimple_in_cfg(function*, bool, bool)
/home/dcb40b/gcc/working/gcc/../../trunk/gcc/tree-cfg.cc:5682

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[schwab--- via Gcc-bugs]

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

--- Comment #8 from Andreas Schwab  ---
If sp isn't changed then it should not appear as output.

[Bug c/117021] [C2y] Implement N3370, Case range expressions

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

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

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

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

commit r15-4766-gabcfe1e51c18b14d324586f1d9d50e8238497865
Author: Jakub Jelinek 
Date:   Wed Oct 30 07:59:52 2024 +0100

c: Add C2Y N3370 - Case range expressions support [PR117021]

The following patch adds the C2Y N3370 paper support.
We had the case ranges as a GNU extension for decades, so this patch
simply:
1) adds different diagnostics when it is used in C (depending on
flag_isoc2y
   and pedantic and warn_c23_c2y_compat)
2) emits a pedwarn in C if in a range conversion changes the value of
   the low or high bounds and in that case doesn't emit -Woverflow and
   similar warnings anymore if the pedwarn has been diagnosed
3) changes the handling of empty ranges both in C and C++; previously
   we just warned but let the values be still looked up in the splay
   tree/entered into it (and let only gimplification throw away those
   empty cases), so e.g. case -6 ... -8: break; case -6: break;
   complained about duplicate case label.  But that actually isn't
   duplicate case label, case -6 ... -8: stands for nothing at all
   and that is how it is treated later on (thrown away)

2024-10-30  Jakub Jelinek  

PR c/117021
gcc/c-family/
* c-common.cc (c_add_case_label): Emit different diagnostics for C
on case ranges.  Diagnose for C using pedwarn conversions of range
expressions changing value and don't emit further conversion
diagnostics if the pedwarn has been diagnosed.  For empty ranges
bail out after emitting warning, don't add anything into splay
trees nor add a CASE_LABEL_EXPR.
gcc/testsuite/
* gcc.dg/switch-6.c: Expect different diagnostics.  Add -std=gnu23
to dg-options.
* gcc.dg/switch-7.c: Expect different diagnostics.  Add -std=c23
to dg-options.
* gcc.dg/gnu23-switch-1.c: New test.
* gcc.dg/gnu23-switch-2.c: New test.
* gcc.dg/c23-switch-1.c: New test.
* gcc.dg/c2y-switch-1.c: New test.
* gcc.dg/c2y-switch-2.c: New test.
* gcc.dg/c2y-switch-3.c: New test.

[Bug c/117021] [C2y] Implement N3370, Case range expressions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Implemented for 15.1+.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #3)
> asm() modifying the stack pointer are invalid.

Yeah, but the construct in Comment 0 is what kernel people use to prevent asm
from being scheduled before frame is set up. The asm does not modify the stack
pointer (the SP after the asm is the same), but can clobber the redzone.

The proposed patch improves stack pointer RTX detection in
notice_stack_pointer_modification_1 to look at RTL and everything, including
redzone prevention, starts to work.

[Bug c/117362] New: target() attribute applied to wrong function, or wrong check order in conjunction with interrupt() attribute

[cs at aibiot dot de via Gcc-bugs]

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

Bug ID: 117362
   Summary: target() attribute applied to wrong function, or wrong
check order in conjunction with interrupt() attribute
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cs at aibiot dot de
  Target Milestone: ---

This bug exists both in 14.2.1 20240921 and 15.0.0 20241006.

The source code (simplified):

static __attribute__ ((used,target("general-regs-only"),interrupt("IRQ"))) void
irqa (void) {}
static __attribute__ ((used,interrupt("IRQ"))) void irqb (void) {}
static __attribute__ ((used,interrupt("IRQ"))) void irqc (void) {}
static void irqd
[[gnu::used,gnu::interrupt("IRQ"),gnu::target("general-regs-only")]] (void) {}

The command line:

arm-none-eabi-gcc -std=gnu23 -g -O2 -Wall -Werror -Wextra -Wpedantic -Wshadow
-pipe -mcpu=cortex-a5 -mfpu=vfpv4-d16 -mfloat-abi=hard -o t.o -c t.c
t.c:1:1: error: FP registers might be clobbered despite 'interrupt' attribute:
compile with '-mgeneral-regs-only' [-Werror=attributes]
1 | static __attribute__
((used,target("general-regs-only"),interrupt("IRQ"))) void irqa (void) {}
  | ^~
t.c:3:1: error: FP registers might be clobbered despite 'interrupt' attribute:
compile with '-mgeneral-regs-only' [-Werror=attributes]
3 | static __attribute__ ((used,interrupt("IRQ"))) void irqc (void) {}
  | ^~
t.c:4:1: error: FP registers might be clobbered despite 'interrupt' attribute:
compile with '-mgeneral-regs-only' [-Werror=attributes]
4 | static void irqd
[[gnu::used,gnu::interrupt("IRQ"),gnu::target("general-regs-only")]] (void) {}
  | ^~
cc1: all warnings being treated as errors

The error is only reported on the first and third function, although the first
should be correct and the second and third should report the error. It is as
though the target attribute is applied to the wrong (second) function, or
processing of checks for the interrupt() attribute checks the wrong state. This
happens for both C23 and classic attribute syntax. Ordering of the target and
interrupt attributes seems to not matter.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[schwab--- via Gcc-bugs]

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

--- Comment #5 from Andreas Schwab  ---
This should be warned similar to "listing the stack pointer register %qs in a
clobber list is deprecated".

[Bug target/117312] RFE: x86 (and perhaps others): inline assembly: "red-zone" clobber

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Uroš Bizjak  ---
With the patch in PR117359 applied and testcase patched with:

--cut here--
--- pr117312.c  2024-10-30 10:50:04.921338850 +0100
+++ pr117312-new.c  2024-10-30 10:49:49.441488965 +0100
@@ -1,3 +1,6 @@
+register unsigned long current_stack_pointer asm ("%rsp");
+#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
+
 /* Just an opaque data source */
 static inline __attribute__((always_inline)) int get_random(void)
 {
@@ -22,7 +25,7 @@
 /* Clobbers [-16..-1](%rsp) */
 /* "volatile" or a memory clobber doesn't seem to make any difference */
 asm("push %2; pushf; pop %0; pop %1"
-   : "=r" (y), "=r" (z)
+   : "=r" (y), "=r" (z), ASM_CALL_CONSTRAINT
: "r" (x)
: "memory");

the resulting asm differs in:

--- pr117312.s  2024-10-30 10:50:13.170258856 +0100
+++ pr117312-new.s  2024-10-30 10:50:28.517110031 +0100
@@ -1,4 +1,4 @@
-   .file   "pr117312.c"
+   .file   "pr117312-new.c"
.text
.p2align 4
.globl  asm_clobbers_redzone
@@ -6,115 +6,116 @@
 asm_clobbers_redzone:
 .LFB1:
.cfi_startproc
-   movl%edi, %eax
+   subq$72, %rsp
+   .cfi_def_cfa_offset 80
 #APP
-# 5 "pr117312.c" 1
+# 8 "pr117312-new.c" 1
rdrand %edx
 # 0 "" 2
 #NO_APP
-   movl%edx, -72(%rsp)
+   movl%edx, (%rsp)
 #APP
-# 5 "pr117312.c" 1
-   rdrand %ecx
+# 8 "pr117312-new.c" 1
+   rdrand %eax
 # 0 "" 2
 #NO_APP
-   movl%ecx, -68(%rsp)
+   movl%eax, 4(%rsp)
 #APP
-# 5 "pr117312.c" 1
-   rdrand %esi
+# 8 "pr117312-new.c" 1
+   rdrand %ecx
 # 0 "" 2
 #NO_APP
-   movl%esi, -64(%rsp)
+   movl%ecx, 8(%rsp)
...

No redzone was used with the patched testcase.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hpa at zytor dot com

--- Comment #6 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #3)
> asm() modifying the stack pointer are invalid.
Adding Peter to the discussion.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Andreas Schwab from comment #5)
> This should be warned similar to "listing the stack pointer register %qs in
> a clobber list is deprecated".
The compiler already warns when "rsp" is added to the list of clobbers:

pr117312.c:24:5: warning: listing the stack pointer register ‘rsp’ in a clobber
list is deprecated [-Wdeprecated]
   24 | asm("push %2; pushf; pop %0; pop %1"
  | ^~~
pr117312.c:24:5: note: the value of the stack pointer after an ‘asm’ statement
must be the same as it was before the statement

But RSP is *not* clobbered. The asm does not change the value of RSP, as is
requested in the note.

[Bug target/80881] Implement Windows native TLS

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

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

--- Comment #70 from Eric Botcazou  ---
> I apologize for vanishing suddenly and not giving progress reports, I am
> currently busy with some JDK work. The only thing left missing is the
> configure check. I will return to finishing TLS support once and for all
> when my JDK fixes have been completed

The configure check is in the candidate patch though.

[Bug target/117312] RFE: x86 (and perhaps others): inline assembly: "red-zone" clobber

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to H. Peter Anvin from comment #15)
> Odd. When I added a read flag intrinsic to my test case, it prevented the
> red zone from being used. If it clobbers the redzone, then that's obviously
> a very serious problem.

The generic compiler part detects stack pointer modification (c.f.
notice_stack_pointer_modification_1 in stack-ptr-mod.cc) and clears
crtl->sp_is_unchanging.

Now, consider the following testcase, derived from x86 linux sources:

--cut here--
register unsigned long current_stack_pointer asm ("sp");
#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)

void foo (void)
{
  asm volatile ("#" : ASM_CALL_CONSTRAINT);
}
--cut here--

The asm writes to stack pointer, as can be seen from _.final dump:

(insn:TI 5 2 15 2 (parallel [
(set (reg/v:DI 7 sp [ current_stack_pointer ])
(asm_operands/v:DI ("#") ("=r") 0 [
(reg/v:DI 7 sp [ current_stack_pointer ])
]
 [
(asm_input:DI ("0") rsp.c:6)
]
 [] rsp.c:6))
(clobber (reg:CC 17 flags))
]) "rsp.c":6:3 -1
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

but middle-end fails to detect this write. This issue can be observed by
putting a breakpoint at ix86_compute_frame_layout and:

Breakpoint 2, ix86_compute_frame_layout () at
../../git/gcc/gcc/config/i386/i386.cc:6876
6876  struct ix86_frame *frame = &cfun->machine->frame;
(gdb) p x_rtl->sp_is_unchanging 
$1 = true

Which makes this PR a bug in the target-independent part of the compiler.

I will file a new PR that will obsolete this one. x86 redzone creation depends
on (c.f. ix86_compute_frame_layout):

  if (ix86_using_red_zone ()
  && crtl->sp_is_unchanging
  && crtl->is_leaf
  && !ix86_pc_thunk_call_expanded
  && !ix86_current_function_calls_tls_descriptor)

And when crtl->sp_is_unchanging correctly detects stack pointer change in the
asm, the redzone creation (and other things that depend on
crtl->sp_is_unchanging) will be disabled. There is no need for "red-zone"
clobber, existing ASM_CALL_CONSTRAINT should do the trick.

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist

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

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

Sam James  changed:

   What|Removed |Added

Summary|ice during GIMPLE pass: |[15 regression] ICE during
   |ldist   |GIMPLE pass: ldist
   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code
  Component|c   |tree-optimization

[Bug rtl-optimization/117360] [15 regression] ext-dce.cc:573:15: runtime error: shift exponent 127 is too large for 64-bit type 'long long unsigned int'

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

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

Sam James  changed:

   What|Removed |Added

 Blocks||63426
   Target Milestone|--- |15.0
Summary|ext-dce.cc:573:15: runtime  |[15 regression]
   |error: shift exponent 127   |ext-dce.cc:573:15: runtime
   |is too large for 64-bit |error: shift exponent 127
   |type 'long long unsigned|is too large for 64-bit
   |int'|type 'long long unsigned
   ||int'


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Andreas Schwab from comment #8)
> If sp isn't changed then it should not appear as output.

SP isn't changed, but memory locations that depend on SP may be changed. By
listing RSP in the output we can say to the compiler that RSP changed in the
asm and that optimizations that depend on RSP not changing are now invalid.

This is what notice_stack_pointer_modification_1 records and it is exactly what
we need to prevent redzone creation.

[Bug c++/117364] [12/13/14/15 Regression][coroutines] Use of triggers an ICE on sparc

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-30

--- Comment #1 from Iain Sandoe  ---
the code that the coroutines implementation generates is like this:


   = Promise::get_return_object (_2);
  Coro (_Coro_frameptr);
  return ;

This is because the return entity must be fully constructed before the
coroutine is started (Coro (_Coro_frameptr);) - and the later has potentially
indirect access to that entity.

We have to construct the entity in the return slot to avoid a copy (which would
break C++17 copy elision rules)

This does not seem morally different from NVRO.

At present, I do not have a handle on where the actual issue is - since
Rainer's and Eric's reports are from completely different phases in the
lowering.

[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()

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

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

--- Comment #16 from Iain Sandoe  ---
let's move the Sparc bug to a new one (PR117364) since it's not directly
related to this fix at all (just triggered by the test case).

[Bug c++/117364] New: [12/13/14/15 Regression][coroutines] Use of triggers an ICE on spare

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

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

Bug ID: 117364
   Summary: [12/13/14/15 Regression][coroutines] Use of 
triggers an ICE on spare
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

This was identified with the test case attached to PR115905, but is not
otherwise related to that patch or indeed any recent coroutines patch.


Rainer identified:
r11-1613-g788b962aa00959
as the original change.

This is copied from PR115905 for the record:

Rainer's original report has the issue triggering in the tree checks (and my
debugging of that says that the alignment entry appears to have been GGC'd - it
has the characteristic 0xafafafaf pattern).


Eric has added the following which suggests that the problem is occurring much
later (in RTL) - so it's a bit unclear (perhaps because there's a GGC issue
along the way?):

The symptom on 64-bit SPARC is that MEM_ALIGN is applied to something that is
not a MEM, but a PARALLEL:

(parallel:DI [
(expr_list:REG_DEP_TRUE (reg:DI 114 [  ])
(const_int 0 [0]))
])

This comes from the Early SRA pass which turns:

  D.8652.D.8175._M_fr_ptr = _11;
   = D.8652;

into

  SR.40_20 = _11;
  MEM[(struct Handle *)&] = SR.40_20;

which is a store to something that is not addressable at the RTL level.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Uroš Bizjak  ---
(In reply to Andreas Schwab from comment #10)
> If you change memory, then that memory needs to be in the output/clobber
> list.

Adding redzone memory to output is not effective, please see PR117312 for the
experiment.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[schwab--- via Gcc-bugs]

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

--- Comment #10 from Andreas Schwab  ---
If you change memory, then that memory needs to be in the output/clobber list.

[Bug c/117366] New: arm thumb1 epilogue size optimizer violates -ffixed

[matt.parks--- via Gcc-bugs]

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

Bug ID: 117366
   Summary: arm thumb1 epilogue size optimizer violates -ffixed
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt.pa...@go-aps.com
  Target Milestone: ---

arm thumb1 epilogue size optimizer violates -ffixed-r4.

Compile the following minimal code snippet with options:
arm-none-eabi-gcc -Os -ffixed-r4 -march=armv5te -mthumb -mabi=apcs-gnu -S
test_thumb.c -o test_thumb.s

test_thumb.c:
---
void func(void *, void *, void *, int, int);

int bad_func(void) {
   int a, b, c;
   func(&a, &b, &c, 1, 2);
   return b;
}
---
In test_thumb.s:
Function prolog is:
push {r0, r1, r2, r3, lr}

Function epilogue is:
pop {r1, r2, r3, r4, pc} <-- popping into r4 violates --fixed-r4

Bug is in function thumb1_extra_regs_pushed, which optimizes the prologue and
epilog for optimize_size to do extra dummy push/pop registers instead of a
separate sub/add for the stack pointer. The bug is present from the first
appearance of the function in gcc 4.6.0 and is still present in the git master
branch.

Code snippet with the bug:
while (reg_base + n_free < 8 && !(live_regs_mask & 1)
 && (for_prologue || call_used_or_fixed_reg_p (reg_base + n_free)))

The problem is that call_used_or_fixed_reg_p (and call_used_regs[reg_base +
n_free] which was used prior to gcc 10) includes fixed registers, because
-ffixed-reg gets added to both the call_used_regs and fixed_regs. Because fixed
register r4 is adjacent to normal call_used_regs r0-r3, it gets included as a
candidate for a free register. For the prologue, that's fine because pushing a
fixed register for dummy stack space doesn't hurt anything, but for the
epilogue, causes corruption of the fixed reg.

I tested the following fix - change back half of the conditional expression to:
... && (for_prologue || (call_used_or_fixed_reg_p (reg_base + n_free) &&
!fixed_reg[reg_base + n_free]

By excluding the fixed reg r4, the code is fixed by having
thumb1_extra_regs_pushed return 0 because amount > n_free * 4. The corrected
epilogue is:
add sp, sp, #16
pop {pc}

[Bug c++/117364] [12/13/14/15 Regression][coroutines] Use of triggers an ICE on sparc

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

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Eric Botcazou from comment #2)
> > This does not seem morally different from NVRO.
> 
> Yes, that's perfectly fine.
> 
> > At present, I do not have a handle on where the actual issue is - since
> > Rainer's and Eric's reports are from completely different phases in the
> > lowering.
> 
> Either we should stop Early SRA from doing the transformation (and I agree
> that this could also happen out of the regular NRVO) or we should enhance
> the RTL expander to deal with this (questionable IMO) construct.

Apologies for being slow here - which, specific, construct are you considering
questionable?
and is there anything that the FE can do to make this better - without losing
the copy-elision guarantee?

(we are stuck with the basic sequence as described, it is mandated by the
standard - so if that's the fundamental issue, we'd need to figure out a way to
meeting the copy-elision criteria at the same time)

[Bug target/117312] RFE: x86 (and perhaps others): inline assembly: "red-zone" clobber

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

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

--- Comment #19 from Jakub Jelinek  ---
"memory" clobber is IMO about possibly changing any user var in memory behind
the back of the compiler, not about changing whatever compiler internals stored
somewhere on the stack in stack slots that don't have address taken and could
escape to the inline asm.
So, compiler doesn't need to assume the inline asm could have say changed the
saved frame pointer or return address on the stack, or stuff temporarily pushed
into the red zone, stack canary, pseudos pushed temporarily to stack during
reload, ...
Because there is no way the compiler can cope with that being changed,
reloading is exactly what the compiler does if say inline asm clobbers a
register in which something that needs to live across the inline asm is stored.
So, if we don't want to support rsp clobbers or rsp as +r operand anymore as
hacks that happened to disable red-zone, IMHO we should add a new clobber, say
"redzone" which makes it explicit what we want to achieve.

[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time

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

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

Jason Merrill  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-30

[Bug libstdc++/111861] ranges::min/max should not use `auto __result = *__first;`

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Interesting, I guess 'auto x = *iter;' should never be done in generic code
then?

[Bug c/117313] [15 regression] ICE when building linux-6.11.5 (output_constructor_regular_field, at varasm.cc:5672)

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #8 from Sam James  ---
Fixed AFAICT.

[Bug c++/116607] ICE: tree check: expected tree_list, have integer_cst in has_active_contract_condition, at cp/contracts.cc:1505 with no_sanitize attribute and -fcontracts option

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:673d6b2cbf610508d315526f4963793a343a2070

commit r15-4778-g673d6b2cbf610508d315526f4963793a343a2070
Author: Iain Sandoe 
Date:   Wed Oct 30 10:29:49 2024 +

c++, contracts: Only check contracts attributes [PR116607].

The ICE described in the PR is caused by not filtering out non-
contract attributes before making the has_active_contract_condition
test.  Fixed, as suggested by Andrew Pinski, by just using the
existing CONTRACT_CHAIN () macro to advance through the list.

PR c++/116607

gcc/cp/ChangeLog:

* contracts.cc (has_active_contract_condition): Use the
CONTRACT_CHAIN macro to advance through the attribute list.

gcc/testsuite/ChangeLog:

* g++.dg/contracts/pr116607.C: New test.

Signed-off-by: Iain Sandoe 

[Bug rtl-optimization/117360] [15 regression] ext-dce.cc:573:15: runtime error: shift exponent 127 is too large for 64-bit type 'long long unsigned int'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
While you're at it, the ULL uses in ext-dce.cc should be
HOST_WIDE_INT_UC () or 1ULL should be HOST_WIDE_INT_1U.

[Bug middle-end/117354] ICE: in extract_bit_field_1, at expmed.cc:1838 with _BitInt (and asan in some cases)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 59501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59501&action=edit
gcc15-pr117354.patch

Untested fix.

[Bug c++/116607] ICE: tree check: expected tree_list, have integer_cst in has_active_contract_condition, at cp/contracts.cc:1505 with no_sanitize attribute and -fcontracts option

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Sandoe  ---
fixed for trunk.

[Bug rtl-optimization/117360] [15 regression] ext-dce.cc:573:15: runtime error: shift exponent 127 is too large for 64-bit type 'long long unsigned int'

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/117370] New: std::nothrow variants of operator new are not optimized away when block is unused

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

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

Bug ID: 117370
   Summary: std::nothrow variants of operator new are not
optimized away when block is unused
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

#include 
void test1()
{
int *a = new int;
delete(a);
}
void test()
{
int *a = new (std::nothrow) int;
delete(a);
}
void test2()
{
int *a = new (std::nothrow) int;
if (!a)
__builtin_abort ();
delete(a);
}


compiles to:

;; Function test1 (_Z5test1v, funcdef_no=17, decl_uid=3143, cgraph_uid=17,
symbol_order=18)

void test1 ()
{
   [local count: 1073741824]:
  return;

}



;; Function test (_Z4testv, funcdef_no=18, decl_uid=3147, cgraph_uid=18,
symbol_order=19)

Removing basic block 5
void test ()
{
  int * a;

   [local count: 1073741824]:
  a_4 = operator new (4, ¬hrow);
  if (a_4 != 0B)
goto ; [99.96%]
  else
goto ; [0.04%]

   [local count: 1073312328]:
  *a_4 ={v} {CLOBBER(eob)};
  operator delete (a_4, 4); [tail call]

   [local count: 1073741824]:
  return;

}



;; Function test2 (_Z5test2v, funcdef_no=19, decl_uid=3151, cgraph_uid=19,
symbol_order=20)

void test2 ()
{
  int * a;

   [local count: 1073741824]:
  a_3 = operator new (4, ¬hrow);
  if (a_3 == 0B)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  *a_3 ={v} {CLOBBER(eob)};
  operator delete (a_3, 4); [tail call]
  return;

}


so only first variant is optimized out. Clang optimizes away all three
new/delete pairs

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Andreas Schwab from comment #12)
> Neither is clobbering a register.

Yes, as I have already reported in Comment #7.

But adding RSP to the output list will do exactly what we want, as reported in
PR117312 c#17.

[Bug c++/117294] Concept swallow diagnostics when they're defined in terms of type traits

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

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

--- Comment #2 from Jonathan Wakely  ---
Interestingly, Clang *does* say why the concept failed, and says that there was
an explicit constructor that wasn't a candidate. But it also prints notes about
implicit copy constructor and implicit move constructor (which don't seem
useful) and it says that the ill-formed conversion from '1' to 'A' occurred "in
evaluation of exception specification for 'Foo::Foo'" which is just
confusing.

def.cc:15:11: error: no viable conversion from 'int' to 'A'
   15 | T a = 1;
  |   ^
def.cc:14:8: note: in instantiation of default member initializer 'Foo::a'
requested here
   14 | struct Foo {
  |^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/type_traits:3383:46:
note: in evaluation of exception specification for 'Foo::Foo' needed here
 3383 |   inline constexpr bool is_constructible_v = __is_constructible(_Tp,
_Args...);
  |  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:160:30:
note: in instantiation of variable template specialization
'std::is_constructible_v>' requested here
  160 |   = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;
  |  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:160:30:
note: while substituting template arguments into constraint expression here
  160 |   = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;
  |  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:164:37:
note: while checking the satisfaction of concept 'constructible_from>'
requested here
  164 | concept default_initializable = constructible_from<_Tp>
  | ^~~
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:164:37:
note: while substituting template arguments into constraint expression here
  164 | concept default_initializable = constructible_from<_Tp>
  | ^~~
def.cc:3:11: note: while checking the satisfaction of concept
'default_initializable>' requested here
3 | template 
  |   ^
def.cc:3:11: note: while substituting template arguments into constraint
expression here
3 | template 
  |   ^~
def.cc:20:10: note: while checking constraint satisfaction for template
'make>' required here
   20 |   return make>();
  |  ^~~~
def.cc:20:10: note: in instantiation of function template specialization
'make>' requested here
def.cc:9:8: note: candidate constructor (the implicit copy constructor) not
viable: no known conversion from 'int' to 'const A &' for 1st argument
9 | struct A {
  |^
def.cc:9:8: note: candidate constructor (the implicit move constructor) not
viable: no known conversion from 'int' to 'A &&' for 1st argument
9 | struct A {
  |^
def.cc:10:14: note: explicit constructor is not a candidate
   10 | explicit A(int) {}
  |  ^
def.cc:20:10: error: no matching function for call to 'make'
   20 |   return make>();
  |  ^~~~
def.cc:4:6: note: candidate template ignored: constraints not satisfied [with T
= Foo]
4 | auto make() {
  |  ^
def.cc:3:11: note: because 'Foo' does not satisfy 'default_initializable'
3 | template 
  |   ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:167:2:
note: because '_Tp{}' would be invalid
  167 | _Tp{};
  | ^
2 errors generated.


Why is it showing anything about _Tp{} when the earlier constructible_from<_Tp>
requirement already failed?

[Bug target/117312] RFE: x86 (and perhaps others): inline assembly: "red-zone" clobber

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #18)
> I think ->sp_is_unchanging isn't the correct vehicle to test whether the red
> zone is usable - as you point out the red zone might be used/clobbered so the
> x86 backend would need to check for that, and a "memory" clobber should be
> enough to indicate this might happen (even if that pessimizes other code).

Please see Comment #16, x86 already checks sp_is_unchanging when redzone is
created in ix86_compute_frame_layout:

  if (ix86_using_red_zone ()
  && crtl->sp_is_unchanging
  && crtl->is_leaf
  && !ix86_pc_thunk_call_expanded
  && !ix86_current_function_calls_tls_descriptor)

Lookgin also at the proposed patch in PR117359, IMO having rsp in the output
list is what informs the compiler that %rsp is changing.

[Bug c++/117294] Concept swallow diagnostics when they're defined in terms of type traits

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Even if we remove the constrained function template and just write an
> assertion based on the underlying built-in, there's no more information:
> 
> struct A {
> explicit A(int) {}
> };
> 
> template 
> struct Foo {
> T a = 1;
> };
> 
> auto tryit() {
>   static_assert( __is_constructible(Foo) );
> }

For this simpler case, Clang gives:

def.cc:7:11: error: no viable conversion from 'int' to 'A'
7 | T a = 1;
  |   ^
def.cc:6:8: note: in instantiation of default member initializer 'Foo::a'
requested here
6 | struct Foo {
  |^
def.cc:11:18: note: in evaluation of exception specification for 'Foo::Foo'
needed here
   11 |   static_assert( __is_constructible(Foo) );
  |  ^
def.cc:1:8: note: candidate constructor (the implicit copy constructor) not
viable: no known conversion from 'int' to 'const A &' for 1st argument
1 | struct A {
  |^
def.cc:1:8: note: candidate constructor (the implicit move constructor) not
viable: no known conversion from 'int' to 'A &&' for 1st argument
1 | struct A {
  |^
def.cc:2:14: note: explicit constructor is not a candidate
2 | explicit A(int) {}
  |  ^
1 error generated.


Which I suppose is much closer to what Barry is asking for. So it's certainly
possible, and I'm just not very imaginative.

[Bug c/117367] [14/15 regression] Miscompile with different optimization flags

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

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

--- Comment #3 from Sam James  ---
ASAN says:

==3038484==ERROR: AddressSanitizer: global-buffer-overflow on address
0x5bb17fa7e4a1 at pc 0x5bb17fa794c3 bp 0x7ffdda66b1e0 sp 0x7ffdda66b1d0
READ of size 1 at 0x5bb17fa7e4a1 thread T0
#0 0x5bb17fa794c2 in v /tmp/p.c:19
#1 0x5bb17fa794c2 in h /tmp/p.c:25
#2 0x5bb17fa794c2 in r /tmp/p.c:35
#3 0x5bb17fa784aa in main /tmp/p.c:48
#4 0x7d58a6203746 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#5 0x7d58a62037f6 in __libc_start_main_impl ../csu/libc-start.c:360
#6 0x5bb17fa78510 in _start (/tmp/p+0x510)

0x5bb17fa7e4a1 is located 0 bytes after global variable 'c' defined in
'/tmp/p.c:5:6' (0x5bb17fa7e4a0) of size 1
  'c' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow /tmp/p.c:19 in v
Shadow bytes around the buggy address:
  0x5bb17fa7e200: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x5bb17fa7e280: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x5bb17fa7e300: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x5bb17fa7e380: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x5bb17fa7e400: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
=>0x5bb17fa7e480: f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x5bb17fa7e500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x5bb17fa7e580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x5bb17fa7e600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x5bb17fa7e680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x5bb17fa7e700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[Bug modula2/117371] New: [14.2 Regression] type incompatibility between ‘INTEGER’ and ‘CARDINAL’

[ludovic--- via Gcc-bugs]

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

Bug ID: 117371
   Summary: [14.2 Regression] type incompatibility between
‘INTEGER’ and ‘CARDINAL’
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: ludo...@ludovic-brenta.org
  Target Milestone: ---

The following compiles and runs fine with gm2 13.0:

(* -*- mode: Modula-2; compile-command: "gm2 -fiso -g -O2 -o primes primes.mod"
-*- *)

MODULE primes;
FROM STextIO IMPORT WriteString, WriteLn, ReadChar;
FROM SWholeIO IMPORT WriteCard;
IMPORT RealMath;

PROCEDURE Compute_Primes (is_prime : ARRAY OF BOOLEAN);
VAR
 k, m : CARDINAL; (* line 10 *)
BEGIN
 FOR k := 1 TO HIGH (is_prime) DO is_prime[k] := TRUE; END;
 WriteCard (1, 1);
 WriteString (" ");
 FOR k := 2 TO HIGH (is_prime) DO
  IF is_prime[k] THEN
   WriteCard (k, 1);
   WriteString (" ");
  END;
  FOR m := k * k TO HIGH (is_prime) BY k DO (* line 20 *)
   is_prime[m] := FALSE;
  END;
 END;
 WriteLn;
END Compute_Primes;

VAR
 is_prime : ARRAY [1 .. 16 * 1024] OF BOOLEAN;
BEGIN
 Compute_Primes (is_prime);
END primes.


When recompiling the same with gm2 14.0, I get:

gm2 -fiso -g -O2 -o primes primes.mod
cc1gm2: error: In procedure ‘Compute_Primes’: type incompatibility between
‘INTEGER’ and ‘CARDINAL’

There is no indication on the location of the error.
If, at line 10, I change CARDINAL to INTEGER I get:

gm2 -fiso -g -O2 -o primes primes.mod
primes.mod:20:35: error: In procedure ‘Compute_Primes’: type incompatibility
between ‘INTEGER’ and ‘CARDINAL’
   20 |   FOR m := k * k TO HIGH (is_prime) BY k DO
  | ~~^~~~

Now there is a location for the error but I think the error is legit as
m, k, k*k, are INTEGER whereas HIGH returns a CARDINAL.  So I think the
bug is triggered by the original code where m and k are CARDINALs.

By the way:

gm2 --version -fiso -g -O2 -o primes primes.mod
gm2 (Debian 14.2.0-3) 14.2.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.

[Bug modula2/117371] [14.2 Regression] type incompatibility between ‘INTEGER’ and ‘CARDINAL’

[ludovic--- via Gcc-bugs]

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

--- Comment #1 from Ludovic Brenta  ---
And it just occurred to me that, when m and k are declared
INTEGER, perhaps the call to WriteCard (k, 1) should also be
flagged as an error?

[Bug jit/117275] test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by David Malcolm
:

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

commit r14-10856-gacc0b9ff9cf1bcfed63812ca223251485b6471b7
Author: David Malcolm 
Date:   Wed Oct 30 16:11:41 2024 -0400

jit: fix leak of pending_assemble_externals_set [PR117275]

My recent r15-4580-g779c0390e3b57d fix for resetting state in
varasm.cc introduced some noise to "make selftest-valgrind" and,
presumably, a memory leak in libgccjit:

==2462086== 160 (56 direct, 104 indirect) bytes in 1 blocks are definitely
lost in loss record 248 of 352
==2462086==at 0x5270E7D: operator new(unsigned long)
(vg_replace_malloc.c:342)
==2462086==by 0x1D1EB89: init_varasm_once() (varasm.cc:6806)
==2462086==by 0x181C845: backend_init() (toplev.cc:1826)
==2462086==by 0x181D41A: do_compile() (toplev.cc:2193)
==2462086==by 0x181D99C: toplev::main(int, char**) (toplev.cc:2371)
==2462086==by 0x378391D: main (main.cc:39)

Fixed thusly.

gcc/ChangeLog:
PR jit/117275
* varasm.cc (process_pending_assemble_externals): Reset
pending_assemble_externals_set to nullptr after deleting it.
(varasm_cc_finalize): Delete pending_assemble_externals_set.

Signed-off-by: David Malcolm 
(cherry picked from commit 7f41203f08b9948c1c636dc9d66571121c6c7793)
Signed-off-by: David Malcolm 

[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests

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

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

--- Comment #14 from Jonathan Wakely  ---
Aha, it needs a non-empty set of args, which can be ignored. So:

proc dg-gfortran-onepass { args } {
global DO_ONE_PASS 
set DO_ONE_PASS 1
puts "\nRunning dg-gfortran-onepass\n"
}

and then in the tests:

! { dg-gfortran-onepass "" }

[Bug jit/117275] test-functions.c.exe and test-tls.c.exe FAIL on ppc64le with an assertion failure

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:70f911bf547326a7b9ae6e116c65c22ce0cd0e65

commit r14-10855-g70f911bf547326a7b9ae6e116c65c22ce0cd0e65
Author: David Malcolm 
Date:   Wed Oct 30 16:11:40 2024 -0400

jit: reset state in varasm.cc [PR117275]

PR jit/117275 reports various jit test failures seen on
powerpc64le-unknown-linux-gnu due to hitting this assertion
in varasm.cc on the 2nd compilation in a process:

#2  0x763e67d0 in assemble_external_libcall (fun=0x72a4b1d8)
at ../../src/gcc/varasm.cc:2650
2650  gcc_assert (!pending_assemble_externals_processed);
(gdb) p pending_assemble_externals_processed
$1 = true

We're not properly resetting state in varasm.cc after a compile
for libgccjit.

Fixed thusly.

gcc/ChangeLog:
PR jit/117275
* toplev.cc (toplev::finalize): Call varasm_cc_finalize.
* varasm.cc (varasm_cc_finalize): New.
* varasm.h (varasm_cc_finalize): New decl.

Signed-off-by: David Malcolm 
(cherry picked from commit 779c0390e3b57d1eebd41bbfe43d1f329c91de6c)
Signed-off-by: David Malcolm 

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 59504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59504&action=edit
wrong code due to the wrong type being used

Attached is the gimple testcase for the wrong type being used and shows the
wrong code happening due to overflow happening when there was no overflow in
the first place.

[Bug c++/116208] `__ct_base ` is used instead of the ctor name in warning's `inlined from` when using LTO

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

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

--- Comment #9 from Sam James  ---
(In reply to Simon Martin from comment #8)
> [...]
> How do you reproduce this? Are you configuring with
> --with-build-config=bootstrap-lto?

Sorry for the delay -- I just confirmed I can reproduce it on trunk with just
./configure --with-build-config="bootstrap-lto":

```
/tmp/build/./prev-gcc/xg++ -B/tmp/build/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
-I/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/home/sam/git/gcc/libstdc++-v3/libsupc++
-L/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs  -fno-PIE -c
 -DIN_GCC_FRONTEND -g -O2 -fno-checking -flto=jobserver -frandom-seed=1
-DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings  -DHAVE_CONFIG_H -fno-PIE -I. -I.
-I/home/sam/git/gcc/gcc -I/home/sam/git/gcc/gcc/.
-I/home/sam/git/gcc/gcc/../include  -I/home/sam/git/gcc/gcc/../libcpp/include
-I/home/sam/git/gcc/gcc/../libcody  -I/home/sam/git/gcc/gcc/../libdecnumber
-I/home/sam/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/sam/git/gcc/gcc/../libbacktrace   -o cc1plus-checksum.o -MT
cc1plus-checksum.o -MMD -MP -MF ./.deps/cc1plus-checksum.TPo
cc1plus-checksum.cc
make[3]: Leaving directory '/tmp/build/gcc'
/tmp/build/./prev-gcc/xg++ -B/tmp/build/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 
-I/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/home/sam/git/gcc/libstdc++-v3/libsupc++
-L/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -no-pie   -g
-O2 -fno-checking -flto=jobserver -frandom-seed=1 -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings  -DHAVE_CONFIG_H -no-pie
-static-libstdc++ -static-libgcc  -o cc1plus \
  cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o
cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o
cp/cp-ubsan.o cp/cvt.o cp/contracts.o cp/cxx-pretty-print.o cp/decl.o
cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o
cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/mapper-client.o
cp/mapper-resolver.o cp/method.o cp/module.o cp/name-lookup.o cp/optimize.o
cp/parser.o cp/pt.o cp/ptree.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o
cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o
c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o
c-family/c-spellcheck.o c-family/c-type-mismatch.o i386-c.o glibc-c.o
cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcody/libcody.a \
libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -lmpc -lmpfr -lgmp
-rdynamic  -L./../zlib -lz -lzstd
In function ‘release’,
inlined from ‘release’ at /home/sam/git/gcc/gcc/vec.h:2027:20,
inlined from ‘__dt_base ’ at /home/sam/git/gcc/gcc/vec.h:1686:19,
inlined from ‘can_be_handled’ at
/home/sam/git/gcc/gcc/tree-switch-conversion.cc:1890:1:
/home/sam/git/gcc/gcc/vec.h:347:10: warning: ‘free’ called on unallocated
object ‘dest_bbs’ [-Wfree-nonheap-object]
  347 |   ::free (v);
  |  ^
/home/sam/git/gcc/gcc/tree-switch-conversion.cc: In function ‘can_be_handled’:
/home/sam/git/gcc/gcc/tree-switch-conversion.cc:1862:39: note: declared here
 1862 |   auto_vec dest_bbs;
  |   ^
```

[Bug rtl-optimization/117360] [15 regression] ext-dce.cc:573:15: runtime error: shift exponent 127 is too large for 64-bit type 'long long unsigned int'

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
(In reply to Jakub Jelinek from comment #1)
> While you're at it, the ULL uses in ext-dce.cc should be
> HOST_WIDE_INT_UC () or 1ULL should be HOST_WIDE_INT_1U.

It might also be a wise idea in these cases where a shift
is a computed amount, to have a sanity check to make sure
that the shift is <= sizeof( type) * 8.

Something like 

assert( GET_MODE_BITSIZE (mode).to_constant () - 1 <= sizeof( unsigned long
long));

in the faulty code.

[Bug libstdc++/117372] New: std::list pretty printer: AttributeError: 'NoneType' object has no attribute 'pointer'

[simon.marchi at polymtl dot ca via Gcc-bugs]

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

Bug ID: 117372
   Summary: std::list pretty printer: AttributeError: 'NoneType'
object has no attribute 'pointer'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

I got this while debugging gdb with gdb.  I have not been able to make a small
reproducer yet.

Steps:

1. Checkout binutils-gdb at commit 35d53ce6429a
2. configure with: ./configure 'CFLAGS=-g3 -O0' 'CXXFLAGS=-g3 -O0'
3. make
4. start gdb: ./gdb
5. attach using system gdb, or some other gdb configured to find the libstdc++
pretty printers
6. print current_program_space.objfiles_list

What I get is

(top-gdb) p current_program_space.objfiles_list
$1 = empty std::__cxx11::listTraceback (most recent call last):
  File "/usr/share/gcc-14.2.1/python/libstdcxx/v6/printers.py", line 422, in
children
nodetype = lookup_node_type('_List_node', self._val.type).pointer()
   ^^
AttributeError: 'NoneType' object has no attribute 'pointer'


It's the result of `lookup_node_type` that is None.

The system gcc version is "gcc (GCC) 14.2.1 20240910" (Arch Linux package)

The system gdb version used to attach is 15.2 (Arch Linux package)

[Bug rtl-optimization/116783] [14 Regression] Wrong code at -O2 with late pair fusion pass (wrong alias analysis)

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

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

--- Comment #8 from Alex Coplan  ---
Should be fixed everywhere, I'll leave this open for a bit until we get
confirmation that this fixes the Debian package build with GCC 14, though.

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
I have a fix which I will be testing fully soon.

I think I can write a gimple testcase ...

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

--- Comment #15 from ak at gcc dot gnu.org ---
I guess to debug have to figure what's different about the decl between the non
autofdo case and autofdo.

I tried to work around it by modifying the urlifier code to avoid the anonymous
name space, but it hits a similar bug later in gimple-range-fold.cc. Here is a
full build log of that attempt: http://firstfloor.org/~andi/l

/home/ak/gcc/obj-auto/./prev-gcc/xg++ -B/home/ak/gcc/obj-auto/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/home/a
k/gcc/obj-auto/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/ak/gcc/obj-auto/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc+
+/.libs 
-I/home/ak/gcc/obj-auto/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/home/ak/gcc/obj-auto/prev-x86_
64-pc-linux-gnu/libstdc++-v3/include  -I/home/ak/gcc/gcc/libstdc++-v3/libsupc++
-L/home/ak/gcc/obj-auto/prev-x86_64-pc-linux-gnu/libs
tdc++-v3/src/.libs
-L/home/ak/gcc/obj-auto/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c   -g -O2 -fchecking=1 -
flto=jobserver -frandom-seed=1 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwri
te-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variad
ic-macros -Wno-overlength-strings  -DHAVE_CONFIG_H -fno-PIE
-fauto-profile=cc1plus.fda -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include  -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc
/../libdecnumber/bid -I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o
gimple-range-fold.o -MT gimple-range-fold.o -MMD -MP -MF
./.deps/gimple-range-fold.TPo ../../gcc/gcc/gimple-range-fold.cc
0x27a4b3f internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:518
0x9bb2a5 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1693
0x9bdd90 format_phase_2
../../gcc/gcc/pretty-print.cc:2162
0x9bdd90 pretty_printer::format(text_info&)
../../gcc/gcc/pretty-print.cc:1712
0x282925e pp_format(pretty_printer*, text_info*)
../../gcc/gcc/pretty-print.h:602
0x282925e pp_format_verbatim(pretty_printer*, text_info*)
../../gcc/gcc/pretty-print.cc:2340
0x282925e pp_verbatim(pretty_printer*, char const*, ...)
../../gcc/gcc/pretty-print.cc:2619
0xae1ea3 print_instantiation_full_context
../../gcc/gcc/cp/error.cc:3807
0xae1ea3 maybe_print_instantiation_context
../../gcc/gcc/cp/error.cc:3962
0xae1ea3 maybe_print_instantiation_context 

../../gcc/gcc/cp/error.cc:3956
0x13adc56 default_tree_diagnostic_text_starter
../../gcc/gcc/tree-diagnostic.cc:52
0x27a2ba0 diagnostic_text_output_format::on_report_diagnostic(diagnostic_info
const&, diagnostic_t)
../../gcc/gcc/diagnostic-format-text.cc:210
0x27a3f62 diagnostic_context::report_diagnostic(diagnostic_info*)
0x27a434e diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
../../gcc/gcc/diagnostic.cc:1585
0x27a4b3f internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:518
0x9bb2a5 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1693
0x750805 write_unscoped_name
../../gcc/gcc/cp/mangle.cc:1197
0xb22496 write_unscoped_template_name
../../gcc/gcc/cp/mangle.cc:1215
0xb22496 write_name
../../gcc/gcc/cp/mangle.cc:1122
0xb23729 write_encoding
../../gcc/gcc/cp/mangle.cc:939
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.

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

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

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

--- Comment #11 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Peter Bergner from comment #4)
> > These die because the struct we're using to check the alignment of uses long
> > double as the "big" aligned type.  We could either disable the tests using a
> > "dg-require-effective-target longdouble128" or we could use a different more
> > aligned type in the struct.  Maybe _Float128 or _Decimal128 or use an
> > attribute aligned?   Thoughts?
> 
> Maybe just some vector type?  Those have 128-bit alignment even with
> -mno-altivec,
> right?

Actually, this fixes the two failing test cases for us.  i386, rs6000, pa and
ia64 ports all set that.  If people don't like that, I suppose we could just
add a test for __powerpc__ in addition to the i386 test.  Thoughts?

diff --git a/gcc/ginclude/stddef.h b/gcc/ginclude/stddef.h
index acac631c649..231c55f22d1 100644
--- a/gcc/ginclude/stddef.h
+++ b/gcc/ginclude/stddef.h
@@ -430,7 +430,7 @@ typedef struct {
  use __float128 here; that is only available on some
  architectures, but only on i386 is extra alignment needed for
  __float128.  */
-#ifdef __i386__
+#ifdef __SIZEOF_FLOAT128__
   __float128 __max_align_f128
__attribute__((__aligned__(__alignof(__float128;
 #endif
 } max_align_t;

[Bug c++/116731] Incorrect behavior of -Wrange-loop-construct in GCC 14

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

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

--- Comment #6 from Marek Polacek  ---
(In reply to Sunil Dora from comment #5)
> Dear GCC Team,
> 
> I am writing to request the backport of this fix (Wrange-loop-construct) to
> GCC version 13.3. Due to particular project requirements, we are unable to
> upgrade our GCC version at this time. This fix not only supports our project
> but could also benefit other community members facing similar constraints.
> 
> To implement the trivially constructible check in GCC 13.3, I identified
> that it requires the use of TREE_VEC instead of TREE_LIST. However, the
> following dependent patches are missing in this version:
> 
> Commit 58b7dbf865b146a4e65dbda9be6df78f212c03b6
> Commit 76fa66ea397cb255ab1d68a90ff6b878236e9620
> Commit d180a5524ccdab8ef839ee55efecf60ce5b0240b

These patches are definitely not backportable to 13.

I need to see if we can backport the patch without also introducing invasive
changes, but I've been busy with stage 1 work.

> I have tested the upstream fix, along with the dependent patches, and can
> confirm that it works as expected in version 13.3.
> 
> Would it be appropriate for me to submit a patch for GCC 13.3 that
> incorporates these changes?
> 
> Thank you for your consideration. I look forward to your guidance on how to
> proceed.

[Bug c++/117370] std::nothrow variants of operator new are not optimized away when block is unused

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 59503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59503&action=edit
gcc15-pr117370-1.patch

The C++ FE marks now 12 out of the 20 global replaceable operator new/delete
with DECL_IS_REPLACEABLE_OPERATOR (in particular the ones that it predeclares),
but doesn't mark those with const std::nothrow_t& last argument.

This patch marks even those, on the suggestion from Jason in grok_op_properties
rather than by predeclaring those too.

The patch alone isn't enough, we need more code in tree-ssa-dce.cc or
elsewhere.
The thing is that for the throwing operator new, evrp figures out it will never
return NULL and so will optimize away the if (a) conditional around operator
delete to if (true).  But that is not the case for the nothrow, the function
can return NULL and then the question is what we are willing to optimize away,
if just the case where only the delete call is skipped and perhaps clobber and
maybe some dead stores to it before delete, or if the operator new returning
NULL branch can be simply optimized away no matter what it does.

That isn't really specific to the nothrow operator new,
void
foo (int x)
{
  int *a = (int *) __builtin_malloc (x);
  if (a)
__builtin_free (a);
}
is exactly the same thing, we also don't DCE that.

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> I think I can write a gimple testcase ...
```
unsigned __GIMPLE ()
test2 (int n)
{
  unsigned t;
  _Bool _3;
  t_2 = (unsigned)n_1(D);
  t_3 = t_2 - 1u;
  n_5 = (signed) t_3;
  _3 = n_1(D) != 0;
  n_6 = _3 ? n_5 : 0;
  return n_6;
}
```

Note I will also fix up the nop_convert's too. they should be nop_convert1 and
nop_convert2. But then the minus in this case should be in inner type rather
than the outter for overflow reasons.

[Bug analyzer/117373] New: [15 regression] -Wunused-parameter warning in analyzer/infinite-loop.cc

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

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

Bug ID: 117373
   Summary: [15 regression] -Wunused-parameter warning in
analyzer/infinite-loop.cc
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

x86_64-pc-linux-gnu-g++  -fPIC -c -DDEF_GENTOO_SCP -DDEF_GENTOO_ZNOW
-DEXTRA_OPTIONS_CF -DEXTRA_OPTIONS -DGENTOO_FORTIFY_SOURCE_LEVEL=3
-DDEF_GENTOO_GLIBCXX_ASSERTIONS -O3 -march=nat
ive -fno-semantic-interposition -mtls-dialect=gnu2 -fdiagnostics-color=always
-Wa,-O2 -Wa,-mtune=znver4 -pipe -Werror=strict-aliasing
-Werror=lto-type-mismatch -Werror=odr -ggdb3 -DI
N_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-error=narrowing -Wwrite-strings -Wcast-qual   -DHAVE_CONFIG_H -fPIC -I.
-Ianalyzer -I/var/tmp/portage/sys-de
vel/gcc-15.0./work/gcc-15.0./gcc
-I/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/analyzer
-I/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/../i
nclude 
-I/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/../libcpp/include
-I/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/../libcody 
-I/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/../libdecnumber
-I/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/../libdecnumber/bid
-I../libdecnumber
-I/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/../libbacktrace
  -o analyzer/infinite-loop.o -MT analyzer/infinite-loop.o -MMD -MP -MF
analyzer/.deps/infinite-loop.TPo
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/analyzer/infinite-loop.cc
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/analyzer/infinite-loop.cc:
In member function ‘virtual bool
infinite_loop_diagnostic::describe_final_event(pretty_printer&, const
ana::evdesc::final_event&)’:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/analyzer/infinite-loop.cc:226:52:
warning: unused parameter ‘ev’ [-Wunused-parameter]
  226 | const evdesc::final_event &ev) final override
  | ~~~^~

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > I think I can write a gimple testcase ...

I messed up that. Still looking to see if I can get a gimple testcase.

[Bug c++/116731] Incorrect behavior of -Wrange-loop-construct in GCC 14

[sunil.dora1988 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Sunil Dora  ---
Dear GCC Team,

I am writing to request the backport of this fix (Wrange-loop-construct) to GCC
version 13.3. Due to particular project requirements, we are unable to upgrade
our GCC version at this time. This fix not only supports our project but could
also benefit other community members facing similar constraints.

To implement the trivially constructible check in GCC 13.3, I identified that
it requires the use of TREE_VEC instead of TREE_LIST. However, the following
dependent patches are missing in this version:

Commit 58b7dbf865b146a4e65dbda9be6df78f212c03b6
Commit 76fa66ea397cb255ab1d68a90ff6b878236e9620
Commit d180a5524ccdab8ef839ee55efecf60ce5b0240b

I have tested the upstream fix, along with the dependent patches, and can
confirm that it works as expected in version 13.3.

Would it be appropriate for me to submit a patch for GCC 13.3 that incorporates
these changes?

Thank you for your consideration. I look forward to your guidance on how to
proceed.

[Bug c++/117158] [12/13/14/15 Regression] ICE with array access inside a template with a base class

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #2 from Simon Martin  ---
Working on it. We get an ICE with c++ > 14; earlier versions work fine.

[Bug rtl-optimization/116783] [14 Regression] Wrong code at -O2 with late pair fusion pass (wrong alias analysis)

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Alex Coplan
:

https://gcc.gnu.org/g:434483ac32a08d1f3608c26fe2da302f0e09d6a2

commit r14-10853-g434483ac32a08d1f3608c26fe2da302f0e09d6a2
Author: Alex Coplan 
Date:   Wed Oct 30 13:46:12 2024 +

aarch64: Assume alias conflict if common address reg changes [PR116783]

As the PR shows, pair fusion was tricking memory_modified_in_insn_p into
returning false when a common base register (in this case, x1) was
modified between the mem and the store insn.  This lead to wrong code as
the accesses really did alias.

To avoid this sort of problem, this patch avoids invoking RTL alias
analysis altogether (and assume an alias conflict) if the two insns to
be compared share a common address register R, and the insns see different
definitions of R (i.e. it was modified in between).

This is a backport (but not a straight cherry pick) of
r15-4518-gc0e54ce1999ccf2241f74c5188b11b92e5aedc1f.

gcc/ChangeLog:

PR rtl-optimization/116783
* config/aarch64/aarch64-ldp-fusion.cc
(def_walker::cand_addr_uses): New.
(def_walker::def_walker): Add parameter for candidate address
uses.
(def_walker::alias_conflict_p): Declare.
(def_walker::addr_reg_conflict_p): New.
(def_walker::conflict_p): New.
(store_walker::store_walker): Add parameter for candidate
address uses and pass to base ctor.
(store_walker::conflict_p): Rename to ...
(store_walker::alias_conflict_p): ... this.
(load_walker::load_walker): Add parameter for candidate
address uses and pass to base ctor.
(load_walker::conflict_p): Rename to ...
(load_walker::alias_conflict_p): ... this.
(ldp_bb_info::try_fuse_pair): Collect address register
uses for candidate insns and pass down to alias walkers.

gcc/testsuite/ChangeLog:

PR rtl-optimization/116783
* g++.dg/torture/pr116783.C: New test.

[Bug fortran/115700] [12/13 regression] Bogus warning for associate with assumed-length character array

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

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|anlauf at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #10 from Paul Thomas  ---
Created attachment 59502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59502&action=edit
Fix for comment 5 of this PR

Is regtesting right now.

Fortran: Fix problem with substring selectors in ASSOCIATE [PR115700]

2024-10-30  Paul Thomas  

gcc/fortran
PR fortran/115700
* resolve.cc (resolve_variable): The typespec of an expression,
which is not a substring, can be shared with a deferred length
associate name.
(resolve_assoc_var): Extract a substring reference with non-
constant start or end. Use it to flag up the need for array
associate name to be a pointer.
(resolve_block_construct): Change comment from past to future
tense.

gcc/testsuite/
PR fortran/115700
* gfortran.dg/associate_70.f90: New test.

[Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time

[juergen.reuter at desy dot de via Gcc-bugs]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #5 from Jürgen Reuter  ---
so this is "just" the backport to older versions missing?

[Bug c++/117374] New: Strange behavior of co_yield in initializer-list

[ddvamp007 at gmail dot com via Gcc-bugs]

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

Bug ID: 117374
   Summary: Strange behavior of co_yield in initializer-list
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ddvamp007 at gmail dot com
  Target Milestone: ---

#include 
#include 

struct Promise;

using HandleBase = std::coroutine_handle;

struct Promise {
HandleBase get_return_object() { return HandleBase::from_promise(*this); }
std::suspend_always initial_suspend() { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }
void return_void() {}
void unhandled_exception() {}

int x = -1;

auto yield_value(int value) {
struct Awaiter {
int &slot;
int value;

Awaiter(int &r, int v) : slot(r), value(v) {
// slot = value;
}

bool await_ready() { return false; }
void await_suspend(HandleBase) {}
int await_resume() { return slot = value; }
};

return Awaiter(x, value);
}
};

struct Handle : HandleBase {
using promise_type = Promise;

Handle(HandleBase b) : HandleBase(std::move(b)) {}

int operator() () {
HandleBase::operator()();
return promise().x;
}
};

Handle Coro() {
int x = 0;

int arr[] = {co_yield x++, co_yield x++, co_yield x++};

std::cout << "In coro arr: [" << arr[0] << ", " << arr[1] << ", " << arr[2]
<< ']';
}

int main() {
auto gen = Coro();

int arr[] = {gen(), gen(), gen()};
auto last = gen();

std::cout << "\nIn main arr: [" << arr[0] << ", " << arr[1] << ", " <<
arr[2] << ']';

std::cout << "\nlast: " << last;

gen.destroy();

return 0;
}

In godbolt gcc 14.2 and gcc (trunk)

This code prints:
  In coro arr: [0, 1, 2]
  In main arr: [-1, -1, -1]
  last: 2

If undo comment in Awaiter constructor:
  In coro arr: [0, 1, 2]
  In main arr: [2, 2, 2]
  last: 2

[Bug middle-end/117375] New: ICE with -fdiagnostics-details patch in sink pass

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

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

Bug ID: 117375
   Summary: ICE with -fdiagnostics-details patch in sink pass
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: qing.zhao at oracle dot com
  Target Milestone: ---

This is with using the RFC/uncommitted patch at
https://inbox.sourceware.org/gcc-patches/20241030141749.4029995-1-qing.z...@oracle.com/,
but it is easier to report here as I have attachments.

```
# gcc -c ./celt/libopus-celt.a.p/celt_encoder.c.i -fdiagnostics-details -O2
during GIMPLE pass: sink
../opus-1.5.2/celt/celt_encoder.c: In function ‘compute_mdcts’:
../opus-1.5.2/celt/celt_encoder.c:461:13: internal compiler error: Segmentation
fault
  461 | static void compute_mdcts(const CELTMode *mode, int shortBlocks,
celt_sig * OPUS_RESTRICT in,
  | ^
0x55d55e4480d5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x55d55e30a832 internal_error(char const*, ...)
???:0
0x55d55e251be6 set_move_history_to_stmt(gimple*, edge_def*, bool, move_reason)
???:0
0x55d55e5c2361 execute_pass_list(function*, opt_pass*)
???:0
0x55d55e4e9d69 cgraph_node::expand()
???:0
0x55d55e4b1d15 symbol_table::compile()
???:0
0x55d55ecece11 symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
```

[Bug middle-end/117375] ICE with -fdiagnostics-details patch in sink pass when building opus-1.5.2

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE with|ICE with
   |-fdiagnostics-details patch |-fdiagnostics-details patch
   |in sink pass|in sink pass when building
   ||opus-1.5.2
   Keywords||ice-on-valid-code

--- Comment #2 from Sam James  ---
Hi Qing, I found this ICE, let me know if you need any more details.

[Bug middle-end/117379] Failure to vectorize multi add + mulit sub

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||53947
   Severity|normal  |enhancement
   Keywords||missed-optimization


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/117379] Failure to vectorize multi add + mulit sub

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|middle-end  |tree-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-31

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

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #2 from Richard Biener  ---
There's a conversion missing, @0 is of the comparison value type.

[Bug target/117318] ICE: in expand_simple_unop, at optabs.cc:2585 with __builtin_ia32_pmovusqb512mem_mask()

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:71a0cf699b6a2dc03abec53aeafab8b70db2bb07

commit r14-10852-g71a0cf699b6a2dc03abec53aeafab8b70db2bb07
Author: liuhongt 
Date:   Tue Oct 29 02:09:39 2024 -0700

Fix ICE due to subreg:us_truncate.

Force_operand issues an ICE when input
is (subreg:DI (us_truncate:V8QI)), it's probably because it's an
invalid rtx, So refine backend patterns for that.

gcc/ChangeLog:

PR target/117318
* config/i386/sse.md (*avx512vl_v2div2qi2_mask_store_1):
Rename to ..
(avx512vl_v2div2qi2_mask_store_1): .. this.
(avx512vl_v2div2qi2_mask_store_2): Change to
define_expand.
(*avx512vl_v4qi2_mask_store_1): Rename to ..
(avx512vl_v4qi2_mask_store_1): .. this.
(avx512vl_v4qi2_mask_store_2): Change to
define_expand.
(*avx512vl_v8qi2_mask_store_1): Rename to ..
(avx512vl_v8qi2_mask_store_1): .. this.
(avx512vl_v8qi2_mask_store_2): Change to
define_expand.
(*avx512vl_v4hi2_mask_store_1): Rename to ..
(avx512vl_v4hi2_mask_store_1): .. this.
(avx512vl_v4hi2_mask_store_2): Change to
define_expand.
(*avx512vl_v2div2hi2_mask_store_1): Rename to ..
(avx512vl_v2div2hi2_mask_store_1): .. this.
(avx512vl_v2div2hi2_mask_store_2): Change to
define_expand.
(*avx512vl_v2div2si2_mask_store_1): Rename to ..
(avx512vl_v2div2si2_mask_store_1): .. this.
(avx512vl_v2div2si2_mask_store_2): Change to
define_expand.
(*avx512f_v8div16qi2_mask_store_1): Rename to ..
(avx512f_v8div16qi2_mask_store_1): .. this.
(avx512f_v8div16qi2_mask_store_2): Change to
define_expand.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit bc0eeccf27a084461a2d5661e23468350acb43da)

[Bug c++/117364] [12/13/14/15 Regression][coroutines] Use of triggers an ICE on sparc

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.5

--- Comment #5 from Richard Biener  ---
(In reply to Eric Botcazou from comment #4)
> > Apologies for being slow here - which, specific, construct are you
> > considering questionable?
> 
> MEM[(struct Handle *)&] = SR.40_20;
> 
> when  is not addressable at the RTL level.

Note MEM_EXPR expansion "works fine" when the base is a register, in this
case it serves merely as changing TBAA.

[Bug target/117318] ICE: in expand_simple_unop, at optabs.cc:2585 with __builtin_ia32_pmovusqb512mem_mask()

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by hongtao Liu
:

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

commit r12-10793-gd0a932fb53ccdf5155db90632901c55446b8
Author: liuhongt 
Date:   Tue Oct 29 02:09:39 2024 -0700

Fix ICE due to subreg:us_truncate.

Force_operand issues an ICE when input
is (subreg:DI (us_truncate:V8QI)), it's probably because it's an
invalid rtx, So refine backend patterns for that.

gcc/ChangeLog:

PR target/117318
* config/i386/sse.md (*avx512vl_v2div2qi2_mask_store_1):
Rename to ..
(avx512vl_v2div2qi2_mask_store_1): .. this.
(avx512vl_v2div2qi2_mask_store_2): Change to
define_expand.
(*avx512vl_v4qi2_mask_store_1): Rename to ..
(avx512vl_v4qi2_mask_store_1): .. this.
(avx512vl_v4qi2_mask_store_2): Change to
define_expand.
(*avx512vl_v8qi2_mask_store_1): Rename to ..
(avx512vl_v8qi2_mask_store_1): .. this.
(avx512vl_v8qi2_mask_store_2): Change to
define_expand.
(*avx512vl_v4hi2_mask_store_1): Rename to ..
(avx512vl_v4hi2_mask_store_1): .. this.
(avx512vl_v4hi2_mask_store_2): Change to
define_expand.
(*avx512vl_v2div2hi2_mask_store_1): Rename to ..
(avx512vl_v2div2hi2_mask_store_1): .. this.
(avx512vl_v2div2hi2_mask_store_2): Change to
define_expand.
(*avx512vl_v2div2si2_mask_store_1): Rename to ..
(avx512vl_v2div2si2_mask_store_1): .. this.
(avx512vl_v2div2si2_mask_store_2): Change to
define_expand.
(*avx512f_v8div16qi2_mask_store_1): Rename to ..
(avx512f_v8div16qi2_mask_store_1): .. this.
(avx512f_v8div16qi2_mask_store_2): Change to
define_expand.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit bc0eeccf27a084461a2d5661e23468350acb43da)

[Bug c/117367] New: Miscompile with different optimization flags

[yunboni at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 117367
   Summary: Miscompile with different optimization flags
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

Created attachment 59499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59499&action=edit
The preprocessed file

When I compiled this code with O2 and O3 flags, its outputs were different: 

#define a() 0
#include 
#include 
char c[];
char *d;
int32_t e;
uint32_t f[];
const int32_t *i;
int b() {}
int v(int n, char *o) {
  char *g = o;
  d = c;
  while (n) {
d++;
n /= 10;
  }
  while (d != c)
*g++ = *--d;
  *g++ = '\0';
  return g - o - 1;
}
int h(int n, char) {
  char p[3];
  int l = v(n, p);
  return l;
}
void m() {}
const int32_t *q();
uint16_t r() {
  int16_t s[1][3][2];
  int32_t *t = &e, j, k;
  for (; j < 3; j++)
for (k = 0; k < 2; k++)
  s[h(53, 0) - 2][j][k] = 1;
  if ((*t = b() - 1 + s[0][0][1]) != m)
;
  else
for (;;)
  if (*i)
if (f[a()]) {
  const int32_t **u = &i;
  *u = q();
}
}
const int32_t *q() {}
int main() {
  r();
  printf("%d\n", e);
}

For O2, its output is: 0
For O3, its output is: -1

The details can be found here: https://godbolt.org/z/334KGnj77

[Bug c/117368] New: Miscompile with different optimization flags

[yunboni at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 117368
   Summary: Miscompile with different optimization flags
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

Created attachment 59500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59500&action=edit
The preprocessed file

When I compiled this code with O2 and O3 flags, its outputs were different: 

#define a() 0
#include 
#include 
char c[];
char *d;
int32_t e;
uint32_t f[];
const int32_t *i;
int b() {}
int v(int n, char *o) {
  char *g = o;
  d = c;
  while (n) {
d++;
n /= 10;
  }
  while (d != c)
*g++ = *--d;
  *g++ = '\0';
  return g - o - 1;
}
int h(int n, char) {
  char p[3];
  int l = v(n, p);
  return l;
}
void m() {}
const int32_t *q();
uint16_t r() {
  int16_t s[1][3][2];
  int32_t *t = &e, j, k;
  for (; j < 3; j++)
for (k = 0; k < 2; k++)
  s[h(53, 0) - 2][j][k] = 1;
  if ((*t = b() - 1 + s[0][0][1]) != m)
;
  else
for (;;)
  if (*i)
if (f[a()]) {
  const int32_t **u = &i;
  *u = q();
}
}
const int32_t *q() {}
int main() {
  r();
  printf("%d\n", e);
}

For O2, its output is: 0
For O3, its output is: -1

The details can be found here: https://godbolt.org/z/334KGnj77

[Bug c/117367] Miscompile with different optimization flags

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
Needs -fno-stack-protector if defaulting to SSP.

[Bug c/117367] [14/15 regression] Miscompile with different optimization flags

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.3
  Known to work||13.3.1
  Known to fail||14.2.1, 15.0
Summary|Miscompile with different   |[14/15 regression]
   |optimization flags  |Miscompile with different
   ||optimization flags
   Keywords||wrong-code

[Bug c/117368] Miscompile with different optimization flags

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
Dupe.

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

[Bug c/117367] Miscompile with different optimization flags

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

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

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

[Bug analyzer/117369] New: False positive Wanalyzer-out-of-bounds fanalyzer warnings for sprintf to offset at -O1 and above

[zany at triq dot net via Gcc-bugs]

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

Bug ID: 117369
   Summary: False positive Wanalyzer-out-of-bounds fanalyzer
warnings for sprintf to offset at -O1 and above
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zany at triq dot net
  Target Milestone: ---

With  gcc (Debian 14.2.0-6) 14.2.0
on  Linux 6.11.4-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.4-1
(2024-10-20) x86_64 GNU/Linux
using GCC from https://packages.debian.org/trixie/gcc-14 as installed in
https://cloud.debian.org/images/cloud/trixie/daily/20241028-1914/debian-13-genericcloud-amd64-daily-20241028-1914.json
with additional $ sudo apt-get install build-essential

for this program with relevant #include  expanded for brevity:

extern int sprintf (char *__restrict __s,
  const char *__restrict __format, ...) __attribute__ ((__nothrow__));
int main() {
char buf[16];
sprintf(buf + 1, ".");
}

gcc -O1 -fanalyzer -c test.c
(also -Os, -O2, -O3, but -O0 does not report this)

We get a false positive -Wanalyzer-out-of-bounds warning:

test.c: In function ‘main’:
test.c:5:5: warning: stack-based buffer overflow [CWE-121]
[-Wanalyzer-out-of-bounds]
5 | sprintf(buf + 1, ".");
  | ^
  ‘main’: events 1-2
|
|4 | char buf[16];
|  |  ^~~
|  |  |
|  |  (1) capacity: 16 bytes
|5 | sprintf(buf + 1, ".");
|  | ~
|  | |
|  | (2) out-of-bounds write at byte 16 but ‘buf’ ends at byte 16
|
test.c:5:5: note: write of 1 byte to beyond the end of ‘buf’
5 | sprintf(buf + 1, ".");
  | ^
test.c:5:5: note: valid subscripts for ‘buf’ are ‘[0]’ to ‘[15]’

  ┌──┐
  │write of ‘char[16]’ (16 bytes)│
  └──┘
│   │   │
│   │   │
v   v   v
  ┌───┬───┬┬─┐ ┌─┐
  │[0]│...│[1] │  [15]   │ │ │
  ├───┴───┴┴─┤ │after valid range│
  │   ‘buf’ (type: ‘char[16]’)   │ │ │
  └──┘ └─┘
  ├──┬───┤ ├┬┤
 │  │
   ╭─┴╮  ╭──┴──╮
   │capacity: 16 bytes│  │⚠️  overflow of 1 byte│
   ╰──╯  ╰─╯

[Bug c/117367] [14/15 regression] Miscompile with different optimization flags

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Jakub Jelinek  ---
The testcase is garbage or reduced to garbage, there are tons of UBs in it.
E.g.
  int32_t *t = &e, j, k;
  for (; j < 3; j++)
j is uninitialized here.
h(53, 0) -> v(53, p) -> 
  d = c;
  while (n) {
d++;
as c is char c[];, d++ is another UB.  So is later dereferencing it.

[Bug c++/117364] [12/13/14/15 Regression][coroutines] Use of triggers an ICE on sparc

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

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

--- Comment #4 from Eric Botcazou  ---
> Apologies for being slow here - which, specific, construct are you
> considering questionable?

MEM[(struct Handle *)&] = SR.40_20;

when  is not addressable at the RTL level.

[Bug middle-end/117359] Stack pointer modifications in asm are not flagged in crtl->sp_is_unchanging

[schwab--- via Gcc-bugs]

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

--- Comment #12 from Andreas Schwab  ---
Neither is clobbering a register.

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-30
  Known to work||14.2.1
 CC||sjames at gcc dot gnu.org
  Known to fail||15.0

[Bug c++/117365] New: Captured this lost after assignment to std::function

[Koen.Poppe at vandewiele dot com via Gcc-bugs]

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

Bug ID: 117365
   Summary: Captured this lost after assignment to std::function
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Koen.Poppe at vandewiele dot com
  Target Milestone: ---

Created attachment 59498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59498&action=edit
Preprocessed source of minimal example

When cross compiling to ARM: a lambda with "this" captured stored into an
std::function looses the by-value captured this which results in a segmentation
fault if that this pointer is used.

Minimal program (main.cpp, preprocessed source attached):

#include 
#include 
#include 

#define CHECK(cond) do { if (cond){ std::cout << __LINE__ << ": '" #cond "' = "
<< "ok" << std::endl; } else { std::cerr << __LINE__ << ": '" #cond "' FAILED!"
<< std::endl; return __LINE__; } } while(false)

struct Class
{
using Fun = std::function;
int testWrapped()
{
Fun fun;
CHECK(!fun);
std::cout << "this = " << reinterpret_cast(this) <<
std::endl;
fun = [this]() -> Class* {
std::cout << "this captured in lambda = " <<
reinterpret_cast(this) << std::endl;
return this;
};
CHECK(fun);
CHECK(fun() == this);
std::cout << "lambda returns" << reinterpret_cast(fun());
return 0;
}
};

int main()
{
Class c;
return c.testWrapped();
}


Expected output of the attached program:

13: '!fun' = ok
this = 2127567732
19: 'fun' = ok
this captured in lambda = 2127567732
20: 'fun() == this' = ok

Actual output:

13: '!fun' = ok
this = 2127567732
19: 'fun' = ok
this captured in lambda = 135996
20: 'fun() == this' FAILED!

As this is compiling for an embedded target, I have not been able to run this
with a more recent version to check whether this is already fixed.


Output of gcc -v -save-temps:

compiling main.cpp
Using built-in specs.
COLLECT_GCC=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
Target: arm-poky-linux-gnueabi
Configured with: ../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/configure
--build=x86_64-linux --host=x86_64-pokysdk-linux
--target=arm-poky-linux-gnueabi
--prefix=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr
--exec_prefix=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr
--bindir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi
--sbindir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi
--libexecdir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi
--datadir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/share
--sysconfdir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/etc
--sharedstatedir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/com
--localstatedir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/var
--libdir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi
--includedir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/include
--oldincludedir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/include
--infodir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/share/info
--mandir=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/x86_64-pokysdk-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/tmp/work/tmp/sysroots/x86_64-nativesdk-pokysdk-linux
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix
--enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi-
--without-local-prefix --enable-lto --enable-libssp --enable-libitm
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/6.2.0
--with-build-time-tools=/tmp/work/tmp/sysroots/x86_64-linux/usr/arm-poky-linux-gnueabi/bin
--with-sysroot=/not/exist
--with-build-sysroot=/tmp/work/tmp/sysroots/imx6sololcc
--without-long-double-128 --enable-poison-system-directories
--with-mpfr=/tmp/work/tmp/sysroots/x86_64-nativesdk-pokysdk-linux
--with-mpc=/tmp/work/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --enable-nls
--enable-initfini-array --with-arch=armv7-a
Thread model: posix
gcc version 6.2.0 (GCC) 
COLLECT_GCC_OPTIONS='--sysroot=/opt/fsl-imx-x11/4.9.11-1.0.0/sysroots/cortexa9hf-neon-poky-linux-gnueabi'
'-march=armv7-a' '-mfpu=neon' '-mfloat-abi=hard' '-mcp

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15 regression] ICE during  |[15 regression] ICE during
   |GIMPLE pass: ldist  |GIMPLE pass: ldist since
   ||r15-4763-g4af8db3eca12b2
 CC||xuli1 at eswincomputing dot com

--- Comment #1 from Sam James  ---
r15-4763-g4af8db3eca12b2

[Bug fortran/117347] Associate with derived type array constructor

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Slightly reduced testcase:

program pr117347_red
  implicit none
  type :: point
 real :: x = 42.
  end type point
  type(point) :: mypoint
  real:: pi(1)
  associate (points =>  mypoint ) ! accepted
pi(:) = points% x
  end associate
  associate (points => (mypoint)) ! accepted
pi(:) = points% x
  end associate
  associate (points => [mypoint]) ! REJECTED
pi(:) = points% x
  end associate
  print *, pi
end program

[Bug c++/117364] [12/13/14/15 Regression][coroutines] Use of triggers an ICE on sparc

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

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

--- Comment #2 from Eric Botcazou  ---
> This does not seem morally different from NVRO.

Yes, that's perfectly fine.

> At present, I do not have a handle on where the actual issue is - since
> Rainer's and Eric's reports are from completely different phases in the
> lowering.

Either we should stop Early SRA from doing the transformation (and I agree that
this could also happen out of the regular NRVO) or we should enhance the RTL
expander to deal with this (questionable IMO) construct.

[Bug target/117365] Captured this lost after assignment to std::function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-30
 Target|arm-poky-linux-gnueabi-g++  |arm-*-linux-gnueabi
 Ever confirmed|0   |1
  Component|c++ |target
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
(In reply to Koen Poppe from comment #0)
> As this is compiling for an embedded target, I have not been able to run
> this with a more recent version to check whether this is already fixed.

Somebody needs to check this on a non-ancient release though.

[Bug middle-end/117354] ICE: in extract_bit_field_1, at expmed.cc:1838 with _BitInt (and asan in some cases)

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

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

--- Comment #9 from Jakub Jelinek  ---
Doesn't need -fsanitize=address, just ensuring the _BitInt(256) var is just
8-byte aligned is enough:
struct S {
  unsigned char y;
  _BitInt(256) x;
} s;

__attribute__((noipa)) static void
foo (const char *, _BitInt(256))
{
}

__attribute__((noipa)) static void
bar(_BitInt(256))
{
}

static void
baz (void *p)
{
  foo ("x = %llu\n", s.x);
  __builtin_memcpy (p, &s.x, sizeof s.x);
}

int
main ()
{
  void *ptr = &s.x;
  baz (&s.x);
  bar (*(_BitInt(256) *) ptr);
}

[Bug target/117312] RFE: x86 (and perhaps others): inline assembly: "red-zone" clobber

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

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

--- Comment #18 from Richard Biener  ---
I think ->sp_is_unchanging isn't the correct vehicle to test whether the red
zone is usable - as you point out the red zone might be used/clobbered so the
x86 backend would need to check for that, and a "memory" clobber should be
enough to indicate this might happen (even if that pessimizes other code).

[Bug libstdc++/104465] std::vector should satisfy std::ranges::viewable_range (P2415 for -c++2b)

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #7 from Patrick Palka  ---
P2415 has since been implemented for GCC 12+ by r12-7330-g5e1b17f038671d, so I
think we can close this.

[Bug middle-end/19779] IBM 128bit long double format is not constant folded.

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #16 from Segher Boessenkool  ---
It would be nice if we supported IEEE QP (as long double) on all PowerPC
implementations.  As some kind of soft float.  All code to do that is
already part of trunk, it "just" needs to be wired up!

It would allow us to do IEEE QP as long double by default, on any ABI,
on any PowerPC implementation.  We should have done this as the very first
thing, not start at the end as we did!