[Bug libstdc++/120068] New: The new contrib/relpath.sh script should be made executable otherwise the build fails

[guido2022 at trentalancia dot com via Gcc-bugs]

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

Bug ID: 120068
   Summary: The new contrib/relpath.sh script should be made
executable otherwise the build fails
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guido2022 at trentalancia dot com
  Target Milestone: ---

The new contrib/relpath.sh shell script introduced in PR/libstdc++ 106852
should be made executable, otherwise the build fails due to "permission denied"
error.

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |bootstrap

--- Comment #1 from Andrew Pinski  ---
it is executable in git:
[apinski@xeond2 gcc]$ ls -latr contrib/relpath.sh
-rwxr-xr-x. 1 apinski apinski 1487 Apr 16 14:32 contrib/relpath.sh

[Bug rtl-optimization/120059] [16 regression] ICE when building mesa in vartrack since r16-286

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #11 from Joseph S. Myers  ---
The same commit also causes an ICE building glibc for powerpc64le-linux-gnu
(probably causes the build failure for powerpc64-linux-gnu as well, but
powerpc64le was what I used for bisection).

[Bug c/117023] [C2y] Implement N3322, Allow zero length operations on null pointers

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

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

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

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

commit r16-363-g1e27e9a3184c948b499a21ff20181611514ed720
Author: Jakub Jelinek 
Date:   Fri May 2 19:40:55 2025 +0200

ranger: Improve nonnull_if_nonzero attribute [PR117023]

On Mon, Mar 31, 2025 at 11:30:20AM -0400, Andrew MacLeod wrote:
> Infer range processing was adjusted to allow a query to be specified,
> but during VRP folding, ranger w3as not providing a query.  This results
> in contextual ranges being missed.   Pass the cache in as the query
> which provide a read-only query of the current state.

Now that this patch is in, I've retested my patch and it works fine.
If we can determine a range for the arg2 argument and prove that it
doesn't include zero, we can imply nonzero for the arg1 argument.

2025-05-02  Jakub Jelinek  
Andrew MacLeod  

PR c/117023
* gimple-range-infer.cc (gimple_infer_range::gimple_infer_range):
For nonnull_if_nonzero attribute check also arg2 range if it
doesn't
include zero and in that case call add_nonzero too.

* gcc.dg/tree-ssa/pr78154-2.c: New test.

[Bug target/118100] [14/15/16 Regression] Segment Fault by rvv intrinsic compilation at `-O2` and `-O3`.

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #2 from mcccs at gmx dot com ---
I meant spike --isa=rv64gcv_zvfh pk a.out

[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error

[simonsobisch at gnu dot org via Gcc-bugs]

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

--- Comment #5 from Simon Sobisch  ---
@Bob, what do you think of committing that patch as it waits on one of the
COBOL maintainers (and later or work on supporting that - at least as
"ignored")?

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> it is executable in git:
> [apinski@xeond2 gcc]$ ls -latr contrib/relpath.sh
> -rwxr-xr-x. 1 apinski apinski 1487 Apr 16 14:32 contrib/relpath.sh

https://gcc.gnu.org/cgit/gcc/tree/contrib:
-rwxr-xr-x  relpath.sh

[Bug target/120067] RISC-V: x264 sub4x4_dct high icount

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Note this reduced testcase can be misleading.
The local 'd' array is used uninitialised, which is undefined.
Clang optimises away the whole function to a store of zero, for example.

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

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

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

--- Comment #4 from Jerry DeLisle  ---
Vincent was able to reduce this further. Two files, gtk_sup.f90 and test.f90.

$ cat gtk_sup.f90 
module gtk_sup
  use, intrinsic :: iso_c_binding
end module gtk_sup

$ cat test.f90
program tests_gtk_sup
use gtk_sup

type(c_ptr), target :: val

! If you comment the following line, it compiles and runs:
print *, c_associated(val, c_loc(val))

end program tests_gtk_sup

$ gfc -c gtk_sup.f90 
$ ls
gtk_sup.f90  gtk_sup.mod  gtk_sup.o  test.f90
$ gfc -c test.f90 
f951: internal compiler error: gfc_typename(): Undefined type
0x694bce diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../trunk/gcc/diagnostic.h:1180
0x694bce gfc_report_diagnostic
../../trunk/gcc/fortran/error.cc:250
0x694bce gfc_internal_error(char const*, ...)
../../trunk/gcc/fortran/error.cc:834
0x6d5ecf gfc_typename(gfc_typespec*, bool)
../../trunk/gcc/fortran/misc.cc:218
0x66335a gfc_check_c_associated(gfc_expr*, gfc_expr*)
../../trunk/gcc/fortran/check.cc:5977
0x6aeb92 check_specific
../../trunk/gcc/fortran/intrinsic.cc:4971
0x6b7bb5 gfc_intrinsic_func_interface(gfc_expr*, int)
../../trunk/gcc/fortran/intrinsic.cc:5217
0x72626b resolve_unknown_f
   ...

Anyone have any thoughts?

Re: [Bug target/120067] New: RISC-V: x264 sub4x4_dct high icount

[Robin Dapp via Gcc-bugs]

This is reduced from 525.x264_r's 4th hottest block:
https://godbolt.org/z/KdWv1er6f

AArch64 assembly is clean and efficient (35 insns) while RISC-V's is long and
messy (114 insns).

The most obvious issue is that it keeps spilling and reloading the same data
from the stack. Also I do not understand why we need those vslidedown.

A rapid look at the expand dump (see attachment) shows that the latter come
from VIEW_CONVERT_EXPR.

I will keep looking into this.


If it's just about "short and non-messy" just drop the -mrvv-vector-bits=zvl.  
Without it our code is similar to aarch64's.


There is indeed a problem with =zvl that we have been discussing in the 
patchwork sync call for a while already.  The issue is that we're handling VLS 
modes as VLA modes in certain situations resulting in unfortunate codegen.  The 
vector extracts (slidedowns) are one example of it.


The whole function is not very easy to vectorize efficiently, though.  qemu 
icount will give a wrong impression here because usually segmented loads and 
stores are rather slow.  IMHO a good implementation will need to be longer and 
messier.


--
Regards
Robin

[Bug target/120067] RISC-V: x264 sub4x4_dct high icount

[rdapp.gcc at gmail dot com via Gcc-bugs]

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

--- Comment #2 from rdapp.gcc at gmail dot com ---
> This is reduced from 525.x264_r's 4th hottest block:
> https://godbolt.org/z/KdWv1er6f
>
> AArch64 assembly is clean and efficient (35 insns) while RISC-V's is long and
> messy (114 insns).
>
> The most obvious issue is that it keeps spilling and reloading the same data
> from the stack. Also I do not understand why we need those vslidedown.
>
> A rapid look at the expand dump (see attachment) shows that the latter come
> from VIEW_CONVERT_EXPR.
>
> I will keep looking into this.

If it's just about "short and non-messy" just drop the -mrvv-vector-bits=zvl.  
Without it our code is similar to aarch64's.

There is indeed a problem with =zvl that we have been discussing in the 
patchwork sync call for a while already.  The issue is that we're handling VLS 
modes as VLA modes in certain situations resulting in unfortunate codegen.  The 
vector extracts (slidedowns) are one example of it.

The whole function is not very easy to vectorize efficiently, though.  qemu 
icount will give a wrong impression here because usually segmented loads and 
stores are rather slow.  IMHO a good implementation will need to be longer and 
messier.

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

[guido2022 at trentalancia dot com via Gcc-bugs]

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

guido2022 at trentalancia dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from guido2022 at trentalancia dot com ---
Yes, you are right, I am experiecing the issue because I upgraded to gcc-15.1.0
by using the gcc-14.2.0-15.1.0.diff.xz patch.

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

[guido2022 at trentalancia dot com via Gcc-bugs]

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

--- Comment #6 from guido2022 at trentalancia dot com ---
The issue is only triggered by using the differential patch and not the tarball
or git.

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

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

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

--- Comment #4 from Andrew Pinski  ---
Also can you provide what target are you building for and on?
The exact configure command line?
Did you extract the tar ball not with GNU tar (which is required)?

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-05-02
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Downloaded a fresh release tar ball and the executable bit is set.
```
[apinski@xeond2 releases]$ wget
https://gcc.gnu.org/pub/gcc/releases/gcc-15.1.0/gcc-15.1.0.tar.xz
--2025-05-02 11:29:09-- 
https://gcc.gnu.org/pub/gcc/releases/gcc-15.1.0/gcc-15.1.0.tar.xz
Resolving gcc.gnu.org (gcc.gnu.org)... 8.43.85.97, 2620:52:3:1:0:246e:9693:128c
Connecting to gcc.gnu.org (gcc.gnu.org)|8.43.85.97|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 98268344 (94M) [application/x-xz]
Saving to: ‘gcc-15.1.0.tar.xz’

gcc-15.1.0.tar.xz  
100%[>]
 93.72M  2.13MB/sin 30s

2025-05-02 11:29:40 (3.10 MB/s) - ‘gcc-15.1.0.tar.xz’ saved [98268344/98268344]

[apinski@xeond2 releases]$ tar xf gcc-15.1.0.tar.xz
[apinski@xeond2 releases]$ ls -l gcc-15.1.0/contrib/relpath.sh
-rwxr-xr-x. 1 apinski apinski 1487 Apr 25 01:17 gcc-15.1.0/contrib/relpath.sh
```

The first line of relpath.sh:
```
#!/bin/sh
```

Which looks correct.

Can you give the exact command that is failing?

[Bug bootstrap/120068] The new contrib/relpath.sh script should be made executable otherwise the build fails

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to guido2022 from comment #6)
> The issue is only triggered by using the differential patch and not the
> tarball or git.

Right, the diff is only there for folks to look at and not really use. the diff
does not contain the meta data about the executable bits at all; it is not
using git diff.

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)

> $ gfc -c test.f90 
> f951: internal compiler error: gfc_typename(): Undefined type
> 0x694bce diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
>   ../../trunk/gcc/diagnostic.h:1180
> 0x694bce gfc_report_diagnostic
>   ../../trunk/gcc/fortran/error.cc:250
> 0x694bce gfc_internal_error(char const*, ...)
>   ../../trunk/gcc/fortran/error.cc:834
> 0x6d5ecf gfc_typename(gfc_typespec*, bool)
>   ../../trunk/gcc/fortran/misc.cc:218
> 0x66335a gfc_check_c_associated(gfc_expr*, gfc_expr*)
>   ../../trunk/gcc/fortran/check.cc:5977
> 0x6aeb92 check_specific
>   ../../trunk/gcc/fortran/intrinsic.cc:4971
> 0x6b7bb5 gfc_intrinsic_func_interface(gfc_expr*, int)
>   ../../trunk/gcc/fortran/intrinsic.cc:5217
> 0x72626b resolve_unknown_f
>...
> 
> Anyone have any thoughts?

Yes.  Set a breakpoint at check.cc:5977 and print c_ptr_2:

c_loc is a function and BT_VOID, and this is not handled.

[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #15 from John David Anglin  ---
The testsuite errors that I see are like this:
RUN ad8011a


raised ADA.CALENDAR.TIME_ERROR : a-calend.adb:601
FAIL:   ad8011a

[Bug tree-optimization/120065] [14/15/16 Regression] profile info corrupted by dom2

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

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

--- Comment #3 from Jan Hubicka  ---

  while (n > 0 && a)
;

This is an odd loop which loops iterates 0 times or infinitely many times.
We do not pattern match that at profile-estimate time (since such code is kind
of useless) and we guess it iterates 8.09 times.  

Befoe dom 2 we have:

  a.0_17 = a;
  if (a.0_17 != 0B)
goto ; [94.50%]
  else
goto ; [5.50%]

:
:
  a.0_1 = a;
  if (a.0_1 != 0B)
goto ; [94.50%]
  else
goto ; [5.50%]

  goto bb 4

:
  ... for loop

We do not yet see that the loop is infinite.

Dom optimizes it to:

  if (n_9(D) > 0)
goto ; [48.59%]
  else
goto ; [51.41%]
:
  a.0_17 = a;
  if (a.0_17 != 0B) 
goto ; [94.50%]
  else
goto ; [5.50%]  

:
  Here is "Invalid sum of incoming counts 1011616600 (estimated locally, freq
8.8071), should be 958878295 (estimated locally, freq 8.3480)"

  a.0_1 = a.0_17;
  goto ; [100.00%]


  Here is "Invalid sum of incoming counts 3069425 (estimated locally, freq
0.0267), should be 102228543 (estimated locally, freq 0.8900)"

  j = 0;
  j.4_16 = 0;
  if (n_9(D) > 0)
goto ; [100.00%]
  else
goto ; [0.00%]


Now BB 4 is a self loop which by itself can not have right profile (frequency
would have to be infinity and thus it gets capped to something) and bb 5 is now
header of the for loop. Before we discovered that while loop is infinite, we
expected it to finish and go to next loop and that is why the profile is too
high after removing this path.

It is kind of pathological case, but if infinite was discovered in early
optimizations things would be smoother overall. Function body would be smaller,
profile would not be mis-guessed. We could detect that if forced progression is
on, the program is valid only if the whole loop does not iterate)

[Bug c/120057] [15/16 regression] 'constexpr' integer initializer is not an integer constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/120057] [15/16 regression] 'constexpr' integer initializer is not an integer constant expression

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:14c2a12748eea0eef714a125cb1a6c834fd60560

commit r15-9615-g14c2a12748eea0eef714a125cb1a6c834fd60560
Author: Jakub Jelinek 
Date:   Fri May 2 21:19:05 2025 +0200

c: Fix up RAW_DATA_CST handling in check_constexpr_init [PR120057]

The pr120057-1.c testcase is incorrectly rejected since
 r15-4377 (and for a while it also ICEd after the error), i.e.
the optimization of large C initializers using RAW_DATA_CST.
Similarly, the embed-18.c testcase is incorrectly rejected since
the embed support has been introduced and RAW_DATA_CST used for that.

The callers of check_constexpr_init (store_init_value and
output_init_element) compute int_const_expr as
  int_const_expr = (TREE_CODE (init) == INTEGER_CST
&& !TREE_OVERFLOW (init)
&& INTEGRAL_TYPE_P (TREE_TYPE (init)));
but that is only passed through down to check_constexpr_init.
I think tweaking those 2 callers to also allow RAW_DATA_CST for
int_const_expr when check_constexpr_init needs top special case it
no matter what would be larger, so the patch just changes
check_constexpr_init to deal with RAW_DATA_CST in the initializers.
For TYPE_UNSIGNED char precision integral types RAW_DATA_CST is
always valid, for !TYPE_UNSIGNED we need to check for 128-255 values
being turned into negative ones.

2025-05-02  Jakub Jelinek  

PR c/120057
* c-typeck.cc (check_constexpr_init): Handle RAW_DATA_CST.

* gcc.dg/cpp/embed-18.c: New test.
* gcc.dg/pr120057-1.c: New test.
* gcc.dg/pr120057-2.c: New test.

(cherry picked from commit e81f2f4855876c5d85ab9870c5a150ee1a59ee73)

[Bug c/120057] [15/16 regression] 'constexpr' integer initializer is not an integer constant expression

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

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

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

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

commit r16-364-ge81f2f4855876c5d85ab9870c5a150ee1a59ee73
Author: Jakub Jelinek 
Date:   Fri May 2 21:19:05 2025 +0200

c: Fix up RAW_DATA_CST handling in check_constexpr_init [PR120057]

The pr120057-1.c testcase is incorrectly rejected since
 r15-4377 (and for a while it also ICEd after the error), i.e.
the optimization of large C initializers using RAW_DATA_CST.
Similarly, the embed-18.c testcase is incorrectly rejected since
the embed support has been introduced and RAW_DATA_CST used for that.

The callers of check_constexpr_init (store_init_value and
output_init_element) compute int_const_expr as
  int_const_expr = (TREE_CODE (init) == INTEGER_CST
&& !TREE_OVERFLOW (init)
&& INTEGRAL_TYPE_P (TREE_TYPE (init)));
but that is only passed through down to check_constexpr_init.
I think tweaking those 2 callers to also allow RAW_DATA_CST for
int_const_expr when check_constexpr_init needs top special case it
no matter what would be larger, so the patch just changes
check_constexpr_init to deal with RAW_DATA_CST in the initializers.
For TYPE_UNSIGNED char precision integral types RAW_DATA_CST is
always valid, for !TYPE_UNSIGNED we need to check for 128-255 values
being turned into negative ones.

2025-05-02  Jakub Jelinek  

PR c/120057
* c-typeck.cc (check_constexpr_init): Handle RAW_DATA_CST.

* gcc.dg/cpp/embed-18.c: New test.
* gcc.dg/pr120057-1.c: New test.
* gcc.dg/pr120057-2.c: New test.

[Bug target/120069] New: Yes another imagick -march=native -flto -Ofast + PGO regression between g:1c0cbc1b300e08df5ebfce00a7195890d78f2064 and g:55b01e17c793688a2878fa43a76df1266153b438

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

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

Bug ID: 120069
   Summary: Yes another imagick -march=native -flto -Ofast + PGO
regression between
g:1c0cbc1b300e08df5ebfce00a7195890d78f2064 and
g:55b01e17c793688a2878fa43a76df1266153b438
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is seen on zen2
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=286.507.0
and zen3
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=477.507.0

There are quite few suspects, so it would be nice to bisect this...

[Bug target/120019] [16 regression] PR 111657 change broke Solaris/x86 bootstrap

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
Comment on attachment 61270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61270
Proposed patch

># HG changeset patch
># Parent  45d1a47b563d28797adaefc1f063c6e3d2541ec3
>i386: Fix rep movs[qldb] handling with Solaris/x86 as
>
>diff --git a/gcc/config.in b/gcc/config.in
>--- a/gcc/config.in
>+++ b/gcc/config.in
>@@ -526,6 +526,12 @@
> #endif
> 
> 
>+/* Define if the assembler supports movs operands. */
>+#ifndef USED_FOR_TARGET
>+#undef HAVE_AS_IX86_MOVS_OPERANDS
>+#endif

We should avoid above complication with asm support detection and always use
explicit prefixes.

>+
> /* Define if your assembler supports the .quad directive. */
> #ifndef USED_FOR_TARGET
> #undef HAVE_AS_IX86_QUAD
>diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
>--- a/gcc/config/i386/i386.cc
>+++ b/gcc/config/i386/i386.cc
>@@ -13829,6 +13829,7 @@ print_reg (rtx x, int code, FILE *file)
>H -- print a memory address offset by 8; used for sse high-parts
>Y -- print condition for XOP pcom* instruction.
>V -- print naked full integer register name without %.
>+   v -- print address space prefix unless HAVE_AS_IX86_MOVS_OPERANDS

Better say "-- print segment override prefix"

>+ -- print a branch hint as 'cs' or 'ds' prefix
>; -- print a semicolon (after prefixes due to bug in older gas).
>~ -- print "i" if TARGET_AVX2, "f" otherwise.
>@@ -14334,6 +14335,25 @@ ix86_print_operand (FILE *file, rtx x, i
> 
> return;
> 
>+  case 'v':
>+#ifndef HAVE_AS_IX86_MOVS_OPERANDS
>+if (MEM_P (x) && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x)))
>+  return;
>+
>+switch (MEM_ADDR_SPACE (x))
>+  {
>+  case ADDR_SPACE_SEG_FS:
>+fputs ("fs ", file);
>+break;
>+  case ADDR_SPACE_SEG_GS:
>+fputs ("gs ", file);
>+break;
>+  default:
>+gcc_unreachable ();
>+  }
>+#endif

We can perhaps also report operand lossage for invalid operands:

if (MEM_P (x))
  {
switch (MEM_ADDR_SPACE (x))
  {
...
case ADDR_SPACE_GENERIC:
  break;
default:
  gcc_unreachable ();
  }
   }
  else
   output_operand_lossage ("operand is not a memory reference, invalid operand
code 'v'");


>+return;
>+
>   case '*':
> if (ASSEMBLER_DIALECT == ASM_ATT)
>   putc ('*', file);
>diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
>--- a/gcc/config/i386/i386.h
>+++ b/gcc/config/i386/i386.h
>@@ -3039,6 +3039,12 @@ extern enum attr_cpu ix86_schedule;
> #define LIBGCC2_UNWIND_ATTRIBUTE __attribute__((target ("no-mmx,no-sse")))
> #endif
> 
>+#ifdef HAVE_AS_IX86_MOVS_OPERANDS
>+#define MOVS_OPERANDS "\t{%1, %0|%0, %1}"
>+#else
>+#define MOVS_OPERANDS ""
>+#endif

The above is not needed when explicit prefixes are always used

> /*
> Local variables:
> version-control: t
>diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>--- a/gcc/config/i386/i386.md
>+++ b/gcc/config/i386/i386.md
>@@ -58,6 +58,7 @@
> ;; H -- print a memory address offset by 8; used for sse high-parts
> ;; K -- print HLE lock prefix
> ;; Y -- print condition for XOP pcom* instruction.
>+;; v -- print address space prefix unless HAVE_AS_IX86_MOVS_OPERANDS

As above.

> ;; + -- print a branch hint as 'cs' or 'ds' prefix
> ;; ; -- print a semicolon (after prefixes due to bug in older gas).
> ;; ~ -- print "i" if TARGET_AVX2, "f" otherwise.
>@@ -25643,7 +25644,7 @@
>   operands[0] = SET_DEST (exp);
>   operands[1] = SET_SRC (exp);
> 
>-  return "movsq\t{%1, %0|%0, %1}";
>+  return "movsq" MOVS_OPERANDS;

This also needs to output addr32 prefix (%^) and the new segment override
prefix:

return "%^%v1movsq"

> }
>   [(set_attr "type" "str")
>(set_attr "memory" "both")
>@@ -25666,7 +25667,7 @@
>   operands[0] = SET_DEST (exp);
>   operands[1] = SET_SRC (exp);
> 
>-  return "movs{l|d}\t{%1, %0|%0, %1}";
>+  return "movs{l|d}" MOVS_OPERANDS;

Also here and for other instructions.

> }
>   [(set_attr "type" "str")
>(set_attr "memory" "both")
>@@ -25689,7 +25690,7 @@
>   operands[0] = SET_DEST (exp);
>   operands[1] = SET_SRC (exp);
> 
>-  return "movsw\t{%1, %0|%0, %1}";
>+  return "movsw" MOVS_OPERANDS;
> }
>   [(set_attr "type" "str")
>(set_attr "memory" "both")
>@@ -25712,7 +25713,7 @@
>   operands[0] = SET_DEST (exp);
>   operands[1] = SET_SRC (exp);
> 
>-  return "movsb\t{%1, %0|%0, %1}";
>+  return "movsb" MOVS_OPERANDS;
> }
>   [(set_attr "type" "str")
>(set_attr "memory" "both")
>@@ -25759,7 +25760,7 @@
>   operands[0] = SET_DEST (exp);
>   operands[1] = SET_SRC (exp);
> 
>-  return "rep{%;} movsq\t{%1, %0|%0, %1}";
>+  return "%^%v1rep{%;} movsq" MOVS_OPERANDS;

On a related note, ";" after prefix is a historic relict which should probably
be removed.

> }
>   [(set_attr "type" "str")
>(set_attr "prefix_rep" "1")
>@@ -25786,7 +25787,7 @@
>   operands[0] =

[Bug c++/107744] Error in constant evaluation of dynamic_cast

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jason Merrill  ---
Fixed by r16-325-g25fe59805029e1 like PR85944.

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

[Bug c++/85944] Address of temporary at global scope not considered constexpr

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

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

--- Comment #19 from Jason Merrill  ---
*** Bug 107744 has been marked as a duplicate of this bug. ***

[Bug c++/85944] Address of temporary at global scope not considered constexpr

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

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

--- Comment #18 from Jason Merrill  ---
*** Bug 99018 has been marked as a duplicate of this bug. ***

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 107744 Summary: Error in constant evaluation of dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107744

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[mitza at ociweb dot com via Gcc-bugs]

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

--- Comment #19 from Adam Mitz  ---
Bison users may insert arbitrary code (like a #pragma) in the input file which
is copied to the output.  As an example, this is used to silence GCC's warning
here
https://github.com/DOCGroup/ACE_TAO/blob/e3b027b753b21daf35682d34a1f0f1f4c7af40ff/ACE/ace/Svc_Conf.y#L48

[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can you please upload a collection of header files + source in that case
(everything strace shows as being loaded)?
And/or perhaps try to gradually replace content of the source files with empty
lines if it is solely about certain number of lines.

[Bug tree-optimization/120065] New: [14/15/16 Regression] profile info corrupted by dom2

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

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

Bug ID: 120065
   Summary: [14/15/16 Regression] profile info corrupted by dom2
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following testcase on the trunk, the profile info gets corrupted by
dom2 (reproduced on both x86_64 and aarch64):

$ cat small.c
float *a;
int j;
void foo(int n, float f) {
  while (n > 0 && a)
;
  for (j = 0; j < n; ++j)
a[j] = f;
}
$ ./xgcc -B . -c small.c -O2 -S -o /dev/null
-fdump-tree-thread1-blocks-details=- | grep -B 1 "Invalid sum"
$ ./xgcc -B . -c small.c -O2 -S -o /dev/null -fdump-tree-dom2-blocks-details=-
| grep -B 1 "Invalid sum"
;;   basic block 4, loop depth 1, count 958878295 (estimated locally, freq
8.3480), maybe hot
;;   Invalid sum of incoming counts 1011616600 (estimated locally, freq
8.8071), should be 958878295 (estimated locally, freq 8.3480)
--
;;   basic block 5, loop depth 0, count 102228543 (estimated locally, freq
0.8900), maybe hot
;;   Invalid sum of incoming counts 3069425 (estimated locally, freq 0.0267),
should be 102228543 (estimated locally, freq 0.8900)
--
;;   basic block 8, loop depth 0, count 12634988 (estimated locally, freq
0.1100), maybe hot
;;   Invalid sum of incoming counts 59055800 (estimated locally, freq 0.5141),
should be 12634988 (estimated locally, freq 0.1100)

It seems to have started in the GCC 14 timeframe.

[Bug target/119929] [16 Regression] build fails on mips64el-linux-gnu (and other mips targets) since r16-51-g727a43e0a66052

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Sorry, I've been pretty sick the last week.  I reverted the patch (there's was
a dependency on an earlier change in a large patchkit series).

[Bug c/120066] New: FAIL: gcc.c-torture/compile/pr51694.c -O0 (internal compiler error: Segmentation fault)

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

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

Bug ID: 120066
   Summary: FAIL: gcc.c-torture/compile/pr51694.c   -O0  (internal
compiler error: Segmentation fault)
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/ -fdiagnostics-plain-output -O0 -w -std=gnu17 -fpermissive -c -o
pr5
1694.o /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr51694.c
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr51694.c: In
functio
n 'foo':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr51694.c:10:3:
inter
nal compiler error: Segmentation fault
Please submit a full bug report, with preprocessed source (by using
-freport-bug
).
See  for instructions.
compiler exited with status 1
FAIL: gcc.c-torture/compile/pr51694.c   -O0  (internal compiler error:
Segmentation fault)
FAIL: gcc.c-torture/compile/pr51694.c   -O0  (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr51694.c:10:3:
internal compiler error: Segmentation fault

(gdb) r
Starting program: /home/dave/gnu/gcc/objdir64/stage1-gcc/cc1 -fpreprocessed
pr51   
   694.i -quiet
-dumpbase pr51694.c -dumpbase-ext .c -O0 -w -std=gnu17 -version -fd
   
  iagnostics-color=never
-fdiagnostics-urls=never -fno-diagnostics-show-caret -fno  
   
-diagnostics-show-line-numbers
-fdiagnostics-path-format=separate-events -fdiagn  
   
ostics-text-art-charset=none
-fno-diagnostics-show-event-links -fpermissive -o p
   
  r51694.s
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work.  See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.
GNU C17 (GCC) version 16.0.0 20250501 (experimental) [remotes/origin/HEAD
r16-33 

4-gb6d37ec1dd2] (hppa64-hp-hpux11.11)
compiled by GNU C version 12.4.1 20250420
[remotes/origin/releases/gcc-1 
   
 2 r12-11061-g0701c8d3250], GMP version 6.2.1, MPFR version 4.1.1,
MPC version 1. 

2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2774e6447d44ede61d9aee1059c29ac6

Program received signal SIGSEGV, Segmentation fault.
convert_arguments (fundecl=, function=0x83ffbfec7000,
origtypes=0x83ffbfea69d8, values=0x83ffbfea6a00,
fntype=0x83ffbfd8a7e0, arg_loc=..., loc=4611686018427387904)
at ../../gcc/gcc/tree.h:6922
6922  return DECL_BUILT_IN_CLASS (node) != NOT_BUILT_IN;
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x407180c4 to 0x407180e4:
   0x407180c4 , tree_node*, vec*,
vec*, tree_node*)+1580>: cmpb,*=,n
r0,ret0,0x407183c0 , tree_node*, vec*,
vec*, tree_node*)+2344>
   0x407180c8 , tree_node*, vec*,
vec*, tree_node*)+1584>: ldw 38(r14),ret0
   0x407180cc , tree_node*, vec*,
vec*, tree_node*)+1588>: bb,*<
ret0,1e,0x407180e8 , tree_node*, vec*,
vec*, tree_node*)+1616>
   0x407180d0 , tree_node*, vec*,
vec*, tree_node*)+1592>: ldd -138(sp),r20
=> 0x407180d4 , tree_node*, vec*,
vec*, tree_node*)+1596>: ldw dc(r13),r31
   0x407180d8  to continue, or q  to quit---
, va_heap, vl_ptr>, tree_node*, vec*,
vec*, tree_node*)+1600>:depwi,z
-1,31,30,ret0
   0x407180dc , tree_node*, vec*,
vec*, tree_node*)+1604>: cmpb,>>=
ret0,r31,0x4071831c , tree_node*, vec*, vec*, tree_node*)+2180>
   0x407180e0 , tree_node*, vec*,
vec*, tree_node*)+1608>: ldo 

[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

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

[Bug c/120066] FAIL: gcc.c-torture/compile/pr51694.c -O0 (internal compiler error: Segmentation fault)

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

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

--- Comment #2 from Andrew Pinski  ---
Fixed this morning.

[Bug c/120066] FAIL: gcc.c-torture/compile/pr51694.c -O0 (internal compiler error: Segmentation fault)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c/120057] [15/16 regression] 'constexpr' integer initializer is not an integer constant expression

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

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

--- Comment #3 from Jakub Jelinek  ---
Started with r15-4377-gf9bac238840155e1539aa68daf1507ea63c9ed80 (where it
started to ICE after error) and since
r15-5481-g5afc98fec97d84baa0c580809fb3e220444fa20d the ICE is gone.

[Bug c++/85944] Address of temporary at global scope not considered constexpr

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #17 from Jason Merrill  ---
Fixed on trunk by r16-325-g25fe59805029e1 for PR119162.

[Bug c++/115207] [constexpr] constexpr assignment rejected as non const on self-assignment test

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

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

Jason Merrill  changed:

   What|Removed |Added

   Last reconfirmed||2025-05-02
 CC||jason at gcc dot gnu.org
 Status|RESOLVED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #3 from Jason Merrill  ---
Not fixed by r16-325-g25fe59805029e1 so not a duplicate.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 115207 Summary: [constexpr] constexpr assignment rejected as non const on 
self-assignment test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115207

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|DUPLICATE   |---

[Bug target/119900] [16 regression] imagick slowdown with -Ofast -march=native -fprofile-use since r16-39-gf6859fb621179e (interaction of rpad and late-combine)

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r16-358-gc85148d036d17295bb2560e10020c924c83a5d13
Author: Jan Hubicka 
Date:   Fri May 2 15:53:35 2025 +0200

Make ix86 cost of VEC_SELECT equivalent to SUBREG cost 1

This patch fixes regression of imagick with PGO and AVX512 where correcting
size
cost of SSE operations (to be 4 instead of 2 originally cut&pasted from
x87)
made late combine to eliminate zero registers introduced by rapd.  The
problem
is that cost-model mistakely accounts VEC_SELECT as real instruction while
it is
optimized to nothing if src==dest (which is the case of these testcases).
This register is used to eliminate false dependency between source and
destination
of int->fp conversions.

While ix86_insn_cost hook already contains logic to incrase cost of the
zero-extend
the costs was not enough.

gcc/ChangeLog:

PR target/119900
* config/i386/i386.cc (ix86_can_change_mode_class): Add TODO
comment.
(ix86_rtx_costs): Make VEC_SELECT equivalent to SUBREG cost 1.

[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #8 from Andrew Macleod  ---
IKt seems the root problem is that the ipa_vr class doesn't support UNDEFINED
ranges, and in this case it has a range but when the bitmask is explicitly
applied, we recognize that the range is actualyl UNDEFINED and convert it... 
and then we trip over the UNDEFINED problem as it was unexpected.

Im going to look back at what happens when we always generate a mask and value
and keep the range properly normalized.

Aldy made it on-demand only because the cost was high at the time (5% VRP), but
we do occasionally keep tripping over out-of-sync things.. like this. There
(likely) wouldn't be a problem if the range was simply UNDEFINED at its
creation time rather than being in this intermediate state for "a while" and
then normalized to UNDEFINED when the bitmask is applied.  

Im curious what the cost would be now, and if it could be alleviated enough to
make it worthwhile. 

Another option is to add a type to UNDEFINED, which I have looked at before.
That has its own issues, but I will take another look in a bit.

[Bug rtl-optimization/120064] [15/16 Regression] -f[no-]ext-dce not documented

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|doc: -f[no-]ext-dce not |[15/16 Regression]
   |documented  |-f[no-]ext-dce not
   ||documented
   Last reconfirmed||2025-05-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. They are not documented in invoke.texi.

The pass is not documented either in passes.texi (though most passes are not
described there).

Re: [Ada] incorrectly specified array of record aggregates in protected object causes bug box in GNAT 12.2.0

[Eric Botcazou]

> Sorry again if I included the wrong information, or formatted the email
> wrong or anything like that. It's my first time using a gnu mailing list.

Instructions are at: https://gcc.gnu.org/bugs/, see "Where to post it".

-- 
Eric Botcazou

[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails

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

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

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

https://gcc.gnu.org/g:4704b94fc76b51e79e6fcf63344f70da4d89d75c

commit r16-361-g4704b94fc76b51e79e6fcf63344f70da4d89d75c
Author: Jakub Jelinek 
Date:   Fri May 2 19:09:34 2025 +0200

cobol, v2: Fix up cobol cross-compilation from 32-bit arches [PR119364]

Right now it is not possible to even build cross-compilers from 32-bit
architectures to e.g. x86_64-linux or aarch64-linux, even from
little-endian
ones.

The following patch attempts to fix that.

There were various issues seen e.g. trying to build i686-linux ->
x86_64-linux cross-compiler (so still 64-bit libgcobol, but the compiler
is 32-bit).
1) warning about >> 32 shift of size_t, on 32-bit arches size_t is 32-bit
   and so the shift is UB; fixed by doing (new_size>>16)>>16 so that
   it ors in >> 32 when new_size is 64-bit and 0 when it is 32-bit
2) enum cbl_field_attr_t was using size_t as underlying type, but has
   various bitmasks which require full 64-bit type; changed this to
uint64_t
   underlying type and using unsigned long long in the structure; various
   routines which operate with those attributes had to be changed also to
   work with uint64_t instead of size_t
3) on i686-linux, config.h can #define _FILE_OFFSET_BITS 64 or similar
   macros; as documented, those macros have to be defined before including
   first C library header, but some sources included cobol-system.h which
   includes config.h only after various other headers; this resulted in
   link failures, as ino_t was sometimes unsigned long and sometines
   unsigned long long, depending on whether config.h was included first or
   not, and e.g. cobol_filename uses ino_t argument
4) lots of places used %ld or %lx *printf format specifers with size_t
   arguments; that works only if size_t is unsigned long, but not when it
   is unsigned int or unsigned long long or some other type; now while
   ISO C99 has %zd or %zx to print size_t and C++14 includes C99 (or C11?),
   while for the C++ headers the C++ compilers typically have full control
   over it and so support everything in C++14 (e.g. libstdc++ in GCC 5.1+
   or libc++ if not too old), for C library we are dependent on the system
   C library (note, on the host for the compiler side).  And not all hosts
   support C99 in their C libraries; so instead of just changing it to
   %zd or %zx, I'm changing it to what we use elsewhere in GCC,
   HOST_SIZE_T_PRINT_{DEC,UNSIGNED,HEX_PURE} or GCC_PRISZ macros in the
   *printf family format string and casts of the size_t arguments to
   fmt_size_t.  Note, if not using the C library *printf family (e.g. in
   dbgmsg, sprintf, snprintf, fprintf, etc.) but the GCC diagnostic code
   (e.g. err_msg, error, warning, yywarn, ...), then %zd/%zu is supported
   and on the other side HOST_SIZE_T_PRINT_{DEC,UNSIGNED,HEX_PURE} etc.
   macros shouldn't be used (for two reasons, because it is unnecessary
   when %zd/%zu is guaranteed to be supported there because GCC has
   control over that and more importantly because it breaks translations,
   both extraction of the to be translated strings and we don't want to
   have different messages, once with %lld, once with %ld, once with just
%d
   or %I64d depending on host, translators couldn't translate it all).
5) see above, there were already tons of %zd/%zu or %3zu etc. format
   specifers in *printf format strings, this patch changes those too
6) I've noticed dbgmsg wasn't declared with printf attribute, which
resulted
   in bugs where format specifiers didn't match actually passed types of
   arguments

2025-05-02  Jakub Jelinek  

PR cobol/119364
libgcobol/
* valconv.cc (__gg__realloc_if_necessary): Use (new_size>>16)>>16;
instead of new_size>>32; to avoid warnings on 32-bit hosts.
* common-defs.h (enum cbl_field_attr_t): Use uint64_t
as underlying type rather than size_t.
* gcobolio.h (cblc_field_t): Change attr member type from size_t
to unsigned long long.
gcc/cobol/
* util.cc (is_numeric_edited): Use HOST_SIZE_T_PRINT_UNSIGNED
instead of "%zu" and cast corresponding argument to fmt_size_t.
(normalize_picture): Use GCC_PRISZ instead of "z" and pass address
of fmt_size_t var to sscanf and copy afterwards.
(cbl_refer_t::str): Use HOST_SIZE_T_PRINT_UNSIGNED instead of
"%zu" or GCC_PRISZ instead of "z" and cast corresponding argument
to fmt_size_t.
(struct move_corresponding_field): Likewise.
(valid_move): Likewise.
(ambiguous_reference): Likewise.
(parent_names): Likewise.

[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails

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

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

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

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

commit r16-362-gc77d04506e6abdc45969d0ff146204be7485244a
Author: Jakub Jelinek 
Date:   Fri May 2 19:10:59 2025 +0200

cobol: Fix up exception handling [PR119364]

The following patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682500.html
fixes most of the remaining make check-cobol FAILs in the
i686-linux -> x86_64-linux cross-compiler.

Using the testing environment detailed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680403.html
with this patch I get just cobol.dg/group1/declarative_1.cob FAILs
in i686-linux -> x86_64-linux cross and no FAILs in x86_64-linux
native one.

The patch isn't needed just for cross-compilation with different
hosts, but also on x86_64-linux/aarch64-linux native, because without
it the FE is hashing padding bits which contain random garbage and making
code generation decisions based on that.  That is very much against the
reproduceability requirements.

2025-05-02  Jakub Jelinek  

PR cobol/119364
* structs.h (cbl_enabled_exception_type_node): New variable
declaration.
* structs.cc (cbl_enabled_exception_type_node): New variable.
(create_cbl_enabled_exception_t): New function.
(create_our_type_nodes): Initialize cbl_enabled_exception_type_node
using it.
* genapi.cc (stash_exceptions): Don't compare padding bits to
determine if the exceptions are the same as last time.  Use
cbl_enabled_exception_type_node for target size and field offsets
and native_encode_expr to write each field into byte sequence.

[Bug rtl-optimization/120059] [16 regression] ICE when building mesa in vartrack since r16-286

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Pengfei Li from comment #9)
> Thanks Andrew for the quick fix. I've bootstrapped and regression tested the
> fix on x86_64 and AArch64.
> 
> Apologies for introducing the issue (I'm new to GCC), and really appreciate
> Andrew's help.

No problem. I have been working through another subreg issue recently dealing
with my patch to simplify-rtx.cc so it was not big context switch for me to
find and fix this issue also.

[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Macleod  ---
Created attachment 61274
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61274&action=edit
potential patch

(In reply to Andrew Macleod from comment #8)

> 
> Another option is to add a type to UNDEFINED, which I have looked at before.
> That has its own issues, but I will take another look in a bit.

I have prototyped this, and can confirm that adding a type to UNDEFINED does
resolve the problem.   

That seems like overkill for back porting however.  it looks like there are
only 2 places where this is a real risk.. And since it can only happen when
code is going to be unreachable, we could simply turn the UNDEFINED into a
VARYING value...  like this patch.

The testcase still reduces down to return 0.

I'm running it through testing now.  This would be suitable fix for gcc 14/15. 
For trunk I could apply this and the revert it if I do either of the other
options..  (ie add a type to UNDEFINED or always keep the mask up to date)

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression between g:1c0cbc1b300e08df5ebfce00a7195890d78f2064 and g:55b01e17c793688a2878fa43a76df126

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> It also happens on aarch64:
> PGO+LTO:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=792.507.0
> PGO:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=797.507.0

Though this is 10 days before the x86 one.

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression between g:1c0cbc1b300e08df5ebfce00a7195890d78f2064 and g:55b01e17c793688a2878fa43a76df126

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization
Summary|Yes another imagick |[16 Regression] Yes another
   |-march=native -flto -Ofast  |imagick -march=native -flto
   |+ PGO regression between|-Ofast + PGO regression
   |g:1c0cbc1b300e08df5ebfce00a |between
   |7195890d78f2064 and |g:1c0cbc1b300e08df5ebfce00a
   |g:55b01e17c793688a2878fa43a |7195890d78f2064 and
   |76df1266153b438 |g:55b01e17c793688a2878fa43a
   ||76df1266153b438
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |16.0
   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
It also happens on aarch64:
PGO+LTO:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=792.507.0
PGO:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=797.507.0

[Bug target/110273] [12/13/14/15/16 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment

[zfigura at codeweavers dot com via Gcc-bugs]

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

Zeb Figura  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Zeb Figura  ---
(In reply to LIU Hao from comment #17)
> Would you please check whether this is fixed after
> https://gcc.gnu.org/g:dea7b9a78b11b5ca0c85b971521144ba07a66aca ?

Yes, I think we can call this fixed. Thanks!

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #6 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #4)
> Vincent was able to reduce this further. Two files, gtk_sup.f90 and test.f90.
> 
> $ cat gtk_sup.f90 
> module gtk_sup
>   use, intrinsic :: iso_c_binding
> end module gtk_sup

...

> Anyone have any thoughts?

The iso_c_binding module is created on-the-fly.  Trying to write
it out to a user's module seems to be rather dubious.

If iso_c_binding is available, c_ptr_2 has

(gdb) p *c_ptr_2->value.function->isym
$1 = {name = 0x8048197d8 "c_loc", lib_name = 0x804833150 "_gfortran_c_loc", 
  formal = 0x804189140, ts = {type = BT_DERIVED, kind = 0, u = {
  derived = 0x804042900, cl = 0x804042900, pad = 67381504}, 
interface = 0x0, is_c_interop = 1, is_iso_c = 0, f90_type = BT_VOID, 
deferred = false, interop_kind = 0x0}, elemental = 0, inquiry = 1, 
  transformational = 0, pure = 1, generic = 0, specific = 0, actual_ok = 0,

If one looks at the -fdump-tree-original, one sees that c_loc and 
c_associated are in-lined

{
  void * D.4657;
  logical(kind=4) D.4658;

  D.4657 = (void *) &val;
  D.4658 = val != 0B && val == D.4657;
  _gfortran_transfer_logical_write (&dt_parm.0, &D.4658, 4);
}

and in fact the type is 'void *'.

Now, if one tries to get c_loc's info from the gtk_sup module, you end up with

(gdb) p *c_ptr_2->value.function->isym
$1 = {name = 0x8048197d8 "c_loc", lib_name = 0x804833150 "_gfortran_c_loc", 
  formal = 0x804189140, ts = {type = BT_VOID, kind = 0, u = {derived = 0x0, 
  cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0, 
f90_type = BT_UNKNOWN, deferred = false, interop_kind = 0x0}, 
  elemental = 0, inquiry = 1, transformational = 0, pure = 1, generic = 0, 
  specific = 0, actual_ok = 0, noreturn = 0, conversion = 0, from_module = 1, 
  vararg = 0, standard = 16, simplify = {f0 = 0x0, f1 = 0x0, f2 = 0x0, 

If one short-circuits the check with 

  if (c_ptr_2->ts.type == BT_VOID)
 return true;

then everthing compiles and runs.

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

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

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

--- Comment #7 from Jerry DeLisle  ---
That is exactly the patch I was testing Steve.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[zfigura at codeweavers dot com via Gcc-bugs]

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

--- Comment #43 from Zeb Figura  ---
Right, sorry, I should clarify—I can see what the *actual* effect of
-mstackrealign / __force_align_arg_pointer__ is. I'm confused at what its
*intended* effect is. "Align to 16 bytes, but only if we need 16-byte
alignment, and do nothing if we need 8-byte alignment" seems very odd and not
intended.

If we have PREFERRED_STACK_BOUNDARY_DEFAULT set to 32 does -mstackrealign
actually ever do anything? IIUC it didn't do anything previously unless there
was something on *this* function's stack that needed alignment.
-mpreferred-stack-boundary seems to just be a stronger version of the same
flag.

[Bug target/110273] [12/13/14/15/16 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment

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

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

Sam James  changed:

   What|Removed |Added

  Known to work||16.0
   Target Milestone|12.5|16.0

[Bug c++/117827] [12 regression] Incorrect destructor calls after array-new-expression since r12-6328-gbeaee0a871b648

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

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

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

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

commit r16-343-gc6efdffa7d5c68a14aa5de3a426a44ee05aaa1b9
Author: Jakub Jelinek 
Date:   Fri May 2 09:16:27 2025 +0200

++: Small build_vec_init improvement [PR117827]

As discussed in the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674492.html
thread, the following patch attempts to improve build_vec_init generated
code.  E.g. on g++.dg/eh/aggregate1.C test the patch has differences like:
 D.2988 = &D.2950->e1;
 D.2989 = D.2988;
 D.2990 = 1;
 try
   {
 goto ;
 :
 A::A (D.2989);
 D.2990 = D.2990 + -1;
 D.2989 = D.2989 + 1;
 :
 if (D.2990 >= 0) goto ; else goto
;
 :
 retval.4 = D.2988;
 _13 = &D.2950->e2;
 A::A (_13);
-D.2990 = 1;
+D.2988 = 0B;
 D.2951 = D.2951 + -1;
   }
 catch
   {
 {
   struct A * D.2991;

   if (D.2988 != 0B) goto ; else goto
;
   :
   _11 = 1 - D.2990;
   _12 = (sizetype) _11;
   D.2991 = D.2988 + _12;
   :
   if (D.2991 == D.2988) goto ; else
goto ;
   :
   D.2991 = D.2991 + 18446744073709551615;
   A::~A (D.2991);
   goto ;
   :
   goto ;
   :
   :
 }
   }
in 3 spots.  As you can see, both setting D.2990 (i.e. iterator) to
maxindex and setting D.2988 (i.e. rval) to nullptr have the same effect of
not actually destructing anything anymore in the cleanup, the
advantage of clearing rval is that setting something to zero is often less
expensive than potentially huge maxindex and that the cleanup tests that
value first.

2025-05-02  Jakub Jelinek  

PR c++/117827
* init.cc (build_vec_init): Push to *cleanup_flags clearing of rval
instead of setting of iterator to maxindex.

[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #6 from Florian Weimer  ---
Fixed in trunk.

[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent

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

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

Bug 120055 Summary: [16 Regression] ice in convert_arguments with recent 
compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055

   What|Removed |Added

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

[Bug tree-optimization/120035] Loops are not optimized when "unsigned i" is used

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Ah, so this is because the loop in question looks to us like

 do
   {
  ++i;
  if (i == 1ul << 60)
break;
  ++i;
   }
 while (i < 1ul << 60);

and we are confused about this case since we also do not know the
initial value (which is set from the loop including the call).

Analyzing # of iterations of loop 2
  exit condition [i_18 + 2, + , 2] != 1152921504606846976
  bounds on difference of bases: -1 ... 1152921504606846974
  result:
under assumptions (i_18 & 1) == 0
# of iterations (1152921504606846974 - i_18) /[ex] 2, bounded by
9223372036854775807
Analyzing # of iterations of loop 2 
  exit condition [i_18 + 1, + , 2] != 1152921504606846976
  bounds on difference of bases: 0 ... 1152921504606846975
  result:
under assumptions (1152921504606846975 - i_18 & 1) == 0
# of iterations (1152921504606846975 - i_18) /[ex] 2, bounded by
9223372036854775807
cannot prove finiteness of loop 2

so we fail to "combine" the two exits assumptions when computing the upper
bound of iterations for the loop.  Also a side-effect of handling
< as != - this also shows that when threadfull2 creates the second loop
in the first place we fail to do so "conciously" and forget to copy over
the flag that says that second loop is finite as well.

The issue is that thread2 unrolls part of the loop body but that also seems
like an enabler to split it out ...

Isolated testcase for the niter issue:

void f(unsigned i)
{
  do
{
  ++i;
  if (i == 1u << 28)
break;
  ++i;
}
  while (i != 1u <<28);
}

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

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

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

--- Comment #27 from GCC Commits  ---
The master branch has been updated by Filip Kastl :

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

commit r16-348-gc14560907a9586ad405f26ab937881eb08f39497
Author: Filip Kastl 
Date:   Thu May 1 15:32:07 2025 +0200

gimple: Don't warn about using different algs for big switch lowering
[PR117091]

We currently don't switch to a faster switch lowering algorithm when a
switch is too big.  This patch removes a warning about this.

PR middle-end/117091

gcc/ChangeLog:

* tree-switch-conversion.cc
(switch_decision_tree::analyze_switch_statement):
Remove warning about using different algorithms.

Signed-off-by: Filip Kastl 

[Bug middle-end/117091] switch clustering takes extensive time with large switches even at -O0

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

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

--- Comment #26 from GCC Commits  ---
The master branch has been updated by Filip Kastl :

https://gcc.gnu.org/g:5274db0c9b8c0e2d2879b237eb2ab576543b6c37

commit r16-346-g5274db0c9b8c0e2d2879b237eb2ab576543b6c37
Author: Filip Kastl 
Date:   Thu May 1 15:30:52 2025 +0200

gimple: Merge slow and fast bit-test switch lowering [PR117091]

PR117091 showed that bit-test switch lowering can take a lot of time.
The algorithm was O(n^2).  We therefore came up with a faster algorithm
(O(n * BITS_IN_WORD)) and made GCC choose between the slow and the fast
algorithm based on how big the switch is.

Here I combine the algorithms so that we get the results of the slower
algorithm in the faster asymptotic time.

PR middle-end/117091

gcc/ChangeLog:

* tree-switch-conversion.cc
(bit_test_cluster::find_bit_tests_fast):
Remove function.
(bit_test_cluster::find_bit_tests_slow): Remove function.
(bit_test_cluster::find_bit_tests): We don't need to decide
between slow and fast so just put the modified (no longer) slow
algorithm here.

Signed-off-by: Filip Kastl 

[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I guess the mask/value comes from the c | 1 parameter passed to f from main.
  # RANGE [irange] int [-INF, -1][1, +INF] MASK 0xfffe VALUE 0x1
  _2 = c.0_1 | 1;
But f is
void f (int e)
{
  int e_3(D) = e;
  short int _1;
  int _5;
  int _6;

   [local count: 1073741824]:
  if (e_3(D) == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  _1 = (short int) e_3(D);
  if (_1 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 268435456]:
  # USE = nonlocal escaped
  _6 = d.part.0 (_1);
and so shouldn't call d.part.0 at all if e_3 is not zero.  Perhaps ipa-vrp just
sees that something based on e_3(D) is passed to d.part.0 and doesn't actually
do the path specific checks?  Given the # RANGE [irange] int [-INF, -1][1,
+INF] MASK 0xfffe VALUE 0x1 and # RANGE [irange] short [0, 0] at the same
time the d.part.0 call from f is impossible and so UNDEFINED range is
reasonable.

[Bug rtl-optimization/120059] [16 regression] ICE when building mesa in vartrack since r16-286

[Pengfei.Li2 at arm dot com via Gcc-bugs]

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

--- Comment #9 from Pengfei Li  ---
Thanks Andrew for the quick fix. I've bootstrapped and regression tested the
fix on x86_64 and AArch64.

Apologies for introducing the issue (I'm new to GCC), and really appreciate
Andrew's help.

[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Florian Weimer :

https://gcc.gnu.org/g:02fa088f5b61fb5ddfff9e2dc0c0404450e7c6a4

commit r16-345-g02fa088f5b61fb5ddfff9e2dc0c0404450e7c6a4
Author: Florian Weimer 
Date:   Fri May 2 11:39:29 2025 +0200

c: Fix crash in c-typeck.cc convert_arguments with indirect calls

gcc/c/

PR c/120055
* c-typeck.cc (convert_arguments): Check if fundecl is null
before checking for builtin function declaration.

gcc/testsuite/

* gcc.dg/Wdeprecated-non-prototype-6.c: New test.

[Bug c/120057] [15/16 regression] 'constexpr' integer initializer is not an integer constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 61271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61271&action=edit
gcc16-pr120057.patch

Untested fix.

[Bug c++/120012] [12/13/14/15/16 Regression] P1008R1 causes tail padding reuse in C++20 mode

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r16-355-ge6e3b0772ed40cc65a544bbe744ece62d8b9713e
Author: Jason Merrill 
Date:   Wed Apr 30 10:18:46 2025 -0400

c++: C++17/20 class layout divergence [PR120012]

C++20 made a class with only explicitly defaulted constructors no longer
aggregate, and this wrongly affected whether the class is considered "POD
for layout purposes" under the ABI.

Conveniently, we already have check_non_pod_aggregate to diagnose cases
where this makes a difference, due to PR103681 around a C++14 aggregate
change.

PR c++/120012

gcc/cp/ChangeLog:

* cp-tree.h (struct lang_type): Add non_aggregate_pod.
(CLASSTYPE_NON_AGGREGATE_POD): New.
* class.cc (check_bases_and_members): Set it.
(check_non_pod_aggregate): Diagnose it.

gcc/ChangeLog:

* doc/invoke.texi: Document C++20 aggregate fix.
* common.opt: Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/abi/base-defaulted1.C: New test.
* g++.dg/abi/base-defaulted1a.C: New test.

[Bug c++/60336] empty struct value is passed differently in C and C++

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

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

--- Comment #55 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4af5de21363cfdd2be227c05dfdee7e053337f6a

commit r16-354-g4af5de21363cfdd2be227c05dfdee7e053337f6a
Author: Jason Merrill 
Date:   Thu May 1 11:40:17 2025 -0400

i386: -Wabi false positive with indirect call [PR60336]

This warning relies on the TRANSLATION_UNIT_WARN_EMPTY_P flag (set in
cxx_init_decl_processing) to decide whether we want to warn about the GCC 8
empty class parameter passing fix, but in a call through a function pointer
we don't have a translation unit and so complain for any -Wabi flag, even
now long after this was likely to be relevant.

In that situation, let's check the TU for current_function_decl instead.
And if we still can't come up with a TU, default to not warning.

PR c++/60336

gcc/ChangeLog:

* config/i386/i386.cc (ix86_warn_parameter_passing_abi):
If no target, check the current TU.

gcc/testsuite/ChangeLog:

* g++.dg/abi/pr60336-8a.C: New test.

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression between g:1c0cbc1b300e08df5ebfce00a7195890d78f2064 and g:55b01e17c793688a2878fa43a76df126

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jan Hubicka from comment #3)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120069
> > 
> > --- Comment #2 from Andrew Pinski  ---
> > (In reply to Andrew Pinski from comment #1)
> > > It also happens on aarch64:
> > > PGO+LTO:
> > > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=792.507.0
> > > PGO:
> > > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=797.507.0
> > 
> > Though this is 10 days before the x86 one.
> 
> Helene is Intel CPU.  This is PR119900 which is hopefully fixed now.
> Lets see if fixing that also solves this regression.

I think I copied the wrong URLS :).


https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=589.507.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=583.507.0

[Bug c++/21113] Jumps into VLA or VM scope not rejected for C++

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c/120078] [12/13/14/15/16 Regression] -Wjump-misses-init should be enabled by -Wc++-compat

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
Summary|-Wjump-misses-init should   |[12/13/14/15/16 Regression]
   |be enabled by -Wc++-compat  |-Wjump-misses-init should
   ||be enabled by -Wc++-compat

--- Comment #2 from Andrew Pinski  ---
I am thinking r0-116778-gf2bc201f53e2b8 .

[Bug middle-end/120078] [12/13/14/15/16 Regression] -Wjump-misses-init should be enabled by -Wc++-compat

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #3 from Andrew Pinski  ---
case OPT_Wc___compat:
  if (!opts_set->x_warn_enum_compare)
handle_generated_option (opts, opts_set,
 OPT_Wenum_compare, NULL, value,
 lang_mask, kind, loc, handlers, true, dc);
  if (!opts_set->x_warn_enum_int_mismatch)
handle_generated_option (opts, opts_set,
 OPT_Wenum_int_mismatch, NULL, value,
 lang_mask, kind, loc, handlers, true, dc);
  break;


Are handled correctly but not Wjump-misses-init.


Wenum-compare from c-family/c.opt:
```
Wenum-compare
C ObjC C++ ObjC++ Var(warn_enum_compare) Init(-1) Warning LangEnabledBy(C
ObjC,Wall || Wc++-compat)
Warn about comparison of different enum types.
```

[Bug preprocessor/120079] New: RFE: -Wp,-dM equivalent for assertions

[hpa at zytor dot com via Gcc-bugs]

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

Bug ID: 120079
   Summary: RFE: -Wp,-dM equivalent for assertions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

Currently, -Wp,-dM can be used to get all the predefined macros in the
preprocessor, but there is no equivalent to get the C preprocessor assertions,
something like -Wp-dMA which would produce both #define and #assert statements
would allow knowing the full environment for the preprocessor.

[Bug preprocessor/120079] RFE: -Wp,-dM equivalent for assertions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
Assertions are deprecated and documented as such (and has been deprecated since
at least GCC 3.1)

https://gcc.gnu.org/onlinedocs/cpp/Obsolete-Features.html#index-assertions


https://gcc.gnu.org/onlinedocs/gcc-3.1/cpp/Assertions.html

[Bug middle-end/120072] New attribute alloc_variant_zeroed which can be used for alloc+memset->calloc optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/120073] New: __arm_sc_* functions are not included

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

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

Bug ID: 120073
   Summary: __arm_sc_* functions are not included
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: aarch64-sme
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

https://arm-software.github.io/acle/main/acle.html

 Streaming-compatible versions of standard routines ^
ACLE provides the following streaming-compatible functions, with the same
behavior as the standard C functions that they are named after. All of the
functions have external linkage.

  void *__arm_sc_memcpy(void *dest, const void *src, size_t n)
__arm_streaming_compatible;

  void *__arm_sc_memmove(void *dest, const void *src, size_t n)
__arm_streaming_compatible;

  void *__arm_sc_memset(void *s, int c, size_t n)
__arm_streaming_compatible;

  void *__arm_sc_memchr(void *s, int c, size_t n)
__arm_streaming_compatible;

[Bug target/120073] __arm_sc_* functions are not included

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/120074] New: ICE on valid code at -O1 with "-fno-tree-copy-prop -fno-tree-forwprop -fno-tree-ccp" on x86_64-linux-gnu: in decompose, at wide-int.h:1049

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 120074
   Summary: ICE on valid code at -O1 with "-fno-tree-copy-prop
-fno-tree-forwprop -fno-tree-ccp" on x86_64-linux-gnu:
in decompose, at wide-int.h:1049
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/1MeYKeG1Y

It appears to be a recent regression as it only affects 15.1 and later.

[638] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250502 (experimental) (GCC)
[639] %
[639] % gcctk -O1 small.c; ./a.out
0
[640] % gcctk -O1 -fno-tree-copy-prop -fno-tree-forwprop -fno-tree-ccp small.c
during GIMPLE pass: ifcombine
small.c: In function ‘main’:
small.c:5:5: internal compiler error: in decompose, at wide-int.h:1049
5 | int main() {
  | ^~~~
0x2701d06 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0xacb494 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1748
0x820f6e wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
../../gcc-trunk/gcc/wide-int.h:1049
0xe3adb7 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
../../gcc-trunk/gcc/wide-int.h:1272
0xe3adb7 wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
../../gcc-trunk/gcc/wide-int.h:1099
0xe3adb7 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
../../gcc-trunk/gcc/wide-int.h:855
0xe3adb7 wi::binary_traits,
generic_wide_int,
wi::int_traits >::precision_type,
wi::int_traits
>::precision_type>::result_type wi::bit_and,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
../../gcc-trunk/gcc/wide-int.h:2756
0xe3adb7 generic_wide_int&
generic_wide_int::operator&=
>(generic_wide_int const&)
../../gcc-trunk/gcc/wide-int.h:817
0xe8208b fold_truth_andor_for_ifcombine(tree_code, tree_node*, unsigned long,
tree_code, tree_node*, tree_node*, unsigned long, tree_code, tree_node*,
tree_node*, tree_node**)
../../gcc-trunk/gcc/gimple-fold.cc:8340
0x13cc035 ifcombine_ifandif
../../gcc-trunk/gcc/tree-ssa-ifcombine.cc:976
0x13cc3ac tree_ssa_ifcombine_bb_1
../../gcc-trunk/gcc/tree-ssa-ifcombine.cc:1107
0x13cc86a tree_ssa_ifcombine_bb
../../gcc-trunk/gcc/tree-ssa-ifcombine.cc:1207
0x13cc86a execute
../../gcc-trunk/gcc/tree-ssa-ifcombine.cc:1400
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[641] %
[641] % cat small.c
int printf(const char *, ...);
short a;
int b;
int c(int d, int e) { return d < 0 || d > 2147483647 >> e; }
int main() {
  int f = c((b ^ a) & 3, 30);
  printf("%d\n", f);
  return 0;
}

[Bug c++/120076] New: statement expression allows bypassing own initializer

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

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

Bug ID: 120076
   Summary: statement expression allows bypassing own initializer
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, stmt-expr
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Examples:
```
void f(void) {
 for (int i=({ goto ouch; int x = 10; x;});i<0;++i)
ouch:
  ;
}
void g(void) {
  int i1 = ({ 
goto ouch;  
12;
  });
ouch:
  ;
}
```

GCC does have code to check for bypassing initializations when jumping out of a
statement expression, just it does not catch if the statement expression is
being used to initialize a variable.

[Bug target/120077] New: Switch lm32 to LRA

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

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

Bug ID: 120077
   Summary: Switch lm32 to LRA
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
Blocks: 113932
  Target Milestone: ---
Target: lm32

Apparently I didn't file a bug for this one, even though I mentioned it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932#c0.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
[Bug 113932] [meta-bug] Targets which should be ported to LRA

[Bug target/120077] Switch lm32 to LRA

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

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

Sam James  changed:

   What|Removed |Added

 CC||lekernel at gcc dot gnu.org

--- Comment #1 from Sam James  ---
People are getting eager to require LRA. Please port the mcore target to LRA
(see PR113932).

[Bug target/120077] Switch lm32 to LRA

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug rtl-optimization/120059] [16 regression] ICE when building mesa in vartrack since r16-286

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed.

[Bug rtl-optimization/120059] [16 regression] ICE when building mesa in vartrack since r16-286

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

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

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

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

commit r16-365-gdba5d112691a3e10b722468d94fffeda0fdbb818
Author: Andrew Pinski 
Date:   Fri May 2 09:46:24 2025 -0700

simplify-rtl: Fix crash due to simplify_with_subreg_not [PR120059]

r16-286-gd84fbc516ea57d added a call to simplify_gen_subreg but didn't
check if the result of simplify_gen_subreg was non-null.
simplify_gen_subreg
can return NULL if the subreg would be not valid. In the case below we had
a hard register for the SSE register xmm0 of mode SI and doing a subreg to
QI mode but QImode is not a valid mode for the SSE register so
simplify_gen_subreg
would return NULL.

This adds the obvious check.

Pushed as obvious after bootstrap/test on x86_64-linux-gnu.

PR rtl-optimization/120059

gcc/ChangeLog:

* simplify-rtx.cc (simplify_with_subreg_not): Check the result
of simplify_gen_subreg.

gcc/testsuite/ChangeLog:

* gcc.dg/torture/pr120059-1.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/120069] [16 Regression] Yes another imagick -march=native -flto -Ofast + PGO regression between g:1c0cbc1b300e08df5ebfce00a7195890d78f2064 and g:55b01e17c793688a2878fa43a76df126

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #3 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120069
> 
> --- Comment #2 from Andrew Pinski  ---
> (In reply to Andrew Pinski from comment #1)
> > It also happens on aarch64:
> > PGO+LTO:
> > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=792.507.0
> > PGO:
> > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=797.507.0
> 
> Though this is 10 days before the x86 one.

Helene is Intel CPU.  This is PR119900 which is hopefully fixed now.
Lets see if fixing that also solves this regression.

[Bug tree-optimization/120074] [15/16 regression] ICE on valid code at -O1 with "-fno-tree-copy-prop -fno-tree-forwprop -fno-tree-ccp" on x86_64-linux-gnu: in decompose, at wide-int.h:1049

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

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

Sam James  changed:

   What|Removed |Added

Summary|ICE on valid code at -O1|[15/16 regression] ICE on
   |with "-fno-tree-copy-prop   |valid code at -O1 with
   |-fno-tree-forwprop  |"-fno-tree-copy-prop
   |-fno-tree-ccp" on   |-fno-tree-forwprop
   |x86_64-linux-gnu: in|-fno-tree-ccp" on
   |decompose, at   |x86_64-linux-gnu: in
   |wide-int.h:1049 |decompose, at
   ||wide-int.h:1049
   Keywords||ice-on-valid-code,
   ||needs-bisection
   Target Milestone|--- |15.2

[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0

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

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

Sam James  changed:

   What|Removed |Added

Summary|codeview ICE/segfault   |[15/16 regression] codeview
   |starting with 15.1.0|ICE/segfault starting with
   ||15.1.0
   Target Milestone|--- |15.2

[Bug rtl-optimization/120064] [15/16 Regression] -f[no-]ext-dce not documented

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.2

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #8 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #7)
> That is exactly the patch I was testing Steve.

I assume that you've found that you'll need to
deal with both c_ptr_1 and c_ptr_2.  With the
short-circuit for c_ptr_2 in place, this

program tests_gtk_sup
   use gtk_sup
   implicit none
   type(c_ptr), target :: val
   print *, c_associated(val, c_loc(val))
   print *, c_associated(c_loc(val), val)
end program tests_gtk_sup

fails with

% gfcx -o y g.f90 -fdump-tree-original && ./y
g.f90:10:25:
   10 |print *, c_associated(c_loc(val), val)
  | 1
Error: Argument C_PTR_1 at (1) to C_ASSOCIATED shall have the type TYPE(C_PTR)
or TYPE(C_FUNPTR)

IIRC, a subroutine has BT_VOID.  We should expand the 
conditional to also check that we have a function.

  if (c_ptr_2.expr_type == EXPR_FUNCTION && c_ptr_2->ts.type == BT_VOID)
 return true;

We could be extra careful, and look at

(gdb) p c_ptr_2->value.function->isym.id
$8 = GFC_ISYM_C_LOC

BTW, a similar issue may exist for c_funloc, which returns a c_funptr.
I haven't checked it, yet.

[Bug target/120070] [15/16 regression] m68k-linux-gnu-gcc -Os ICE segfault compiling xfs_trans_ail.c

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

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

Sam James  changed:

   What|Removed |Added

Summary|m68k-linux-gnu-gcc -Os ICE  |[15/16 regression]
   |segfault compiling  |m68k-linux-gnu-gcc -Os ICE
   |xfs_trans_ail.c |segfault compiling
   ||xfs_trans_ail.c
   Target Milestone|--- |15.2

--- Comment #1 from Sam James  ---
Confirmed via godbolt.

[Bug target/120070] [15/16 regression] m68k-linux-gnu-gcc -Os ICE segfault compiling xfs_trans_ail.c

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug c/87038] diagnostics: Have -Wjump-misses-init be enabled by -Wall or -Wextra

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

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

--- Comment #25 from Andrew Pinski  ---
Note clang just added -Wjump-bypasses-init which does the exactly same as GCC's
-Wjump-misses-init (https://github.com/llvm/llvm-project/pull/138009)

[Bug c/120078] New: -Wjump-misses-init should be enabled by -Wc++-compat

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

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

Bug ID: 120078
   Summary: -Wjump-misses-init should be enabled by -Wc++-compat
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Since -Wjump-misses-init is useful to see if your C code is compatible with
C++, -Wc++-compat should enabled it also.


Note clang does not enable their option (-Wjump-bypasses-init) by -Wc++-compat
yet either:
https://github.com/llvm/llvm-project/pull/138009#issuecomment-2842923806

[Bug c/120078] -Wjump-misses-init should be enabled by -Wc++-compat

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

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

--- Comment #1 from Andrew Pinski  ---
Actually wait it is enabled:
```
Wjump-misses-init
C ObjC Var(warn_jump_misses_init) Warning LangEnabledby(C ObjC,Wc++-compat)
Warn when a jump misses a variable initialization.

```

But I don't get a warning unless I use the option directly.

Simple example:
```
int f(int a)
{
  goto b;
  int t = a;
b:
  return t;
}
```

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

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

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

--- Comment #44 from Eric Botcazou  ---
> Right, sorry, I should clarify—I can see what the *actual* effect of
> -mstackrealign / __force_align_arg_pointer__ is. I'm confused at what its
> *intended* effect is. "Align to 16 bytes, but only if we need 16-byte
> alignment, and do nothing if we need 8-byte alignment" seems very odd and
> not intended.

Yes, it was invented to support SSE instructions that require strict 16-byte
alignment of memory references.

[Bug target/120070] New: m68k-linux-gnu-gcc -Os ICE segfault compiling xfs_trans_ail.c

[ats-gccbugs at offog dot org via Gcc-bugs]

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

Bug ID: 120070
   Summary: m68k-linux-gnu-gcc -Os ICE segfault compiling
xfs_trans_ail.c
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ats-gccbugs at offog dot org
  Target Milestone: ---

Created attachment 61275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61275&action=edit
Minimised example

The attached example was minimised using cvise from Linux 6.14.5's
fs/xfs/xfs_trans_ail.c. It causes a segfault when being compiled for
m68k-linux-gnu with -Os, both using a cross-compiler from x86-64 and natively
on m68k.

$ m68k-linux-gnu-gcc -v -Os -c in3.c
Using built-in specs.
COLLECT_GCC=m68k-linux-gnu-gcc
Target: m68k-linux-gnu
Configured with: /src/devel/gcc-m68k/work/gcc-15.1.0/configure --prefix=/gar
--sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/com
--target=m68k-linux-gnu --with-sysroot=/cross/linux-m68k --disable-libssp
--disable-libcc1 --disable-multilib --with-system-zlib
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-Os' '-c' '-mcpu=68020'
 /gar/packages/gcc-m68k-15.1.0/bin/../libexec/gcc/m68k-linux-gnu/15.1.0/cc1
-quiet -v -iprefix
/gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/m68k-linux-gnu/15.1.0/ in3.c
-quiet -dumpbase in3.c -dumpbase-ext .c -mcpu=68020 -Os -version -o
/tmp/ccYE2g4p.s
GNU C23 (GCC) version 15.1.0 (m68k-linux-gnu)
compiled by GNU C version 15.1.0, GMP version 6.3.0, MPFR version
4.2.2, MPC version 1.3.1, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"/gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/../../lib/gcc/m68k-linux-gnu/15.1.0/include"
ignoring nonexistent directory "/cross/linux-m68k/usr/local/include"
ignoring duplicate directory
"/gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/../../lib/gcc/m68k-linux-gnu/15.1.0/include-fixed"
ignoring duplicate directory
"/gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/../../lib/gcc/m68k-linux-gnu/15.1.0/../../../../m68k-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/m68k-linux-gnu/15.1.0/include

/gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/m68k-linux-gnu/15.1.0/include-fixed

/gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/m68k-linux-gnu/15.1.0/../../../../m68k-linux-gnu/include
 /cross/linux-m68k/usr/include
End of search list.
Compiler executable checksum: 934e09e57f147491320a4df4b8da0612
during RTL pass: reload
in3.c: In function ‘xfsaild’:
in3.c:32:1: internal compiler error: Segmentation fault
   32 | }
  | ^
0x7fb219ef977f ???
   
/src/sys/glibc/work/5b4c4617016d28569106549dff6f9fec73eed5ce/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7fb219ee3db4 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7fb219ee3e66 __libc_start_main_impl
../csu/libc-start.c:360
0xcb6010 _start
../sysdeps/x86_64/start.S:115
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.

The backtrace there doesn't look very helpful, so here's one from gdb:

$ gdb --args
/gar/packages/gcc-m68k-15.1.0/bin/../libexec/gcc/m68k-linux-gnu/15.1.0/cc1
-quiet -v -iprefix
/gar/packages/gcc-m68k-15.1.0/bin/../lib/gcc/m68k-linux-gnu/15.1.0/ in3.c
-quiet -dumpbase in3.c -dumpbase-ext .c -mcpu=68020 -Os -version -o
/tmp/ccjA6b45.s
GNU gdb (GDB) 16.3
(gdb) run
[... same output as above ...]
Compiler executable checksum: 934e09e57f147491320a4df4b8da0612

Program received signal SIGSEGV, Segmentation fault.
0x00f5ff7d in df_install_refs(basic_block_def*, vec const*, df_reg_info**, df_ref_info*, bool) ()
(gdb) where
#0  0x00f5ff7d in df_install_refs(basic_block_def*, vec const*, df_reg_info**, df_ref_info*, bool) ()
#1  0x00f6014f in df_refs_add_to_chains(df_collection_rec*,
basic_block_def*, rtx_insn*, unsigned int) ()
#2  0x00f62064 in df_bb_refs_record(int, bool) ()
#3  0x00f5bb21 in df_scan_blocks() ()
#4  0x01284179 in do_reload() ()
#5  0x01284447 in (anonymous
namespace)::pass_reload::execute(function*) ()
#6  0x013e4563 in execute_one_pass(opt_pass*) ()
#7  0x013e492e in execute_pass_list_1(opt_pass*) ()
#8  0x013e495f in execute_pass_list_1(opt_pass*) ()
#9  0x013e49b8 in execute_pass_list(function*, opt_pass*) ()
#10 0x00f2cebe in cgraph_node::expand() ()
#11 0x00f2d51d in expand_all_functions() ()
#12 0x00f2dfb4 in symbol_table::compile() ()
#13 0x00f2e400 in symbol_table::

[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception

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

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

--- Comment #16 from John David Anglin  ---
More errors:

RUN c85006e

,.,. C85006E ACATS 2.6 31-02-25 19:41:02
 C85006E CHECK THAT A COMPONENT OR SLICE OF A VARIABLE CREATED BY AN
ALLOCATOR CAN BE RENAMED AND HAS THE CORRECT VALUE, AND
THAT THE NEW NAME CAN BE USED IN AN ASSIGNMENT STATEMENT
AND PASSED ON AS AN ACTUAL SUBPROGRAM OR ENTRY 'IN OUT'
OR 'OUT' PARAMETER, AND AS AN ACTUAL GENERIC 'IN OUT'
PARAMETER, AND THAT WHEN THE VALUE OF THE RENAMED
VARIABLE IS CHANGED, THE NEW VALUE IS REFLECTED BY THE
VALUE OF THE NEW NAME.

raised STORAGE_ERROR : s-intman.adb:136 explicit raise
FAIL:   c85006e

RUN c85005e

,.,. C85005E ACATS 2.6 31-02-13 14:29:55
 C85005E CHECK THAT A VARIABLE CREATED BY AN ALLOCATOR CAN BE
RENAMED AND HAS THE CORRECT VALUE, AND THAT THE NEW NAME
CAN BE USED IN AN ASSIGNMENT STATEMENT AND PASSED ON AS
AN ACTUAL SUBPROGRAM OR ENTRY 'IN OUT' OR 'OUT'
PARAMETER, AND AS AN ACTUAL GENERIC 'IN OUT' PARAMETER,
AND THAT WHEN THE VALUE OF THE RENAMED VARIABLE IS
CHANGED, THE NEW VALUE IS REFLECTED BY THE VALUE OF THE
NEW NAME.
Program timed out.
FAIL:   c85005e

[Bug debug/120051] codeview ICE/segfault starting with 15.1.0

[bc-info at styx dot cabel.net via Gcc-bugs]

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

Iouri Kharon  changed:

   What|Removed |Added

 CC||bc-info at styx dot cabel.net

--- Comment #1 from Iouri Kharon  ---
Created attachment 61272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61272&action=edit
A small patch for temporary(?) fix for this (and several similar) problems.

Most likely some of the fixes should be done the different way (let the author
of the code decide), but it removes the detected crashes (both on your
test and on several more complex ones).

info: remove GPF's in cc1 when build patch-2.8 and libiconv-1.18.

[Bug target/118100] [14/15/16 Regression] Segment Fault by rvv intrinsic compilation at `-O2` and `-O3`.

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #1 from mcccs at gmx dot com ---
Does "spike pk a.out" work for you?

[Bug target/119966] [16 regression] pru: Invalid register in RTL expression starting with r16-160-ge6f89d78c1a752

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

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

--- Comment #7 from Dimitar Dimitrov  ---
Thank you Andrew and Richard for the detailed analysis.

I tried the following change. It gave a few ICE regressions for x86_64, which I
have not yet investigated.  The patch fixed most but not all ICE regressions
for PRU.

diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc
index 3e2c4309dee..47effdbe17b 100644
--- a/gcc/emit-rtl.cc
+++ b/gcc/emit-rtl.cc
@@ -971,4 +971,4 @@ validate_subreg (machine_mode omode, machine_mode imode,
   /* Paradoxical subregs must have offset zero.  */
-  if (maybe_gt (osize, isize))
-return known_eq (offset, 0U);
+  if (maybe_gt (osize, isize) && !known_eq (offset, 0U))
+return false;

@@ -988,3 +988,4 @@ validate_subreg (machine_mode omode, machine_mode imode,

-  return subreg_offset_representable_p (regno, imode, offset, omode);
+  return simplify_subreg_regno (regno, imode, offset, omode) >= 0;
 }



I'll continue with analysis of validate_subreg and its callers, so that I can
understand its intended semantics.  But since it's taking time and PRU build is
still broken, I'll try to temporarily workaround the issue for PRU using
TARGET_LEGITIMATE_COMBINED_INSN.

[Bug tree-optimization/120065] [14/15/16 Regression] profile info corrupted by dom2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce on x86_64.