[Bug tree-optimization/119733] store-merging increases alignment

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

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

Krister Walfridsson  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Krister Walfridsson  ---
The struct is 64-bit aligned in the C semantics, but the GIMPLE semantics is
more permissive (see the recent discussions on the mailing list [1][2]), and
several passes create misaligned pointers. For example, ivopts decides to
calculate &u.buf[off] as:

  union 
{
  char buf[31];
  long long int align_int;
  long double align_fp;
} * _13;
  _14 = (sizetype) off_4(D);
  _13 = &u + _14;

when compiling the function

static union {
  char buf[31];
  long long align_int;
  long double align_fp;
} u;

void check (int off)
{
  char *q;
  int i;

  q = u.buf;
  for (i = 0; i < off; i++, q++)
if (*q != 'a')
  __builtin_abort ();
}

which makes _13 misaligned when off is not a multiple of 8.

So I claim the store-merging pass is not allowed to use the alignment of the
pointer to do the optimization. But it may of course be the case that it's
store-merging that is correct, and ivopts, etc. that are wrong. In that case, I
need some additional information about what the correct GIMPLE semantics is, so
I can report the real issues...

References:
 1. https://gcc.gnu.org/pipermail/gcc/2025-March/245763.html
 2. https://gcc.gnu.org/pipermail/gcc/2025-April/245870.html

[Bug c++/116416] Missing optimization: compile time evaluation of prvalue

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r15-9400-ge7bccec33beece4a46bc1b20ed375e803e97aa88
Author: Patrick Palka 
Date:   Sat Apr 12 14:06:56 2025 -0400

c++: improve constexpr prvalue folding [PR116416]

This patch improves upon r15-6052-g12de1942a0a673 by performing prvalue
folding with mce_false rather than mce_unknown when it's safe to do so
(i.e. ff_mce_false is set), so that we can also fold temporary initializers
that call is_constant_evaluated etc.

In passing I noticed constexpr-prvalue1.C could more precisely verify the
optimization happened by inspecting what the front end spits out instead
of inspecting the optimized assembly -- that there's no constructor call
doesn't necessarily imply the constructor has been completely folded away,
only that its body has been inlined.

PR c++/116416

gcc/cp/ChangeLog:

* constexpr.cc (maybe_constant_init_1): Generalize type of
of manifestly_const_eval parameter from bool to mce_value.
(maybe_constant_init): Define 3-parameter version taking a
manifestly_const_eval instead of bool parameter.
(cxx_constant_init): Adjust.
* cp-gimplify.cc (cp_fold_r) : Pass mce_false
to maybe_constant_init during prvalue folding if ff_mce_false is
set.
* cp-tree.h (maybe_constant_init): Declare new overload.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-prvalue1.C: Adjust to instead inspect
the 'original' dump.
* g++.dg/cpp1y/constexpr-prvalue1a.C: New test.

Reviewed-by: Jason Merrill 

[Bug tree-optimization/119733] store-merging increases alignment

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Andrew Pinski  ---
>From Richard B.'s email
"So ultimatively the abstract machine knows
the alignment of objects from their declaration (DECL_ALIGN) or the
allocation (malloc, etc.) and that of pointers by tracking their provenance.

So in the end alignment checking is similarly difficult as verifying actual
TBAA constraints (tracking the active dynamic type of every memory location)"

He didn't mention that strict aliasing turns off the alignment requirement and
it does not in gimple semantics. 

The output even before store merging from the SLP vectorizer also has the same
semantics here. Since we went from an alignment of 8bit to 16 bits.

[Bug tree-optimization/119471] (a * b) != 0 then we know that both a!=0 & b != 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases

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

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

Bug 119471 Summary: (a * b) != 0 then we know that both a!=0 & b != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119471

   What|Removed |Added

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

[Bug tree-optimization/110992] [13/14/15 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

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

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

Bug 119471 Summary: (a * b) != 0 then we know that both a!=0 & b != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119471

   What|Removed |Added

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

[Bug target/87832] AMD pipeline models are very costly size-wise

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-12

[Bug d/119758] d: -fonly= argument only matches when including full relative path to the input file

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

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

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

https://gcc.gnu.org/g:8a03d014ec096b3e8c9941a6bf724d3daaeeb289

commit r15-9402-g8a03d014ec096b3e8c9941a6bf724d3daaeeb289
Author: Iain Buclaw 
Date:   Sat Apr 12 09:40:24 2025 +0200

d: Fix -fonly= argument only matches when including full path [PR119758]

Using `strcmp' to match the `-fonly=' argument with the input source
file made the feature inflexible to use.  By mistake, the driver was
also found to omit all other modules on the command line as well, which
differed from the documentation on the flag:

Tell the compiler to parse and run semantic analysis on all modules
on the command line, but only generate code for the given argument.

New tests added to check the feature, which didn't exist before.

PR d/119758

gcc/d/ChangeLog:

* d-lang.cc (d_parse_file): Use endswith in test for -fonly=
argument.
* d-spec.cc (lang_specific_driver): Rework -fonly= and pass all
input
files to the front-end compiler when the option is seen.

gcc/testsuite/ChangeLog:

* gdc.dg/driver_fonly1.d: New test.
* gdc.dg/driver_fonly2.d: New test.
* gdc.dg/driver_fonly3.d: New test.
* gdc.dg/imports/fonly.d: New test.

[Bug d/109023] d: Add option to include imported modules in the compilation

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

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

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

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

commit r15-9403-g9a7b6668f8f79be8fa73982b8b0bde33c1d8c61f
Author: Iain Buclaw 
Date:   Sat Apr 12 11:13:50 2025 +0200

d: Add option to include imported modules in the compilation [PR109023]

Adds the ability to include imported modules in the compilation, as if
they were given on the command line.  When this option is enabled, all
imported modules are compiled except those that are part of libphobos.

PR d/109023

gcc/d/ChangeLog:

* d-compiler.cc: Include dmd/errors.h.
(Compiler::onImport): Implement.
* d-lang.cc (d_handle_option): Handle -finclude-imports.
(d_parse_file): Run semantic on included imports.
* gdc.texi: Document -finclude-imports.
* lang.opt: Add finclude-imports.
* lang.opt.urls: Regenerate.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/imports/pr109023.d: New test.
* gdc.dg/torture/pr109023.d: New test.

[Bug middle-end/115675] [15 Regression] truncv4hiv4qi affect r14-1402-gd8545fb2c71683's optimization.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Last reconfirmed|2025-01-24 00:00:00 |2025-4-12

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 61089 [details]
> Testcase from the testsuite

Compile with -O2 -mavx to show the issue. Note r15-1678-ge5f8a39941f6f0 added
-mno-avx to force turning off AVX for the testcase so the testsuite does not
regress.

[Bug c/96476] [Request] expose preferred vector width to preprocessor

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> We could seed it from largest integer/float vector-mode that has
> an add optab for example if the target does not override it.

Though I am curious how that would interact with Variable length vectors. Or
would that be just for fixed length vectors?

IN theory we could implement large fixed length vector sizes using variable
length ones too though currently we don't support that in a generic fashion.

[Bug target/119760] New: GCC does not implement intrinsics for Vector Multiply-by-10 Unsigned Quadword and varients

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

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

Bug ID: 119760
   Summary: GCC does not implement intrinsics for Vector
Multiply-by-10 Unsigned Quadword and varients
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: munroesj at gcc dot gnu.org
  Target Milestone: ---

POWER8 (PowerISA 2.07) introduced Binary Coded Decimal (BCD) Add/Subtract.

GCC implemented builtins (__builtin_bcdadd/sub) operating on the vector
__int128 type for these instructions. This included predicated for comparison,

6.62.26.3 PowerPC AltiVec Built-in Functions Available on ISA 2.07

POWER9 (PowerISA 3.0) more BCD instructions (shift/trucate/Convert/Zoned).
All operated on VSRs (128-bit). Happy COBOL and RPG!

POWER9 also implemented Vector Multiply-by-10 Unsigned Quadword [with
carry/extend].
Also operating on VSRs. 

As far as I can tell none of the POWER9 BCD operations where implemented in
GCC.

[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87

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

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

--- Comment #26 from Sam James  ---
(In reply to mcccs from comment #25)
> I used creduce and some de-namespacing and brought it to about 60k lines, I
> hope to post the checkpoint soon

Thank you! Even partial reductions often help a lot (though do keep going)
because it makes it way easier to spot problematic lines.

[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87

[mcccs at gmx dot com via Gcc-bugs]

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

mcccs at gmx dot com changed:

   What|Removed |Added

 CC||mcccs at gmx dot com

--- Comment #25 from mcccs at gmx dot com ---
I used creduce and some de-namespacing and brought it to about 60k lines, I
hope to post the checkpoint soon

[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #27 from mcccs at gmx dot com ---
*sorry I meant 60k bytes not lines

[Bug d/119761] New: d: importC cannot find input file '__importc_builtins.d'

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

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

Bug ID: 119761
   Summary: d: importC cannot find input file
'__importc_builtins.d'
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gcc dot gnu.org
  Target Milestone: ---

Any sources that trigger importC to import this module fail.

```cfile.c
int printf(const char *, ...);
```

```importc.d
import cfile;
```

This happens because upstream renamed the name of the module (merged in
r15-6559-g332cf038fda109) from __builtins.di to __importc_builtins.di.

[Bug cobol/119302] cobol.3 manpage is installed without program_transform_name

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

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

James K. Lowden  changed:

   What|Removed |Added

 CC||jklowden at gcc dot gnu.org

--- Comment #3 from James K. Lowden  ---
The posted patch is good but insufficient.  As you suggest, the name should be
libgcobol.3.  It documents an interface exposed by the library.  I don't know
what I was thinking.

[Bug modula2/119751] There's a need to tidy up m2 subdirectories' contents

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

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

--- Comment #10 from Gaius Mulley  ---
Created attachment 61090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61090&action=edit
Proposed fix to remove gcc/m2/gm2-libs/COROUTINES.mod

The above patch removes gcc/m2/gm2-libs/COROUTINES.mod which is unnecessary as
the
accompanying gcc/m2/gm2-libs/COROUTINES.def is a definition for "C" module.
The gcc/m2/gm2-libs/COROUTINES.def is minimal compared to its ISO counterpart.

The gcc/m2/gm2-libs/COROUTINES.def cannot be removed as it satisfies the import
requirements of gcc/m2/gm2-libs/RTint.mod for the PIM dialect.  If removed then
the ISO gcc/m2/gm2-libs-iso/COROUTINES.def will be picked up and all its
dependant modules.

Bootstrapped tested on x86_64.

The patch removes file gcc/m2/gm2-libs/COROUTINES.mod and removes the single
reference to this file in Make-lang.in

[Bug c++/119762] New: [15 Regression[modules]

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

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

Bug ID: 119762
   Summary: [15 Regression[modules]
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
  Target Milestone: ---

[Bug c++/119762] [modules] Error when loading an unused defaulted function on top of a used one

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

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

Nathaniel Shead  changed:

   What|Removed |Added

Summary|[15 Regression[modules] |[modules] Error when
   ||loading an unused defaulted
   ||function on top of a used
   ||one

--- Comment #1 from Nathaniel Shead  ---
Consider:

  // A.cpp
  module;
  struct exception_ptr {
friend bool operator==(const exception_ptr&, const exception_ptr&) =
default;
  };
  export module M;
  export using ::exception_ptr;


  // B.cpp
  struct exception_ptr {
friend bool operator==(const exception_ptr&, const exception_ptr&) =
default;
  };
  void enqueue() {
exception_ptr e;
e == e;
  }
  import M;
  int main() {
exception_ptr e;
e == e;
  }


$ g++ -fmodules -std=c++20 -S A.cpp B.cpp:
In module M, imported at /app/main.cpp:8:
A.cpp: In function 'int main()':
A.cpp:3:13: error: conflicting global module declaration 'bool operator==(const
exception_ptr&, const exception_ptr&)'
3 | friend bool operator==(const exception_ptr&, const exception_ptr&) =
default;
  | ^~~~
main.cpp:2:13: note: existing declaration 'constexpr bool operator==(const
exception_ptr&, const exception_ptr&)'
2 | friend bool operator==(const exception_ptr&, const exception_ptr&) =
default;
  | ^~~~
main.cpp:10:1: note: during load of binding '::exception_ptr@M'
   10 | exception_ptr e;
  | ^

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

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

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

--- Comment #5 from Jonathan Wakely  ---
Ah no, it looks like GCC only emits a line in that format for the main source
file, not for the included headers. So maybe GCC could just emit one extra
line, and not remove anything from the current output.

[Bug modula2/119751] There's a need to tidy up m2 subdirectories' contents

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

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

--- Comment #5 from Gaius Mulley  ---
Thanks for the report.

[As an aside gm2 from GCC-12 has a completely different linking mechanism to
gm2 GCC-14.2]

The file gcc/m2/gm2-libs/COROUTINES.def is a definition for "C" and thus has no
accompanying .mod file (just like libc.def, libm.def, cxxabi.def).  The reason
for this stripped down version of COROUTINES.def is to provide a base layer
compatibility between the runtime modules of the ISO and PIM dialects.  The
file gcc/m2/gm2-libs/COROUTINES.def is tiny:

DEFINITION MODULE FOR "C" COROUTINES ;

CONST
   UnassignedPriority = 0 ;

TYPE
   INTERRUPTSOURCE = CARDINAL ;
   PROTECTION = [UnassignedPriority..7] ;

END COROUTINES.

and is only defining a constant and two types, just enough to satisfy the
shared code between the ISO and PIM libraries.  COROUTINES are not part of the
PIM dialect (PIM uses the type PROCESS found in SYSTEM), so the application
module should be compiled using the -fiso switch.  

$ gm2 -fiso coex.mod 
$ > ./a.out 
A
B
C
D
E

It would be good to improve the gm2 error message saying wrong dialect (try
-fiso) maybe with a yet to be implemented warning or error attribute.

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

[love4boobies at yahoo dot com via Gcc-bugs]

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

--- Comment #6 from Bogdan  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Bogdan from comment #2)
> > GCC does use the options specified in the standard.
> 
> I think it would be more accurate to say that the standard specifies the
> options that GCC (and traditional UNIX cc compilers) use.

I didn't mean to express any sort of causal relationship, just one of partial
equivalence. Generally speaking, they evolve together: standards are, for the
most part, informed by common practice and existing solutions and the existing
solutions may adapt when consensus is reached. Don't mind my phrasing.

> The text you quote is new in POSIX.1-2024, so GCC's preprocessor format is
> much, much older. But it only says:
> 
> "it may contain extra information appropriate for subsequent compilation
> passes and shall contain at least one line with the format ..."
> 
> And GCC does that. So GCC is already conforming, and your scripts to process
> the preprocessor output are failing to handle "extra information appropriate
> for subsequent compilation passes".

Indeed. This particular change to the specification is part of a set of
unrelated additions to the make utility (not important but it's ticket 1325 on
the Austin Group's bug tracker, in case anyone's really curious).

(In reply to Jonathan Wakely from comment #5)
> Ah no, it looks like GCC only emits a line in that format for the main
> source file, not for the included headers. So maybe GCC could just emit one
> extra line, and not remove anything from the current output.

I had not considered that. This approach seems elegant as it aligns with POSIX
without requiring any extra configuration on the user's part.

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

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

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

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

https://gcc.gnu.org/g:0562e17bd04b65aebff4721db05631b9f34af146

commit r15-9395-g0562e17bd04b65aebff4721db05631b9f34af146
Author: Jakub Jelinek 
Date:   Sat Apr 12 13:11:59 2025 +0200

tailc, expand: Tail call -fdump-{tree-tailc,expand-details} changes
[PR119718]

The following patch makes some adjustments so that users can analyze what
calls weren't tail called even without using musttail attribute (though I'm
still not convinced it should be a warning, because we don't distinguish
between calls in return call (...); statements vs. calls that just happened
to end up in tail positions because something has been optimized away etc.

E.g. for
int foo (int, int, int, int, int, int, int);
int bar (int);
void qux (int *);

int
baz (int x)
{
  if (x)
return foo (1, 2, 3, 4, 5, 6, 7);
  else
{
  int y;
  qux (&y);
  return bar (x);
}
}
./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ;
grep -B1 '^\(;; \)\?Cannot tail-call:' pr119718.c.*
pr119718.c.222t.tailc-_7 = bar (0);
pr119718.c.222t.tailc:Cannot tail-call: call invocation refers to locals
--
pr119718.c.270r.expand-;; foo (1, 2, 3, 4, 5, 6, 7) [tail call]
pr119718.c.270r.expand:;; Cannot tail-call: callee required more stack
slots than the caller

The changes are:
1) in tailc pass use wording more consistent with the musttail error
wording
2) do it only in *-details dump
3) add similar diagnostics on the expand side, but this time only for the
   CALL_EXPR_TAILCALL calls, if something wasn't marked that way, it is up
   to tailc pass to emit message about it, if it was and it still can't be
   tail called, let it tell users about that; in this case I need
   to use the ;; prefix because it will appear in the middle of
   the IL dump and ;; is what is used for such purposes in other spots
4) I've tried to improve formatting of the maybe_error_musttail and
   maybe_complain_about_tail_call calls

2025-04-12  Jakub Jelinek  

PR tree-optimization/119718
* tree-tailcall.cc (maybe_error_musttail): Only dump into dump_file
if dump_flags & TDF_DETAILS.  Use "Cannot tail-call: " prefix
instead
of "Cannot convert: ".
(find_tail_calls, tree_optimize_tail_calls_1): Formatting fixes
for maybe_error_musttail calls.
* calls.cc (maybe_complain_about_tail_call): Emit also a message
into dump_file when dump_flags & TDF_DETAILS for CALL_EXPR_TAILCALL
calls.
(initialize_argument_information): Formatting fix for
maybe_complain_about_tail_call calls.
(can_implement_as_sibling_call_p, expand_call): Likewise.

[Bug tree-optimization/119718] __attribute__((musttail)) affects whether -foptimize-tail-calls will in fact optimize a tail call

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

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

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

https://gcc.gnu.org/g:7e91bba6d53899689b00bd0c995b35f6586fcacd

commit r15-9396-g7e91bba6d53899689b00bd0c995b35f6586fcacd
Author: Jakub Jelinek 
Date:   Sat Apr 12 13:12:56 2025 +0200

tailc, expand: Small incremental tweak to tail call dump [PR119718]

Here is an optional incremental tweak to the previous patch.
Instead of

./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ;
grep -B1 '^\(;; \)\?Cannot tail-call:' pr119718.c.*
pr119718.c.222t.tailc-_7 = bar (0);
pr119718.c.222t.tailc:Cannot tail-call: call invocation refers to locals
--
pr119718.c.270r.expand-;; foo (1, 2, 3, 4, 5, 6, 7) [tail call]
pr119718.c.270r.expand:;; Cannot tail-call: callee required more stack
slots than the caller

this dumps

./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ;
grep '^\(;; \)\?Cannot tail-call:' pr119718.c.*
pr119718.c.222t.tailc:Cannot tail-call: call invocation refers to locals:
_7 = bar (0);
pr119718.c.270r.expand:;; Cannot tail-call: callee required more stack
slots than the caller: foo (1, 2, 3, 4, 5, 6, 7) [tail call]

2025-04-12  Jakub Jelinek  

PR tree-optimization/119718
* tree-tailcall.cc (maybe_error_musttail): Dump the GIMPLE at the
end of the Cannot tail-call line rather than on the line before it.
* calls.cc (maybe_complain_about_tail_call): Dump the GENERIC
at the end of the ;; Cannot tail-call line rather than on the
line before it.

[Bug tree-optimization/119722] wrong code with _BitInt(), __builtin_stdc_rotate_left() at -O2 -fno-tree-forwprop -fno-tree-copy-prop -fno-tree-fre

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

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

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

https://gcc.gnu.org/g:3f9dfb94eab1ab1bbf9a2b5e20d1f61e36516063

commit r15-9397-g3f9dfb94eab1ab1bbf9a2b5e20d1f61e36516063
Author: Jakub Jelinek 
Date:   Sat Apr 12 13:13:53 2025 +0200

bitintlower: Fix up handling of SSA_NAME copies in coalescing [PR119722]

The following patch is miscompiled, because during the limited
SSA name coalescing the bitintlower pass does we incorrectly don't
register a conflict.
This is on
   [local count: 1073741824]:
  # b_17 = PHI 
  g.4_13 = g;
  _14 = g.4_13 >> 50;
  _15 = (unsigned int) _14;
  _21 = b_17;
  _16 = (unsigned int) _21;
  s_22 = _15 + _16;
  return s_22;
basic block where in the map->bitint bitmap we track 14, 17 and 19.
The build_bitint_stmt_ssa_conflicts "hook" has special code where
it tracks uses at the final statements of mergeable operations, so
e.g. the
  _16 = (unsigned int) _21;
statement is considered to be use of b_17 because _21 is not in
map->bitmap (or large_huge.m_names), i.e. is mergeable.
The problem is that build_ssa_conflict_graph has special code to handle
SSA_NAME copies and _21 = b_17; is gimple_assign_copy_p.  In such cases
it calls live_track_clear_var on the rhs1.  The problem is that
on the above bb, after we note in the _16 = (unsigned int) _21;
stmt we need b_17 the generic code makes us forget that because
of the copy statement, and then build_bitint_stmt_ssa_conflicts
ignores it completely (because _21 is large/huge bitint and is
not in map->bitint, so assumed to be handled by a later stmt in the
bb, for backwards walk like this before this one).
As the b_17 use is ignored, the coalescing thinks it can put
all of b_17, b_19 and _14 into the same partition, which is wrong,
while we can and should coalesce b_17 and b_19, _14 needs to be a different
temporary because b_17 is set before and used after _14 has been written.

The following patch fixes it by handling gimple_assign_copy_p in two
separate spots, move the generic coalesce handling of it after
build_ssa_conflict_graph (where build_ssa_conflict_graph handling
doesn't fall through to that, it does continue after the call) and
inside of build_ssa_conflict_graph it performs it too, but only if
the lhs is not mergeable large/huge bitint.

2025-04-12  Jakub Jelinek  

PR tree-optimization/119722
* gimple-lower-bitint.h (build_bitint_stmt_ssa_conflicts): Add
CLEAR argument.
* gimple-lower-bitint.cc (build_bitint_stmt_ssa_conflicts): Add
CLEAR argument.  Call clear on gimple_assign_copy_p rhs1 if lhs
is large/huge bitint unless lhs is not in names.
* tree-ssa-coalesce.cc (build_ssa_conflict_graph): Adjust
build_bitint_stmt_ssa_conflicts caller.  Move gimple_assign_copy_p
handling to after the build_bitint_stmt_ssa_conflicts call.

* gcc.dg/torture/bitint-77.c: New test.

[Bug driver/119727] -freport-bug vs. ASLR

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

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

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

https://gcc.gnu.org/g:8b2ceb421f045ee8b39d7941f39f1e9a67217583

commit r15-9398-g8b2ceb421f045ee8b39d7941f39f1e9a67217583
Author: Jakub Jelinek 
Date:   Sat Apr 12 13:15:13 2025 +0200

driver: Fix up -freport-bug for ASLR [PR119727]

With --enable-host-pie -freport-bug almost never prepares preprocessed
source and instead emits
The bug is not reproducible, so it is likely a hardware or OS problem.
message even for bogus which are 100% reproducible.
The way -freport-bug works is that it reruns it 3 times, capturing stdout
and stderr from each and then tries to compare the outputs in between
different runs.
The libbacktrace emitted hexadecimal addresses at the start of the lines
can differ between runs due to ASLR, either of the PIE executable, or
even if not PIE if there is some frame with e.g. libc function (say
crash in strlen/memcpy etc.).

The following patch fixes it by ignoring such differences at the start of
the lines.

2025-04-12  Jakub Jelinek  

PR driver/119727
* gcc.cc (files_equal_p): Rewritten using fopen/fgets/fclose
instead
of open/fstat/read/close.  At the start of lines, ignore lowercase
hexadecimal addresses followed by space.

[Bug tree-optimization/119722] wrong code with _BitInt(), __builtin_stdc_rotate_left() at -O2 -fno-tree-forwprop -fno-tree-copy-prop -fno-tree-fre

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

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

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug modula2/119751] There's a need to tidy up m2 subdirectories' contents

[zbigniew2011 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Zbigniew  ---
Indeed I confirm 'gm2 -fiso coex.mod -o coex' works in case of GCC 14.2.0. Yes,
the error message could be a bit more specific, if it's feasible.
In case of 12.2.0 there's still an error (below) — but I assume it's exactly
what has been fixed in later versions:

gm2 -fiso coex.mod -o coex

/usr/bin/ld: /tmp/ccGZZwij.a(coex_m2.o): in function `init(int, char**)':
coex_m2.cpp:(.text+0xd2): undefined reference to `_M2_CoEx_init'
/usr/bin/ld: /tmp/ccGZZwij.a(coex_m2.o): in function `finish()':
coex_m2.cpp:(.text+0x100): undefined reference to `_M2_CoEx_finish'

[Bug modula2/119751] There's a need to tidy up m2 subdirectories' contents

[zbigniew2011 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Zbigniew  ---
I'd like to stress it: presently these error messages (I mean without '-fiso'
option) look like compiler was malfunctioning:

coex.mod:8:24: error: In program module 'CoEx': unknown symbol 'COROUTINE'
8 | FROM COROUTINES IMPORT COROUTINE, NEWCOROUTINE, TRANSFER;
  |^
coex.mod:8:35: error: unknown symbol 'NEWCOROUTINE'
8 | FROM COROUTINES IMPORT COROUTINE, NEWCOROUTINE, TRANSFER;
  |   ^~~~
coex.mod:8:49: error: unknown symbol 'TRANSFER'
8 | FROM COROUTINES IMPORT COROUTINE, NEWCOROUTINE, TRANSFER;
  | ^~~~
coex.mod:44:9: error: the following unknown symbols in module 'CoEx' were
locally used: NEWCOROUTINE, COROUTINE and TRANSFER
   44 | END CoEx.
  | ^

As one can find out: the module exists, these symbols can be found inside, so
the only guess — for anyone who's not (yet) expert in Modula 2 — is „must be
something wrong with the libraries”. And after I found similar module in
sibling sub-dir my conclusion was: „conflicting libraries, probably” (which has
been „confirmed” when I renamed the file, and when I found even more difficult
issue in 12.2).

[Bug c++/119755] New: type_traits:828:11: fatal error: failed to load pendings for 'std::__is_one_of'

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

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

Bug ID: 119755
   Summary: type_traits:828:11: fatal error: failed to load
pendings for 'std::__is_one_of'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Given a file with the single line:

#include 


Using a recent trunk:

g++ -fsearch-include-path  ../include/c++/15.0.1/bits/std.compat.cc
-std=gnu++26 -x c++ - -fmodules

It fails with:

In module imported at
/home/jwakely/gcc/15/include/c++/15.0.1/bits/std.compat.cc:30:8:
/home/jwakely/gcc/15/include/c++/15.0.1/type_traits: In substitution of
‘template using std::__is_one_of =
std::__or_...> [with _Tp = unsigned char; _Types =
{unsigned char, short unsigned int, unsigned int, long unsigned int, long long
unsigned int, __int128 unsigned}]’:
/home/jwakely/gcc/15/include/c++/15.0.1/type_traits:828:11:   required by
substitution of ‘template using std::__is_unsigned_integer =
std::__is_one_of >::type,
unsigned char, short unsigned int, unsigned int, long unsigned int, long long
unsigned int, __int128 unsigned> [with _Tp = unsigned char]’
  828 | using __is_unsigned_integer = __is_one_of<__remove_cv_t<_Tp>,
  |   ^
/home/jwakely/gcc/15/include/c++/15.0.1/bit:397:62:   required from ‘unsigned
int __gnu_cxx::stdc_leading_zeros(_Tp) [with _Tp = unsigned char]’
  397 | concept __unsigned_integer = __is_unsigned_integer<_Tp>::value;
  |  ^
/home/jwakely/gcc/15/include/c++/15.0.1/stdbit.h:63:28:   required from here
   63 | { return stdc_leading_zeros(__value); }
  |  ~~^
std: error: failed to read compiled module cluster 4625: Bad file data
std: note: compiled module file is ‘gcm.cache/std.gcm’
In file included from /home/jwakely/gcc/15/include/c++/15.0.1/concepts:48,
 from /home/jwakely/gcc/15/include/c++/15.0.1/bit:38,
 from /home/jwakely/gcc/15/include/c++/15.0.1/stdbit.h:33,
 from
/home/jwakely/gcc/15/include/c++/15.0.1/bits/std.compat.cc:26:
/home/jwakely/gcc/15/include/c++/15.0.1/type_traits:828:11: fatal error: failed
to load pendings for ‘std::__is_one_of’
  828 | using __is_unsigned_integer = __is_one_of<__remove_cv_t<_Tp>,
  |   ^
compilation terminated.

[Bug c++/119756] New: Error when reading source from stdin and compiling modules: cc1plus: fatal error: stdout: No such file or directory

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

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

Bug ID: 119756
   Summary: Error when reading source from stdin and compiling
modules: cc1plus: fatal error: stdout: No such file or
directory
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This works:

:| ~/gcc/15/bin/g++ -x c++ - -x c++ /dev/null -c -std=c++20

It creates -.o and null.o as expected.

But if you add -fmodules -fsearch-include-path 
../include/c++/15.0.1/bits/std.compat.cc then it fails:

:| ~/gcc/15/bin/g++ -x c++ - -x c++ /dev/null -c -std=c++20 -fmodules \
   -fsearch-include-path  ../include/c++/15.0.1/bits/std.compat.cc


cc1plus: fatal error: stdout: No such file or directory
compilation terminated.
In module imported at
/home/jwakely/gcc/15/include/c++/15.0.1/bits/std.compat.cc:30:8:
std: error: failed to read compiled module: No such file or directory
std: note: compiled module file is ‘gcm.cache/std.gcm’
std: note: imports must be built before being imported
std: fatal error: returning to the gate for a mechanical issue
compilation terminated.


It looks like something about using '-' as the input causes the module code to
use the string 'stdout' as the output.

[Bug tree-optimization/93010] Wrong optimization: provenance affects comparison of saved bits of addresses of dead auto variables

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

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

--- Comment #5 from Sam James  ---
Martin, just to check, did you want to confirm this (it's still UNCONFIRMED) or
just add yourself to CC?

[Bug driver/119727] -freport-bug vs. ASLR

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

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

--- Comment #6 from Sam James  ---
Let's consider backporting this one after some time on trunk? It'd help us a
lot with user reports and would mean we can default-enable -freport-bug
downstream.

[Bug tree-optimization/93010] Wrong optimization: provenance affects comparison of saved bits of addresses of dead auto variables

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2025-04-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #6 from uecker at gcc dot gnu.org ---

I wanted to add myself to the CC list. But let's confirm it, as it is not
standards compliant to compare to equal integers as unequal.

[Bug bootstrap/119729] configure should issue a warning about building in the src tree

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to mcccs from comment #4)
> Suggested patch:
> 
> +if test $srcdir = . ; then
> +  AC_MSG_ERROR([building in the top level project directory is not
> supported. Please change the current directory to a new directory (can be a
> new subdirectory of the project root)])
> +fi
> 
> just above "# Find the build and target subdir names." in top-level
> configure.ac

Since gcc, gdb and binutils (and newlib though not updated as much IIRC) all
share the same toplevel configure, you need to check with gdb and binutils
folks also if that is acceptable; otherwise you need to add a check to see if
the gcc directory exists too.

[Bug c++/119755] type_traits:828:11: fatal error: failed to load pendings for 'std::__is_one_of'

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Blocks||103524
 CC||nshead at gcc dot gnu.org

--- Comment #1 from Nathaniel Shead  ---
Unfortunately I haven't been able to reproduce, it looks like at the least this
is relying on std.cc having been built at some point in the past.  Are you able
to reproduce with some series of commands in a fresh directory (i.e. after a
'rm -rf gcm.cache')?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #61087|0   |1
is obsolete||

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

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-12
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv64-unknown-linux-gnu   |riscv*-unknown-linux-gnu

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Sam James from comment #1)
> > -O2 -fno-vect-cost-model -march=rv64gcv_zvl256b fails
> 
> `-O2 -fno-vect-cost-model -march=rv64gcv ` is enough to get it to fail. That
> is zvl256b is not needed.

ICEs also on 32bit (-march=rv32gcv ).

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

--- Comment #7 from Andrew Pinski  ---
Looks like only can hit on riscv due to the only one I know of that has gather
support it seems.

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 61087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61087&action=edit
No include testcase

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Sam James from comment #1)
> -O2 -fno-vect-cost-model -march=rv64gcv_zvl256b fails

`-O2 -fno-vect-cost-model -march=rv64gcv ` is enough to get it to fail. That is
zvl256b is not needed.

[Bug tree-optimization/119733] store-merging increases alignment

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
It can use alignment of the whole structure whose part is accessed, as long as
it is actually accessed.
We can't derive alignment from mere existance of pointer (at least in GIMPLE),
that would break too much real world code, but whenever anything from the
structure is accessed, we can rely on the full alignment of it.

[Bug rtl-optimization/117706] [15 regression] gcc.dg/ira-shrinkwrap-prep-[12].c XPASS

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15 regression] |[15 regression]
   |gcc.dg/ira-shrinkwrap-prep- |gcc.dg/ira-shrinkwrap-prep-
   |1.c etc. XPASS  |[12].c  XPASS
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-12
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
/* { dg-do compile { target { { { i?86-*-* x86_64-*-* } && lp64 } || { {
powerpc*-*-* && lp64 } || { arm_nothumb || { aarch64*-*-* && lp64 } } } } } }
*/


/* { dg-final { scan-rtl-dump "Split live-range of register" "ira" { xfail { !
aarch64*-*-* } } } } */

So I looked into the testresults and it still fails on powerpc and I think arm.

So I will update it include ! i?86/x86_64 in a few minutes.

[Bug rtl-optimization/117706] [15 regression] gcc.dg/ira-shrinkwrap-prep-[12].c XPASS

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

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

--- Comment #2 from Sam James  ---
Running it manually, it looks like it still fails on arm indeed.

[Bug rtl-optimization/117706] [15 regression] gcc.dg/ira-shrinkwrap-prep-[12].c XPASS

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Note it was r15-1735-ge62ea4fb8ffcab which fixed it for x86_64 (in a similar
fashion as aarch64 with r15-1579-g792f97b44ffc5e which added late combine).

I am not sure why arm still fails though; powerpc still has late combine
disabled (PR 115612) which is the most likely reason why it still fails there.

[Bug libfortran/119502] Runtime segfault when closing invalid unit

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

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

--- Comment #6 from Jerry DeLisle  ---
Interestingly PR 48618 has a slightly different interpretation of the standard.
 I will be checking the 2023 to see.

[Bug rtl-optimization/117706] [15 regression] gcc.dg/ira-shrinkwrap-prep-[12].c XPASS

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

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

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

https://gcc.gnu.org/g:359b6128ade70f80cc850fdc8e3e90837ba1ff70

commit r15-9401-g359b6128ade70f80cc850fdc8e3e90837ba1ff70
Author: Andrew Pinski 
Date:   Sat Apr 12 12:26:26 2025 -0700

testsuite: unxfail ira-shrinkwrap-prep-[12].c for x86_64 [PR117706]

When late combine was enabled for x86_64 (r15-1735-ge62ea4fb8ffcab),
these 2 testcases start to xpass in a similar fashion as when late
combine was added and the testcase was updated for aarch64 not to
xfail them there.

Pushed as obvious after a test to make sure the testcase no longer xpass.

PR testsuite/117706
gcc/testsuite/ChangeLog:

* gcc.dg/ira-shrinkwrap-prep-1.c: Unxfail for i?68-*-* and
x86_64-*-*.
* gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.

Signed-off-by: Andrew Pinski 

[Bug rtl-optimization/117706] [15 regression] gcc.dg/ira-shrinkwrap-prep-[12].c XPASS

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug cobol/119759] New: LICENSE file in gcc/cobol

[simonsobisch at gnu dot org via Gcc-bugs]

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

Bug ID: 119759
   Summary: LICENSE file in gcc/cobol
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: cobol
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simonsobisch at gnu dot org
  Target Milestone: ---

As far as I know this file should be deleted.

[Bug cobol/119759] LICENSE file in gcc/cobol

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

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

--- Comment #1 from Sam James  ---
I'm not sure why it's even BSD to begin with. I did try to ask on the ML but
didn't get an answer.

Besides, if it's part of GCC, the whole thing is GPL anyway.

[Bug tree-optimization/110992] [13/14/15 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||15.0
 Resolution|--- |FIXED
   Target Milestone|13.4|15.0

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

[Bug libgcc/117600] [15 regression] libgcc arm build doesn't respect --disable-werror

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Since it is only aarch64, there are currently only a few aarch64 targets that
are build regularly, -elf, -mingw, -linux-gnu (soon -darwin). 


freebsd, netbsd, fuchsia, gnu (hurd), vxworks and rtems exists but I am not
even sure they are buildable right now either. 

So closing as won't fix since -Werror here is fine and if someone is building
some other aarch64 target they can fix the warning and/or edit the source file
to remove -Werror for now.

[Bug tree-optimization/119733] store-merging increases alignment

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

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

Krister Walfridsson  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #6 from Krister Walfridsson  ---
That's what I believe I've implemented! But the compiler doesn't see the object
here, so we can't reason from the provenance -- we just have a random pointer.
And a pointer may have any value.

I'd argue we can only assume 16-bit alignment, which is enforced by the load:
  unsigned short pc = q->c;
But you're right that SLP already increased this, which smtgcc should have
reported...

Anyway, all my confusion seems to come from get_object_alignment being
inconsistent in what it returns. I need to take a closer look at it. So I now
agree this bug report being invalid. :)

[Bug tree-optimization/119733] store-merging increases alignment

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

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

Krister Walfridsson  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug d/109023] d: Add option to include imported modules in the compilation

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

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
For now, added with no extra considerations being made.  Only, modules that are
part of libphobos are excluded from being compiled in.

Future improvements, such as compiling imports based on a pattern match can be
done in other PRs / units of work.

[Bug testsuite/119382] [15 Regression] gcc.target/powerpc/vsx-builtin-7.c fail starting with r15-7961-gdc47161c1f32c3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed so closing.

[Bug middle-end/115675] [15 Regression] truncv4hiv4qi affect r14-1402-gd8545fb2c71683's optimization.

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 61089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61089&action=edit
Testcase from the testsuite

[Bug d/119758] d: -fonly= argument only matches when including full relative path to the input file

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

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Fix committed.

[Bug libstdc++/119748] std::string::string(InputIterator, InputIterator) rejects volatile charT* as iterator

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

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

--- Comment #2 from Jonathan Wakely  ---
Ah yes, thanks.

(In reply to Jonathan Wakely from comment #0)
> _S_copy(__p, std::__niter_base(__k1), __k2 - __k1);
>  #if __cpp_lib_concepts
>   else if constexpr (contiguous_iterator<_Iterator>
> -  && is_same_v, _CharT>)
> +  && requires { { std::to_address(__k1) }
> +-> convertible_to; })


This needs to be:

  else if constexpr (requires {
   requires contiguous_iterator<_Iterator>;
   { std::to_address(__k1) }
 -> convertible_to;
 })

Otherwise we evaluate the requires-expression even when contiguous_iterator
isn't satisfied, and we can't use std::to_address if it's not a contiguous
iterator.

[Bug bootstrap/119729] configure should issue a warning about building in the src tree

[mcccs at gmx dot com via Gcc-bugs]

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

--- Comment #4 from mcccs at gmx dot com ---
Suggested patch:

+if test $srcdir = . ; then
+  AC_MSG_ERROR([building in the top level project directory is not supported.
Please change the current directory to a new directory (can be a new
subdirectory of the project root)])
+fi

just above "# Find the build and target subdir names." in top-level
configure.ac

[Bug fortran/101602] [F2018] local and local_init are not supported in DO CONCURRENT

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

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

--- Comment #10 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

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

commit r15-9393-gf417af3f9f94538c2600e78e6c60b61c29fdbf99
Author: Thomas Schwinge 
Date:   Sat Apr 12 10:53:14 2025 +0200

Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT: Fix
'static_assert' [PR101602]

Fix-up for commit 2d7e1d6e40a13a5f160b584336795b80f193ec3b
"Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]":

../../source-gcc/gcc/fortran/trans-stmt.cc: In function âvoid
gfc_trans_concurrent_locality_spec(bool, stmtblock_t*,
std::vector*, gfc_expr_list**)â:
../../source-gcc/gcc/fortran/trans-stmt.cc:5157:59: error: expected
â,â before â)â token
   static_assert (LOCALITY_LOCAL_INIT - LOCALITY_LOCAL == 1);
   ^
../../source-gcc/gcc/fortran/trans-stmt.cc:5157:59: error: expected
string-literal before â)â token
make[2]: *** [Makefile:1210: fortran/trans-stmt.o] Error 1

PR fortran/101602
gcc/fortran/
* trans-stmt.cc (gfc_trans_concurrent_locality_spec): Fix
'static_assert'.

[Bug libstdc++/119752] ranges::find does not handle ranges of volatile elements well

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=119748
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-12
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Not many algos care about contiguous ranges, and some of the ones that do care
(copy etc.) are already using memcpyable_iterator which excludes volatile
types.

[Bug d/112291] cyclic reference struct with `in` parameter and `-fpreview=in` causes bogus error: overlapping initializer for field ...

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

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

Iain Buclaw  changed:

   What|Removed |Added

  Known to fail||13.3.0
 CC||ibuclaw at gcc dot gnu.org
  Known to work||14.1.0

--- Comment #1 from Iain Buclaw  ---
This is fine as of gdc-14.  Only gdc-12 and gdc-13 are affected.

[Bug c++/119762] [modules] Error when loading an unused defaulted function on top of a used one

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Blocks||103524
   Last reconfirmed||2025-04-12
 Ever confirmed|0   |1

--- Comment #2 from Nathaniel Shead  ---
I have a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680646.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c++/119763] New: [modules] Declarations in extern "C++" incorrectly treated as attached to named module

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

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

Bug ID: 119763
   Summary: [modules] Declarations in extern "C++" incorrectly
treated as attached to named module
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
  Target Milestone: ---

Consider:

  // main.cpp
  export module M;
  extern "C++" {
static int internal() { return 123; }
export struct S {
  int foo() { return internal(); }
};
  }

$ g++ -fmodules -S main.cpp
main.cpp:5:9: error: 'int S::foo()' exposes TU-local entity 'int internal()'
5 | int foo() { return internal(); }
  | ^~~
main.cpp:3:14: note: 'int internal()' declared with internal linkage
3 |   static int internal() { return 123; }
  |  ^~~~

But this is wrong: by https://eel.is/c++draft/module.unit#7.2.2, 'S' is
attached to the global module, and so by https://eel.is/c++draft/class.mfct#1
it should be declared 'inline', which means that this is not an exposure.

[Bug c++/119763] [modules] Declarations in extern "C++" incorrectly treated as attached to named module

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Blocks||103524
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
   Last reconfirmed||2025-04-12

--- Comment #1 from Nathaniel Shead  ---
The following (untested) patch should fix the issue:

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 927f51b116b..0a52d333b8a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7539,7 +7539,7 @@ inline bool module_has_cmi_p ()
 inline bool module_purview_p ()
 { return module_kind & MK_PURVIEW; }
 inline bool module_attach_p ()
-{ return module_kind & MK_ATTACH; }
+{ return (module_kind & MK_ATTACH) && current_lang_depth () == 0; }

 inline bool named_module_purview_p ()
 { return named_module_p () && module_purview_p (); }


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c++/119755] type_traits:828:11: fatal error: failed to load pendings for 'std::__is_one_of'

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #4 from Nathaniel Shead  ---
Reduced:

  // std.cc
  export module std;
  template  void format(_Out) {
constexpr int __term = 0;
[&] { __term; };
  }
  export inline void vformat() {
format(0);
  }

  // std.compat.cc
  import std;
  int x = (vformat(), 0);

$ g++ -fmodules -S std.cc std.compat.cc
In module imported at std.compat.ii:1:1:
std: error: failed to read compiled module cluster 2: Bad file data
std: note: compiled module file is ‘gcm.cache/std.gcm’
std: error: failed to read compiled module cluster 3: Bad file data
std.compat.cc:2:10: fatal error: failed to load binding ‘::vformat@std’
2 | int x = (vformat(), 0);
  |  ^~~
compilation terminated.

The issue appears to be that when loading the lambda we look for '__term' as a
member in its context, but it actually lives outside the lambda so it isn't
found and we bail.

[Bug c++/119763] [modules] Declarations in extern "C++" incorrectly treated as attached to named module

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Nathaniel Shead  ---
(I misread the testcase I'd been given; this is actually correct, and handled
within cp_parser_linkage_specification.)

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 119763 Summary: [modules] Declarations in extern "C++" incorrectly treated 
as attached to named module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119763

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

[Bug d/119761] d: importC cannot find input file '__importc_builtins.d'

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

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

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

https://gcc.gnu.org/g:424c6c88038ef13364e6e7e74e2389923d95396e

commit r15-9404-g424c6c88038ef13364e6e7e74e2389923d95396e
Author: Iain Buclaw 
Date:   Sun Apr 13 00:48:45 2025 +0200

d: Fix importC cannot find input file __importc_builtins.d [PR119761]

Synchronizes the D runtime library with upstream druntime 09ed02ce56,
and fixes a rename of the importC module missed in the r15-6559 merge.

PR d/119761

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime 09ed02ce56.
* libdruntime/Makefile.am (DRUNTIME_DISOURCES): Rename
__builtins.di
to __importc_builtins.di.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/__builtins.di: Move to...
* libdruntime/__importc_builtins.di: ...here.

gcc/testsuite/ChangeLog:

* gdc.dg/import-c/import-c.exp: New test.
* gdc.dg/import-c/pr119761.d: New test.
* gdc.dg/import-c/pr119761c.c: New test.

[Bug d/119761] d: importC cannot find input file '__importc_builtins.d'

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

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Fix committed.

[Bug c++/119764] New: noexcept lambdas do not have unused captures get pruned

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

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

Bug ID: 119764
   Summary: noexcept lambdas do not have unused captures get
pruned
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
  Target Milestone: ---

The following sample fails because the non-ODR usage of 'x' does not get pruned
in 'b':

int main() {
  const int x = 123;
  auto a = [&]() { return x; };
  auto b = [&]() noexcept { return x; };
  static_assert(sizeof(a) == sizeof(b));
}

'g++ main.cpp' gives:

main.cpp: In function 'int main()':
main.cpp:5:29: error: static assertion failed
5 | static_assert(sizeof(a) == sizeof(b));
  |   ~~^~~~
main.cpp:5:29: note: the comparison reduces to '(1 == 8)'

This gave a segmentation fault instead until r9-2784-g86e95f35c52213 (PR87185).

[Bug d/112291] cyclic reference struct with `in` parameter and `-fpreview=in` causes bogus error: overlapping initializer for field ...

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

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||12.4.0, 13.3.0
  Known to fail|13.3.0  |13.2.0
 Resolution|--- |DUPLICATE

--- Comment #2 from Iain Buclaw  ---
Ah, this is a duplicate of pr112285 and pr112290.  Which has already been
backported to 13.3.0 and 12.4.0

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

[Bug d/112290] self-referencing `in` parameter with `-fpreview=in` causes ICE

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

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

--- Comment #5 from Iain Buclaw  ---
*** Bug 112291 has been marked as a duplicate of this bug. ***

[Bug libstdc++/119752] New: ranges::find does not handle volatile char ranges well

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 119752
   Summary: ranges::find does not handle volatile char ranges well
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This is the sibling of PR119748:

https://godbolt.org/z/Mv184YGo8

#include 

int main() {
  volatile char vc[4] = {'a', 'b', 'c', '\n'};
  auto it = std::ranges::find(vc, 'c');
}

Now I began to suspect if it was worth the trouble to review the entire
's specialization for contiguous ranges one by one to ensure that
volatile arrays were supported...

[Bug libstdc++/119754] New: std::uninitialized_value_construct does not begin lifetime of trivial types

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

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

Bug ID: 119754
   Summary: std::uninitialized_value_construct does not begin
lifetime of trivial types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

consteval bool f(int n)
{
  int* p = std::allocator().allocate(n);
  std::uninitialized_value_construct(p, p+n);
  std::allocator().deallocate(p, n);
  return true;
}

static_assert(f(10));


With -std=c++26 GCC accepts this, but Clang doesn't:

ef.cc:12:15: error: static assertion expression is not an integral constant
expression
   12 | static_assert(f(10));
  |   ^
/home/jwakely/gcc/15/lib/gcc/x86_64-pc-linux-gnu/15.0.1/../../../../include/c++/15.0.1/bits/stl_algobase.h:925:11:
note: assignment to object outside its lifetime is not allowed in a constant
expression
  925 | *__first = __val;
  | ~^~~

[Bug c++/113835] [13/14/15 Regression] compiling std::vector with const size in C++20 is slow

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #13)
> Hmm, __uninitialized_default doesn't have a std::is_constant_evaluated
> check, but I think it needs it for exactly the same reasons.

I've opened Bug 119754 for that.

[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types

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

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

--- Comment #1 from Jonathan Wakely  ---
GCC fails to diagnose it for the same reason that it fails to diagnose this:

#include 
consteval bool f()
{
  int* p = std::allocator().allocate(1);
  *p = 99;
  std::allocator().deallocate(p, 1);
  return true;
}
static_assert(f());

I'm not sure if we have a bug about this, but there are some similar ones.

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Bogdan from comment #2)
> GCC does use the options specified in the standard.

I think it would be more accurate to say that the standard specifies the
options that GCC (and traditional UNIX cc compilers) use.

POSIX-1.2017 said very little about the format of preprocessor output, just:

"If the -E option is specified, the standard output shall be a text file that
represents the results of the preprocessing stage of the language; it may
contain extra information appropriate for subsequent compilation passes."

The text you quote is new in POSIX.1-2024, so GCC's preprocessor format is
much, much older. But it only says:

"it may contain extra information appropriate for subsequent compilation passes
and shall contain at least one line with the format ..."

And GCC does that. So GCC is already conforming, and your scripts to process
the preprocessor output are failing to handle "extra information appropriate
for subsequent compilation passes".

[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Version|unknown |15.0

[Bug c++/119755] type_traits:828:11: fatal error: failed to load pendings for 'std::__is_one_of'

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-04-12
 Status|UNCONFIRMED |NEW

--- Comment #2 from Nathaniel Shead  ---
Ah actually, trying again on a slightly newer build I can reproduce.  The
following is sufficient to cause the error:

$ g++ -fmodules -std=gnu++26 -fsearch-include-path -S bits/std.cc
bits/std.compat.cc

Reducing...

[Bug c++/113835] [13/14/15 Regression] compiling std::vector with const size in C++20 is slow

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

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

--- Comment #15 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #12)
> The __uninitialized_default_n_1 specialization assumes that we can use
> std::fill_n to assign to objects outside their lifetime. I don't think
> that's valid during constant evaluation, is it?

No, you're right; I guess I was thinking that for a type with a trivial default
constructor, assignment could start the lifetime like it does for a union
member, or that allocate would vacuously initialize the elements of an array of
such type.

One of those being needed because we don't get implicit object creation in
constant evaluation.

[Bug c++/119755] type_traits:828:11: fatal error: failed to load pendings for 'std::__is_one_of'

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

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

--- Comment #3 from Jonathan Wakely  ---
Sorry for the slightly confused report, I think what I pasted here wasn't quite
what I was testing (e.g. the command has `-x c++ -` but I said to compile a
file).

Thanks for figuring out what I actually meant to report!

[Bug c++/113835] [13/14/15 Regression] compiling std::vector with const size in C++20 is slow

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

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

--- Comment #16 from Jason Merrill  ---
(In reply to Patrick Palka from comment #4)
> r13-6421 just makes us use mce_true and mce_uknown during trial constant
> evaluation of x's initialization, so my guess is before that commit the
> evaluation was quickly aborted as soon as it saw a
> std::is_constant_evaluated() call, and afterwards we evaluate
> is_constant_evaluated() to true and keep going until we hit
> constexpr_loop_limit / constexpr_ops_limit.  So perhaps we should have
> reduced limits for trial constant evaluation?

The issue is that as I mentioned in comment #10, the trial mce_unknown
evaluation was the only evaluation, so before that commit the evaluation was
quickly aborted and then we never try again.

So it's not clear to me that this is a regression: now we are actually trying
to do manifest constant-initialization as specified by the standard, and
failing due to implementation limits.  Previously we wrongly didn't try. 
Admittedly, we end up with the same result after taking much longer, so that's
definitely a regression in the user experience.

Incidentally, perhaps we want to give a diagnostic about hitting implementation
limits even in contexts like this that allow non-constant results.

[Bug c++/113835] [13/14/15 Regression] compiling std::vector with const size in C++20 is slow

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

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

--- Comment #17 from Jason Merrill  ---
Clang shows the same behavior, taking a long time to give up and do dynamic
initialization.

[Bug target/97585] Improve documentation for -march=x86-64 to say MMX, SSE, SSE2 are implied

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||sandra at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #4 from sandra at gcc dot gnu.org ---
Fixed for GCC 15.

[Bug target/97585] Improve documentation for -march=x86-64 to say MMX, SSE, SSE2 are implied

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/97585] Improve documentation for -march=x86-64 to say MMX, SSE, SSE2 are implied

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:342f1663bfb0e662f12c035c922d72166be9dd22

commit r15-9399-g342f1663bfb0e662f12c035c922d72166be9dd22
Author: Sandra Loosemore 
Date:   Sat Apr 12 04:03:11 2025 +

Doc: Explicitly document extensions implied by -march=x86_64 [PR97585]

gcc/ChangeLog
PR target/97585
* doc/invoke.texi (x86 Options): Document list of extensions
supported by -march=x86_64, according to the declaration of
PTA_X86_64_BASELINE in config/i386/i386.h.

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|RISC-V: ICE in operator[],  |[15 regression] RISC-V: ICE
   |at vec.h:910|when building curl-8.13.0
   ||(in operator[], at
   ||vec.h:910)
  Component|c   |tree-optimization
   Target Milestone|--- |15.0

[Bug c/119757] New: RISC-V: ICE in operator[], at vec.h:910

[negge at dgql dot org via Gcc-bugs]

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

Bug ID: 119757
   Summary: RISC-V: ICE in operator[], at vec.h:910
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: negge at dgql dot org
  Target Milestone: ---

Created attachment 61086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61086&action=edit
base64.c

Building curl-8.13.0 with gcc-15.0. gives an internal compiler error. I
have attached a reduced input file base64.c. Note, it compiles fine without
-O3.

# riscv64-unknown-linux-gnu-gcc --version
riscv64-unknown-linux-gnu-gcc (Gentoo 15.0. p, commit
b83b3cd6a079211515a891c3c8bfd008a197f1d6) 15.0.1 20250411 (experimental)
93f6ea830348a5a733ecde863cddae80d84bdda0
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# riscv64-unknown-linux-gnu-gcc /tmp/base64.c -O3 -march=rv64gcv_zvl256b -c -o
/dev/null
during GIMPLE pass: vect
/tmp/bad2.c: In function ‘Curl_base64_encode’:
/tmp/bad2.c:76:10: internal compiler error: in operator[], at vec.h:910
   76 | CURLcode Curl_base64_encode(const char *inputbuff, size_t insize,
  |  ^~
0xc6e2f2b3 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, std::__va_list*,
diagnostic_t)
???:0
0xc6e46edf internal_error(char const*, ...)
???:0
0xc4835167 fancy_abort(char const*, int, char const*)
???:0
0xc540657f vect_analyze_slp(vec_info*, unsigned int, bool)
???:0
0xc53d3617 vect_analyze_loop(loop*, gimple*, vec_info_shared*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/119757] [15 regression] RISC-V: ICE when building curl-8.13.0 (in operator[], at vec.h:910)

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

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

--- Comment #1 from Sam James  ---
-O2 -fno-vect-cost-model -march=rv64gcv_zvl256b fails

[Bug c++/106618] C++ Option Summary shows `-fargs-in-order` instead of `-fstrong-eval-order`

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/116242] [meta-bug] Tracker for zvl issues in RISC-V

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||meta-bug
   Last reconfirmed||2025-04-12

[Bug c++/113835] [13/14/15 Regression] compiling std::vector with const size in C++20 is slow

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

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

--- Comment #18 from Jason Merrill  ---
If I increase the limits (or reduce N) enough that we get through the whole
evaluation, constant-evaluation still fails right at the end because the result
refers to the result of operator new and we don't have non-transient constexpr
allocation (P3554) yet.  I'm not sure how we could shortcut that failure in
general, but I suppose we could recognize std::vector and bail out early.

[Bug modula2/119751] There's a need to tidy up m2 subdirectories' contents

[zbigniew2011 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Zbigniew  ---
I'd like also to note there's also a need to take better care about the docs;
for example: I tried a code snippet from
https://gcc.gnu.org/onlinedocs/gm2/Assembly-language.html („2.17 Interface to
assembly language”) — simply by including that proc definition into that
„coroutine example” module.
Unfortunately, both examples generate error message instead of code:

coex2.mod: Assembler messages:
coex2.mod:22: Error: operand type mismatch for `movq'

So either something isn't right with both examples — or there's a need to
describe something MORE DETAILED WAY immediately on the very same page (if it
was my mistake?); that's what the docs are for, anyway.

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Bogdan from comment #0)
> 1. If those numbers at the end are unimportant, maybe just strip them from
> the output. I'm not even sure what they represent.

See the documentation:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html

> 2. If they are important, change -E to match POSIX and have GCC's current
> output be available via either a new option or an extra one used in
> conjunction with -E.

They're definitely important, so this is not an option. Changing the default
behaviour would break things. Any change to the behaviour must be disabled by
default.

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

[love4boobies at yahoo dot com via Gcc-bugs]

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

--- Comment #2 from Bogdan  ---
Yes, distributions often use an alias where c99 or c17 will actually be GCC
using the appropriate --std option. But it seems reasonable to try to keep
close to the standard whenever there is a good technical reason not to. With a
few exceptions, GCC does use the options specified in the standard.

[Bug preprocessor/119753] gcc -E is not POSIX-compliant

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

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

--- Comment #1 from Jonathan Wakely  ---
POSIX is talking about the 'c17' utility, not a command called 'gcc'. I don't
think GCC claims to be equivalent to 'c17'.

Any 'c99' or 'c17' utility you have is not part of upstream GCC but is
installed by your distro.

A new option or environment variable that makes 'gcc' more compatible with the
POSIX requirements does seem reasonable though.