[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs

[rsworktech at outlook dot com via Gcc-bugs]

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

--- Comment #19 from Levi Zim  ---
Another trigger flag, a little surprisingly, is
-ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc in CFLAGS

[Bug rtl-optimization/119307] New: [15 Regression] ICE: in lra_rtx_hash, at lra.cc:1782 with -Os -mx32 -maddress-mode=long -fprofile-generate -ftrapv

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 119307
   Summary: [15 Regression] ICE: in lra_rtx_hash, at lra.cc:1782
with -Os -mx32 -maddress-mode=long -fprofile-generate
-ftrapv
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnux32

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -mx32 -maddress-mode=long -fprofile-generate
-ftrapv testcase.c 
during RTL pass: reload
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: in lra_rtx_hash, at lra.cc:1782
   11 | }
  | ^
0x2def3c1 internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:517
0xefbd65 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1722
0x81f05b lra_rtx_hash(rtx_def*)
/repo/gcc-trunk/gcc/lra.cc:1782
0x145a36f lra_rtx_hash(rtx_def*)
/repo/gcc-trunk/gcc/lra.cc:1765
0x2ec4415 htab_find_slot
/repo/gcc-trunk/libiberty/hashtab.c:703
0x147a8a7 insert_invariant
/repo/gcc-trunk/gcc/lra-constraints.cc:5676
0x147a8a7 process_invariant_for_inheritance
/repo/gcc-trunk/gcc/lra-constraints.cc:6567
0x147a8a7 inherit_in_ebb
/repo/gcc-trunk/gcc/lra-constraints.cc:6948
0x147a8a7 lra_inheritance()
/repo/gcc-trunk/gcc/lra-constraints.cc:7343
0x145d1ed lra(_IO_FILE*, int)
/repo/gcc-trunk/gcc/lra.cc:2478
0x140676f do_reload
/repo/gcc-trunk/gcc/ira.cc:5987
0x140676f execute
/repo/gcc-trunk/gcc/ira.cc:6175
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-20250315085318-r15-8068-g254549d2bb9bb3-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.1/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
--disable-bootstrap --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-20250315085318-r15-8068-g254549d2bb9bb3-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250315 (experimental) (GCC)

[Bug cobol/119308] New: Cobol ICE on "hello world" on POWER in rs6000_output_function_epilogue

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

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

Bug ID: 119308
   Summary: Cobol ICE on "hello world" on POWER in
rs6000_output_function_epilogue
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: cobol
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Thought I'd give gcobol a spin on POWER.

For the "Hello, world" program faithfully copied from Wikipedia, I get
on POWER (gcc120) with 53fc26e54fadb51c3f655286d4475625b82a12b1 :

[tkoenig@cfarm120 ~]$ cat hello.cob 
   IDENTIFICATION DIVISION.
   PROGRAM-ID. hello-world.
   PROCEDURE DIVISION.
   DISPLAY "Hello, world!"
   .
[tkoenig@cfarm120 ~]$ trunk-bin/gcc/cobol1  hello.cob

Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 1152k}  {heap 1152k} 
{heap 1152k}  {heap 1536k}  {heap 1536k}
 {heap 1536k}  {heap 1536k}Streaming LTO
  {heap 1536k}  {heap 1536k}  {heap 1536k}
 {heap 1536k}  {heap 1536k}  {heap 1536k}
 {heap 1536k}Assembling functions:
 hello$worldduring RTL pass: final
In function ‘hello$world’:
cobol1: internal compiler error: in rs6000_output_function_epilogue, at
config/rs6000/rs6000-logue.cc:5361
0x123585df internal_error(char const*, ...)
../../trunk/gcc/diagnostic-global-context.cc:517
0x1034f707 fancy_abort(char const*, int, char const*)
../../trunk/gcc/diagnostic.cc:1722
0x114a877b rs6000_output_function_epilogue(_IO_FILE*)
../../trunk/gcc/config/rs6000/rs6000-logue.cc:5361
0x1073765b final_end_function()
../../trunk/gcc/final.cc:1864
0x10740a5f rest_of_handle_final
../../trunk/gcc/final.cc:4258
0x10740a5f execute
../../trunk/gcc/final.cc:4328
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.

It seems that language_string being "GCC COBOL" is not handled in that
function.

[Bug cobol/119213] gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with hardcoded lib64

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #5 from Iain Sandoe  ---
(In reply to Richard Biener from comment #3)
> I suggest we try dropping this completely then?

In my experiments on x86_64 Darwin and Linux, I dropped everything except the
LIB_INCLUDE path (since the FE pulls in headers and source from the library).

That works fine - so I'd suggest we drop this stuff (and the corresponding
references to it in the gcobolspec.cc) and pick up any fallout in a more
specific way.

[Bug cobol/119241] cobol Front end uses host floating point (128b) support

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

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

--- Comment #5 from Iain Sandoe  ---
In my experiments with x86_64 Darwin and Linux, I have managed to convert the
library to use libquadmath.

I started to try and apply Jakub's suggestions to the FE for this BZ, since
what it is doing at the moment clearly cannot work in the general case (I think
it will be limited to native builds in general at the moment).

However, unfortunately I have not been able to figure out how all of this is
supposed to fit together:

 1. the FE pulls in a lot of library headers
 2. the FE pulls in some of the library sources
 3. the functions that make use of host 128b FP do not seem to have head
comments describing their purpose.

In short, I'm stuck (at least in the time I have available) in progressing this
- but suspect it's one of the most important changes to make in supporting the
"usual build process" for GCC.

Is there any kind of "internals manual" for cobol? (apologies if it is under my
nose and I missed it).

... in the short-term I have some heinous hacks that allow it to build (native)
on x86_64 Darwin, without breaking Linux .. but ...

[Bug ada/119309] New: Compiler continues to run indefinitely while processing code that contains errors.

[d.van.raaij at gmail dot com via Gcc-bugs]

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

Bug ID: 119309
   Summary: Compiler continues to run indefinitely while
processing code that contains errors.
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.van.raaij at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

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

The compiler continues to run indefinitely while processing the code attached
to this report. The code is expected to be rejected as it contains errors.

A cursory look with gdb suggests that the compiler is stuck in a loop in
`Find_Direct_Name' in sem_ch8.adb:

6394  while Present (E2) loop --  True
6395 if Is_Immediately_Visible (E2) then  --  True
..
6408if Scope (E) = Scope (E2) --  True
6409  and then Ekind (E) = E_Package  --  False
..
6419   for J in Level + 1 .. Scope_Stack.Last loop--  3 + 1
.. 3
..
6431 E2 := Homonym (E2);
6432  end loop;

*** Compiler output ***

$ gcc -c reproducer.ads


*** Compiler version ***

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-15.0.1-build/gcc-15.0.1-20250225/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250225 (Red Hat 15.0.1-0) (GCC)

[Bug cobol/119301] cobol FE uses get_current_dir_name unconditionally

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
The patch works for Darwin and does not break Linux, un-assigning myself.

[Bug cobol/119295] cobol, libcobol uses random_r which is GLIBC specific

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
patch works on Darwin and does not break Linux, un-assigning myself for now.

[Bug cobol/119295] cobol, libcobol uses random_r which is GLIBC specific

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

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

--- Comment #1 from Iain Sandoe  ---
Created attachment 60775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60775&action=edit
Patch tested on x86_64 Darwin and Linux

Unfortunately, we don't have a fallback on Darwin other than to use the
original 'random()' and friends.

[Bug cobol/119296] cobol, libgcobol the library uses strfromf* which are C23 and not generally available outside GLIBC

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Sandoe  ---
I suspect that the FE side of this will disappear when PR119241 is resolved.

However, the library is more tricky .. at present, I made a fallback to using
snprintf (since the format strings are fixed in the current library impl.)

for the 128b cases, we can use the libquadmath "snprintf" support on platforms
using libquadmath .. a more general solution would be better.

As of now the provisions made above work "basically" and so un-assigning myself
for now.

[Bug cobol/119213] gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with hardcoded lib64

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

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

--- Comment #6 from Iain Sandoe  ---
Created attachment 60776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60776&action=edit
Patch to remove std= and forced lib paths

This removes these from the CPPSPEC in the cobol Make-lang.in and also the
references and hard-wired uses in gcobolspec.cc.

[Bug rtl-optimization/119310] New: Unnecessary instructions on std::bit_cast of an array of 3 strongly-typed floats

[bernardo at bernardosulzbach dot com via Gcc-bugs]

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

Bug ID: 119310
   Summary: Unnecessary instructions on std::bit_cast of an array
of 3 strongly-typed floats
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernardo at bernardosulzbach dot com
  Target Milestone: ---

I looked at some 10 other std::bit_cast-related issues, but none of them seemed
to be the same issue as this.

This matters for code that creates strong types around primitives to prevent
programmer mistakes such as mixing up units.
Users might expect to be able to cast away these strong types cheaply if they
don't interfere with memory layout.

https://godbolt.org/z/PM16z9fj6 is a minimal example. Note that this is not
happening for n = 2 and n = 4.

```cpp
#include 
#include 

using T = float;

struct StrongA {
T value;
};

template 
using Vec = std::array;

auto bitCast(Vec<2> a) { return std::bit_cast>(a);
}
auto bitCast(Vec<3> a) { return std::bit_cast>(a);
}
auto bitCast(Vec<4> a) { return std::bit_cast>(a);
}
```

generates

```
bitCast(std::array):
movdDWORD PTR [rsp-32], xmm1
movss   xmm1, DWORD PTR [rsp-32]
movss   DWORD PTR [rsp-16], xmm1
movdxmm1, DWORD PTR [rsp-16]
ret
```

for the n = 3 case, which seems to effectively do nothing other than `ret`.

Maybe some optimization rule isn't triggering because of the mix of movss and
movd?

I guessed the component, so "rtl-optimization" might be wrong.

[Bug ada/119309] Compiler continues to run indefinitely while processing code that contains errors

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-16
   Keywords||error-recovery
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|Compiler continues to run   |Compiler continues to run
   |indefinitely while  |indefinitely while
   |processing code that|processing code that
   |contains errors.|contains errors
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Too many errors indeed.

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

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

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

--- Comment #9 from Iain Sandoe  ---
Created attachment 60777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60777&action=edit
Initial patch (working on x86_64 darwin and linux)

The relationship between the library and the FE remains unclear. However, we
can configure the code to use the 'q' suffix and __float128 + libquadmath for
support.  This can be done without altering the Linux impl.

NOTE: this does not attempt to add the configuration for the 3rd case (PPC64
ieee128) although it should be feasible to follow the pattern of libgfortran
there.

The patch is quite large, but the code changes are mechanical (applying macros
for the 128b FP type and to allow for the different function suffixes).

The only really substantial changes are in the configuration.

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #10 from Iain Sandoe  ---
the patch works well enough for me to make progress on Darwin (without breaking
Linux), so un-assigning myself for now.

[Bug modula2/115111] Incorrect line debugging locations at start of WHILE loop.

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-03-16

--- Comment #1 from Gaius Mulley  ---
Confirmed

[Bug cobol/119211] [15 Regression] Cobol GCC 15 release checklist

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Depends on||119308
 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
Added PR 119308, "Hello World" does not work on Power.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
[Bug 119308] Cobol ICE on "hello world" on POWER in
rs6000_output_function_epilogue

[Bug cobol/119211] [15 Regression] Cobol GCC 15 release checklist

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

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

--- Comment #5 from Sam James  ---
(In reply to Thomas Koenig from comment #4)
> Added PR 119308, "Hello World" does not work on Power.

I don't consider that a release blocker, personally, as it's documented (or
should be) that it only works on amd64+arm64 right now, and
--enable-languages=all shouldn't include it. If it does, *that's* the bug.

[Bug cobol/119211] [15 Regression] Cobol GCC 15 release checklist

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

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Sam James from comment #5)
> (In reply to Thomas Koenig from comment #4)
> > Added PR 119308, "Hello World" does not work on Power.
> 
> I don't consider that a release blocker, personally, as it's documented (or
> should be) that it only works on amd64+arm64 right now, and
> --enable-languages=all shouldn't include it. If it does, *that's* the bug.

Move it to "See also", then?

[Bug modula2/115111] Incorrect line debugging locations at start of WHILE loop.

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r15-8074-g5ed0564f2879db35106272556ba91f028177c5cd
Author: Gaius Mulley 
Date:   Sun Mar 16 15:56:48 2025 +

PR modula2/115111 Incorrect line debugging locations at the end of the
WHILE loop

This fix corrects the END token position used during the GotoOp at the
bottom of the WHILE loop.  The fix is to pass the relative token position
down to M2Quads.  This method should be replicated for the other loops
END or UNTIL keywords and possibly the END statements for
conditional statements.

gcc/m2/ChangeLog:

PR modula2/115111
* gm2-compiler/M2GenGCC.mod (CodeStatementNote): Add debugging.
* gm2-compiler/M2Quads.def (BuildEndWhile): New parameter
reltokpos.
* gm2-compiler/M2Quads.mod (BuildEndWhile): Reimplement using new
parameter.
* gm2-compiler/P3Build.bnf (WhileStatement): Call BuildEndWhile
with -1 relative position.
* gm2-gcc/m2block.cc (do_add_stmt): Tidy comment.
(GetGlobals): Ditto.
(flush_pending_note): Remove #if 0 code.
* gm2-gcc/m2pp.cc (m2pp_nop_expr): New function.
(m2pp_statement): New case clause call m2pp_nop_expr.

gcc/testsuite/ChangeLog:

PR modula2/115111
* gm2/pim/pass/whilestep.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug modula2/115111] Incorrect line debugging locations at start of WHILE loop.

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #4 from Gaius Mulley  ---
Closing.

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

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

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

--- Comment #33 from Hongtao Liu  ---
I have a fix in ivopt for x86 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115842#c6, you may try to see if
that helps?

[Bug preprocessor/118725] libcpp build failure with NLS enabled

[andress.barajas at gmail dot com via Gcc-bugs]

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

Andy B  changed:

   What|Removed |Added

 CC||andress.barajas at gmail dot 
com

--- Comment #6 from Andy B  ---
I am getting this error also but only for GCC 13.3.0 and GCC 15.0.1 on M4 Mac
mini.  For GCC 14.2.0 seems to compile fine for me. I believe I traced it to
the ./contrib/download_prerequisites file. For GCC 14.2.0 it contains:

gettext='gettext-0.22.tar.gz'

and builds fine but that entry is missing for GCC 13.3.0 and GCC 15.0.1.

[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7

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

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

--- Comment #8 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #6)
> It looks like the testcase is fragile, it's supposed to check the compiler
> ability of generating code_6_gottpoff_reloc instruction, but failed since
> there's a seg_prefixed memory usage(r14-6242-gd564198f960a2f).
> 
> mov r13, QWORD PTR j@gottpoff[rip]
> mov r12, QWORD PTR a@gottpoff[rip]
> mov rbp, QWORD PTR [rsp+1040]
> lea rbx, [rsp+1040]
> add r14, QWORD PTR fs:0, r12

@hjl, should we mark it as xfail?

[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7

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

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

--- Comment #9 from Hongtao Liu  ---
(In reply to Sam James from comment #7)
> This stopped failing for me around:
> 
> commit 2bc3ea210565dc7cdbba9adb31acceefed406254
> Author: Sam James 
> Date:   Fri Nov 22 15:20:45 2024 +
> 
> saving uncommitted changes in /etc prior to emerge run
> 


I didn't find this commit in gcc trunk?

[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7

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

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

--- Comment #11 from H.J. Lu  ---
(In reply to H.J. Lu from comment #10)
> (In reply to Hongtao Liu from comment #8)
> > (In reply to Hongtao Liu from comment #6)
> > > It looks like the testcase is fragile, it's supposed to check the compiler
> > > ability of generating code_6_gottpoff_reloc instruction, but failed since
> > > there's a seg_prefixed memory usage(r14-6242-gd564198f960a2f).
> > > 
> > > mov r13, QWORD PTR j@gottpoff[rip]
> > > mov r12, QWORD PTR a@gottpoff[rip]
> > > mov rbp, QWORD PTR [rsp+1040]
> > > lea rbx, [rsp+1040]
> > > add r14, QWORD PTR fs:0, r12
> > 
> > @hjl, should we mark it as xfail?
> 
> Sure.

Only xfail

/* { dg-final { scan-assembler-times "addq\[ \t]+%r\[a-z0-9\]+,
a@gottpoff\\(%rip\\), %r\[a-z0-9\]+" 1 { target lp64 } } } */

[Bug c/119315] [15 Regression] ICE: verify_gimple failed during IPA pass remove_symbols with -Os and nested function with VLA types

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Same as PR 85047 in the end.

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

[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #34 from chenglulu  ---
(In reply to Xi Ruoyao from comment #29)
> For 15 r15-7525 is intended for this issue.  But I don't know if it's a good
> idea to backport it, as it's only a workaround, not a proper fix.
> 
> Could someone try the diff in PR 115842 comment 6 (one time just on the
> trunk, another with r15-7525 reverted)?

I have tested on r15-8080, and the results are as follows:

-march=la664 -mtune=la464 -Ofast -flto: 13.4
-march=la664 -mtune=la464 -Ofast -flto -maddr-reg-reg-cost=1:   13.3 
-march=la664 -mtune=la464 -Ofast -flto + PR 115842 comment 6:   13.5
-march=la664 -mtune=la464 -Ofast -flto -maddr-reg-reg-cost=1 + PR 115842
comment 6:   13.3

[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7

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

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

--- Comment #10 from H.J. Lu  ---
(In reply to Hongtao Liu from comment #8)
> (In reply to Hongtao Liu from comment #6)
> > It looks like the testcase is fragile, it's supposed to check the compiler
> > ability of generating code_6_gottpoff_reloc instruction, but failed since
> > there's a seg_prefixed memory usage(r14-6242-gd564198f960a2f).
> > 
> > mov r13, QWORD PTR j@gottpoff[rip]
> > mov r12, QWORD PTR a@gottpoff[rip]
> > mov rbp, QWORD PTR [rsp+1040]
> > lea rbx, [rsp+1040]
> > add r14, QWORD PTR fs:0, r12
> 
> @hjl, should we mark it as xfail?

Sure.

[Bug target/119172] [12/13/14 regression] macOS SDK version is not set by gcc

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #2 from Iain Sandoe  ---
fixed on trunk so far, back ports to follow.

[Bug c/119311] musttail attribute is lost sometimes as single statement for then part of an if statement

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug middle-end/113546] [13/14/15 Regression] aarch64: bootstrap-debug-lean broken with -fcompare-debug failure since r13-2921-gf1adf45b17f7f1

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

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

--- Comment #13 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r15-8075-gc5ca45b8069229b6ad9bc845f03f46340f6316d7
Author: Andrew Pinski 
Date:   Sat Mar 15 16:37:41 2025 -0700

discriminators: Fix assigning discriminators on edge [PR113546]

The problem here is there was a compare debug since the discriminators
would still take into account debug statements. For the edge we would look
at the first statement after the labels and that might have been a debug
statement.
So we need to skip over debug statements otherwise we could get different
discriminators # with and without -g.

Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR middle-end/113546

gcc/ChangeLog:

* tree-cfg.cc (first_non_label_stmt): Rename to ...
(first_non_label_nondebug_stmt): This and use
gsi_start_nondebug_after_labels_bb.
(assign_discriminators): Update call to
first_non_label_nondebug_stmt.

gcc/testsuite/ChangeLog:

* c-c++-common/torture/pr113546-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug target/118485] [15 Regression] gnat fails to build on m68k-linux-gnu-gnu

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

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

--- Comment #8 from Sam James  ---
It builds OK on hppa too which is 32-bit BE.

[Bug middle-end/113546] [13/14 Regression] aarch64: bootstrap-debug-lean broken with -fcompare-debug failure since r13-2921-gf1adf45b17f7f1

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13/14/15 Regression]   |[13/14 Regression] aarch64:
   |aarch64:|bootstrap-debug-lean broken
   |bootstrap-debug-lean broken |with -fcompare-debug
   |with -fcompare-debug|failure since
   |failure since   |r13-2921-gf1adf45b17f7f1
   |r13-2921-gf1adf45b17f7f1|
  Known to work||15.0

--- Comment #14 from Andrew Pinski  ---
Fixed on the trunk so far.

[Bug debug/108784] '-fcompare-debug' failure (length) w/ --param ira-simple-lra-insn-threshold=1

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Arseny Solokha from comment #1)
> (In reply to Arseny Solokha from comment #0)
> > I believe it has nothing to do w/
> > -fharden-conditional-branches, as there are many testcases that fail w/ that
> > omitted.
> 
> Like the following one (though I get hundreds of them each day starting from
> that snapshot):
> 
> int
> foo (int x)
> {
>   int i, a = 0;
> 
>   x <<= !!x;
> 
>   for (i = 0; i < 7; ++i)
> {
>   int i;
> 
>   for (i = 0; i < 12; ++i)
> {
>   ++x;
>   a += x + i;
> }
> }
> 
>   return x;
> }


This one looks fixed on the trunk.  I have not tested other yet.

[Bug c/119314] New: Possibly wrong code generation for branch after tail function call

[root at hsnovel dot net via Gcc-bugs]

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

Bug ID: 119314
   Summary: Possibly wrong code generation for branch after tail
function call
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: root at hsnovel dot net
  Target Milestone: ---

gcc -v output

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20250207 (GCC)


The code is a part of a much larger proprietary codebase, so it's not possible
for me to share the exact code that reproduces it. I am writing this report to
inform you, as I unfortunutely I cannot share the code.

These are the flags:

-fno-optimize-sibling-calls -fwrapv -std=c11 -fno-strict-aliasing
-Wstrict-prototypes -Wall -Wextra -Wfloat-conversion -Wreturn-local-addr
-Wshadow -Wformat -Wcast-align -Wmisleading-indentation -msse4.1 -O2 -DNDEBUG
-fomit-frame-pointer

This is the the snippet, (part of a much bigger function):

STRING CachedName = tctx_lookupTable->playerNames[playerHandle.slot].string;

DEBUG_LOG_INFO("2 Data %p\n", dest.Data);
DEBUG_LOG_INFO("2 Size %d\n", dest.Size);

if (dest.Data)
{
DEBUG_LOG_INFO("3 Data %p\n", dest.Data);
U32 CopySize = Min(CachedName.Size, dest.Size);
memcpy(dest.Data, CachedName.Data, CopySize);
return CopySize;
}
else
{
return CachedName.Size;
}

where DEBUG_LOG_INFO is:

#define log_info(...) log_log(Log_Info, __VA_ARGS__)
#define DEBUG_LOG_INFO(...) log_info(__VA_ARGS__)

static const char* log_level_colors[] = {
[Log_Err]  = "\x1b[31m",
[Log_Warn] = "\x1b[33m",
[Log_Info] = "\x1b[36m",
[Log_Enum_Count] = "\x1b[0m"
};

static const char* log_level_string[] = {
[Log_Err]   = "[ERROR]: ",
[Log_Warn]  = "[WARN] : ",
[Log_Info]  = "[INFO] : ",
};

void log_log(enum log_level level, const char *args, ...)
{
va_list va;
FILE *fd;

if (level == Log_Err)
fflush(stdout);

va_start(va, args);
fd = (level == Log_Err) ? stderr : stdout;

fprintf(fd, "%s", log_level_colors[level]);
fprintf(fd, "%s", log_level_string[level]);
vfprintf(fd, args, va);

if (level == Log_Err)
fflush(stderr);

fprintf(fd, "%s", log_level_colors[Log_Enum_Count]);
va_end(va);
}

and STRING is:

typedef struct
{
char *Data;
unsigned int Size;
} STRING;

When the code snippet executes, it runs:

[INFO] : 2 Data (nil)
[INFO] : 2 Size 0
[INFO] : 3 Data (nil)

It enters the if branch and prints 3 Data (nil), even tough it prints the
pointer as (nil) in "2 Data", right before entering the branch.

This is the assembly that got generated for that snippet:

; CODE XREF from sym.IGNORE_THIS_ITS_FUNCTION_NAME @ 0x8bcc(x)
; 0x28f58  
lea rdi, section..got  
call fcn.6260;[ob] 
; int64_t arg3 
mov rdx, rbp   
; int64_t arg1 
mov edi, 2 
; int64_t arg2 
; 0x234e6  
; "2 Data %p\n"
lea rsi, str.2_Data__p_n   
mov rax, qword [rax]   
add rbx, qword [rax + 0x10]
xor eax, eax   
mov r13, qword [rbx + 8]   
mov ebx, dword [rbx + 0x10]
call sym.log_log;[oa]  
xor eax, eax   
; int64_t arg3 
mov edx, r14d   

[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-16
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
>The code is a part of a much larger proprietary codebase, so it's not possible 
>for me to share the exact code that reproduces it. I am writing this report to 
>inform you, as I unfortunutely I cannot share the code.


And there is not much we can do without a testcase sorry.

[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call

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

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

--- Comment #2 from Andrew Pinski  ---
See https://gcc.gnu.org/bugs/#need

Also try using -fsanitize=address,undefined and fixing all of the issues that
it reports if any.

[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call

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

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

--- Comment #3 from Andrew Pinski  ---
Before `DEBUG_LOG_INFO("2 Data %p\n", dest.Data);`
is there any calls before hand? Like say to memcpy? or anything that might have
the nonnull attribute on it and uses dest.Data?

Note memcpy before C23 was undefined (even if the length was 0) to pass a null
pointer to it. 

Does -fno-delete-null-pointer-checks if the issue you are running into? If so
there is most likely a what I described, `-fsanitize=undefined` should catch
that at runtime.

[Bug lto/85047] cdd2a01 (and others) FAIL with -flto (VLA type in struct causes issues)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kristerw at gcc dot gnu.org

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

[Bug middle-end/119315] New: ICE: verify_gimple failed during IPA pass remove_symbols with -Os

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

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

Bug ID: 119315
   Summary: ICE: verify_gimple failed during IPA pass
remove_symbols with -Os
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

Compiling the function below for X86_64 with -Os results in an ICE:

during IPA pass: remove_symbols
bug.c:25:1: internal compiler error: verify_gimple failed

The function:

void
foo (int n)
{
  struct S { int a[n]; };

  struct S
  fn (void)
  {
struct S s;
s.a[0] = 42;
return s;
  }

  auto struct S
  fn2 (void)
  {
return fn ();
  }

  struct S x;
  x = fn2 ();

  if (x.a[0] != 42)
__builtin_abort ();
}

[Bug target/119172] [12/13/14 regression] macOS SDK version is not set by gcc

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

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

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

https://gcc.gnu.org/g:952e17223d3a9809a32be23f86f77166b5860b36

commit r15-8073-g952e17223d3a9809a32be23f86f77166b5860b36
Author: Iain Sandoe 
Date:   Sun Mar 9 09:24:34 2025 +

Darwin: Pass -macos_version_min to the linker [PR119172].

For binaries to be notarised, the SDK version must be available.
Since we do not, at present, parse this information we have been
passing "0.0" to ld64.  This now results in a warning and a fail
to notarise.  As a quick-fix, we can fall back to letting ld64
figure out the SDK version (which it does for -macos_version_min).

TODO: Parse the SDKSetting.plist at some point.

PR target/119172

gcc/ChangeLog:

* config.in: Regenerate.
* config/darwin.h (DARWIN_PLATFORM_ID): Add the option to
use -macos_version_min where available.
* configure: Regenerate.
* configure.ac: Check for ld64 support of -macos_version_min.

Signed-off-by: Iain Sandoe 
(cherry picked from commit 36f5ea5806d246d78555e65273a057718833e3cd)

[Bug c/119311] New: musttail attribute ineffective at -O0 and -O1

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 119311
   Summary: musttail attribute ineffective at -O0 and -O1
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 60778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60778&action=edit
test case foo.c

The documentation https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html
says:
"If the compiler cannot generate a musttail tail call it will report an error."

But this is not what I see, with the attached program, on x86_64: At
optimization levels -O0 and -O1, non-tail calls are generated; no error is
reported.

How to reproduce:
Compile the attached foo.c with option -S.

Expected:
No "call gcd" instruction inside function 'gcd'.

Actual:
With -O0 and -O1: Two "call gcd" instructions inside function 'gcd'.

Seen with with GCC version 15.0.1 20250316 (from godbolt.org).

[Bug c/119312] New: Constant array not allocated in read-only segment

[bruno at clisp dot org via Gcc-bugs]

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

Bug ID: 119312
   Summary: Constant array not allocated in read-only segment
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 60779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60779&action=edit
test case foo.c

When constant data is allocated in a read-only segment, it is more efficient
than in the .data segment (namely, the OS does not need to copy such a memory
page to the swap when memory is tight).

When compiling this program, although the array 'html5' contains only constant
data (note that the struct has no holes and has alignment 1), gcc puts it in
the .data segment.

How to reproduce:
$ gcc -O2 -c foo.c
$ size foo.o
   textdata bss dec hex filename
270 230   0 500 1f4 foo.o

Only when I add an additional 'const' to the 'html5' array, does gcc put it
into the .rodata or .text segment.

[Bug cobol/119241] cobol Front end uses host floating point (128b) support

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

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Robert Dubner from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > In my experiments with x86_64 Darwin and Linux, I have managed to convert
> > the library to use libquadmath.
> > 
> > I started to try and apply Jakub's suggestions to the FE for this BZ, since
> > what it is doing at the moment clearly cannot work in the general case (I
> > think it will be limited to native builds in general at the moment).
> > 
> > However, unfortunately I have not been able to figure out how all of this is
> > supposed to fit together:
> > 
> >  1. the FE pulls in a lot of library headers
> >  2. the FE pulls in some of the library sources
> >  3. the functions that make use of host 128b FP do not seem to have head
> > comments describing their purpose.
> > 
> > In short, I'm stuck (at least in the time I have available) in progressing
> > this - but suspect it's one of the most important changes to make in
> > supporting the "usual build process" for GCC.
> > 
> > Is there any kind of "internals manual" for cobol? (apologies if it is under
> > my nose and I missed it).
> > 
> > ... in the short-term I have some heinous hacks that allow it to build
> > (native) on x86_64 Darwin, without breaking Linux .. but ...
> 
> No, there is nothing like an internals manual.

OK.

I am going to reply to parts of this - which does not mean I'm ignoring the
rest, just that its going to take some digestion.

> There is a fair amount of functionality that is performed identically in
> both  compile-time and in run-time.
> 
> For example: COBOL needs to be able to run using both ASCII and EBCDIC as
> the run-time internal character set.  In support of that, we do conversions
> between EBCDIC, ASCII, and UTF-8 (basic COBOL uses 8-bit characters, but in
> general we need to convert to and from a UTF-8 locale, because that's what
> the terminal could be running).  Those conversions are done by both the
> compiler and the compiled executable, and so I rigged things up so that the
> front end uses the same source code as the library.

I see - this sounds reasonable.

> Numerical calculations:  In COBOL you can define a 32-digit integer named
> 32-DIGIT-INTEGER, and you can have statements like 
> 
> "ADD 123456789012345678901234567890 TO 32-DIGIT-INTEGER"
> 
> (And, yes, 32-DIGIT-INTEGER is a perfectly legitimate COBOL user-declared
> identifier.  I have started to forget why COBOL, at first glance, causes a
> modern programmer's eyes to glaze over, then I remember that stuff like that
> can happen.)
> 
> So, the host needs to be able to do 128-bit arithmetic.  I chose to do it
> with __int128 and _Float128, because I was young and ignorant and provincial.

> What's possibly perplexing you is at the borderline between the compiler
> making calculations of constants, and then the GENERIC that I generate to
> make those constants available to the run-time.  And I had the advantage,
> and the disadvantage, of not knowing how anybody else has solved those
> problems.  I just dived in.

Right .. so the main thing that needs to be clear is that the code and
constants that are generated are for $target (and live in the same numerical
spaces as the library and $target).

(at the risk of teachin' one's grandma)

The $host might have completely different characteristics from $target - it
might not support the same numerical types or be the same endian-ness.

Therefore one cannot, in general, use native host computations to produce
literals for the target (at present, the code only happens to work when $host
== $target or their numerical properties are identical).

The things that Jakub pointed to are a series of tools that allow an arbitrary
host to produce literals for an arbitrary target.  The tricky bit is
understanding how to wire those up and the deleted part of your reply is
probably what needs to be digested to understand that.

Keeping very clear separation between things $host and things $target will
definitely save you sleepless nights later.

> And I also -- forgive me, for I am sinning -- am simply not used to other
> people diving in and changing code I've written.  It's great, and I welcome
> it.  But I am just not used to it.

It can be one of the more challenging parts of OSS... indeed .. but you are the
maintainer(s) other people (mostly) cannot "just change your code" - they must
present proposed changes for your review.  I say "mostly" because there are
some rules about obvious changes and permissions for global maintainers.

I am sure we will be presenting you with proposed changes soon :) In some cases
it will be for targets you might not have easy access to so possibly helpful.

>  And I am not used to how the time
> evaporates like the last snowfall in a warm spring rain.

doesn't it just.

[Bug c++/119316] new expression incorrectly required to have constant expression size inside a requires constraint of a template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-17
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|new expression incorrectly  |new expression incorrectly
   |required to have constant   |required to have constant
   |expression size |expression size inside a
   ||requires constraint of a
   ||template function

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

[Bug target/118485] [15 Regression] gnat fails to build on m68k-linux-gnu-gnu

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to Matthias Klose from comment #4)
> I don't see any other gnat failures on 32bit archs. But I think m68k is the
> only big-endian one.

powerpc is 32-bit big-endian as well.

[Bug target/116256] [15 Regression] RISC-V: testsuite failures since late-combine-pass

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:9d68a2a67351fc5b56262c0028ef8fd1d1466627

commit r15-8080-g9d68a2a67351fc5b56262c0028ef8fd1d1466627
Author: Jeff Law 
Date:   Sun Mar 16 17:43:48 2025 -0600

[RISC-V][PR target/116256][V4] Fix minor code quality regression in
reassociated arithmetic

Arggh.  This time add arguments for rv32.  Hand edited the testcase part of
the
patch, but I think I got it right.

One.  More.  Time.

-pedantic-errors this time ;(  Adding an explicit -std=gnu23 to shut that
up.
Part of me wants to know why that's getting added by the pre-commit, but
not
enough to chase it down.

--

This failed pre-commit CI the first time through. The only change is in the
return type in the test bool -> _Bool.

The patch for target/116256 significantly simplified the condition and, I
guess
not too surprisingly, exposed a minor code quality regression.

Specifically the split part of the define_insn_and_split only splits after
reload (because we use a match_scratch).  So there's nothing to combine the
load-immediate with the subsequent add into an addi when the immediate fits
into a simm12 field.

This patch adjusts the split code to handle that scenario directly and
generate
the more efficient code.  We can squeeze out the slli in this test with a
bit
more work, but that's out of scope right now since that isn't a regression.

Tested in my tester.  Waiting on pre-commit testing to render a verdict.

PR target/116256
gcc
* config/riscv/riscv.md (reassociation splitters): Do not load the
adjusted addend into a register if it fits in a simm12.

gcc/testsuite
* gcc.target/riscv/pr116256-1.c: New test.

[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call

[root at hsnovel dot net via Gcc-bugs]

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

--- Comment #4 from Novel  ---
(In reply to Andrew Pinski from comment #1)
> >The code is a part of a much larger proprietary codebase, so it's not 
> >possible for me to share the exact code that reproduces it. I am writing 
> >this report to inform you, as I unfortunutely I cannot share the code.
> 
> 
> And there is not much we can do without a testcase sorry.

I know, I just wanted to report it regardless. Tought it could help in some
way.

(In reply to Andrew Pinski from comment #2)
> See https://gcc.gnu.org/bugs/#need
> 
> Also try using -fsanitize=address,undefined and fixing all of the issues
> that it reports if any.

I will do it when I get back to the working enviroment.(In reply to Andrew
Pinski from comment #3)
> Before `DEBUG_LOG_INFO("2 Data %p\n", dest.Data);`
> is there any calls before hand? Like say to memcpy? or anything that might
> have the nonnull attribute on it and uses dest.Data?
> 
> Note memcpy before C23 was undefined (even if the length was 0) to pass a
> null pointer to it. 
> 
> Does -fno-delete-null-pointer-checks if the issue you are running into? If
> so there is most likely a what I described, `-fsanitize=undefined` should
> catch that at runtime.

No there isn't any call before that touches the variable dest, or anything that
has an attribute nonnull. dest also is an argument to the function, and this
function doesn't get called in anywhere in the source code. This program is a
shared library, and it returns the address of the function in a function that
is exported.

I did not specify any attribute or logic that might make the compiler assume
what dest.Data can be. It's not even accessed in any way before and after the
snipped I showed. It's a parameter to a function that isn't even called
anywhere in the entire project. But this bug does indeed happen only on release
builds. Debug builds work just fine.

If the compiler can determine that dest.Data is somehow non null, I can tell
that there is clearly a bug, unless it's some super agressive compiler
optimization.

I will test the sanitizer as soon as I get back the working place, I will
report back when I do.

[Bug c/119315] [15 Regression] ICE: verify_gimple failed during IPA pass remove_symbols with -Os and nested function with VLA types

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Summary|ICE: verify_gimple failed   |[15 Regression] ICE:
   |during IPA pass |verify_gimple failed during
   |remove_symbols with -Os and |IPA pass remove_symbols
   |nested function with VLA|with -Os and nested
   |types   |function with VLA types
   Keywords||needs-bisection

[Bug middle-end/119314] Possibly wrong code generation for branch after tail function call

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Novel from comment #0)

> ; CODE XREF from sym.IGNORE_THIS_ITS_FUNCTION_NAME @ 0x8bcc(x)
> ; 0x28f58  
> lea rdi, section..got  
> call fcn.6260;[ob] 
> ; int64_t arg3 
> mov rdx, rbp   
> ; int64_t arg1 
> mov edi, 2 
> ; int64_t arg2 
> ; 0x234e6  
> ; "2 Data %p\n"
> lea rsi, str.2_Data__p_n   
> mov rax, qword [rax]   
> add rbx, qword [rax + 0x10]
> xor eax, eax   
> mov r13, qword [rbx + 8]   
> mov ebx, dword [rbx + 0x10]
> call sym.log_log;[oa]  
> xor eax, eax   
> ; int64_t arg3 
> mov edx, r14d  
> ; int64_t arg1 
> mov edi, 2 
> ; int64_t arg2 
> ; 0x234f1  
> ; "2 Size %d\n"
> lea rsi, str.2_Size__d_n   
> call sym.log_log;[oa]  
> test rbp, rbp  
> je 0x8a98

Test %RBP .

So if a function does not restore correctly %RBP things could go wrong. 

Also try running your test program under valgrind, it might catch some stuff
too.

The other thing to try is change log_info to be a just printf.

There could be a bug in musl fprintf too that is not restoring some register
correctly. It is not obvious what is going on here from even the snip of code.

[Bug c++/119316] New: new expression incorrectly required to have constant expression size

[eczbek.void at gmail dot com via Gcc-bugs]

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

Bug ID: 119316
   Summary: new expression incorrectly required to have constant
expression size
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eczbek.void at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/YTK4PYrqE


```cpp
template
void foo(unsigned n) requires(requires { new T[n]; }) {}

int main() { foo(5); }
```


```
: In instantiation of 'void foo(unsigned int) requires requires{new T(
foo::n);} [with T = int]':
:2:48: error: size of array is not an integral constant-expression
2 | void foo(unsigned n) requires(requires { new T[n]; }) {}
  |^
```

[Bug c/118061] [15 regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tagged_types_tu_compatible_p, at c/c-typeck.cc:1946

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677745.html

[Bug rtl-optimization/105653] [12/13/14/15 Regression] '-fcompare-debug' failure w/ -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||14.1.0
 CC||pinskia at gcc dot gnu.org

--- Comment #6 from Andrew Pinski  ---
Looks like this was fixed in GCC 14.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b

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

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

--- Comment #50 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #20)
> (In reply to Jakub Jelinek from comment #19)
> > Guess I'll start another reduction with additional -gno-statement-frontiers.
> Likewise.

FYI, both of these are the same as PR 113546 (which was just fixed today). 


(In reply to Jakub Jelinek from comment #36)
> Actually, while i386-expand.o compilation fails with -fcompare-debug even
> after the above patch, seems that is only because of the discriminator
> issue, the *.gkd difference is then:

> So, this should no longer fail normal bootstrap comparison (but of course
> fail -fcompare-debug bootstrap).  And with -fcompare-debug
> -gno-statement-frontiers it compiles fine.

This is also the same as PR 113546.

[Bug c/118765] c23 tag matching broken for multiple redeclarations of typedefs

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

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

--- Comment #15 from uecker at gcc dot gnu.org ---
PATCH 1: https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677746.html
PATCH 2: https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677747.html

[Bug c++/48379] -Wdouble-promotion warns for promotion by varargs

[adam.f.badura at gmail dot com via Gcc-bugs]

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

Adam Badura  changed:

   What|Removed |Added

 CC||adam.f.badura at gmail dot com

--- Comment #6 from Adam Badura  ---
To help others who might get here like I did, if you are using macros for
logging/printing (that eventually call printf-like functions) or are willing to
use them, _Pragma could be used to silence the warning "locally", like this
(https://godbolt.org/z/5oYPhjen9):

#include 

#define LOG(fmt, ...) \
_Pragma("GCC diagnostic push")  \
_Pragma("GCC diagnostic ignored \"-Wdouble-promotion\"") \
std::printf(fmt, __VA_ARGS__); \
_Pragma("GCC diagnostic pop")  \


void test(float f)
{
LOG("%f", f);
}

[Bug fortran/60560] Problem allocating character array with assumed length

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r15-8079-gb2b139ddee763dd5fd71a3368e5e66399e3c52a3
Author: Harald Anlauf 
Date:   Sat Mar 15 15:11:22 2025 +0100

Fortran: fix bogus dependency check in ALLOCATE statement [PR60560]

Restrict dependency check of ALLOCATE object to variables in the same
statement, but exclude check of length type parameter that might be
set in the declaration and could lead to a bogus cyclic dependency.

PR fortran/60560

gcc/fortran/ChangeLog:

* expr.cc (gfc_traverse_expr): Do not descend into length type
parameter for negative values of auxiliary parameter f.
* resolve.cc (gfc_find_var_in_expr): New helper function to check
dependence of an expression on given variable.
(resolve_allocate_expr): Use it to determine if array bounds in an
ALLOCATE statement depend explicitly on a variable.

gcc/testsuite/ChangeLog:

* gfortran.dg/allocate_error_8.f90: New test.

[Bug c++/48379] -Wdouble-promotion warns for promotion by varargs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #7 from Andrew Pinski  ---
>Since, there's not much that can be done to fix this situation it's probably 
>not worth warning about.


No it is warning you because on the other side using va_arg with float will
cause a trap as it is undefined to do. It is warning explicitly because it will
promote to double because of the way C defines it.  Note with C23's _Float32
type will not promote to double/_Float64.

[Bug c++/48379] -Wdouble-promotion warns for promotion by varargs

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

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

--- Comment #8 from Andrew Pinski  ---
>As has already been said, nothing can he done about the promotion in this 
>context, so it's not worth warning about.

That is NOT true in C23 since you could use _Float32 instead.
Basically the warning here is very much useful as it is still is an implicit
cast to double happening for var-args. If you don't want an implicit cast
either add a cast or NOT use varargs or use _Float32 instead.

[Bug c/119311] musttail attribute is lost sometimes as single statement for then part of an if statement

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|musttail attribute  |musttail attribute is lost
   |ineffective at -O0 and -O1  |sometimes as single
   ||statement for then part of
   ||an if statement
   Last reconfirmed||2025-03-16

--- Comment #1 from Andrew Pinski  ---
Looks like the C front-end loses the musttail call attribute.

Workaround is to do:
  if (a > b) {
[[gnu::musttail]] return gcd (a , b);
  }
  else {
[[gnu::musttail]]return gcd (a, b);
  }

[Bug middle-end/119312] Constant array not allocated in read-only segment

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/119312] Constant array not allocated in read-only segment

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-03-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. clang also does not move the variable to rodata.

There might be a dup of this somewhere.

[Bug c++/119222] Conversion of inf to integer is not diagnosed

[gwen3293940943 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Gwen Fu  ---
I know how this bug generate this time (100%)!
This is because the funx conversion_warning (in c-family/c-warn.cc , the helper
function for warnings_for_convert_and_check)lacks some checks when expr is of
type double

here is the curcial part about this bugu  of conversion_warning:
static bool
conversion_warning (location_t loc, tree type, tree expr, tree result)
{
  // type -> int , expr->1.0/0.0  result->(int)1.0/0.0 
  .
  switch (TREE_CODE (expr))
{
case EQ_EXPR:
case NE_EXPR:
case LE_EXPR:
case GE_EXPR:
.
case REAL_CST:
case INTEGER_CST:
.
   }
  return false ;
}

And 
warning_for_convert_and_check only responsible for the two situations below :
 if (TREE_CODE (expr) == INTEGER_CST
  && (TREE_CODE (type) == INTEGER_TYPE
  || TREE_CODE (type) == BITINT_TYPE
  || (TREE_CODE (type) == ENUMERAL_TYPE
  && TREE_CODE (ENUM_UNDERLYING_TYPE (type)) != BOOLEAN_TYPE))
  && !int_fits_type_p (expr, type))
{}
  else if ((TREE_CODE (result) == INTEGER_CST
|| TREE_CODE (result) == FIXED_CST) && TREE_OVERFLOW (result))
{.}

The rest of the situation is all handed over to the top function。
If you need more testimonies , I will give you !

[Bug middle-end/119310] Unnecessary instructions on std::bit_cast of an array of 3 strongly-typed floats

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end
   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug fortran/60560] Problem allocating character array with assumed length

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |15.0
 Resolution|--- |FIXED

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed.

Sorry that it took so long (almost 11 years)!

[Bug fortran/68241] [meta-bug] [F03] Deferred-length character

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 60560, which changed state.

Bug 60560 Summary: Problem allocating character array with assumed length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60560

   What|Removed |Added

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

[Bug bootstrap/119313] New: Internal compiler error when bootstrapping gcc cross compiler targeting powerpc64-apple-darwin8

[edoardo762 at gmail dot com via Gcc-bugs]

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

Bug ID: 119313
   Summary: Internal compiler error when bootstrapping gcc cross
compiler targeting powerpc64-apple-darwin8
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: edoardo762 at gmail dot com
  Target Milestone: ---

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

When bootstrapping a GCC cross compiler targeting powerpc mac os using
https://github.com/tpoechtrager/osxcross/blob/ppc-test/README.PPC-GCC-5.5.0-SDK-10.5.md,
since version 13.2 at least, GCC fails the process with an internal compiler
error in rs6000_emit_prologue.
The error seems to be triggered by the call to __builtin_eh_return.
Attached is the preprocessed source file causing the crash generated with
-freport-bug

[Bug target/119313] Internal compiler error when bootstrapping gcc cross compiler targeting powerpc64-apple-darwin8

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

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

--- Comment #1 from Andrew Pinski  ---
// ../../../../libgcc/unwind.inc:141:1: internal compiler error: in
rs6000_emit_prologue, at config/rs6000/rs6000-logue.cc:3118
//   141 | }
//   | ^
// 0x19f636f internal_error(char const*, ...)
//  ../../gcc/diagnostic-global-context.cc:517
// 0x6cec0f fancy_abort(char const*, int, char const*)
//  ../../gcc/diagnostic.cc:1722
// 0x6c1fdd rs6000_emit_prologue()
//  ../../gcc/config/rs6000/rs6000-logue.cc:3118
// 0x16732ea gen_prologue()
//  ../../gcc/config/rs6000/rs6000.md:13933
// 0x1087095 target_gen_prologue
//  ../../gcc/config/rs6000/darwin.md:353
// 0x9c2d87 make_prologue_seq
//  ../../gcc/function.cc:5875
// 0x9c2f43 thread_prologue_and_epilogue_insns()
//  ../../gcc/function.cc:6110
// 0x9c3562 rest_of_handle_thread_prologue_and_epilogue
//  ../../gcc/function.cc:6627
// 0x9c3562 execute
//  ../../gcc/function.cc:6713
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See  for instructions.

[Bug target/119313] Internal compiler error when bootstrapping gcc cross compiler targeting powerpc64-apple-darwin8

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

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

--- Comment #2 from Andrew Pinski  ---
  /* The SAVE_WORLD and RESTORE_WORLD routines make a number of
 assumptions about the offsets of various bits of the stack
 frame.  */
  gcc_assert (info->gp_save_offset == -220
  && info->fp_save_offset == -144
  && info->lr_save_offset == 8
  && info->cr_save_offset == 4
  && info->push_p
  && info->lr_save_p
  && (!crtl->calls_eh_return
  || info->ehrd_offset == -432)
  && info->vrsave_save_offset == -224
  && info->altivec_save_offset == -416);

[Bug modula2/115111] Incorrect line debugging locations at start of WHILE loop.

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 60780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60780&action=edit
Proposed fix for while end debugging info

This patch corrects the END token location and fixes the debugging line numbers
for the WHILE END loop.  The fix passes a relative token number down to
M2Quads.mod and is added to GetTokenNo (which is always one beyond the current
token processed).
This implementation should be extended to other loops and condition statements.

[Bug cobol/119241] cobol Front end uses host floating point (128b) support

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

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

--- Comment #6 from Robert Dubner  ---
(In reply to Iain Sandoe from comment #5)
> In my experiments with x86_64 Darwin and Linux, I have managed to convert
> the library to use libquadmath.
> 
> I started to try and apply Jakub's suggestions to the FE for this BZ, since
> what it is doing at the moment clearly cannot work in the general case (I
> think it will be limited to native builds in general at the moment).
> 
> However, unfortunately I have not been able to figure out how all of this is
> supposed to fit together:
> 
>  1. the FE pulls in a lot of library headers
>  2. the FE pulls in some of the library sources
>  3. the functions that make use of host 128b FP do not seem to have head
> comments describing their purpose.
> 
> In short, I'm stuck (at least in the time I have available) in progressing
> this - but suspect it's one of the most important changes to make in
> supporting the "usual build process" for GCC.
> 
> Is there any kind of "internals manual" for cobol? (apologies if it is under
> my nose and I missed it).
> 
> ... in the short-term I have some heinous hacks that allow it to build
> (native) on x86_64 Darwin, without breaking Linux .. but ...

No, there is nothing like an internals manual.

There is a fair amount of functionality that is performed identically in both 
compile-time and in run-time.

For example: COBOL needs to be able to run using both ASCII and EBCDIC as the
run-time internal character set.  In support of that, we do conversions between
EBCDIC, ASCII, and UTF-8 (basic COBOL uses 8-bit characters, but in general we
need to convert to and from a UTF-8 locale, because that's what the terminal
could be running).  Those conversions are done by both the compiler and the
compiled executable, and so I rigged things up so that the front end uses the
same source code as the library.

Numerical calculations:  In COBOL you can define a 32-digit integer named
32-DIGIT-INTEGER, and you can have statements like 

"ADD 123456789012345678901234567890 TO 32-DIGIT-INTEGER"

(And, yes, 32-DIGIT-INTEGER is a perfectly legitimate COBOL user-declared
identifier.  I have started to forget why COBOL, at first glance, causes a
modern programmer's eyes to glaze over, then I remember that stuff like that
can happen.)

So, the host needs to be able to do 128-bit arithmetic.  I chose to do it with
__int128 and _Float128, because I was young and ignorant and provincial.

What's possibly perplexing you is at the borderline between the compiler making
calculations of constants, and then the GENERIC that I generate to make those
constants available to the run-time.  And I had the advantage, and the
disadvantage, of not knowing how anybody else has solved those problems.  I
just dived in.

What might take some adjusting for experienced GCC programmers is that there is
no such thing as a COBOL variable type, in the sense that int8_t, int32_t, and
so on are C variable types.  COBOL variables are implemented as structures, and
I use GENERIC, where I can, to manipulate those structures as if the GENERIC
were assembly language.  More complex manipulations are done by calls to
libgcobol.so.  

So, you might be looking at the GENERIC that's manipulating those cblc_field_t
run-time structures.  The matching compile-time structure is cbl_field_t, and
one of its fields is the "tree var_decl_node" that is the reference to the
cblc_field_t structure.

(I get confused when I talk about this.  I have no trouble programming it, but
talking about it ties me up in knots. There's something about talking about
writing C code that interprets COBOL and generates GENERIC that creates the
assembly language that causes a processing queue in my brain to overflow.)

I plan to make the switch to real.h and wide-int.h in the host code.  What
happens in the libgcobol code, I have yet to sort out. But I underestimated the
number of moles that were going to pop up by having the COBOL front end added
to GCC-15, and I overestimated the speed with which I would be able to whack
them.

And I also -- forgive me, for I am sinning -- am simply not used to other
people diving in and changing code I've written.  It's great, and I welcome it.
 But I am just not used to it.  And I am not used to how the time evaporates
like the last snowfall in a warm spring rain.

[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810

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

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

--- Comment #24 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #23)
> Created attachment 60785 [details]
> Fully reduced testcase
> 
> `./xgcc -B. -O2 -g -fcompare-debug -S t.c -fschedule-insns` is enough now.
> This fails for both C and C++ front-ends.

With the latest patch (attached here) we get:
```
diff -up t.cc.gkd t.gk.cc.gkd |less
--- t.cc.gkd2025-03-16 21:42:13.762110092 -0700
+++ t.gk.cc.gkd 2025-03-16 21:42:13.909110107 -0700
@@ -108,13 +108,9 @@ Declarations used by l, sorted by DECL_U
 (note # 0 0 NOTE_INSN_PROLOGUE_END)
 (insn # 0 0 (set (reg/f:DI 19 x19 [orig:109 m ] [109])
 (reg:DI 1 x1 [ m ]))# {*movdi_aarch64}
- (nil))
-(insn:TI # 0 0 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
-(const_int 40 [0x28])) [ %sfp+-24 S8 A64])
-(reg/f:DI 1 x1 [orig:109 m ] [109]))# {*movdi_aarch64}
- (expr_list:REG_DEAD (reg/f:DI 1 x1 [orig:109 m ] [109])
+ (expr_list:REG_DEAD (reg:DI 1 x1 [ m ])
 (nil)))
-(call_insn # 0 0 (parallel [
+(call_insn:TI # 0 0 (parallel [
 (call (mem:DI (symbol_ref:DI ("_Z1gv") [flags 0x41] 
) [ g S8 A8])
 (const_int 0 [0]))
 (unspec:DI [


```

The first difference is in LRA:
```
  
  --
  
  Creating newreg=112, assigning class NO_REGS to save r112
   14: call [`_Z1gv'] argc:0
  REG_CALL_DECL `_Z1gv'
Add reg<-save before:
   61: r109:DI=r112:DI

   13: NOTE_INSN_BASIC_BLOCK 3
Add save<-reg after:
   60: r112:DI=r109:DI
```

Is there for without -g and missing for the -g case.

I hope this helps. Because this is now a small testcase and all.

[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810

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

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

--- Comment #22 from Andrew Pinski  ---
Created attachment 60784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60784&action=edit
First step at reducing the testcase

I did:
git cherry-pick 3c67a0fa1dd39a3378deb854a7fef0ff7fe38004

First and then built a cross compiler for aarch64-linux-gnu

[apinski@xeond2 gcc]$ ./xgcc -B. -O2 -g -fcompare-debug -fno-exceptions
-fno-rtti -S t.cc -fschedule-insns
xgcc: error: t.cc: ‘-fcompare-debug’ failure (length)

[Bug c++/119319] [14/15 Regression] incorrect error: invalid use of incomplete type

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

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

--- Comment #6 from Andrew Pinski  ---
> I just can't find the incompleteness

the use of Xyzzy is before it is fully declared. There is only a forward
declaration of the struct type when it is used.

[Bug c/119317] Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

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

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

--- Comment #3 from Andrew Pinski  ---
I should mention another workaround if you don't want to disable debugging
info, is to add -gno-statement-frontiers . Since there are no debugger
consumers of dwarf statement-frontiers should not cause any issues with your
debugging experience.

[Bug cobol/119213] gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with hardcoded lib64

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

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

Robert Dubner  changed:

   What|Removed |Added

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

--- Comment #7 from Robert Dubner  ---
There are two major issues here.  I'll put them into two comments.

I acknowledge that CPPFLAGS doesn't belong to me; I used it to solve a problem
before I understood that Make-lang.in gets incorporated with all of the other
Make-lang.in fragments to create the top-level Makefile.

However, I used it to solve a couple of problems.  I need advice as to how to
solve them.

First, and foremost:  As currently implemented, the host code and the libgcobol
code use the same data structures.  Simple example: exception processing. The
gcc/cobol and libgcobol code need to agree on what the exception codes are. 
So, that's kept in libgcobol/ec.h, and the gcc/cobol code needs to access it.

Another example:  COBOL variables are data structures; that structure contains
information about cbl_field_type_t, an enum that indicates the type of COBOL
variable.  The gcc/cobol host code and the gcc/libgcobol code have to agree on
those.  So, that information is in libgcobol/common-defs.h, and is accessed by
gcc/cobol code, too.

If I get rid of the -I$(LIB_INCLUDE) that I put into CPPFLAGS, the "can't find
ec.h" errors appear.

I suppose that I could fix this with >>>#include "../../libgcobol/ec.h"<<<
everywhere #include "ec.h" currently appears.

Is that my solution?

[Bug tree-optimization/119318] New: [15 Regression] wrong code with vector arithmetics at -O2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 119318
   Summary: [15 Regression] wrong code with vector arithmetics at
-O2
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  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 60786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60786&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O2 testcase.c -Wno-psabi
$ ./a.out 
Aborted

$ 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-20250316155648-r15-8074-g5ed0564f2879db-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.1/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
--disable-bootstrap --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-20250316155648-r15-8074-g5ed0564f2879db-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250316 (experimental) (GCC)

[Bug tree-optimization/119318] [15 Regression] wrong code with vector arithmetics at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-03-17
   Target Milestone|--- |15.0

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

[Bug c++/119319] incorrect error: invalid use of incomplete type

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

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

--- Comment #1 from Hans-Peter Nilsson  ---
Tested gcc-14.2 and trunk at r15-7991-g503f10e34dcd
No other options than -O0 / -O1 are required to reproduce.

[Bug c++/119319] incorrect error: invalid use of incomplete type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-17
 Target|arm-linux-gnueabi   |arm*-*-*eabi
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |14.3

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

[Bug c++/119319] New: incorrect error: invalid use of incomplete type

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

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

Bug ID: 119319
   Summary: incorrect error: invalid use of incomplete type
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---
Target: arm-linux-gnueabi

Created attachment 60787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60787&action=edit
Reduced testcase. Error at -O1 or above, only for the listed target, no error
at -O0

For the attached heavily reduced test-case, this error is emitted at -O1 and
above, but only for the listed target (arm-linux-gnueabi):

../../testcase.cc: In instantiation of 'struct std::pair >':
../../testcase.cc:67:34:   required from 'constexpr std::_Vector_base<_Tp,
_Alloc>::~_Vector_base() [with _Tp = std::pair >; _Alloc =
std::allocator > >]'
   67 |  _M_impl._M_end_of_storage - _M_impl._M_start);
  |  ~~^~
../../testcase.cc:75:11:   required from here
   75 | class vector : protected _Vector_base < _Tp, _Alloc > { };
  |   ^~
../../testcase.cc:24:9: error: 'std::pair<_T1, _T2>::first' has incomplete type
   24 | _T1 first;
  | ^
../../testcase.cc:83:9: note: forward declaration of 'class n0::Xyzzy'
   83 |   class Xyzzy;
  | ^
../../testcase.cc: In constructor 'n0::CL0::CL0(int, const char*, const
n0::US0&)':
../../testcase.cc:106:28: note: synthesized method 'constexpr
std::vector >,
std::allocator > >
>::~vector()' first required here
  106 |   : Error (err, estr), us0 (vec) { }
  |^

The key line being has incomplete type and what seems to refer to Xyzzy, but
the error message quotes a forward declaration, though there's a complete
declaration (reduced empty).

I just can't find the incompleteness, and the optimization and target-specific
behavior tells me this is a gcc bug rather than program error.

Targets for which this error does *not* appear: cris-elf, aarch64-linux (also
with -mabi=ilp32).  The -ftree-dump-original output shows an extra return
statement for the listed target, which looks correlated.  (I have not traced
its target-specific origin.)

[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #60784|0   |1
is obsolete||

--- Comment #23 from Andrew Pinski  ---
Created attachment 60785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60785&action=edit
Fully reduced testcase

`./xgcc -B. -O2 -g -fcompare-debug -S t.c -fschedule-insns` is enough now. This
fails for both C and C++ front-ends.

[Bug c++/119319] [14/15 Regression] incorrect error: invalid use of incomplete type

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 60788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60788&action=edit
Reduced further

[Bug cobol/119213] gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with hardcoded lib64

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #8 from Xi Ruoyao  ---
(In reply to Robert Dubner from comment #7)
> There are two major issues here.  I'll put them into two comments.
> 
> I acknowledge that CPPFLAGS doesn't belong to me; I used it to solve a
> problem before I understood that Make-lang.in gets incorporated with all of
> the other Make-lang.in fragments to create the top-level Makefile.
> 
> However, I used it to solve a couple of problems.  I need advice as to how
> to solve them.
> 
> First, and foremost:  As currently implemented, the host code and the
> libgcobol code use the same data structures.  Simple example: exception
> processing. The gcc/cobol and libgcobol code need to agree on what the
> exception codes are.  So, that's kept in libgcobol/ec.h, and the gcc/cobol
> code needs to access it.
> 
> Another example:  COBOL variables are data structures; that structure
> contains information about cbl_field_type_t, an enum that indicates the type
> of COBOL variable.  The gcc/cobol host code and the gcc/libgcobol code have
> to agree on those.  So, that information is in libgcobol/common-defs.h, and
> is accessed by gcc/cobol code, too.
> 
> If I get rid of the -I$(LIB_INCLUDE) that I put into CPPFLAGS, the "can't
> find ec.h" errors appear.
> 
> I suppose that I could fix this with >>>#include "../../libgcobol/ec.h"<<<
> everywhere #include "ec.h" currently appears.
> 
> Is that my solution?

Or move ec.h etc. into gcc/cobol, and in libgcobol add
-I$(srcdir)/../gcc/cobol.  It'd be like how libgcc uses headers in the gcc/
directory.

[Bug c++/119319] [14/15 Regression] incorrect error: invalid use of incomplete type

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

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

--- Comment #7 from Andrew Pinski  ---
That is:
```
  using US0 = vv < std::pair < n0::Xyzzy, typename n1::CL1 < n1::S0, 999 >::ps
> >;
  class CL0 : public Error
  {
  private:
US0 us0;
  public:
CL0 (int err, const char *estr, const US0 & vec)
  : Error (err, estr), us0 (vec) { }
  };
  class Xyzzy : public n1::CL2 < x0 > { };

```

Xyzzy is used in CL0's us0 via the `std::vector>`.

[Bug c/47409] volatile struct member bug

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

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

--- Comment #27 from Andrew Pinski  ---
I am not even sure if clang implementation of this is correct either.
Take:
```
struct s2 {
  volatile int t;
  int x[1024];
};
struct s2 s;
void foo () {
  s = s;
}
```

clang will copy all of s2 rather than just the volatile part.

So it looks like clang just promotes the whole struct to volatile; though not
fully.

[Bug c++/119319] [14/15 Regression] incorrect error: invalid use of incomplete type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-stdcheck

--- Comment #5 from Andrew Pinski  ---
I am 99% sure this is invalid code; that just happens to get accepted on other
targets.

EDG and clang reject it.
MSVC accepts it.

[Bug c/119317] Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-03-17

--- Comment #2 from Andrew Pinski  ---
Confirmed. statement-frontiers come into play again.

[Bug c/47409] volatile struct member bug

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

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

--- Comment #26 from Andrew Pinski  ---
(In reply to Richard Biener from comment #6)
> We should at least make sure to use memcpy for the array part in
> 
> struct {
>   volatile int i;
>   int a[10];
> } a, b;
> a = b;
> 
> do we really want to blow up code-size (and compile-time) for

(and stack in some cases).  See
https://github.com/llvm/llvm-project/issues/118149#issuecomment-2710308402
which shows that clang will place sometimes the full object on the stack and
then do a copy of part of it using load/store (for the volatile part) and then
memcpy for the rest. instead of just using the volatile part of the stack only.

[Bug debug/119317] Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

[gandalf at winds dot org via Gcc-bugs]

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

--- Comment #1 from gandalf at winds dot org ---
Created attachment 60783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60783&action=edit
test17.i

[Bug debug/119317] New: Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

[gandalf at winds dot org via Gcc-bugs]

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

Bug ID: 119317
   Summary: Named loops (C2y) do not compile with -O1 and -ggdb2
or higher
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

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

The following function fails to compile with -O1 and -ggdb2 or higher:

int fun()
{
  main:
  while(1)
continue main;
}

$ gcc-15 -std=gnu2y -O1 -ggdb2 -Wall -c -o test17.o test17.c
test17.c: In function 'fun':
test17.c:5:14: error: 'continue' statement operand 'main' does not refer to a
named loop
test17.c:3:3: warning: label 'main' defined but not used