[Bug tree-optimization/91940] __builtin_bswap16 loop optimization

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

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

--- Comment #11 from Jakub Jelinek  ---
Only 16-bit byteswap has the r>> 8 canonical form, larger byteswaps don't.
Larger byteswaps certainly aren't rotates, but just permutes.  So, if the
vectorizer doesn't try that already, it should try to vectorize bswap32,
bswap64 etc. as a permutation.

[Bug c++/116276] [14/15 regression] multiple inheritance CTAD regression with -std=c++23

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
r14-6551-g83088b331cde0843d65d316e554873ef6d7b6bca started rejecting this.

[Bug rtl-optimization/116028] [15 regression] gcc.dg/pr10474.c test failure since r15-1619-g3b9b8d6cfdf593

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Surya Kumari Jangala
:

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

commit r15-2810-g3c67a0fa1dd39a3378deb854a7fef0ff7fe38004
Author: Surya Kumari Jangala 
Date:   Thu Dec 7 22:42:43 2023 -0600

lra: emit caller-save register spills before call insn [PR116028]

LRA emits insns to save caller-save registers in the
inheritance/splitting pass. In this pass, LRA builds EBBs (Extended
Basic Block) and traverses the insns in the EBBs in reverse order from
the last insn to the first insn. When LRA sees a write to a pseudo (that
has been assigned a caller-save register), and there is a read following
the write, with an intervening call insn between the write and read,
then LRA generates a spill immediately after the write and a restore
immediately before the read. The spill is needed because the call insn
will clobber the caller-save register.

If there is a write insn and a call insn in two separate BBs but
belonging to the same EBB, the spill insn gets generated in the BB
containing the write insn. If the write insn is in the entry BB, then
the spill insn that is generated in the entry BB prevents shrink wrap
from happening. This is because the spill insn references the stack
pointer and hence the prolog gets generated in the entry BB itself.

This patch ensures the the spill insn is generated before the call insn
instead of after the write. This also ensures that the spill occurs
only in the path containing the call.

2024-08-01  Surya Kumari Jangala  

gcc:
PR rtl-optimization/116028
* lra-constraints.cc (split_reg): Spill register before call
insn.
(latest_call_insn): New variable.
(inherit_in_ebb): Track the latest call insn.

gcc/testsuite:
PR rtl-optimization/116028
* gcc.dg/ira-shrinkwrap-prep-1.c: Remove xfail for powerpc.
* gcc.dg/pr10474.c: Remove xfail for powerpc.

[Bug c++/116281] Comma operator used in the middle operand of a conditional expression is incorrectly rejected in non static data member initializer

[schwab--- via Gcc-bugs]

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

--- Comment #3 from Andreas Schwab  ---
In other contexts where the comma has a special meaning like function call
arguments the expression is accepted.

[Bug c/116284] New: incorrect classification of zero-sized array as variably modified

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 116284
   Summary: incorrect classification of zero-sized array as
variably modified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

In the following example we can an error because 'd' is classified as variably
modified.

static int a[0];
static int b[sizeof a];

void foo(int (*x)[*]);

static int c[0];
static int d[sizeof c];


:11:12: error: variably modified 'd' at file scope
   11 | static int d[sizeof c];

https://godbolt.org/z/a8Ej6c5jr



Found by Alejandro Colomar.

[Bug tree-optimization/116258] PAREN_EXPR lowering for vectors is bad

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-2811-g5aa4cd913e48cfce3ca0ab58cf6f80f55dbb0f58
Author: Richard Biener 
Date:   Thu Aug 8 09:35:42 2024 +0200

tree-optimization/116258 - fix i386 testcase

With -march=cascadelake we use vpermilps instead of shufps.

PR tree-optimization/116258
* gcc.target/i386/pr116258.c: Also allow vpermilps.

[Bug c/116016] enhancement: add __builtin_set_counted_by(P->FAM, COUNT) or equivalent

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #66 from Alejandro Colomar  ---
(In reply to Kees Cook from comment #65)
> (In reply to Alejandro Colomar from comment #64)
> > How about having two macros?  One that works for non-attributed pointers,
> > and other that works for attributed ones.  And use the appropriate one for
> > each of them.
> > 
> > If you accidentally use the one that uses the builtin, it'll cause a
> > compiler error.
> 
> No, that's exactly what I am trying avoid. There should be no additional
> work needed beyond adding "counted_by" to the struct.

Hmmm, I understand.

> 
> > alloc_no_attribute() would work everywhere, and alloc() only where the
> > attribute is used.
> 
> We are actively trying to reduce the number of duplicate APIs. The compiler
> has everything it needs to do this without duplicating an API.
> 
> > You could still do this with my approach.  And there are less NULL pointers
> > around, which would get messy.
> 
> I disagree: all the NULL checks are constant and removed at compile time.

I wasn't worried about the run-time performance.  I'm worried about the
complexity it adds.  You're forcing all users of this builtin to do NULL checks
before using it.

However, if you have compile-time errors, a user that does not have the same
needs as the kernel will be able to do the 2 APIs approach.  Or even say, one
uses the attribute already everywhere (e.g., the kernel in a near future where
all code has been adapted), so has a single API, which uses the builtin, and
they want to make sure no new code is added that doesn't have the attribute.  A
compiler error would easily show bugs like that, while NULL checks would just
silence it.

So, an alternative, which would support both my and your constraints would be
to request Clang to implement __builtin_has_attribute() *and* have a compiler
error if __builtin_set_counted_by is used on a pointer that doesn't have it, I
think.

> There is literally no benefit at all to having 2 APIs. :)

[Bug tree-optimization/91940] __builtin_bswap16 loop optimization

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

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

--- Comment #12 from Jorn Wolfgang Rennecke  ---
(In reply to Jakub Jelinek from comment #11)

But the condition I quoted rejects the recognition of a bswap16 with
non-promoted
arguments.
vectorizable_bswap doesn't do anything for processors that don't have byte
vectors,
even if they have support for shifts, or and bswap16 for V2HI vectors.
As it is, the test just fails.

If I change the test in vect_recog_rotate_pattern to:

 || TYPE_PRECISION (type) < 16

I get an expansion with shifts and or, which a combiner splitter pattern can
transform into a bswapv2hi2 .

[Bug tree-optimization/116166] [13/14 Regression] risc-v (last) insn-emit-nn.c build takes hours

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

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

--- Comment #28 from Richard Biener  ---
(In reply to Mark Wielaard from comment #27)
> With gcc-15-2794-g5b97d1a most insn-*.cc files compile in minutes.
> The only exception is insn-recog.cc which takes 85 minutes (1 hour 25
> minutes).
> 
> Time variable   usr   sys 
> wall   GGC
[...]
>  TOTAL  :4977.01152.84   5153.57
> 5635M
> 
> It is one large (19MB) file on risc-v. There is a bug #116146 to split it up.

I'll note this is a flat profile and definitely a different "bug" (if one
at all).  I'll also note that once functions cross a certain size boundary
some data structures fall out of caches and you'll observe a general slowdown
everywhere - that's of course more pronounced on cache-starved implementations.

It might be interesting to have statistics on function sizes in
insn-recog.cc to see if there's any outliers - if it's just very many
there's nothing to do but split the file up.

> grep ^static insn-recog.cc  | wc -l
2404

so it's not obvious it's just many (that would make each function ~250 lines).

[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file

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

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

--- Comment #15 from Richard Biener  ---
The testcase is a bit unwieldly for developing a fix - I wonder if it's
possible to auto-generate smaller testcases with the same structure?

[Bug ipa/116191] Avoid inlining in unlikely branches

[ilija.tovilo at me dot com via Gcc-bugs]

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

--- Comment #5 from ilija.tovilo  ---
That's true ofc, but if you look at the example:

__attribute__((cold)) extern void cold_func(void);

Simply removing the cold attribute will cause zend_string_release() to be
inlined, so it is indeed involved in inlining heuristics in some way.

[Bug target/116280] [15 Regression] RISC-V: expected mode RVVMF8QI for operand 2 of insn pred_vwsllrvvmf4hi but got mode RVVMF2SI

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |15.0

[Bug target/116282] [15 Regression] RISC-V rv64id_zba_zbkb ICE: could not split insn

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/116283] [15 Regression] RISC-V rv64id_zbs ICE: unrecognizable insn

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug testsuite/116271] [15 regression] gcc.dg/vect/tsvc/vect-tsvc-s176.c fails after r15-2777-g8fac69a2dbff98

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug rtl-optimization/116273] [14/15 regression] RISC-V: gcc.dg/long_branch.c flakey timeout, insn scheduling is slow

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
   Target Milestone|--- |14.3
 Target||riscv
   Keywords||compile-time-hog,
   ||testsuite-fail
 CC||jiwang at gcc dot gnu.org
Summary|[14/15 regression] RISC-V:  |[14/15 regression] RISC-V:
   |gcc.dg/long_branch.c flakey |gcc.dg/long_branch.c flakey
   |timeout |timeout, insn scheduling is
   ||slow

--- Comment #1 from Richard Biener  ---
There's

/* { dg-skip-if "limited code space" { pdp11-*-* } } */
/* { dg-timeout-factor 4.0 { target hppa*-*-* } } */

so it's expected to compile slowly on some archs.

Note that on x86 a compiler built with -O0 and checking enabled builds
the testcase in less than 10 seconds.

It might be worth investigating why it's so slow in the postcommit ci
(that runs simulated?).

A x86->riscv cross (same -O0 and checking) builds the testcase in
30s so there does seem to be a significant overhead for targeting risc-v here.

What stands out is

 scheduling :  20.20 ( 66%)

with -fno-schedule-insns it's a lot faster.  Enabling -fschedule-insns
on x86 we observe a similar slowdown.

The testcase was introduced in r5-6853-g096e8448caeeb8 with a aarch64
change that doesn't indicate why such a large testcase is necessary
(and no PR reference).

[Bug c++/116285] New: Compilation of nodejs/v8 8_base_without_compiler.runtime-temporal.cc is slow

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

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

Bug ID: 116285
   Summary: Compilation of nodejs/v8
8_base_without_compiler.runtime-temporal.cc is slow
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

We're currently looking at nodejs taking a while longer (~8 minutes) to build
with GCC than Clang. I'm going to report some other testcases later which have
some different properties (and are far more pronounced) and will give more
background there.

This one feels kind of standalone and different to the others not yet reported.

On trunk with --enable-checking=release:
```
$ time /tmp/bisect-gcc-pfx/bin/g++ -c
v8_base_without_compiler.runtime-temporal.ii -O0 -march=znver1 -std=gnu++20
-ftime-report
In file included from ../../deps/v8/src/objects/contexts.h:9,
 from ../../deps/v8/src/execution/thread-local-top.h:13,
 from ../../deps/v8/src/execution/isolate-data.h:12,
 from ../../deps/v8/src/execution/isolate.h:29,
 from ../../deps/v8/src/execution/isolate-inl.h:8,
 from ../../deps/v8/src/runtime/runtime-temporal.cc:5:
../../deps/v8/src/objects/fixed-array.h:615:41: warning: template-id not
allowed for constructor in C++20 [-Wtemplate-id-cdtor]
../../deps/v8/src/objects/fixed-array.h:615:41: note: remove the '< >'
../../deps/v8/src/objects/fixed-array.h:615:212: warning: template-id not
allowed for constructor in C++20 [-Wtemplate-id-cdtor]
../../deps/v8/src/objects/fixed-array.h:615:212: note: remove the '< >'
../../deps/v8/src/objects/fixed-array.h:672:32: warning: template-id not
allowed for constructor in C++20 [-Wtemplate-id-cdtor]
../../deps/v8/src/objects/fixed-array.h:672:32: note: remove the '< >'
../../deps/v8/src/objects/fixed-array.h:672:194: warning: template-id not
allowed for constructor in C++20 [-Wtemplate-id-cdtor]
../../deps/v8/src/objects/fixed-array.h:672:194: note: remove the '< >'

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 2171k (  0%)
 phase parsing  :   5.11 ( 89%)   1.14 ( 93%)   6.28 ( 90%)
  625M ( 89%)
 phase lang. deferred   :   0.53 (  9%)   0.08 (  7%)   0.61 (  9%)
   66M (  9%)
 phase opt and generate :   0.09 (  2%)   0.00 (  0%)   0.10 (  1%)
 9987k (  1%)
 |name lookup   :   1.04 ( 18%)   0.19 ( 16%)   1.25 ( 18%)
   24M (  3%)
 |overload resolution   :   1.32 ( 23%)   0.22 ( 18%)   1.37 ( 20%)
  101M ( 14%)
 garbage collection :   0.38 (  7%)   0.00 (  0%)   0.38 (  5%)
0  (  0%)
 callgraph construction :   0.08 (  1%)   0.00 (  0%)   0.07 (  1%)
 7630k (  1%)
 callgraph ipa passes   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  647k (  0%)
 trivially dead code:   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
0  (  0%)
 preprocessing  :   0.19 (  3%)   0.18 ( 15%)   0.34 (  5%)
 5702k (  1%)
 parser (global):   0.74 ( 13%)   0.28 ( 23%)   1.01 ( 14%)
  128M ( 18%)
 parser struct body :   0.73 ( 13%)   0.14 ( 11%)   0.99 ( 14%)
   98M ( 14%)
 parser enumerator list :   0.02 (  0%)   0.00 (  0%)   0.04 (  1%)
 2465k (  0%)
 parser function body   :   0.05 (  1%)   0.02 (  2%)   0.09 (  1%)
 5367k (  1%)
 parser inl. func. body :   0.75 ( 13%)   0.12 ( 10%)   0.96 ( 14%)
   68M ( 10%)
 parser inl. meth. body :   0.31 (  5%)   0.08 (  7%)   0.41 (  6%)
   40M (  6%)
 template instantiation :   1.99 ( 35%)   0.39 ( 32%)   2.19 ( 31%)
  340M ( 48%)
 constant expression evaluation :   0.48 (  8%)   0.01 (  1%)   0.46 (  7%)
 2297k (  0%)
 tree operand scan  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  147k (  0%)
 varconst   :   0.00 (  0%)   0.00 (  0%)   0.02 (  0%)
   58k (  0%)
 integrated RA  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  866k (  0%)
 final  :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
   60k (  0%)
 TOTAL  :   5.73  1.22  7.00   
  703M

real0m7.076s
user0m5.741s
sys 0m1.298s

$ time /tmp/bisect-gcc-pfx/bin/g++ -c
v8_base_without_compiler.runtime-temporal.ii -O2 -march=znver1 -std=gnu++20
-ftime-report
In file included from ../../deps/v8/src/objects/contexts.h:9,
 from ../../deps/v8/src/execution/thread-local-top.h:13,
 from ../../deps/v8/src/execution/isolate-data.h:12,
 from ../../deps/v8/src/execution

[Bug c++/116285] Compilation of nodejs/v8 8_base_without_compiler.runtime-temporal.cc is slow

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

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

--- Comment #1 from Sam James  ---
Created attachment 58866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58866&action=edit
v8_base_without_compiler.runtime-temporal.ii

[Bug target/116274] [14/15 Regression] x86: poor code generation with 16 byte function arguments and addition

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
t.c:2:35: note: Cost model analysis: 
_1 + _2 1 times scalar_stmt costs 4 in body
a.x 1 times scalar_load costs 12 in body
a.y 1 times scalar_load costs 12 in body 
a.x 1 times unaligned_load (misalign -1) costs 12 in body
_1 + _2 1 times vector_stmt costs 4 in body
_1 + _2 1 times vec_perm costs 4 in body 
_1 + _2 1 times vec_to_scalar costs 4 in body
_1 + _2 0 times scalar_stmt costs 0 in body
t.c:2:35: note: Cost model analysis for part in loop 0:
  Vector cost: 24
  Scalar cost: 28
t.c:2:35: note: Basic block will be vectorized using SLP

It's vectorizer costing not knowing that a.y and a.x are readily available
in registers and thus the cost of 24 for the two loads doesn't exist.

On the vector side there's the issue that we spill.  We are expanding from

  vect__1.5_5 = MEM  [(long int *)&a];
  _6 = VIEW_CONVERT_EXPR(vect__1.5_5);
  _7 = .REDUC_PLUS (_6); [tail call]
  _8 = (long int) _7;
  return _8;

;; _7 = .REDUC_PLUS (_6); [tail call]

(insn 10 9 11 (set (reg:V1TI 108)
(lshiftrt:V1TI (subreg:V1TI (reg/v:TI 102 [ a ]) 0)
(const_int 64 [0x40]))) -1
 (nil))

(insn 11 10 12 (set (reg:V2DI 107)
(subreg:V2DI (reg:V1TI 108) 0)) -1
 (nil))

(insn 12 11 13 (set (reg:V2DI 106)
(plus:V2DI (reg:V2DI 107)
(subreg:V2DI (reg/v:TI 102 [ a ]) 0))) -1
 (nil))

(insn 13 12 0 (set (reg:DI 100 [ _7 ])
(vec_select:DI (reg:V2DI 106)
(parallel [
(const_int 0 [0])
]))) -1
 (nil))

that's not unreasonable.  Note we set up TI 102 like

(insn 2 8 3 2 (set (reg:DI 104)
(reg:DI 5 di [ a ])) "t.c":2:23 -1
 (nil))
(insn 3 2 4 2 (set (reg:DI 105)
(reg:DI 4 si [ a+8 ])) "t.c":2:23 -1
 (nil))
(insn 4 3 5 2 (set (reg:TI 103)
(zero_extend:TI (reg:DI 104))) "t.c":2:23 -1
 (nil))
(insn 5 4 6 2 (set (reg:TI 103)
(ior:TI (and:TI (reg:TI 103)
(const_wide_int 0x0))
(ashift:TI (zero_extend:TI (reg:DI 105))
(const_int 64 [0x40] "t.c":2:23 -1
 (nil))
(insn 6 5 7 2 (set (reg/v:TI 102 [ a ])
(reg:TI 103)) "t.c":2:23 -1
 (nil))

and the task is to "recover" from the back-and-forth.  Unfortunately
combine fails:

Trying 5, 10 -> 12:
5: r103:TI=zero_extend(r111:DI)<<0x40|zero_extend(r110:DI)
  REG_DEAD r111:DI
  REG_DEAD r110:DI
   10: r108:V1TI=r103:TI#0 0>>0x40
   12: r106:V2DI=r108:V1TI#0+r103:TI#0
  REG_DEAD r108:V1TI
  REG_DEAD r103:TI
Failed to match this instruction: 
(set (reg:V2DI 106)
(plus:V2DI (subreg:V2DI (lshiftrt:V1TI (subreg:V1TI (ior:TI (ashift:TI
(zero_extend:TI (reg:DI 111))
(const_int 64 [0x40]))
(zero_extend:TI (reg:DI 110))) 0)
(const_int 64 [0x40])) 0)
(subreg:V2DI (ior:TI (ashift:TI (zero_extend:TI (reg:DI 111))
(const_int 64 [0x40]))
(zero_extend:TI (reg:DI 110))) 0)))

why we end up spilling or in the end STV2 doesn't help or what exactly
the reason is neither combine nor late-combine nor forwprop help isn't clear.

Of course the vectorizer costing is off here - load/store cost is dominating
it in general and I've mentioned decreasing the load/store costing compared
to the arithmetic stmt costing.

Still I would expect RTL optimizations to recover from this failure and
re-surrect the scalar add of the incoming register arguments.

Roger is very good at analyzing this stuff, so CCing him.

The regression is because the target now exposes the two-lane V2DImode
reduc_plus pattern (if that were fed by a much larger sequence of
vectorizable arithmetic it should be a win).

[Bug c++/115744] [C++26] P2747R2 - constexpr placement new

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

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

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

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

commit r15-2815-gafa3a4a52cf91485477e4aaa5f05987ec7ff869d
Author: Jakub Jelinek 
Date:   Thu Aug 8 11:05:36 2024 +0200

c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new
[PR115744]

With the PR115754 fix in, constexpr placement new mostly just works,
so this patch just adds constexpr keyword to the placement new operators
in , adds FTMs and testsuite coverage.

There is one accepts-invalid though, the
new (p + 1) int[]{2, 3};  // error (in this paper)
case from the paper.  Can we handle that incrementally?
The problem with that is I think calling operator new now that it is
constexpr should be fine even in that case in constant expressions, so
int *p = std::allocator{}.allocate(3);
int *q = operator new[] (sizeof (int) * 2, p + 1);
should be ok, so it can't be easily the placement new operator call
itself on whose constexpr evaluation we try something special, it should
be on the new expression, but constexpr.cc actually sees only
<<< Unknown tree: expr_stmt
  (void) (TARGET_EXPR (b) + 4>>, TARGET_EXPR )>,   int * D.2643;
  <<< Unknown tree: expr_stmt
(void) (D.2643 = (int *) D.2642) >>>;
and that is just fine by the preexisting constexpr evaluation rules.

Should build_new_1 emit some extra cast for the array cases with placement
new in maybe_constexpr_fn (current_function_decl) that the existing P2738
code would catch?

2024-08-08  Jakub Jelinek  

PR c++/115744
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Change __cpp_constexpr
from 202306L to 202406L for C++26.
gcc/testsuite/
* g++.dg/cpp2a/construct_at.h (operator new, operator new[]):
Use constexpr instead of inline if __cpp_constexpr >= 202406L.
* g++.dg/cpp26/constexpr-new1.C: New test.
* g++.dg/cpp26/constexpr-new2.C: New test.
* g++.dg/cpp26/constexpr-new3.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_constexpr): Adjust expected
value.
libstdc++-v3/
* libsupc++/new (__glibcxx_want_constexpr_new): Define before
including bits/version.h.
(_GLIBCXX_PLACEMENT_CONSTEXPR): Define.
(operator new, operator new[]): Use it for placement new instead
of inline.
* include/bits/version.def (constexpr_new): New FTM.
* include/bits/version.h: Regenerate.

[Bug c++/115744] [C++26] P2747R2 - constexpr placement new

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/115754] [14 Regression] C++26 ICE on constexpr new

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

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

Bug 115744 Summary: [C++26] P2747R2 - constexpr placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744

   What|Removed |Added

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

[Bug c++/110338] Implement C++26 language features

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

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

Bug 115744 Summary: [C++26] P2747R2 - constexpr placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744

   What|Removed |Added

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

[Bug c++/115744] [C++26] P2747R2 - constexpr placement new

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/116286] New: Compilation of nodejs/v8 v8_turboshaft.csa-optimize-phase.cc is slow

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

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

Bug ID: 116286
   Summary: Compilation of nodejs/v8
v8_turboshaft.csa-optimize-phase.cc is slow
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Clang takes about the same time to build the non-preprocessed version of this,
so maybe it's unavoidable.

It's fine if there's nothing to be done here.

On releases/gcc-13 with --enable-checking=release:
```
$ time /tmp/bisect-gcc-pfx/bin/g++ -c v8_turboshaft.csa-optimize-phase.ii -O2
-march=znver2 -std=gnu++20 -ftime-report -c -w
Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)
 2151k (  0%)
 phase parsing  :  11.90 ( 25%)   2.33 ( 45%)  14.28 ( 27%)
 1359M ( 38%)
 phase lang. deferred   :   5.23 ( 11%)   0.66 ( 13%)   5.92 ( 11%)
  556M ( 16%)
 phase opt and generate :  30.34 ( 64%)   2.23 ( 43%)  32.71 ( 62%)
 1633M ( 46%)
 |name lookup   :   4.31 (  9%)   0.55 ( 11%)   4.76 (  9%)
   53M (  2%)
 |overload resolution   :   6.17 ( 13%)   0.74 ( 14%)   7.07 ( 13%)
  525M ( 15%)
 garbage collection :   2.39 (  5%)   0.00 (  0%)   2.39 (  5%)
0  (  0%)
 dump files :   0.43 (  1%)   0.04 (  1%)   0.58 (  1%)
0  (  0%)
 callgraph construction :   0.79 (  2%)   0.06 (  1%)   0.69 (  1%)
   66M (  2%)
 callgraph optimization :   0.82 (  2%)   0.12 (  2%)   0.97 (  2%)
 1360k (  0%)
 callgraph functions expansion  :  19.26 ( 41%)   0.80 ( 15%)  20.15 ( 38%)
  703M ( 20%)
 callgraph ipa passes   :   9.58 ( 20%)   1.25 ( 24%)  10.87 ( 21%)
  630M ( 18%)
 ipa function summary   :   0.13 (  0%)   0.01 (  0%)   0.17 (  0%)
10201k (  0%)
 ipa dead code removal  :   0.05 (  0%)   0.00 (  0%)   0.05 (  0%)
0  (  0%)
 ipa inheritance graph  :   0.01 (  0%)   0.00 (  0%)   0.02 (  0%)
   27k (  0%)
 ipa cp :   0.17 (  0%)   0.01 (  0%)   0.15 (  0%)
 9702k (  0%)
 ipa inlining heuristics:   0.34 (  1%)   0.00 (  0%)   0.38 (  1%)
   29M (  1%)
 ipa function splitting :   0.04 (  0%)   0.00 (  0%)   0.09 (  0%)
 1082k (  0%)
 ipa comdats:   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
0  (  0%)
 ipa reference  :   0.03 (  0%)   0.00 (  0%)   0.03 (  0%)
0  (  0%)
 ipa pure const :   0.15 (  0%)   0.03 (  1%)   0.22 (  0%)
  394k (  0%)
 ipa icf:   0.11 (  0%)   0.00 (  0%)   0.11 (  0%)
   17k (  0%)
 ipa SRA:   0.11 (  0%)   0.00 (  0%)   0.11 (  0%)
 5722k (  0%)
 ipa free lang data :   0.02 (  0%)   0.00 (  0%)   0.02 (  0%)
0  (  0%)
 ipa free inline summary:   0.02 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 ipa modref :   0.10 (  0%)   0.00 (  0%)   0.11 (  0%)
 6211k (  0%)
 cfg construction   :   0.02 (  0%)   0.00 (  0%)   0.00 (  0%)
 1728k (  0%)
 cfg cleanup:   0.24 (  1%)   0.00 (  0%)   0.23 (  0%)
 4876k (  0%)
 trivially dead code:   0.03 (  0%)   0.00 (  0%)   0.08 (  0%)
0  (  0%)
 df scan insns  :   0.12 (  0%)   0.00 (  0%)   0.07 (  0%)
   58k (  0%)
 df reaching defs   :   0.11 (  0%)   0.00 (  0%)   0.14 (  0%)
0  (  0%)
 df live regs   :   0.53 (  1%)   0.03 (  1%)   0.54 (  1%)
0  (  0%)
 df live&initialized regs   :   0.27 (  1%)   0.00 (  0%)   0.18 (  0%)
0  (  0%)
 df use-def / def-use chains:   0.07 (  0%)   0.00 (  0%)   0.05 (  0%)
0  (  0%)
 df live reg subwords   :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
0  (  0%)
 df reg dead/unused notes   :   0.28 (  1%)   0.01 (  0%)   0.30 (  1%)
 7528k (  0%)
 register information   :   0.03 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 alias analysis :   0.23 (  0%)   0.01 (  0%)   0.30 (  1%)
   20M (  1%)
 alias stmt walking :   0.68 (  1%)   0.09 (  2%)   0.85 (  2%)
 5830k (  0%)
 register scan  :   0.04 (  0%)   0.00 (  0%)   0.01 (  0%)
 1225k (  0%)
 rebuild jump labels:   0.05 (  0%)   0.00 (  0%)   0.10 (  0%)
0  (  0%)
 preprocessing  :   0.41 (  1%)   0.43 (  8%)   0.77 (  1%)
   39M (  1%)
 parser (global):   1.23 (  3%)   0.47 (  9%)   1.75 (  3%)
  235M (  7%)
 parser struct body

[Bug c++/116286] Compilation of nodejs/v8 v8_turboshaft.csa-optimize-phase.cc is slow

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

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

--- Comment #1 from Sam James  ---
https://dev.gentoo.org/~sam/bugs/gcc/116286/v8_turboshaft.csa-optimize-phase.ii.xz

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch since r15-888-gb644126237a1aa

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

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

Sam James  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #4 from Sam James  ---
https://lore.kernel.org/lkml/ea203f8e-8dd4-46f6-ada5-a2bf5ea81...@app.fastmail.com/

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch since r15-888-gb644126237a1aa

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

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

--- Comment #5 from Sam James  ---
(In reply to Sam James from comment #4)
> https://lore.kernel.org/lkml/ea203f8e-8dd4-46f6-ada5-a2bf5ea8185e@app.
> fastmail.com/

.. and the original thread from Sebastian was
https://lore.kernel.org/lkml/20240801152836.xojc9...@linutronix.de/.

[Bug target/116274] [14/15 Regression] x86: poor code generation with 16 byte function arguments and addition

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #3 from Richard Biener  ---
struct a { int x,y,z,w; };
int test(struct a a) { return a.x+a.y+a.z+a.w; }

behaves similarly.

I do have a patch for the vectorizer costing that avoids vectorizing in
these cases.  We will still vectorize

struct a { short a0,a1,a2,a3,a4,a5,a6,a7; };
short test(struct a a) { return a.a0+a.a1+a.a2+a.a3+a.a4+a.a5+a.a6+a.a7; }

generating

test:
.LFB0:
.cfi_startproc
movaps  %xmm1, -24(%rsp)
movq-16(%rsp), %rdx
movq%rdi, %xmm1
movq%rsi, %xmm3
pinsrq  $1, %rdx, %xmm1
punpcklqdq  %xmm3, %xmm1
movaps  %xmm1, -24(%rsp)
movdqa  %xmm1, %xmm2
pinsrq  $1, -16(%rsp), %xmm2
movdqa  %xmm2, %xmm0
psrldq  $8, %xmm0
paddw   %xmm1, %xmm0
movdqa  %xmm0, %xmm1
psrldq  $4, %xmm1
paddw   %xmm1, %xmm0
movdqa  %xmm0, %xmm1
psrldq  $2, %xmm1
paddw   %xmm1, %xmm0
pextrw  $0, %xmm0, %eax
ret

as opposed to

test:
.LFB0:
.cfi_startproc
movl%edi, %eax
movq%rdi, %rdx
sarl$16, %eax
salq$16, %rdx
addl%edi, %eax
sarq$48, %rdx
addl%edx, %eax
sarq$48, %rdi
movl%esi, %edx
addl%edi, %eax
sarl$16, %edx
addl%esi, %eax
addl%edx, %eax
movq%rsi, %rdx
sarq$48, %rsi
salq$16, %rdx
sarq$48, %rdx
addl%edx, %eax
addl%esi, %eax
ret

it still has the odd (dead)

movaps  %xmm1, -24(%rsp)
movq-16(%rsp), %rdx

The

movaps  %xmm1, -24(%rsp)
movdqa  %xmm1, %xmm2
pinsrq  $1, -16(%rsp), %xmm2

codegen is probably an RA/LRA artifact caused by bad instruction constraints
and the refuse to reload to a gpr.  Not sure if a move high to gpr is a thing,
pextrq would work for sure.  But an unpck looks like a better match anyway.

[Bug target/116287] New: __builtin_ia32_bzhi_si() ignores side effects of its arguments

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 116287
   Summary: __builtin_ia32_bzhi_si() ignores side effects of its
arguments
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

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

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

[Bug target/116287] __builtin_ia32_bzhi_si() ignores side effects of its arguments

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/116275] [15 regression] ICE when building llvm-18.1.8 (convert_insn, at config/i386/i386-features.cc:1502)

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #4 from Roger Sayle  ---
Created attachment 58868
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58868&action=edit
proposed patch

Here's my proposed fix (the first of two patches) that resolves the ICE with
the testcase.  The problem is that i386.md has a *extenddi2_doubleword_highpart
pattern on !TARGET_64BIT for noticing that sign-extending a doubleword can be
optimized to just manipulating the highpart.  The STV pass recognizes this as a
candidate, where previously ASHIFTRT of V2DI required AVX512VL, which runs into
problems as the post-reload splitter *extendv2di2_highpart_stv is conditional
on AVX512VL.

The first patch resolves this problem by adding a pre-reload splitter for this
case, called imaginatively called *extendv2di2_highpart_stv_noavx512vl.  This
relies on split1's recursive splitting, so that the generated code for
(x<<8)>>8 in the testcase becomes:

vpsllq  $8, %xmm0, %xmm0
vpsrad  $8, %xmm0, %xmm1
vpsrlq  $8, %xmm0, %xmm0
vpblendd$5, %xmm0, %xmm1, %xmm0

I'll post a follow-up patch (part 2) that provides a better implementation for
this V2DI highpart sign extension, which can be done in 3 insns (taking
advantage of SSE's ability to arithmetic shift right the "highpart"):

vpsllq  $8, %xmm0, %xmm1
vpsrad  $8, %xmm1, %xmm1
vpblendd$5, %xmm0, %xmm1, %xmm0

Sorry for the inconvenience.  In the meantime, -mno-stv can be used as a
workaround.  The bootstrap and regression testing should finish in a little
while.

[Bug target/116275] [15 regression] ICE when building llvm-18.1.8 (convert_insn, at config/i386/i386-features.cc:1502)

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

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

--- Comment #5 from Sam James  ---
Thank you, I'll use that for now, but please don't apologise. I do the testing
because I enjoy it and to help. No harm done.

[Bug c++/116288] New: C++ overloading

[hans.buchmann.wantuch at gmail dot com via Gcc-bugs]

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

Bug ID: 116288
   Summary: C++ overloading
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hans.buchmann.wantuch at gmail dot com
  Target Milestone: ---

Created attachment 58869
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58869&action=edit
generated with -freport-bug

Compiling the code:

-8<-8<-8<-8<-8<
void hex(long unsigned val,unsigned w=0);
void hex(long long unsigned val,unsigned w=0);


void hex(const char key[],unsigned char val);
void hex(const char key[],unsigned short val);
void hex(const char key[],unsigned val);
void hex(const char key[],long unsigned val);
void hex(const char key[],long long unsigned val);
void hex(const char key[],int val);


using Trap=void(*)();

struct Entry
{
 static const unsigned CODE=1;
 const unsigned code[CODE];
 Trap   trap;

 constexpr Entry(Trap trap)
 :code 
 {
  0xd5033fbf,// 0x000  dmb sy
 }
 ,trap(trap){}

 void debug()const
 {
  hex("disht=", (const unsigned char*)(&(trap)) - 
(const unsigned char*)(code));
 }

};

-8<-8<-8<-8<-8<

with:

aarch64-linux-gnu-g++  -freport-bug -c -o bug.o bug.cc

results in:

bug.cc: In member function 'void Entry::debug() const':
bug.cc:35:6: internal compiler error: Segmentation fault
   35 |   hex("disht=", (const unsigned char*)(&(trap)) -
  |   ~~~^~~~
   36 | (const unsigned char*)(code));
  | ~
0x1fa7957 internal_error(char const*, ...)
???:0
0x78ad27 build_new_function_call(tree_node*, vec**, int)
???:0
0x96285d finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x90d9cc c_parse_file()
???:0
0xa17011 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.

Sincerely

Hans Buchmann

[Bug target/115464] [14 Backport] ICE when building libaom on arm64 (neon sve bridge usage with tbl/perm)

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

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

--- Comment #13 from Sam James  ---
Alpine hit this when building libaom w/ gcc-14.2
(https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1473732#L471).

FWIW, I've not hit any other issues on trunk like this, so should be ready to
backport?

[Bug c++/116289] New: [13.3 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

[iamsupermouse at mail dot ru via Gcc-bugs]

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

Bug ID: 116289
   Summary: [13.3 regression] Can't apply decltype to comparison
operators created by spaceship operator for local
classes
   Product: gcc
   Version: 13.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamsupermouse at mail dot ru
  Target Milestone: ---

This bug only affects 13.3. Works fine in 13.2 and in 14.x.
Having this fixed in 13.x branch would be nice, since it affects `std::less{}`.

The following code doesn't compile: (running `g++ -std=c++20`)

https://gcc.godbolt.org/z/bodKevcvc

#include 

int main()
{
struct A
{
int x = 0;
auto operator<=>(const A &) const = default;
};
decltype(A{} < A{}) y;
}

With following error:

In member function 'constexpr auto main()::A::operator<=>(const main()::A&)
const':
cc1plus: error: taking address of an immediate function 'consteval
std::__cmp_cat::__unspec::__unspec(std::__cmp_cat::__unspec*)'

[Bug target/116054] RISCV: RV32: prologue/epilogue degradation

[tommy_murphy at hotmail dot com via Gcc-bugs]

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

Tommy Murphy  changed:

   What|Removed |Added

 CC||tommy_murphy at hotmail dot com

--- Comment #5 from Tommy Murphy  ---
FWIW this comment in the riscv-gnu-toolchain GitHub repo suggests that the
issue only affects RV32 code:

https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1519#issuecomment-2245438452

[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-08
   Priority|P3  |P2
  Known to work||12.4.0, 13.2.0, 14.2.0,
   ||15.0
   Target Milestone|--- |13.4
  Known to fail||13.3.0
Summary|[13.3 regression] Can't |[13 regression] Can't apply
   |apply decltype to   |decltype to comparison
   |comparison operators|operators created by
   |created by spaceship|spaceship operator for
   |operator for local classes  |local classes
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/116287] __builtin_ia32_bzhi_si() ignores side effects of its arguments

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

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

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

Untested fix.

[Bug c++/116288] C++ overloading

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
   Keywords||ice-on-invalid-code

--- Comment #1 from Richard Biener  ---
On x86_64 this doesn't ICE but is rejected:

t.C: In member function ‘void Entry::debug() const’:
t.C:30:6: error: call of overloaded ‘hex(const char [7], long int)’ is
ambiguous
   30 |   hex("disht=", (const unsigned char*)(&(trap)) -
  |   ~~~^~~~
   31 | (const unsigned char*)(code));
  | ~

I can't reproduce the crash with a cross to aarch64 on trunk either.

[Bug c++/116286] Compilation of nodejs/v8 v8_turboshaft.csa-optimize-phase.cc is slow

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

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

--- Comment #2 from Richard Biener  ---
 template instantiation :   8.85 ( 19%)   1.46 ( 28%)  10.50 ( 20%)
 1147M ( 32%)
 |overload resolution   :   6.17 ( 13%)   0.74 ( 14%)   7.07 ( 13%)
  525M ( 15%)
 |name lookup   :   4.31 (  9%)   0.55 ( 11%)   4.76 (  9%)
   53M (  2%)

stand out, so I would guess "well, C++ ...".  The rest is flat, so you
want to generate much code - it takes time.

[Bug c++/116286] Compilation of nodejs/v8 v8_turboshaft.csa-optimize-phase.cc is slow

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

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

--- Comment #3 from Sam James  ---
The context is some nodejs bump imports a massive upgrade of v8 and compared to
clang, we take like 10 minutes longer to build (and gcc build time doubled
between versions). Unfortunately, it looks like it's a bunch of incremental
issues and not any single or even handful of objects taking longer.

C++ is C++ though so I don't mind WONTFIX if this one here isn't really useful.

[Bug c++/116288] C++ overloading

[hans.buchmann.wantuch at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hans Buchmann  ---
I use:
uname -a

Linux buchmann-h 6.10.3-arch1-2 #1 SMP PREEMPT_DYNAMIC Tue, 06 Aug 2024
07:21:19 + x86_64 GNU/Linux

with

pacman -Ss aarch64-linux-gnu-gcc

extra/aarch64-linux-gnu-gcc 14.1.0-1 [installed]
The GNU Compiler Collection - cross compiler for ARM64 target

[Bug c++/116288] C++ overloading

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
The second argument is ptrdiff_t, so on some targets where ptrdiff_t is int it
can be valid (most 32-bit arches), but where it is long int or long long int it
is ambiguous.
The ICE started with r14-6522-gb24c09bfb626271cda345f5a6f0d3a6b6480593d
and got fixed with r15-1292-g7fed7e9bbc57d502e141e079a6be2706bdbd4560
so I think this is a dup of PR115239.

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

[Bug c++/115239] [14 Regression] ICE: Segmentation fault with ambiguous function call in some cases (`const char*` vs `char` with `long` vs `unsigned`) since r14-6522

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hans.buchmann.wantuch@gmail
   ||.com

--- Comment #10 from Jakub Jelinek  ---
*** Bug 116288 has been marked as a duplicate of this bug. ***

[Bug c++/115062] [modules] internal compiler error: in simplify_aggr_init_exp

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r15-2819-g71aebb36174c194231da5f9c7c23f81dbb082ca4
Author: Nathaniel Shead 
Date:   Thu Aug 8 17:52:03 2024 +1000

c++: Propagate TREE_ADDRESSABLE in fixup_type_variants [PR115062]

This has caused issues with modules when an import fills in the
definition of a type already created with a typedef.

PR c++/115062

gcc/cp/ChangeLog:

* class.cc (fixup_type_variants): Propagate TREE_ADDRESSABLE.
(finish_struct_bits): Cleanup now that TREE_ADDRESSABLE is
propagated by fixup_type_variants.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr115062_a.H: New test.
* g++.dg/modules/pr115062_b.H: New test.
* g++.dg/modules/pr115062_c.C: New test.

Signed-off-by: Nathaniel Shead 

[Bug c++/115062] [modules] internal compiler error: in simplify_aggr_init_exp

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |15.0
 Resolution|--- |FIXED

--- Comment #4 from Nathaniel Shead  ---
Fixed for GCC 15.

[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 115062, which changed state.

Bug 115062 Summary: [modules] internal compiler error: in simplify_aggr_init_exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115062

   What|Removed |Added

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

[Bug middle-end/116290] New: [12/13/14/15 regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

Bug ID: 116290
   Summary: [12/13/14/15 regression] -fcompare-debug
-gno-statement-frontiers -O2 failure with
evolution-data-server-3.52.4
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58871&action=edit
camel-message-info.c.i.xz

11 is fine.

```
$ gcc -c
../evolution-data-server-3.52.4_build/src/camel/CMakeFiles/camel.dir/camel-message-info.c.i
-fcompare-debug -gno-statement-frontiers -O2
gcc: error:
../evolution-data-server-3.52.4_build/src/camel/CMakeFiles/camel.dir/camel-message-info.c.i:
‘-fcompare-debug’ failure (length)
```

```

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl,df
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 15.0. p,
commit 767d91209f8983d23caae12e2337eca6c2b5dbdb' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240808 (experimental)
4d44f3fc387815eb232d7757352857993a1d21d9 (Gentoo 15.0. p, commit
767d91209f8983d23caae12e2337eca6c2b5dbdb)
```

[Bug middle-end/116290] [12/13/14/15 regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

--- Comment #1 from Sam James  ---
```
@@ -37036,13 +37036,20 @@
 (int_list:REG_BR_PROB 118111604 (nil)))
  -> 1416)
 (note # 0 0 [bb 12] NOTE_INSN_BASIC_BLOCK)
-(insn:TI # 0 0 12 (set (reg/v/f:DI 4 si [orig:140 label ] [140])
-(reg/f:DI 2 cx [orig:206 part ] [206]))
"/var/tmp/portage/gnome-extra/evolution-data-server-3.52.4/work/evolution-data-server-3.52.4/src/camel/camel-message-info.c":221:9#
{*mov
di_internal}
+(insn:TI # 0 0 12 (set (reg/v/f:DI 4 si [orig:142 label ] [142])
+(reg/f:DI 2 cx [orig:209 part ] [209]))
"/var/tmp/portage/gnome-extra/evolution-data-server-3.52.4/work/evolution-data-server-3.52.4/src/camel/camel-message-info.c":221:9#
{*mov
di_internal}
  (nil))
-(insn # 0 0 12 (set (reg:DI 3 bx [orig:130 D. ] [130])
+(insn # 0 0 12 (set (reg:DI 3 bx [orig:132 D. ] [132])
 (const_int 1 [0x1]))
"/var/tmp/portage/gnome-extra/evolution-data-server-3.52.4/work/evolution-data-server-3.52.4/src/camel/camel-message-info.c":222:16
discrim 1# {*movdi_inter
nal}
  (expr_list:REG_EQUAL (const_int 1 [0x1])
 (nil)))
+(insn # 0 0 12 (parallel [
+(set (reg:DI 42 r14 [orig:129 _32 ] [129])
+(const_int 0 [0]))
+(clobber (reg:CC 17 flags))
+])
"/var/tmp/portage/gnome-extra/evolution-data-server-3.52.4/work/evolution-data-server-3.52.4/src/camel/camel-message-info.c":222:20
discrim 1# {*movdi_xor}
+ (expr_list:REG_UNUSED (reg:CC 17 flags)
+(nil)))
```

[Bug middle-end/116290] [12/13/14/15 regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
   Keywords||compare-debug-failure

[Bug middle-end/116290] [12/13/14/15 regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

--- Comment #2 from Sam James  ---
Reduced:
```
char *camel_message_info_class_intern_init_part;
void g_once_init_enter();
void camel_message_info_class_intern_init() {
  int ii;
  char *label;
  for (; camel_message_info_class_intern_init_part[ii]; ii++)
if (camel_message_info_class_intern_init_part) {
  if (label && *label)
g_once_init_enter();
  label = &camel_message_info_class_intern_init_part[ii + 1];
  camel_message_info_class_intern_init_part[ii] = ' ';
}
  if (label)
g_once_init_enter();
}
```

[Bug middle-end/116290] [12/13/14/15 regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

--- Comment #3 from Jakub Jelinek  ---
Looks like ivopts.
In message_info_load, ivopts dumps are the first ones to contain differences
like
[local count: 955630198]:
-  # _172 = PHI <_32(59), 0(56)>
   # _173 = PHI <_33(59), label_117(56)>
   # _174 = PHI <_34(59), _169(56)>
   # label_179 = PHI 
-  # ivtmp.411_35 = PHI 
+  # ivtmp.410_35 = PHI 
+  _172 = ivtmp.410_35 + 18446744073709551615;
and
[local count: 324914271]:
   part.22_28 = part;
-  _29 = _172 + 1;
+  _29 = ivtmp.410_35;
   label_124 = part.22_28 + _29;
and
   part.24_31 = part;
-  _32 = ivtmp.411_35;
+  _32 = ivtmp.410_35;
   _33 = part.24_31 + _32;
   _34 = *_33;
-  ivtmp.411_57 = ivtmp.411_35 + 1;
+  ivtmp.410_57 = ivtmp.410_35 + 1;
I only see added # DEBUG lines in slp1.

[Bug middle-end/116290] [12/13/14/15 regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
On the reduced testcase, it started with
r12-4283-g6f966f06146be7689af471d152e18ff50c609d99

Anyway, even on the reduced testcase, slp1 difference is:
--- pr116290.c.186t.slp12024-08-08 15:31:49.607906949 +0200
+++ pr116290.gk.c.186t.slp1 2024-08-08 15:31:49.658906270 +0200
@@ -21,6 +21,8 @@ void camel_message_info_class_intern_ini
   sizetype _32;

[local count: 118111598]:
+  # DEBUG label => label_17(D)
+  # DEBUG ii => ii_16(D)
   camel_message_info_class_intern_init_part.3_27 =
camel_message_info_class_intern_init_part;
   _28 = (sizetype) ii_16(D);
   _29 = camel_message_info_class_intern_init_part.3_27 + _28;
@@ -37,6 +39,8 @@ void camel_message_info_class_intern_ini
   # _32 = PHI <_6(13), _28(12)>
   # ii_33 = PHI 
   # label_34 = PHI 
+  # DEBUG label => label_34
+  # DEBUG ii => ii_33
   if (camel_message_info_class_intern_init_part.3_31 != 0B)
 goto ; [70.00%]
   else
@@ -73,12 +77,16 @@ void camel_message_info_class_intern_ini
   camel_message_info_class_intern_init_part.1_2 =
camel_message_info_class_intern_init_part;
   _3 = _32 + 1;
   label_21 = camel_message_info_class_intern_init_part.1_2 + _3;
+  # DEBUG label => label_21
   _4 = camel_message_info_class_intern_init_part.1_2 + _32;
   *_4 = 32;

[local count: 955630226]:
   # label_10 = PHI 
+  # DEBUG label => label_10
   ii_23 = ii_33 + 1;
+  # DEBUG label => label_10
+  # DEBUG ii => ii_23
   camel_message_info_class_intern_init_part.3_5 =
camel_message_info_class_intern_init_part;
   _6 = (sizetype) ii_23;
   _7 = camel_message_info_class_intern_init_part.3_5 + _6;
while ivopts difference is:
@@ -260,7 +316,7 @@ Candidate 5:

 void camel_message_info_class_intern_init ()
 {
-  sizetype ivtmp.12;
+  sizetype ivtmp.10;
   char * label;
   int ii;
   char _1;
@@ -280,6 +336,8 @@ void camel_message_info_class_intern_ini
   sizetype _32;

[local count: 118111598]:
+  # DEBUG label => label_17(D)
+  # DEBUG ii => ii_16(D)
   camel_message_info_class_intern_init_part.3_27 =
camel_message_info_class_intern_init_part;
   _28 = (sizetype) ii_16(D);
   _29 = camel_message_info_class_intern_init_part.3_27 + _28;
@@ -291,13 +349,15 @@ void camel_message_info_class_intern_ini

[local count: 105119322]:
   _11 = (sizetype) ii_16(D);
-  ivtmp.12_14 = _11 + 1;
+  ivtmp.10_14 = _11 + 1;

[local count: 955630224]:
   # camel_message_info_class_intern_init_part.3_31 = PHI

-  # _32 = PHI <_6(13), _28(12)>
   # label_34 = PHI 
-  # ivtmp.12_25 = PHI 
+  # ivtmp.10_25 = PHI 
+  _32 = ivtmp.10_25 + 18446744073709551615;
+  # DEBUG label => label_34
+  # DEBUG ii => (int) (((unsigned int) ii_16(D) - (unsigned int) ((sizetype)
ii_16(D) + 1)) + (unsigned int) ivtmp.10_25)
   if (camel_message_info_class_intern_init_part.3_31 != 0B)
 goto ; [70.00%]
   else
@@ -332,18 +392,22 @@ void camel_message_info_class_intern_ini

[local count: 668941161]:
   camel_message_info_class_intern_init_part.1_2 =
camel_message_info_class_intern_init_part;
-  _3 = _32 + 1;
+  _3 = ivtmp.10_25;
   label_21 = camel_message_info_class_intern_init_part.1_2 + _3;
+  # DEBUG label => label_21
   _4 = camel_message_info_class_intern_init_part.1_2 + _32;
   *_4 = 32;

[local count: 955630226]:
   # label_10 = PHI 
+  # DEBUG label => label_10
+  # DEBUG label => label_10
+  # DEBUG ii => (int) unsigned int) ii_16(D) - (unsigned int) ((sizetype)
ii_16(D) + 1)) + (unsigned int) ivtmp.10_25) + 1)
   camel_message_info_class_intern_init_part.3_5 =
camel_message_info_class_intern_init_part;
-  _6 = ivtmp.12_25;
+  _6 = ivtmp.10_25;
   _7 = camel_message_info_class_intern_init_part.3_5 + _6;
   _8 = *_7;
-  ivtmp.12_24 = ivtmp.12_25 + 1;
+  ivtmp.10_24 = ivtmp.10_25 + 1;
   if (_8 != 0)
 goto ; [89.00%]
   else

[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #2 from Patrick Palka  ---
Seems we first started rejecting this after the  change r14-3302,
which exposed a consteval bug in the frontend, and this bug was later fixed by
the consteval refactoring r14-4140.

r14-3302 was later backported for GCC 13.3 as r13-7739, but r14-4140 wasn't
(and doesn't seem suitable for backporting).

[Bug target/116240] RISC-V: ICE during RTL pass: combine with -fwrapv -march=rv64imv_xtheadcondmov_xventanacondops at -O2

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

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

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

https://gcc.gnu.org/g:190ad81282057b0e5884fd30a7270356b9b1

commit r15-2821-g190ad81282057b0e5884fd30a7270356b9b1
Author: Jeff Law 
Date:   Thu Aug 8 07:42:26 2024 -0600

[RISC-V][PR target/116240] Ensure object is a comparison before extracting
arguments

This was supposed to go out the door yesterday, but I kept getting
interrupted.

The target bits for rtx costing can't assume the rtl they're given actually
matches a target pattern.   It's just kind of inherent in how the costing
routines get called in various places.

In this particular case we're trying to cost a conditional move:

(set (dest) (if_then_else (cond) (true) (false))

On the RISC-V port the backend only allows actual conditionals for COND. 
So
something like (eq (reg) (const_int 0)).  In the costing code for
if-then-else
we did something like

(XEXP (XEXP (cond, 0), 0)))

Which fails miserably if COND is a terminal node like (reg) rather than (ne
(reg) (const_int 0)

So this patch tightens up the RTL scanning to ensure that we have a
comparison
before we start looking at the comparison's arguments.

Run through my tester without incident, but I'll wait for the pre-commit
tester
to run through a cycle before pushing to the trunk.

Jeff

ps.   We probably could support a naked REG for the condition and
internally convert it to (ne (reg) (const_int 0)), but I don't think it likely
happens with any regularity.

PR target/116240
gcc/
* config/riscv/riscv.cc (riscv_rtx_costs): Ensure object is a
comparison before looking at its arguments.

gcc/testsuite
* gcc.target/riscv/pr116240.c: New test.

[Bug target/116240] RISC-V: ICE during RTL pass: combine with -fwrapv -march=rv64imv_xtheadcondmov_xventanacondops at -O2

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug c++/116291] New: ICE on non-existent module-mapper directory

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

mtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240808 (experimental)
4d44f3fc387815eb232d7757352857993a1d21d9 (Gentoo 15.0. p, commit
767d91209f8983d23caae12e2337eca6c2b5dbdb)
```

[Bug fortran/116292] New: [15 regression] ICE on invalid reduction

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

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

Bug ID: 116292
   Summary: [15 regression] ICE on invalid reduction
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

I hit this when reducing another bug.

```
character, allocatable:: buffer
contains
subroutine format_subsequent_line
character, allocatable :: dummy
if ( remain <= max_width ) then
if ( index_ == count ) then
if ( new_len_buffer > len0 ) then
call move_alloc( dummy, buffer )
end if
end if
end if
end
end
```

```
$ gfortran-15 stdlib_logger.f90-pp.f90
stdlib_logger.f90-pp.f90:8:56:

8 | call move_alloc( dummy, buffer )
  |1
internal compiler error: in build_function_decl, at fortran/trans-decl.cc:2486
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
```

[Bug fortran/116292] [15 regression] ICE on invalid reduction

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

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

--- Comment #1 from Sam James  ---
It's also accepted by <15.

[Bug c++/115806] [12/13/14/15 Regression] No error for member enum redefinition in class template (even after instantiation)

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #3 from Simon Martin  ---
I'm working on this one.

[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|accepts-invalid,|
   |ice-on-invalid-code |
Summary|[15 regression] ICE on  |[15 regression] ICE in
   |invalid reduction   |build_function_decl, at
   ||fortran/trans-decl.cc:2486

--- Comment #2 from Sam James  ---
Actually, maybe it's not even invalid. I don't know Fortran ;)

[Bug c++/116293] New: ICE when failing to open module mapper (error: unknown Compiled Module Interface: no such module)

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

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

Bug ID: 116293
   Summary: ICE when failing to open module mapper (error: unknown
Compiled Module Interface: no such module)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58873&action=edit
vulkan.cppm.ii.xz

I hit this as well as PR116291 when running a command in the wrong directory.

```
$ g++ -MF /tmp/i-do-not-exist/vulkan.cppm.o.d -fmodules-ts
-fmodule-mapper=/tmp/i-do-not-exist -c vulkan.cppm  -MD
vulkan.cppm: error: failed opening mapper ‘/tmp/i-do-not-exist’
vulkan.cppm:20:8: error: unknown Compiled Module Interface: no such module
   20 | export module vulkan_hpp;
  |^
vulkan.cppm:4888:1: internal compiler error: Segmentation fault
 4888 | }  // namespace VULKAN_HPP_NAMESPACE
  | ^
0x55bb8c50138c internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:491
0x55bb8bd80e8d crash_signal
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:321
0x55bb8c662bcd xstrdup
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./libiberty/xstrdup.c:33
0x55bb8c58db5c deps_add_module_target(mkdeps*, char const*, char const*, bool,
bool)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./libcpp/mkdeps.cc:362
0x55bb8bbab398 preprocessed_module(cpp_reader*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/module.cc:20446
0x55bb8ac36bd0 module_token_cdtor(cpp_reader*, unsigned long)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/lex.cc:582
0x55bb8ac91109 cp_lexer_new_main
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/parser.cc:769
0x55bb8ac91109 c_parse_file()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cp/parser.cc:51816
0x55bb8cfd14bb c_common_parse_file()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/c-family/c-opts.cc:1315
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl,df
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 15.0. p,
commit 767d91209f8983d23caae12e2337eca6c2b5dbdb' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240808 (experimental)
4d44f3fc387815eb232d7757352857993a1d21d9 (Gentoo 15.0. p, commit
767d91209f8983d23caae12e2337eca6c2b5dbdb)
```

[Bug tree-optimization/116166] [13/14 Regression] risc-v (last) insn-emit-nn.c build takes hours

[andi at firstfloor dot org via Gcc-bugs]

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

--- Comment #29 from andi at firstfloor dot org ---
> It might be interesting to have statistics on function sizes in
> insn-recog.cc to see if there's any outliers - if it's just very many
> there's nothing to do but split the file up.

Or LTO doing it for you.

[Bug rtl-optimization/116028] [15 regression] gcc.dg/pr10474.c test failure since r15-1619-g3b9b8d6cfdf593

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

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

Surya Kumari Jangala  changed:

   What|Removed |Added

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

--- Comment #9 from Surya Kumari Jangala  ---
Fixed in r15-2810-g3c67a0fa1dd39a

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #146 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #145)
> There is no real error message coming from the compiler itself though. Maybe
> the patches don't fully work with gcc-14?

Same problem with gcc-15.

[Bug target/116283] [15 Regression] RISC-V rv64id_zbs ICE: unrecognizable insn

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-08
 Status|UNCONFIRMED |NEW
 CC||law at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/115806] [12/13/14/15 Regression] No error for member enum redefinition in class template (even after instantiation)

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

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

--- Comment #4 from Simon Martin  ---
This started to fail with
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=557831a91df947b447fc9fd94ecad02470a3c86a

[Bug middle-end/116294] New: -O2 -gno-statement-frontiers -fcompare-debug failure when building duktape-2.7.0

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

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

Bug ID: 116294
   Summary: -O2 -gno-statement-frontiers -fcompare-debug failure
when building duktape-2.7.0
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

```
$ gcc ../duktape-2.7.0/libduktaped.so.207.20700-duktape.i -c -fcompare-debug
-O2 -gno-statement-frontiers
gcc: error: ../duktape-2.7.0/libduktaped.so.207.20700-duktape.i:
‘-fcompare-debug’ failure (length)
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl,df
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 15.0. p,
commit 767d91209f8983d23caae12e2337eca6c2b5dbdb' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240808 (experimental)
4d44f3fc387815eb232d7757352857993a1d21d9 (Gentoo 15.0. p, commit
767d91209f8983d23caae12e2337eca6c2b5dbdb)
```

[Bug middle-end/116294] -O2 -gno-statement-frontiers -fcompare-debug failure when building duktape-2.7.0

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

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

--- Comment #1 from Sam James  ---
I'm reducing it.

[Bug middle-end/116294] -O2 -gno-statement-frontiers -fcompare-debug failure when building duktape-2.7.0

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

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

--- Comment #2 from Sam James  ---
Created attachment 58874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58874&action=edit
libduktaped.so.207.20700-duktape.i.xz

[Bug ipa/96265] offloading to nvptx-none from aarch64-linux-gnu (and riscv*-linux-gnu) does not work

[j.reuter--- via Gcc-bugs]

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

--- Comment #9 from Jan André Reuter  ---
Thanks a lot for the patch Prathamesh Kulkarni. There seems to be some
progress, which is great to see!

I've tried your patch. I applied it to the latest snapshot and also to GCC
14.2.0 and GCC 14.1.0 to see what happens. In general, all three versions seem
to come a bit further towards getting offloading to work. The GCC 15 snapshot
seems closest, but now fails with an unknown argument error. In all cases, I
built GCC with the EasyBlock of Easybuild, though I'm not sure if that's the
cause why the flag is here.

GCC 14.2.0 (built with EasyBuild, applied patch):


```console
$ gcc -fopenmp -foffload=nvptx-none test.c
lto1: internal compiler error: in lto_read_decls, at lto/lto-common.cc:1970
0x68110f lto_read_decls
../.././gcc/lto/lto-common.cc:1970
0x68110f lto_file_finalize
../.././gcc/lto/lto-common.cc:2292
0x68110f lto_create_files_from_ids
../.././gcc/lto/lto-common.cc:2302
0x68110f lto_file_read
../.././gcc/lto/lto-common.cc:2357
0x68110f read_cgraph_and_symbols(unsigned int, char const**)
../.././gcc/lto/lto-common.cc:2805
0x66b13f lto_main()
../.././gcc/lto/lto.cc:656
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.
nvptx mkoffload: fatal error: aarch64-unknown-linux-gnu-accel-nvptx-none-gcc
returned 1 exit status
compilation terminated.
lto-wrapper: fatal error:
/p/usersoftware/cstpa/reuter1/EasyBuild/easybuild/jedi/software/GCCcore/14.2.0/libexec/gcc/aarch64-unknown-linux-gnu/14.2.0//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

---

GCC 14.1.0 (built with EasyBuild, applied patch):


```console
$ gcc -fopenmp -foffload=nvptx-none test.c
lto1: internal compiler error: in lto_read_decls, at lto/lto-common.cc:1970
0x680eaf lto_read_decls
../.././gcc/lto/lto-common.cc:1970
0x680eaf lto_file_finalize
../.././gcc/lto/lto-common.cc:2292
0x680eaf lto_create_files_from_ids
../.././gcc/lto/lto-common.cc:2302
0x680eaf lto_file_read
../.././gcc/lto/lto-common.cc:2357
0x680eaf read_cgraph_and_symbols(unsigned int, char const**)
../.././gcc/lto/lto-common.cc:2805
0x66aebf lto_main()
../.././gcc/lto/lto.cc:656
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.
nvptx mkoffload: fatal error: aarch64-unknown-linux-gnu-accel-nvptx-none-gcc
returned 1 exit status
compilation terminated.
lto-wrapper: fatal error:
/p/usersoftware/cstpa/reuter1/EasyBuild/easybuild/jedi/software/GCCcore/14.1.0/libexec/gcc/aarch64-unknown-linux-gnu/14.1.0//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

```

Execution no longer segmentation faults, but compilation still fails in LTO. No
changes from 14.1.0 to 14.2.0.

---

GCC 15.0.0 (gcc-15-20240804, built with EasyBuild using adapted GCC 14.2.0
EasyConfig and the patch applied):


```console
$ gcc -fopenmp -foffload=nvptx-none test.c
gcc: error: unrecognized command-line option ‘-m64’
nvptx mkoffload: fatal error: gcc returned 1 exit status
compilation terminated.
lto-wrapper: fatal error:
/p/usersoftware/cstpa/reuter1/EasyBuild/easybuild/jedi/software/GCCcore/15.0.0/libexec/gcc/aarch64-unknown-linux-gnu/15.0.0//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ gcc --version
gcc (GCC) 15.0.0 20240804 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

[Bug ipa/96265] offloading to nvptx-none from aarch64-linux-gnu (and riscv*-linux-gnu) does not work

[j.reuter--- via Gcc-bugs]

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

--- Comment #10 from Jan André Reuter  ---
Created attachment 58875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58875&action=edit
Verbose compile output after rebuilding the latest GCC snapshot with the patch
applied

New error message when trying to build OpenMP offload code on aarch64 with the
latest GCC snapshot and the patch applied.

The build mainly failed due to 'unrecognized command-line option ‘-m64’'.

[Bug target/116283] [15 Regression] RISC-V rv64id_zbs ICE: unrecognizable insn

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

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

--- Comment #1 from Jeffrey A. Law  ---
Code is a bit nonsensical in that it masks a shift by a crazy value (3629), but
the underlying bug is real.  Ultimately we're going to rely on the fact that
hardware truncates the count (mask with 0x3f) and since we're shifting a SImode
value, we really just care about 0x1f.  So we can just mask off undesirable
bits.

Initial testing in flight.

[Bug ipa/96265] offloading to nvptx-none from aarch64-linux-gnu (and riscv*-linux-gnu) does not work

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

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

--- Comment #11 from prathamesh3492 at gcc dot gnu.org ---
Hi,
Yes, those two errors are expected.
I posted RFC discussion about AArch64/nvptx offloading issues here:
https://gcc.gnu.org/pipermail/gcc/2024-July/244466.html

For the unrecognized command line -m64 option, I have a WIP patch posted
upstream:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659866.html

Thanks,
Prathamesh

[Bug c++/107637] [C++23] P2718R0 - Final Fix of Broken Range‐based for Loop

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

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

--- Comment #2 from Jakub Jelinek  ---
Adjusted testcase so that it also verifies what is destructed first, S vs. T in
the various cases and standards:

// P2718R0 - Wording for P2644R1 Fix for Range-based for Loop
// { dg-do run { target c++11 } }

extern "C" void abort ();
void check (bool);

struct S
{
  S () { ++s; }
  S (const S &) { ++s; }
  ~S () { check (true); --s; }
  static int s;
};
int S::s;
struct T
{
  T (const S &, const S &) { ++t; }
  T (const T &) { ++t; }
  ~T () { check (false); --t; }
  static int t;
};
int T::t;
int a[4];
int c;

void
check (bool is_s)
{
  if (c)
{
  if (is_s)
{
  if (T::t != (c == 1))
abort ();
}
  else
{
  if (S::s != (c == 1 ? 0 : 2))
abort ();
}
}
}

int *
begin (const S &)
{
  return &a[0];
}

int *
end (const S &)
{
  return &a[4];
}

int *
begin (const T &)
{
  return &a[0];
}

int *
end (const T &)
{
  return &a[4];
}

const S &
foo (const S &x)
{
  return x;
}

const T &
foo (const T &x)
{
  return x;
}

int
main ()
{
  if (S::s != 0)
abort ();
  for (auto x : S ())
{
  if (S::s != 1)
abort ();
}
  if (S::s != 0)
abort ();
  for (auto x : foo (S ()))
{
  if (S::s != (__cpp_range_based_for >= 202211L))
abort ();
}
  if (S::s != 0)
abort ();
  if (T::t != 0)
abort ();
  c = 1 + (__cpp_range_based_for >= 202211L);
  for (auto x : T (S (), S ()))
{
  if (S::s != 2 * (__cpp_range_based_for >= 202211L) || T::t != 1)
abort ();
}
  if (S::s != 0 || T::t != 0)
abort ();
  c = 2;
  for (auto x : foo (T (S (), S (
{
  if (S::s != 2 * (__cpp_range_based_for >= 202211L)
  || T::t != (__cpp_range_based_for >= 202211L))
abort ();
}
  if (S::s != 0 || T::t != 0)
abort ();
}

[Bug tree-optimization/90839] Detect lsb ones counting loop (final value replacement?)

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

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

Andrew Carlotti  changed:

   What|Removed |Added

 CC||acarlotti at gcc dot gnu.org

--- Comment #5 from Andrew Carlotti  ---
This pattern is recognized for unsigned induction variables as of
r13-5193-gd347fbf774dc50. For signed induction variables the loop might be
infinite (if the induction variable is negative), so the code in
tree-ssa-loop-niter:is_rshift_by_1() currently ignores this case.

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch since r15-888-gb644126237a1aa

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

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

--- Comment #6 from H.J. Lu  ---
Created attachment 58876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58876&action=edit
A patch

Here is a patch.  Hongtao, please take a look and add a testcase.  Thanks.

[Bug ipa/116296] New: [15 Regression] internal compiler error: in merge, at ipa-modref-tree.cc:176 at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 116296
   Summary: [15 Regression] internal compiler error: in merge, at
ipa-modref-tree.cc:176 at -O3
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
short c;
#define d(a, b)   
\
  {   
\
__typeof__(a) e = a;  
\
__typeof__(b) f = b;  
\
e > f;
\
  }
void g(int h, int i[11][11]) {
  for (unsigned long j = 0; j < h; j += -6380968575470960909)
c = (d(c, 1 ? i[j][j] : 0));
}

Command/backtrace:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -O3 func.c
during GIMPLE pass: modref
func.c: In function 'g':
func.c:8:6: internal compiler error: in merge, at ipa-modref-tree.cc:176
8 | void g(int h, int i[11][11]) {
  |  ^
0x2de60b5 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:491
0xc50a02 fancy_abort(char const*, int, char const*)
../../../gcc/gcc/diagnostic.cc:1772
0xaabea3 modref_access_node::merge(modref_access_node const&, bool)
../../../gcc/gcc/ipa-modref-tree.cc:176
0x10eee54 modref_access_node::try_merge_with(vec*&, unsigned long)
../../../gcc/gcc/ipa-modref-tree.cc:457
0x10f0cbc modref_access_node::insert(vec*&, modref_access_node, unsigned long, bool)
../../../gcc/gcc/ipa-modref-tree.cc:562
0x10eb903 modref_ref_node::insert_access(modref_access_node, unsigned
long, bool)
../../../gcc/gcc/ipa-modref-tree.h:194
0x10eb903 modref_tree::insert(unsigned int, unsigned int, unsigned int,
int, int, modref_access_node, bool)
../../../gcc/gcc/ipa-modref-tree.h:444
0x10dded8 modref_tree::insert(tree_node*, int, int, modref_access_node
const&, bool)
../../../gcc/gcc/ipa-modref-tree.h:471
0x10dded8 record_access
../../../gcc/gcc/ipa-modref.cc:1078
0x10dea68 analyze_load
../../../gcc/gcc/ipa-modref.cc:1715
0x1023c14 walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
../../../gcc/gcc/gimple-walk.cc:824
0x10e4f01 analyze_stmt
../../../gcc/gcc/ipa-modref.cc:1796
0x10e6749 analyze
../../../gcc/gcc/ipa-modref.cc:1908
0x10e6749 analyze_function
../../../gcc/gcc/ipa-modref.cc:3233
0x10e81be execute
../../../gcc/gcc/ipa-modref.cc:4254
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.

Godbolts
RISC-V: https://godbolt.org/z/EPPhnPdY5
X86: https://godbolt.org/z/3odEoMd6s
ARM: https://godbolt.org/z/vdaGcqxc5

[Bug target/116295] [avr] unrecognizable insn when loading from address-space __flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||addr-space,
   ||ice-on-valid-code
   Assignee|unassigned at gcc dot gnu.org  |gjl at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-08-08
 Ever confirmed|0   |1
 Target||avr
   Target Milestone|--- |15.0

[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

[iamsupermouse at mail dot ru via Gcc-bugs]

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

--- Comment #3 from Egor  ---
(In reply to Patrick Palka from comment #2)
> r14-4140 ... doesn't seem suitable for backporting

Fair enough. What's the procedure now, should I set status=resolved?

[Bug target/116295] [avr] unrecognizable insn when loading from address-space __flash

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

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

commit r15-2838-gc4d3dba253b49fb0e8e32109783f76453bc53653
Author: Georg-Johann Lay 
Date:   Thu Aug 8 18:31:16 2024 +0200

AVR: target/116295 - Fix unrecognizable insn with __flash read.

Some loads from non-generic address-spaces are performed by
libgcc calls, and they don't have a POST_INC form.  Don't consider
such insns when running -mfuse-add.

 PR target/116295
gcc/
* config/avr/avr.cc (Mem_Insn::Mem_Insn): Don't consider MEMs
that are avr_mem_memx_p or avr_load_libgcc_p.

gcc/testsuite/
* gcc.target/avr/torture/pr116295.c: New test.

[Bug target/116295] New: [avr] unrecognizable insn when loading from address-space __flash

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

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

Bug ID: 116295
   Summary: [avr] unrecognizable insn when loading from
address-space __flash
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58877&action=edit
ice-flash.c: GNU-C99 test case

long val;

const __flash long* load4_flash (const __flash long *p)
{
val += *p++;
val += *p++;
return p;
}

triggers an ICE when compiled with

$ avr-gcc ice-flash.c -S -Os

It occurs in some situations when a value from __flash is loaded:

* The device has no LPMx instruction.
* More then 2 bytes are loaded.
* Pass mfuse-add finds an optimization opportunity.

The bug can be worked around with -mno-fuse-add.

ice-flash.c: In function 'load4_flash':
ice-flash.c:8:1: error: unrecognizable insn:
8 | }
  | ^
(insn 52 36 9 2 (parallel [
(set (reg:SI 22 r22)
(mem:SI (post_inc:HI (reg:HI 30 r30)) [1  S4 A8 AS1]))
(clobber (reg:CC 36 cc))
]) "ice-flash.c":5:9 -1
 (expr_list:REG_UNUSED (reg:CC 36 cc)
(expr_list:REG_INC (reg:HI 30 r30)
(nil
during RTL pass: cprop_hardreg
ice-flash.c:8:1: internal compiler error: in extract_insn, at recog.cc:2848

[Bug target/116295] [avr] unrecognizable insn when loading from address-space __flash

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
:

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

commit r14-10573-g9ca1d7a36abecee7da387ceb1c07d77eaad15927
Author: Georg-Johann Lay 
Date:   Thu Aug 8 18:31:16 2024 +0200

AVR: target/116295 - Fix unrecognizable insn with __flash read.

Some loads from non-generic address-spaces are performed by
libgcc calls, and they don't have a POST_INC form.  Don't consider
such insns when running -mfuse-add.

PR target/116295
gcc/
* config/avr/avr.cc (Mem_Insn::Mem_Insn): Don't consider MEMs
that are avr_mem_memx_p or avr_load_libgcc_p.

gcc/testsuite/
* gcc.target/avr/torture/pr116295.c: New test.

(cherry picked from commit c4d3dba253b49fb0e8e32109783f76453bc53653)

[Bug target/116295] [avr] unrecognizable insn when loading from address-space __flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #3 from Georg-Johann Lay  ---
Fixed in v14.3+

[Bug testsuite/116271] [15 regression] gcc.dg/vect/tsvc/vect-tsvc-s176.c fails after r15-2777-g8fac69a2dbff98

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I tried that patch and it seems to work just fine:

make  -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/tsvc/vect-tsvc-s176.c"
# of expected passes6

[Bug target/116229] [15 Regression] wrong code at -Ofast aarch64 due to missing fneg to generate 0x8000000000000000

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:2c24e0568392e51a77ebdaab629d631969ce8966

commit r15-2839-g2c24e0568392e51a77ebdaab629d631969ce8966
Author: Tamar Christina 
Date:   Thu Aug 8 18:51:30 2024 +0100

AArch64: Fix signbit mask creation after late combine [PR116229]

The optimization to generate a Di signbit constant by using fneg was
relying
on nothing being able to push the constant into the negate.  It's run quite
late for this reason.

However late combine now runs after it and triggers RTL simplification
based on
the neg.  When -fno-signed-zeros this ends up dropping the - from the -0.0
and
thus producing incorrect code.

This change adds a new unspec FNEG on DI mode which prevents this
simplication.

gcc/ChangeLog:

PR target/116229
* config/aarch64/aarch64-simd.md (aarch64_fnegv2di2):
New.
* config/aarch64/aarch64.cc (aarch64_maybe_generate_simd_constant):
Update call to gen_aarch64_fnegv2di2.
* config/aarch64/iterators.md: New UNSPEC_FNEG.

gcc/testsuite/ChangeLog:

PR target/116229
* gcc.target/aarch64/pr116229.c: New test.

[Bug target/116229] [15 Regression] wrong code at -Ofast aarch64 due to missing fneg to generate 0x8000000000000000

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
Fixed, thanks for the report!

[Bug c++/116297] New: ICE on using default spaceship comparison operator inside requires

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 116297
   Summary: ICE on using default spaceship comparison operator
inside requires
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

Building of this valid program (accepted in Clang and MSVC)
```
#include 

int main() {
struct A {
auto operator<=>(const A &) const = default;
void f() {
static_assert( requires { A{} <=> A{}; } );
}
};
}
```
results in

internal compiler error: in maybe_push_to_top_level, at cp/name-lookup.cc:8679
7 | static_assert( requires { A{} <=> A{}; } );
  | ^
0x202ef4c internal_error(char const*, ...)
???:0
0x778915 fancy_abort(char const*, int, char const*)
???:0
0x86b86e synthesize_method(tree_node*)
???:0
0x8331be mark_used(tree_node*, int)
???:0
0x7a50e0 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0x98a7a2 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0x90e414 c_parse_file()
???:0
0xa0c4d9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.

Online demo: https://gcc.godbolt.org/z/Ko5911fPh

[Bug testsuite/116041] aarch64 fallout from removing vcond{,u,eq} patterns

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

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

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

https://gcc.gnu.org/g:7223c64745530db102a160d5a1db4c2c8d2b9fe1

commit r15-2840-g7223c64745530db102a160d5a1db4c2c8d2b9fe1
Author: Andrew Pinski 
Date:   Tue Aug 6 16:00:02 2024 -0700

aarch64/testsuite: Fix if-compare_2.c for removing vcond{,u,eq} patterns
[PR116041]

For bar1 and bar2, we currently is expecting to use the bsl instruction but
with slightly different register allocation inside the loop (which happens
after
the removal of the vcond{,u,eq} patterns), we get the bit instruction.  The
pattern that
outputs bsl instruction will output bit and bif too depending register
allocation.

So let's check for bsl, bit or bif instructions instead of just bsl
instruction.

Tested on aarch64 both with an unmodified compiler and one which has the
patch to disable
these optabs.

gcc/testsuite/ChangeLog:

PR testsuite/116041
* gcc.target/aarch64/if-compare_2.c: Support bit and bif for
both bar1 and bar2; add comment on why too.

Signed-off-by: Andrew Pinski 

[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #3 from kargls at comcast dot net ---
Well, the code is massively invalid, so technically gfortran can do
anything, which includes dying with an ICE.  On amd64-*-freebsd,
the code compiles and even executes!  (I suppose I should reconfig
gcc with --enable-checking.)

All of the variables are undefined, so cannot appear in the expressions.
Neither dummy nor buffer are allocated, so cannot appear in move_alloc().
A Fortran compiler is not required to diagnose this for a programmer.

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

Bug 116041 Summary: aarch64 fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116041

   What|Removed |Added

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

[Bug testsuite/116041] aarch64 fallout from removing vcond{,u,eq} patterns

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c++/116297] ICE on using default spaceship comparison operator inside requires

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-08-08
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Even GCC 10 ICEs.  Probably not a regression.

[Bug c++/107637] [C++23] P2718R0 - Final Fix of Broken Range‐based for Loop

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 58878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58878&action=edit
gcc15-pr107637-wip.patch

Completely untested WIP patch, with which the above testcase now passes also in
-std=c++23 mode (well, it passed before too, but only because it had the older
FTM value).
Will need to figure out what to do for OpenMP range for loops tomorrow and add
more testsuite coverage.

[Bug c++/116298] New: No error when taking address of overloaded member function template

[rs2740 at gmail dot com via Gcc-bugs]

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

Bug ID: 116298
   Summary: No error when taking address of overloaded member
function template
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

struct X {
template 
E f() const;// #1
template
E f() const;// #2
template 
E f(int) const; // #3
};
auto x = &X::f;


GCC accepts and appears to pick #1. If #2 is removed GCC correctly rejects.

[Bug c++/116289] [13 regression] Can't apply decltype to comparison operators created by spaceship operator for local classes

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113063

--- Comment #4 from Patrick Palka  ---
I think we can still narrowly fix this on the 13 branch.

[Bug c++/116298] No error when taking address of overloaded function template

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

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. Also happens with functions and not just member functions:
```
template 
  E f() ;// #1
template
  E f() ;// #2
template 
  E f(int) ; // #3
auto x = &f;
```

[Bug c++/116298] No error when taking address of overloaded function template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2024-08-08
   Keywords||ice-on-valid-code
 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Priority|P3  |P4

--- Comment #4 from anlauf at gcc dot gnu.org ---
Confirmed.

Reduced testcase:

program p
  character, allocatable :: buffer, dummy
contains
  subroutine s
call move_alloc (dummy, buffer)
  end
end

% gfc-15 pr116292.f90

pr116292.f90:5:35:

5 | call move_alloc (dummy, buffer)
  |   1
internal compiler error: in build_function_decl, at fortran/trans-decl.cc:2486
0x24a0a76 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:491
0x9799d6 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1772
0x75758c build_function_decl
../../gcc-trunk/gcc/fortran/trans-decl.cc:2486
0xac17bc gfc_get_symbol_decl(gfc_symbol*)
../../gcc-trunk/gcc/fortran/trans-decl.cc:1861
0xadfe3e gfc_conv_variable
../../gcc-trunk/gcc/fortran/trans-expr.cc:3155
0xa8 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-trunk/gcc/fortran/trans-expr.cc:8912
0xade1dd gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-trunk/gcc/fortran/trans-expr.cc:9857
0xaddcef gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-trunk/gcc/fortran/trans-expr.cc:8927
0xac11db gfc_get_symbol_decl(gfc_symbol*)
../../gcc-trunk/gcc/fortran/trans-decl.cc:2031
0xb00d5d conv_intrinsic_move_alloc
../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12769
0xb00d5d gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12918
0xa8e752 trans_code
../../gcc-trunk/gcc/fortran/trans.cc:2425
0xac5b24 gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.cc:7961
0xac58dc gfc_generate_contained_functions
../../gcc-trunk/gcc/fortran/trans-decl.cc:6076
0xac58dc gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.cc:7893
0xa3615f translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:7132
0xa3615f gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7446
0xa8b3cf gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:241