[Bug testsuite/119489] g++.dg/strub-internal-pr112938.C test fails once fixed to actually run

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
(In reply to Sam James from comment #2)
> Fixed the dump issue. Not sure what to do about the volatile C++26 complaint.

You could add -Wno-volatile to the dg-options or use dg-prune-output to remove
that line from the output.

[Bug c++/116960] ICE: Error reporting routines re-entered

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||stevenxia990430 at gmail dot 
com

--- Comment #3 from Marek Polacek  ---
*** Bug 110242 has been marked as a duplicate of this bug. ***

[Bug middle-end/112938] ice with -fstrub=internal

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

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

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

https://gcc.gnu.org/g:50f8148a2754a1552704c6852c336ad008695388

commit r15-8988-g50f8148a2754a1552704c6852c336ad008695388
Author: Jakub Jelinek 
Date:   Thu Mar 27 21:21:48 2025 +0100

testsuite: Fix up strub-internal-pr112938.C test for C++2{0,3,6}

On Thu, Mar 27, 2025 at 12:05:21AM +, Sam James wrote:
> The test was being ignored because dg.exp looks for .C in g++.dg/.
>
> gcc/testsuite/ChangeLog:
>   PR middle-end/112938
>
>   * g++.dg/strub-internal-pr112938.cc: Move to...
>   * g++.dg/strub-internal-pr112938.C: ...here.

This regressed the test for C++20 and higher:
FAIL: g++.dg/strub-internal-pr112938.C  -std=gnu++20 (test for excess
errors)
FAIL: g++.dg/strub-internal-pr112938.C  -std=gnu++23 (test for excess
errors)
FAIL: g++.dg/strub-internal-pr112938.C  -std=gnu++26 (test for excess
errors)

Here is a fix.

2025-03-27  Jakub Jelinek  

* g++.dg/strub-internal-pr112938.C: Add dg-warning for c++20.

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

[schulz.benjamin at googlemail dot com via Gcc-bugs]

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

--- Comment #13 from Benjamin Schulz  ---
Hi many thanks for the effort.
Sorry for the late reply. In desperation, by now I have tried to switch my code
to openmp entirely and compile it with clang... But openacc has more
parallelization levels (gang,loop, vector) as openmp since simd on gpu does not
work with clang. Also, I found the teams distribute keyword of openmp very
restrictive since once this appears, the code can not have commands between
#pragma omp target and #pragma omp teams distribute. This makes it difficult
to, do stuff on the target and then write a teams distribute loop on the
device. So i will try openacc again...



I use gentoo. They already have a gcc ebuild of the versions:

https://packages.gentoo.org/packages/sys-devel/gcc

 15.0.  : 15EAPI 8  ?amd64  ?x86?alpha  ?arm?arm64  ?hppa   ?mips  
?ppc?ppc64  ?riscv  ?sparc


15.0.1_pre20250323-r1  : 15EAPI

Since the entire gentoo is compiled everyday with gcc, I suppose I will not
switch to the 15.0. version by now, which is the development code...

I do not know if gcc version 

15.0.1_pre20250323-r1  : 15EAPI

contains the fixes already. If a sufficiently stable version of gcc appears
that contains the fixes which compile my code, i will try them out happily and
convert my code again to open acc when on the device, and use openmp when on
the host, if this brings some speed.

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

[schulz.benjamin at googlemail dot com via Gcc-bugs]

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

--- Comment #14 from Benjamin Schulz  ---
By the way, the numbers are for simple tests and are correct, as for that
segfault in the last test, this may have been an error owned by me. 
But I don't know yet, I guess I must look at my old code again to see why this
appears (The version that I currently have has changed code and no segfault, at
least with clang. I will test everything out once I get my hands on gcc 15.

[Bug libgcc/119151] [13/14 Regression] unwind-dw2-btree maintains separators wrong

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

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

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

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

commit r14-11465-g7fc02fc0150e6b1ddbac68d42db809522124a48b
Author: Jakub Jelinek 
Date:   Mon Mar 10 10:34:00 2025 +0100

libgcc: Fix up unwind-dw2-btree.h [PR119151]

The following testcase shows a bug in unwind-dw2-btree.h.
In short, the header provides lock-free btree data structure (so no parent
link on nodes, both insertion and deletion are done in top-down walks
with some locking of just a few nodes at a time so that lookups can notice
concurrent modifications and retry, non-leaf (inner) nodes contain keys
which are initially the base address of the left-most leaf entry of the
following child (or all ones if there is none) minus one, insertion ensures
balancing of the tree to ensure [d/2, d] entries filled through aggressive
splitting if it sees a full tree while walking, deletion performs various
operations like merging neighbour trees, merging into parent or moving some
nodes from neighbour to the current one).
What differs from the textbook implementations is mostly that the leaf
nodes
don't include just address as a key, but address range, address + size
(where we don't insert any ranges with zero size) and the lookups can be
performed for any address in the [address, address + size) range.  The keys
on inner nodes are still just address-1, so the child covers all nodes
where addr <= key unless it is covered already in children to the left.
The user (static executables or JIT) should always ensure there is no
overlap in between any of the ranges.

In the testcase a bunch of insertions are done, always followed by one
removal, followed by one insertion of a range slightly different from the
removed one.  E.g. in the first case [&code[0x50], &code[0x59]] range
is removed and then we insert [&code[0x4c], &code[0x53]] range instead.
This is valid, it doesn't overlap anything.  But the problem is that some
non-leaf (inner) one used the &code[0x4f] key (after the 11 insertions
completely correctly).  On removal, nothing adjusts the keys on the parent
nodes (it really can't in the top-down only walk, the keys could be many
nodes
above it and unlike insertion, removal only knows the start address,
doesn't
know the removed size and so will discover it only when reaching the leaf
node which contains it; plus even if it knew the address and size, it still
doesn't know what the second left-most leaf node will be (i.e. the one
after
removal)).  And on insertion, if nodes aren't split at a level, nothing
adjusts the inner keys either.  If a range is inserted and is either fully
bellow key (keys are - 1, so having address + size - 1 being equal to key
is
fine) or fully after key (i.e. address > key), it works just fine, but if
the key is in a middle of the range like in this case, &code[0x4f] is in
the
middle of the [&code[0x4c], &code[0x53]] range, then insertion works fine
(we only use size on the leaf nodes), and lookup of the addresses below
the key work fine too (i.e. [&code[0x4c], &code[0x4f]] will succeed).
The problem is with lookups after the key (i.e. [&code[0x50, &code[0x53]]),
the lookup looks for them in different children of the btree and doesn't
find an entry and returns NULL.

As users need to ensure non-overlapping entries at any time, the following
patch fixes it by adjusting keys during insertion where we know not just
the address but also size; if we find during the top-down walk a key
which is in the middle of the range being inserted, we simply increase the
key to be equal to address + size - 1 of the range being inserted.
There can't be any existing leaf nodes overlapping the range in correct
programs and the btree rebalancing done on deletion ensures we don't have
any empty nodes which would also cause problems.

The patch adjusts the keys in two spots, once for the current node being
walked (the last hunk in the header, with large comment trying to explain
it) and once during inner node splitting in a parent node if we'd otherwise
try to add that key in the middle of the range being inserted into the
parent node (in that case it would be missed in the last hunk).
The testcase covers both of those spots, so succeeds with GCC 12 (which
didn't have btrees) and fails with vanilla GCC trunk and also fails if
either the
  if (fence < base + size - 1)
fence = iter->content.children[slot].separator = base + size - 1;
or
  if (left_fence >= target && left_fence < target + size - 1)
left_fence = target + size - 1;
hunk is removed (of course, only with the current node sizes, i.e. up to
15 children of inner nodes an

[Bug testsuite/116163] RFE: add a linting tool for DejaGnu tests

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

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

--- Comment #18 from GCC Commits  ---
The master branch has been updated by David Malcolm :

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

commit r15-8992-g8d6de758cca6d16eb930ac1a7008ee54ec5489d9
Author: David Malcolm 
Date:   Thu Mar 27 19:46:20 2025 -0400

contrib: add dg-lint and libgdiagnostics.py [PR116163]

Changed in v2:
- eliminated COMMON_MISSPELLINGS in favor of retesting with a regexp
  that adds underscores
- add a list of KNOWN_DIRECTIVES, and complain if we see a directive
  that isn't in the list
- various refactorings to reduce the nesting within the script
- skip more kinds of file ('README', 'Makefile.am', 'Makefile.in',
  'gen_directive_tests')
- keep track of the number of files scanned and report it and the end
  with a note

This patch adds a new dg-lint subdirectory below contrib, containing
a "dg-lint" script for detecting common mistakes made in our DejaGnu
tests.

Specifically, DejaGnu's dg.exp's dg-get-options has a regexp for
detecting dg- directives
  https://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=blob;f=lib/dg.exp
here's the current:

set tmp [grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}"
line]

which if I'm reading it right requires a "{", then one or more tab/space
chars, then a "dg-" directive name, then one of more tab/space
characters, then anything (for arguments to the directive), then one of
more tab/space character, then a "}".

There are numerous places in our testsuite which look like attempts to
use a directive, but which don't match this regexp.

The script warns about such places, along with a list of misspelled
directives (currently just "dg_options" for "dg-options"), and a warning
if a dg-do appears after a dg-require-* (as per
https://gcc.gnu.org/onlinedocs/gccint/Directives.html
"This directive must appear after any dg-do directive in the test
and before any dg-additional-sources directive." for
dg-require-effective-target.

dg-lint uses libgdiagnostics to report its results; the patch adds a
new libgdiagnostics.py script below contrib/dg-lint.  This uses Python's
ctypes module to expose libgdianostics.so to Python via FFI.  Hence
the warnings have colorization, quote the pertinent parts of the tested
file, can have fix-it hints, etc.  Here's the output from the tests, run
from the top-level directory:

$ LD_LIBRARY_PATH=../build/gcc/ ./contrib/dg-lint/dg-lint
contrib/dg-lint/test-*.c
contrib/dg-lint/test-1.c:6:6: warning: misspelled directive: 'dg_final';
did you mean 'dg-final'?
6 | /* { dg_final { scan_assembler_times "vmsumudm" 2 } } */
  |  ^~~~
  |  dg-final
contrib/dg-lint/test-1.c:15:4: warning: directive 'dg-output-file' appears
not to match dg.exp's regexp
   15 |dg-output-file "m4.out"
  |^~
contrib/dg-lint/test-1.c:18:4: warning: directive 'dg-output-file' appears
not to match dg.exp's regexp
   18 |dg-output-file "m4.out" }
  |^~
contrib/dg-lint/test-1.c:21:6: warning: directive 'dg-output-file' appears
not to match dg.exp's regexp
   21 |{ dg-output-file "m4.out"
  |  ^~
contrib/dg-lint/test-1.c:24:5: warning: directive 'dg-output-file' appears
not to match dg.exp's regexp
   24 |{dg-output-file "m4.out"}
  | ^~
contrib/dg-lint/test-1.c:27:6: warning: directive 'dg-output-file' appears
not to match dg.exp's regexp
   27 |{ dg-output-file, "m4.out" }
  |  ^~
contrib/dg-lint/test-2.c:4:6: warning: 'dg-do' after
'dg-require-effective-target'
4 | /* { dg-do compile } */
  |  ^
contrib/dg-lint/test-2.c:3:6: note: 'dg-require-effective-target' was here
3 | /* { dg-require-effective-target c++11 } */
  |  ^~~

I don't yet have a way to verify these tests (clearly we can't use
DejaGnu for this).

These Python bindings could be used by other projects, but so far I only
implemented what I needed for dg-lint.

Running the test on the GCC source tree finds dozens of issues, which
followup patches address.

Tested with Python 3.8

contrib/ChangeLog:
PR testsuite/116163
* dg-lint/dg-lint: New file.
* dg-lint/libgdiagnostics.py: New file.
* dg-lint/test-1.c: New file.
* dg-lint/test-2.c: New file.

Signed-off-by: David Malcolm 

[Bug c++/119499] [15 Regression] g++.dg/modules/gmf-xtreme.C fails on aarch64 and arm

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
I'm not seeing this failure on cfarm426 at r15-8989-g2af32814cf2ba3

PASS: g++.dg/modules/gmf-xtreme.C -std=c++2b  scan-lang-dump module "Wrote 0
clusters"
PASS: g++.dg/modules/gmf-xtreme.C -std=c++2b (test for excess errors)
PASS: g++.dg/modules/gmf-xtreme.C module-cmi empty (gcm.cache/empty.gcm)

[Bug c++/119499] [15 Regression] g++.dg/modules/gmf-xtreme.C fails on aarch64 and arm

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Jason Merrill from comment #1)
> I'm not seeing this failure on cfarm426 at r15-8989-g2af32814cf2ba3
> 
> PASS: g++.dg/modules/gmf-xtreme.C -std=c++2b  scan-lang-dump module "Wrote 0
> clusters"
> PASS: g++.dg/modules/gmf-xtreme.C -std=c++2b (test for excess errors)
> PASS: g++.dg/modules/gmf-xtreme.C module-cmi empty (gcm.cache/empty.gcm)

It might depend on the glibc version. Basically it is a dup of bug 108080.

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

[Bug c++/119499] [15 Regression] g++.dg/modules/gmf-xtreme.C fails on aarch64 and arm

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Jason Merrill from comment #1)
> > I'm not seeing this failure on cfarm426 at r15-8989-g2af32814cf2ba3
> > 
> > PASS: g++.dg/modules/gmf-xtreme.C -std=c++2b  scan-lang-dump module "Wrote 0
> > clusters"
> > PASS: g++.dg/modules/gmf-xtreme.C -std=c++2b (test for excess errors)
> > PASS: g++.dg/modules/gmf-xtreme.C module-cmi empty (gcm.cache/empty.gcm)
> 
> It might depend on the glibc version. Basically it is a dup of bug 108080.
> 
> *** This bug has been marked as a duplicate of bug 108080 ***

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111224#c12 .

That is some version of the glibc's math.h includes definitions of vecmath
which are valid for SVE and `#pragma GCC target` is used and that is known to
be broken.

[Bug tree-optimization/118167] Loop invariant is not deduced in C++-iterator-style loop over pointers

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Andrew Macleod  ---
(In reply to Sam James from comment #5)
> I suppose it's a job for prange?

I don't think so. I think it related to integral values being bumped by 1, and
pointer values being bumped by 4.


It seems the ivopts recognizes the bump by one, and turns 

 [local count: 1014686024]:
  # sum_15 = PHI 
  # iter_17 = PHI 
  if (end_8 > iter_17)
goto ; [99.96%]
  else
goto ; [0.04%]

into

[local count: 1014686024]:
  # sum_15 = PHI 
  # iter_17 = PHI 
  if (iter_17 != end_8)
goto ; [99.96%]
  else
goto ; [0.04%]


With pointers,It seems it cannot transform the > into != .. probably out of
conservativeness about the potential +1, +2, and +3 values. (If the starting
values were "end = begin + 3" the transformation to != wouldn't work).With
a bump by 1, it can always be done.


Regardless, this transformation  eventually allows threading and DOM to
simplify a PHI to a copy.  Once its just a copy, its much easier to apply
relations and realize the assert can never trigger. 

blame byte pointers? :-)   

I don't see anything obvious the ranger can pickup on here.   It seems to fall
into the loop analysis field, and requires a guarantee that 'begin' and 'end'
are exactly a multiple of 4 bytes apart.

at least that is what it looks like to me.

[Bug c++/118672] ICE on template lambda expression return a lambda type

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/110242] ICE on valid (decltype with lambda)

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Dup for which I have a fix.

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

[Bug c++/107430] [meta-bug] lambda in decltype

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

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

Bug 110242 Summary: ICE on valid (decltype with lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110242

   What|Removed |Added

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

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Created attachment 60904 [details]
> the musttail patch for GCC 15

This one didn't work for LTO. Back to the board.

[Bug c/119000] [OpenMP] Function parameter incorrectly reported as set but not used.

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

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

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

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

commit r14-11459-gf14094177725948569e54026b57d5f6dd371e80a
Author: Jakub Jelinek 
Date:   Tue Feb 25 09:33:21 2025 +0100

openmp: Mark OpenMP atomic write expression as read [PR119000]

The following testcase was emitting false positive warning that
the rhs of #pragma omp atomic write was stored but not read,
when the atomic actually does read it.  The following patch
fixes that by calling default_function_array_read_conversion
on it, so that it is marked as read as well as converted from
lvalue to rvalue.
Furthermore, the code had
if (code == NOP_EXPR) ... else ... if (code == NOP_EXPR) ...
with none of ... parts changing code, so I've merged the two ifs.

2025-02-25  Jakub Jelinek  

PR c/119000
* c-parser.cc (c_parser_omp_atomic): For omp write call
default_function_array_read_conversion on the rhs expression.
Merge the two adjacent if (code == NOP_EXPR) blocks.

* c-c++-common/gomp/pr119000.c: New test.

(cherry picked from commit cdffc76393488a73671b70481cf8a4b7c289029d)

[Bug tree-optimization/118915] [12/13/14 Regression] Miscompile at -O2 since r5-4218-g73049af5fa62c7

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

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

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

https://gcc.gnu.org/g:0a3a15cd1c00746f1d4154ea1567f0fd33a2d961

commit r14-11458-g0a3a15cd1c00746f1d4154ea1567f0fd33a2d961
Author: Jakub Jelinek 
Date:   Mon Feb 24 12:19:16 2025 +0100

reassoc: Fix up optimize_range_tests_to_bit_test [PR118915]

The following testcase is miscompiled due to a bug in
optimize_range_tests_to_bit_test.  It is trying to optimize
check for a in [-34,-34] or [-26,-26] or [-6,-6] or [-4,inf] ranges.
Another reassoc optimization folds the the test for the first
two ranges into (a + 34U) & ~8U in [0U,0U] range, and extract_bit_test_mask
actually has code to virtually undo it and treat that again as test
for a being -34 or -26.  The problem is that
optimize_range_tests_to_bit_test
remembers in the type variable TREE_TYPE (ranges[i].exp); from the first
range.  If extract_bit_test_mask doesn't do that virtual undoing of the
BIT_AND_EXPR handling, that is just fine, the returned exp is
ranges[i].exp.
But if the first range is BIT_AND_EXPR, the type could be different, the
BIT_AND_EXPR form has the optional cast to corresponding unsigned type
in order to avoid introducing UB.  Now, type was used to fill in the
max value if ranges[j].high was missing in subsequently tested range,
and so in this particular testcase the [-4,inf] range which was
signed int and so [-4,INT_MAX] was treated as [-4,UINT_MAX] instead.
And we were subtracting values of 2 different types and trying to make
sense out of that.

The following patch fixes this by using the type of the low bound
(which is always non-NULL) for the max value of the high bound instead.

2025-02-24  Jakub Jelinek  

PR tree-optimization/118915
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): For
highj == NULL_TREE use TYPE_MAX_VALUE (TREE_TYPE (lowj)) rather
than TYPE_MAX_VALUE (type).

* gcc.c-torture/execute/pr118915.c: New test.

(cherry picked from commit 5806279610783805286ebcd0af3b455602a3a8f9)

[Bug middle-end/115871] [14 Regression] ICE with declare simd since r14-5057

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

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

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

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

commit r14-11462-gfc39a29f75cb181dcefaebf4489303847ae4fe9d
Author: Jakub Jelinek 
Date:   Sat Mar 1 09:15:57 2025 +0100

openmp: Fix up simd clone mask argument creation on x86 [PR115871]

The following testcase ICEs since r14-5057.
The Intel vector ABI says that in the ZMM case the masks is passed
in unsigned int or unsigned long long arguments and how many bits in
them and how many of those arguments are is determined by the
characteristic
data type of the function.  In the testcase simdlen is 32 and
characteristic
data type is double, so return as well as first argument is passed in 4
V8DFmode arguments and the mask is supposed to be passed in 4 unsigned int
arguments (8 bits in each).
Before the r14-5057 change there was
  sc->args[i].orig_type = parm_type;
...
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
case SIMD_CLONE_ARG_TYPE_VECTOR:
  if (INTEGRAL_TYPE_P (parm_type) || POINTER_TYPE_P (parm_type))
veclen = sc->vecsize_int;
  else
veclen = sc->vecsize_float;
  if (known_eq (veclen, 0U))
veclen = sc->simdlen;
  else
veclen
  = exact_div (veclen,
   GET_MODE_BITSIZE (SCALAR_TYPE_MODE
(parm_type)));
for the argument handling and
  if (sc->inbranch)
{
  tree base_type = simd_clone_compute_base_data_type (sc->origin, sc);
...
  if (INTEGRAL_TYPE_P (base_type) || POINTER_TYPE_P (base_type))
veclen = sc->vecsize_int;
  else
veclen = sc->vecsize_float;
  if (known_eq (veclen, 0U))
veclen = sc->simdlen;
  else
veclen = exact_div (veclen,
GET_MODE_BITSIZE (SCALAR_TYPE_MODE
(base_type)));
for the mask handling.  r14-5057 moved this argument creation later and
unified that:
case SIMD_CLONE_ARG_TYPE_MASK:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
case SIMD_CLONE_ARG_TYPE_VECTOR:
  if (sc->args[i].arg_type == SIMD_CLONE_ARG_TYPE_MASK
  && sc->mask_mode != VOIDmode)
elem_type = boolean_type_node;
  else
elem_type = TREE_TYPE (sc->args[i].vector_type);
  if (INTEGRAL_TYPE_P (elem_type) || POINTER_TYPE_P (elem_type))
veclen = sc->vecsize_int;
  else
veclen = sc->vecsize_float;
  if (known_eq (veclen, 0U))
veclen = sc->simdlen;
  else
veclen
  = exact_div (veclen,
   GET_MODE_BITSIZE (SCALAR_TYPE_MODE
(elem_type)));
This is correct for the argument cases (so linear or vector) (though
POINTER_TYPE_P will never appear as TREE_TYPE of a vector), but the
boolean_type_node in there is completely bogus, when using AVX512 integer
masks as I wrote above we need the characteristic data type, not bool,
and bool is strange in that it has bitsize of 8 (or 32 on darwin), while
the masks are 1 bit per lane anyway.

Fixed thusly.

2025-03-01  Jakub Jelinek  

PR middle-end/115871
* omp-simd-clone.cc (simd_clone_adjust): For
SIMD_CLONE_ARG_TYPE_MASK
and sc->mask_mode not VOIDmode, set elem_type to the characteristic
type rather than boolean_type_node.

* gcc.dg/gomp/simd-clones-8.c: New test.

(cherry picked from commit 6589eb4efe39545ec7f7e641e1d302c89b260350)

[Bug target/117642] [12/13/14 Regression] __sync_lock_release() on 128bit integer does not behave according to documentation

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #12 from sandra at gcc dot gnu.org ---
I believe this has been fixed?

[Bug c++/98533] [12/13/14 Regression] ICE when building actiona with -g ('verify_type' failed) with lambda as default (method) argument in a template member function

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

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

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

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

commit r14-11464-g5bb53795e8706c5e229042acdd16d14ebab1bb11
Author: Jakub Jelinek 
Date:   Thu Mar 6 18:26:37 2025 +0100

c++: Update TYPE_FIELDS of variant types if
cp_parser_late_parsing_default_args etc. modify it [PR98533]

The following testcases ICE during type verification, because TYPE_FIELDS
of e.g. S RECORD_TYPE in pr119123.C is different from TYPE_FIELDS of const
S.
Various decls are added to S's TYPE_FIELDS first, then finish_struct
indirectly calls fixup_type_variants to sync the variant copies.
But later on cp_parser_class_specifier calls
cp_parser_late_parsing_default_args and that apparently adds a lambda
type (from default argument) to TYPE_FIELDS of S.
Dunno if that is right or not, assuming it is right, the following
patch fixes it by updating TYPE_FIELDS of variant types if there were
any changes in the various functions cp_parser_class_specifier defers and
calls on the outermost enclosing class.
There was quite a lot of code repetition already before, so the patch
uses a lambda to avoid the repetitions.
To my surprise, in some of the contract testcases (
g++.dg/contracts/contracts-friend1.C
g++.dg/contracts/contracts-nested-class1.C
g++.dg/contracts/contracts-nested-class2.C
g++.dg/contracts/contracts-redecl7.C
g++.dg/contracts/contracts-redecl8.C
) it is actually setting class_type and pushing TRANSLATION_UNIT_DECL
rather than some class types in some cases.

Or should the lambda pushing into the containing class be somehow avoided?

2025-03-06  Jakub Jelinek  

PR c++/98533
PR c++/119123
* parser.cc (cp_parser_class_specifier): Update TYPE_FIELDS of
variant types in case cp_parser_late_parsing_default_args etc.
change
TYPE_FIELDS on the main variant.  Add switch_to_class lambda and
use it to simplify repeated class switching code.

* g++.dg/cpp0x/pr98533.C: New test.
* g++.dg/cpp0x/pr119123.C: New test.

(cherry picked from commit 179e01085b0aed111ef1f7908c4b87c800f880e9)

[Bug c/114870] [13/14 Regression] stddef.h problem with -Wsystem-headers and -std=gnu23 (which is the default since GCC 15)

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

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

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

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

commit r14-11460-ga266e7354bdae713f73c9f356bb15a387fd4d1b4
Author: Jakub Jelinek 
Date:   Wed Feb 26 19:29:12 2025 +0100

c: stddef.h C23 fixes [PR114870]

The stddef.h header for C23 defines __STDC_VERSION_STDDEF_H__ and
unreachable macros multiple times in some cases.
The header doesn't have normal multiple inclusion guard, because it
supports
for glibc inclusion with __need_{size_t,wchar_t,ptrdiff_t,wint_t,NULL}.
While the definition of __STDC_VERSION_STDDEF_H__ and unreachable is done
solely in the #ifdef _STDDEF_H part, so they are defined only if stddef.h
is included without those __need_* macros defined.  But actually once
stddef.h is included without the __need_* macros, _STDDEF_H is then defined
and while further stddef.h includes without __need_* macros don't do
anything:
 #if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) &&
!defined(_ANSI_STDDEF_H) \
  && !defined(__STDDEF_H__)) \
 || defined(__need_wchar_t) || defined(__need_size_t) \
 || defined(__need_ptrdiff_t) || defined(__need_NULL) \
 || defined(__need_wint_t)
if one includes whole stddef.h first and then stddef.h with some of the
__need_* macros defined, the #ifdef _STDDEF_H part is used again.
It isn't that big deal for most cases, as it uses extra guarding macros
like:
 #ifndef _GCC_MAX_ALIGN_T
 #define _GCC_MAX_ALIGN_T
 ...
 #endif
etc., but for __STDC_VERSION_STDDEF_H__/unreachable nothing like that is
used.

So, either we do what the following patch does and just don't define
__STDC_VERSION_STDDEF_H__/unreachable second time, or use #ifndef
unreachable separately for the #define unreachable() case, or use
new _GCC_STDC_VERSION_STDDEF_H macro to guard this (or two, one for
__STDC_VERSION_STDDEF_H__ and one for unreachable), or rework the initial
condition to be just
 #if !defined(_STDDEF_H) && !defined(_STDDEF_H_) &&
!defined(_ANSI_STDDEF_H) \
 && !defined(__STDDEF_H__)
- I really don't understand why the header should do anything at all after
it has been included once without __need_* macros.  But changing how this
behaves after 35 years might be risky for various OS/libc combinations.

2025-02-26  Jakub Jelinek  

PR c/114870
* ginclude/stddef.h (__STDC_VERSION_STDDEF_H__, unreachable): Don't
redefine multiple times if stddef.h is first included without
__need_*
defines and later with them.  Move nullptr_t and unreachable and
__STDC_VERSION_STDDEF_H__ definitions into the same
defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L #if block.

* gcc.dg/c23-stddef-2.c: New test.

(cherry picked from commit 8d22474af76a386eed488b3c66124134f0e41363)

[Bug c++/119123] [12/13/14/15 Regression] ICE when building llvm-20.1.0 with -g

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

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

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

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

commit r14-11464-g5bb53795e8706c5e229042acdd16d14ebab1bb11
Author: Jakub Jelinek 
Date:   Thu Mar 6 18:26:37 2025 +0100

c++: Update TYPE_FIELDS of variant types if
cp_parser_late_parsing_default_args etc. modify it [PR98533]

The following testcases ICE during type verification, because TYPE_FIELDS
of e.g. S RECORD_TYPE in pr119123.C is different from TYPE_FIELDS of const
S.
Various decls are added to S's TYPE_FIELDS first, then finish_struct
indirectly calls fixup_type_variants to sync the variant copies.
But later on cp_parser_class_specifier calls
cp_parser_late_parsing_default_args and that apparently adds a lambda
type (from default argument) to TYPE_FIELDS of S.
Dunno if that is right or not, assuming it is right, the following
patch fixes it by updating TYPE_FIELDS of variant types if there were
any changes in the various functions cp_parser_class_specifier defers and
calls on the outermost enclosing class.
There was quite a lot of code repetition already before, so the patch
uses a lambda to avoid the repetitions.
To my surprise, in some of the contract testcases (
g++.dg/contracts/contracts-friend1.C
g++.dg/contracts/contracts-nested-class1.C
g++.dg/contracts/contracts-nested-class2.C
g++.dg/contracts/contracts-redecl7.C
g++.dg/contracts/contracts-redecl8.C
) it is actually setting class_type and pushing TRANSLATION_UNIT_DECL
rather than some class types in some cases.

Or should the lambda pushing into the containing class be somehow avoided?

2025-03-06  Jakub Jelinek  

PR c++/98533
PR c++/119123
* parser.cc (cp_parser_class_specifier): Update TYPE_FIELDS of
variant types in case cp_parser_late_parsing_default_args etc.
change
TYPE_FIELDS on the main variant.  Add switch_to_class lambda and
use it to simplify repeated class switching code.

* g++.dg/cpp0x/pr98533.C: New test.
* g++.dg/cpp0x/pr119123.C: New test.

(cherry picked from commit 179e01085b0aed111ef1f7908c4b87c800f880e9)

[Bug c++/119045] ICE when using _Complex accessors, in cxx_eval_store_expression, at cp/constexpr.cc:6418

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

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

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

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

commit r14-11461-gab908fdb911d6a337cd02b6018bc74b3a2f99acf
Author: Jakub Jelinek 
Date:   Fri Feb 28 15:22:47 2025 +0100

c++: Fix cxx_eval_store_expression {REAL,IMAG}PART_EXPR handling [PR119045]

I've added the asserts that probe == target because {REAL,IMAG}PART_EXPR
always implies a scalar type and so applying ARRAY_REF/COMPONENT_REF
etc. on it further doesn't make sense and the later code relies on it
to be the last one in refs array.  But as the following testcase shows,
we can fail those assertions in case there is a reference or pointer
to the __real__ or __imag__ part, in that case we just evaluate the
constant expression and so probe won't be the same as target.
That case doesn't push anything into the refs array though.

The following patch changes those asserts to verify that refs is still
empty, which fixes it.

2025-02-28  Jakub Jelinek  

PR c++/119045
* constexpr.cc (cxx_eval_store_expression) :
Assert that refs->is_empty () rather than probe == target.
(cxx_eval_store_expression) : Likewise.

* g++.dg/cpp1y/constexpr-complex2.C: New test.

(cherry picked from commit 7eb8ec1856f71b039d1c2235b1c941934fa28e22)

[Bug tree-optimization/118953] [14 regression] Miscompile at -O2 since r14-2473-g602e824eec30a7

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

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

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

https://gcc.gnu.org/g:375cc5fb9192c433c0f516c9e99786b92d2e9f95

commit r14-11463-g375cc5fb9192c433c0f516c9e99786b92d2e9f95
Author: Jakub Jelinek 
Date:   Wed Mar 5 14:30:35 2025 +0100

value-range: Fix up irange::union_bitmask [PR118953]

The following testcase is miscompiled during evrp.
Before vrp, we have (from ccp):
  # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000
VALUE 0x2d
  _3 = _2 + 18446744073708503085;
...
  # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000
VALUE 0x59
  _6 = (long long unsigned int) _5;
  # RANGE [irange] int [-INF, +INF] MASK 0xc000 VALUE 0x34
  _7 = k_11 + -1048524;
  switch (_7)  [33.33%], case 8:  [33.33%], case 24: 
[33.33%], case 32:  [33.33%]>
...
  # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc07d
VALUE 0x0
  # i_20 = PHI <_3(4), 0(3), _6(2)>
and evrp is now trying to figure out range for i_20 in range_of_phi.

All the ranges and MASK/VALUE pairs above are correct for the testcase,
k_11 and _2 based on it is a result of multiplication by a constant with
low
14 bits cleared and then some numbers are added to it.

There is an obvious missed optimization for which I've filed PR119039,
simplify_switch_using_ranges could see that all the labels but default
are unreachable because the controlling expression has
MASK 0xc000 VALUE 0x34 and none of 8, 24 and 32 satisfy that.

Anyway, during range_of_phi for i_20, we process the PHI arguments
in order.  For the _3(4) case, we figure out that it is reachable
through the case 24: case 32: labels only of the switch and that
0x34 - 0x2d is 7, so derive
[irange] long long unsigned int [17, 17][25, 25] MASK 0xc000
VALUE 0x2d
(the MASK/VALUE just got inherited from the _3 earlier range).
Now (not suprisingly because those labels aren't actually reachable),
that range is inconsistent, 0x2d is 45, so there is conflict between the
values and the irange_bitmask.
value-range.{h,cc} code differentiates between actually stored
irange_bitmask, which is that MASK 0xc000 VALUE 0x2d, and
semantic bitmask, which is what get_bitmask returns.  That is
  // The mask inherent in the range is calculated on-demand.  For
  // example, [0,255] does not have known bits set by default.  This
  // saves us considerable time, because setting it at creation incurs
  // a large penalty for irange::set.  At the time of writing there
  // was a 5% slowdown in VRP if we kept the mask precisely up to date
  // at all times.  Instead, we default to -1 and set it when
  // explicitly requested.  However, this function will always return
  // the correct mask.
  //
  // This also means that the mask may have a finer granularity than
  // the range and thus contradict it.  Think of the mask as an
  // enhancement to the range.  For example:
  //
  // [3, 1000] MASK 0xfffe VALUE 0x0
  //
  // 3 is in the range endpoints, but is excluded per the known 0 bits
  // in the mask.
  //
  // See also the note in irange_bitmask::intersect.
  irange_bitmask bm
= get_bitmask_from_range (type (), lower_bound (), upper_bound ());
  if (!m_bitmask.unknown_p ())
bm.intersect (m_bitmask);
Now, get_bitmask_from_range here is MASK 0x1f VALUE 0x0 and it intersects
that with that MASK 0xc000 VALUE 0x2d.
Which triggers the ugly special case in irange_bitmask::intersect:
  // If we have two known bits that are incompatible, the resulting
  // bit is undefined.  It is unclear whether we should set the entire
  // range to UNDEFINED, or just a subset of it.  For now, set the
  // entire bitmask to unknown (VARYING).
  if (wi::bit_and (~(m_mask | src.m_mask),
   m_value ^ src.m_value) != 0)
{
  unsigned prec = m_mask.get_precision ();
  m_mask = wi::minus_one (prec);
  m_value = wi::zero (prec);
}
so the semantic bitmask is actually MASK 0x VALUE 0x0.

Next, range_of_phi attempts to union it with the 0(3) PHI argument,
and during irange::union_ first adds the [0,0] to the subranges, so
[irange] long long unsigned int [0, 0][17, 17][25, 25] MASK
0xc000 VALUE 0x2d
and then goes on to irange::union_bitmask which does
  if (m_bitmask == r.m_bitmask)
return false;
  irange_bitmask bm = get_bitmask ();
  irange_bitmask save = bm;
  bm.union_ (r.get_bitmask ());
  if (save == bm)
return false;
  m_bitmask = bm;
  if (save == get_bitmask ())
return false;
m_bitmask MASK 0xc000 VALUE 0x2d isn't the

[Bug middle-end/119204] Internal Compiler Error (“verify_gimple” failed) when compiling code with the wrong return type on strcspn

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

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

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

https://gcc.gnu.org/g:01f20dec2d9ef22b2744a059c75b962d14de4303

commit r14-11467-g01f20dec2d9ef22b2744a059c75b962d14de4303
Author: Richard Biener 
Date:   Tue Mar 11 08:40:44 2025 +0100

middle-end/119204 - ICE with strcspn folding

The following makes sure to convert the folded expression to the
original expression type.

PR middle-end/119204
* builtins.cc (fold_builtin_strcspn): Preserve the original
expression type.

* gcc.dg/pr119204.c: New testcase.

(cherry picked from commit 68932eeb38f66fbc0c3cf4b77ff7dde8a408f2e4)

[Bug c/119183] [12/13/14 Regression] Compilation takes a long time on semi big inner expression

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

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

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

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

commit r14-11466-gc6b38a75fc811f87b1beae1d95b86f613352e3da
Author: Jakub Jelinek 
Date:   Tue Mar 11 11:01:55 2025 +0100

tree: Improve skip_simple_arithmetic [PR119183]

The following testcase takes very long time to compile, because
skip_simple_arithmetic decides to first call tree_invariant_p on
the second argument (and indirectly recurse there).  I think before
canonicalization of operands for commutative binary expressions
(and for non-commutative ones always) it is pretty common that the
first operand is a constant, something which tree_invariant_p handles
immediately, so the following patch special cases that; I've added
there a tree_invariant_p call too after the checks, while it is not
really needed currently, tree_invariant_p has the same checks, I wanted
to be prepared in case tree_invariant_p changes.  But if you think
I should avoid it, I can drop it too.

This is just a partial fix, I think one can certainly construct a testcase
which will still have horrible compile time complexity (but I've tried and
haven't managed to do so), so perhaps we should just limit the recursion
depth through skip_simple_arithmetic/tree_invariant_p with some defaulted
argument.

2025-03-11  Jakub Jelinek  

PR c/119183
* tree.cc (skip_simple_arithmetic): If first operand of binary
expr is TREE_CONSTANT or TREE_READONLY with no side-effects, call
tree_invariant_p on that operand first instead of on the second.

* gcc.dg/pr119183.c: New test.

(cherry picked from commit 20e5aa9cc1519f871cce25dbfdc149d9d60da779)

[Bug tree-optimization/119417] [14 Regression] wrong code with `-O2`, uses uxtw instead of uxth causing different result on ADD instruction since r14-8680-g2f14c0dbb78985

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

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

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

https://gcc.gnu.org/g:6c7c25c282642565b23da21cab7e313e78744ab5

commit r14-11472-g6c7c25c282642565b23da21cab7e313e78744ab5
Author: Jakub Jelinek 
Date:   Wed Mar 26 14:03:50 2025 +0100

widening_mul: Fix up further r14-8680 widening mul issues [PR119417]

The following testcase is miscompiled since r14-8680 PR113560 changes.
I've already tried to fix some of the issues caused by that change in
r14-8823 PR113759, but apparently didn't get it right.

The problem is that the r14-8680 changes sometimes set *type_out to
a narrower type than the *new_rhs_out actually has (because it will
handle stuff like _1 = rhs1 & 0x; and imply from that HImode type_out.

Now, if in convert_mult_to_widen or convert_plusminus_to_widen we actually
get optab for the modes we've asked for (i.e. with from_mode and to_mode),
everything works fine, if the operands don't have the expected types,
they are converted to those (for INTEGER_CSTs with fold_convert,
otherwise with build_and_insert_cast).
On the following testcase on aarch64 that is not the case, we ask
for from_mode HImode and to_mode DImode, but get actual_mode SImode.
The mult_rhs1 operand already has SImode and we change type1 to unsigned
int
and so no cast is actually done, except that the & 0x is lost that way.

The following patch ensures that if we change typeN because of wider
actual_mode (or because of a sign change), we first cast to the old
typeN (if the r14-8680 code was encountered, otherwise it would have the
same precision) and only then change it, and then perhaps cast again.

On the testcase on aarch64-linux the patch results in the expected
-   add x19, x19, w0, uxtw 1
+   add x19, x19, w0, uxth 1
difference.

2025-03-26  Jakub Jelinek  

PR tree-optimization/119417
* tree-ssa-math-opts.cc (convert_mult_to_widen): Before changing
typeN because actual_precision/from_unsignedN differs cast rhsN
to typeN if it has a different type.
(convert_plusminus_to_widen): Before changing
typeN because actual_precision/from_unsignedN differs cast
mult_rhsN
to typeN if it has a different type.

* gcc.dg/torture/pr119417.c: New test.

(cherry picked from commit 02132faf4e2fb604758aa86f0b097e6871be595a)

[Bug middle-end/119219] [15 Regression] ICE on c-c++-common/attr-nonstring-14.c

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

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

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

https://gcc.gnu.org/g:4164c2542952d82e7cdb06d28c8707ac131b5644

commit r14-11468-g4164c2542952d82e7cdb06d28c8707ac131b5644
Author: Jakub Jelinek 
Date:   Wed Mar 12 08:27:17 2025 +0100

builtins: Fix up strspn/strcspn folding [PR119219]

The PR119204 r15-7955 fix caused some regressions.
The problem is that the fold_builtin* APIs document that expr is
either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
can crash e.g. during constexpr evaluation etc.

As can be seen in the surrounding patch, for the neighbouring builtins
(both modf and strpbrk) fold_builtin_2 passes down type, which is the
result type, TREE_TYPE (TREE_TYPE (fndecl)) and those builtins use it
to build the return value, while strspn was always building size_type_node
and strcspn had this change from that to TREE_TYPE (expr).
The patch passes type to these two and uses it there as well.

The patch keeps passing expr because it is used in the
check_nul_terminated_array calls done for both strspn and strcspn,
those calls clearly can deal with NULL expr but prefer if it is non-NULL
for some warning.

2025-03-12  Jakub Jelinek  

PR middle-end/119204
PR middle-end/119219
* builtins.cc (fold_builtin_2): Pass type as another argument
to fold_builtin_strspn and fold_builtin_strcspn.
(fold_builtin_strspn): Add type argument, use it instead of
size_type_node.
(fold_builtin_strcspn): Add type argument, use it instead of
TREE_TYPE (expr).

(cherry picked from commit da967f0ff324053304b350fdb18384607a346ebd)

[Bug middle-end/119204] Internal Compiler Error (“verify_gimple” failed) when compiling code with the wrong return type on strcspn

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

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

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

https://gcc.gnu.org/g:4164c2542952d82e7cdb06d28c8707ac131b5644

commit r14-11468-g4164c2542952d82e7cdb06d28c8707ac131b5644
Author: Jakub Jelinek 
Date:   Wed Mar 12 08:27:17 2025 +0100

builtins: Fix up strspn/strcspn folding [PR119219]

The PR119204 r15-7955 fix caused some regressions.
The problem is that the fold_builtin* APIs document that expr is
either a CALL_EXPR of the call or NULL, so using TREE_TYPE (expr)
can crash e.g. during constexpr evaluation etc.

As can be seen in the surrounding patch, for the neighbouring builtins
(both modf and strpbrk) fold_builtin_2 passes down type, which is the
result type, TREE_TYPE (TREE_TYPE (fndecl)) and those builtins use it
to build the return value, while strspn was always building size_type_node
and strcspn had this change from that to TREE_TYPE (expr).
The patch passes type to these two and uses it there as well.

The patch keeps passing expr because it is used in the
check_nul_terminated_array calls done for both strspn and strcspn,
those calls clearly can deal with NULL expr but prefer if it is non-NULL
for some warning.

2025-03-12  Jakub Jelinek  

PR middle-end/119204
PR middle-end/119219
* builtins.cc (fold_builtin_2): Pass type as another argument
to fold_builtin_strspn and fold_builtin_strcspn.
(fold_builtin_strspn): Add type argument, use it instead of
size_type_node.
(fold_builtin_strcspn): Add type argument, use it instead of
TREE_TYPE (expr).

(cherry picked from commit da967f0ff324053304b350fdb18384607a346ebd)

[Bug c++/119150] [14 Regression] Optimization causes function call arguments to consteval functions to not be manifestly constant-evaluated since r14-4140

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

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

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

https://gcc.gnu.org/g:13fd7c971fb573b2f1721c3684b34a65133b7085

commit r14-11469-g13fd7c971fb573b2f1721c3684b34a65133b7085
Author: Jakub Jelinek 
Date:   Thu Mar 13 00:42:54 2025 +0100

c++: Evaluate immediate invocation call arguments with mce_true [PR119150]

Since Marek's r14-4140 which moved immediate invocation evaluation
from build_over_call to cp_fold_r, the following testcase is miscompiled.

The a = foo (bar ()); case is actually handled right, that is handled
in cp_fold_r and the whole CALL_EXPR is at that point evaluated by
cp_fold_immediate_r with cxx_constant_value (stmt, tf_none);
and that uses mce_true for evaluation of the argument as well as the actual
call.

But in the bool b = foo (bar ()); case we actually try to evaluate this
as non-manifestly constant-evaluated.  And while
  /* Make sure we fold std::is_constant_evaluated to true in an
 immediate function.  */
  if (DECL_IMMEDIATE_FUNCTION_P (fun))
call_ctx.manifestly_const_eval = mce_true;
ensures that if consteval and __builtin_is_constant_evaluated () is true
inside of that call, this happens after arguments to the function
have been already constant evaluated in cxx_bind_parameters_in_call.
The call_ctx in that case also includes new call_ctx.call, something that
shouldn't be used for the arguments, so the following patch just arranges
to call cxx_bind_parameters_in_call with manifestly_constant_evaluated =
mce_true.

2025-03-13  Jakub Jelinek  

PR c++/119150
* constexpr.cc (cxx_eval_call_expression): For
DECL_IMMEDIATE_FUNCTION_P (fun) set manifestly_const_eval in
new_ctx
and new_call to mce_true and set ctx to &new_ctx.

* g++.dg/cpp2a/consteval41.C: New test.

(cherry picked from commit ebf6e6241f5658a3cae462b1314f4a8f2bc71760)

[Bug target/119450] [14 Regression] Crash at -O3: during RTL pass: peephole2 since r14-4928

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

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

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

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

commit r14-11471-g4b364531057c973795dc15d75132fb6c2ea6219b
Author: Jakub Jelinek 
Date:   Wed Mar 26 08:47:20 2025 +0100

i386: Require in peephole2 that memory is offsettable [PR119450]

The following testcase ICEs because a peephole2 attempts to offset
memory which is not offsettable (in particular address is a ZERO_EXTEND
in this case).

Because peephole2s don't support constraints, I've added a check for this
in the peephole2's condition.

2025-03-26  Jakub Jelinek  

PR target/119450
* config/i386/i386.md (narrow test peephole2): Test for
offsettable_memref_p in condition.

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

(cherry picked from commit 84f0b648aeb053b3bd8e1cb6fe282f4da4143708)

[Bug middle-end/119482] slow compilation on ladybird interpreter

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

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

--- Comment #5 from ak at gcc dot gnu.org ---
Also I should add that the Ladybird developers report a 40% performance
improvement from adding flatten to clang.

[Bug libgcc/119151] [13/14 Regression] unwind-dw2-btree maintains separators wrong

[michael at slashhome dot org via Gcc-bugs]

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

--- Comment #15 from Michael Leuchtenburg  ---
I've been running this backported to 14.2.0 for a bit now with good results.
Found some other incompatibilities with our own code related to the changed
malloc pattern relative to pre-btree code (insert now mallocs while holding a
lock when previously it did not, which means we can't use dwarf backtraces in
some spots where we could before) but no new bugs.

Will the GCC commits bot update here when this is backported?

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #9 from 康桓瑋  ---
(In reply to GCC Commits from comment #8)
> The master branch has been updated by Jonathan Wakely :
> 
> https://gcc.gnu.org/g:f4b6acfc36fb1f72fdd5bf4da208515e6495a062
> 
> commit r15-8980-gf4b6acfc36fb1f72fdd5bf4da208515e6495a062
> Author: Jonathan Wakely 
> Date:   Wed Mar 26 11:47:05 2025 +
> 
> libstdc++: Replace use of std::min in ranges::uninitialized_xxx algos
> [PR101587]
> 
> Because ranges can have any signed integer-like type as difference_type,
> it's not valid to use std::min(diff1, diff2). Instead of calling
> std::min with an explicit template argument, this adds a new __mindist
> helper that determines the common type and uses that with std::min.
> 
> libstdc++-v3/ChangeLog:
> 
> PR libstdc++/101587
> * include/bits/ranges_uninitialized.h (__detail::__mindist):
> New function object.
> (ranges::uninitialized_copy, ranges::uninitialized_copy_n)
> (ranges::uninitialized_move, ranges::uninitialized_move_n): Use
> __mindist instead of std::min.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc:
> Check ranges with difference difference types.
> *
> testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
> Likewise.

Still need casting the return difference type from __mindist, I think?

[Bug c++/119499] New: g++.dg/modules/gmf-xtreme.C fails on aarch64 and arm

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

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

Bug ID: 119499
   Summary: g++.dg/modules/gmf-xtreme.C fails on aarch64 and arm
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
CC: jason at redhat dot com
  Target Milestone: ---
Target: arm aarch64

The test introduced by g:b360d4aafc1356386313c7392f7444b3fc356681 fails on arm
and aarch64:
FAIL: g++.dg/modules/gmf-xtreme.C -std=c++2b  scan-lang-dump module "Wrote 0
clusters"
FAIL: g++.dg/modules/gmf-xtreme.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/gmf-xtreme.C module-cmi empty (gcm.cache/empty.gcm)


According to Linaro CI this test regressed since the same commit.
FAIL: g++.dg/modules/xtreme-header-6_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-6_a.H.gcm)

[Bug target/119474] GCN 'libgomp.oacc-c++/pr96835-1.C' ICE 'during GIMPLE pass: ivopts'

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

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

--- Comment #6 from Andrew Stubbs  ---
The address space has to be introduced "late" because it's done in the
accelerator compiler, so post-IPA.  The pass is "oaccdevlow" (currently
no.103).

The address space is selected via the TARGET_GOACC_ADJUST_PRIVATE_DECL hook.

[Bug c++/119497] Improve diagnostic for failed assert(expr) in constexpr context

[thiago at kde dot org via Gcc-bugs]

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

Thiago Macieira  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #4 from Thiago Macieira  ---
If you're going for heuristics, can I also have qt_assert() and qt_assert_x()?

Otherwise, we could do with a __builtin with special semantics or a statement
[[attribute]].

[Bug c++/119497] Improve diagnostic for failed assert(expr) in constexpr context

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

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

--- Comment #5 from Jonathan Wakely  ---
I guess calling any noreturn function inside the expansion of a macro called
'assert' is probably a good enough heuristic.

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> Why for GCC 16?  Can't it be simply only done at least for now for musttail
> calls?

For GCC 15 and musttail, we could just don't do recusive inlining.

testcase for musttail:
```
struct MyStruct {
unsigned  n_recurses;
};

MyStruct foo(MyStruct m) {
if (m.n_recurses == 0)
  return m;
[[clang::musttail]]
return foo(MyStruct{m.n_recurses - 1});
}

int main() {
foo(MyStruct{99});
}
```

Let me do that patch for GCC 15.

[Bug c++/119500] New: False positive "unused variable" warning on static variable templates with custom section placement

[palchak at google dot com via Gcc-bugs]

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

Bug ID: 119500
   Summary: False positive "unused variable" warning on static
variable templates with custom section placement
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palchak at google dot com
  Target Milestone: ---

A false "defined but not used" warning is emitted for static variable templates
with custom section placement.

Example source:
```
template
[[gnu::section(".custom")]]
static int id = ID;

int main() {
return id<42>;
}
```

Compile command:
`g++ example.cc -o example -Wunused`

Output:
```
example.cc:3:12: warning: ‘id’ defined but not used [-Wunused-variable]
3 | static int id = ID;
  |^~
```

The variable template is very clearly used.

Compiler explorer reproduction:
https://godbolt.org/z/hjsabfcfT

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

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
Negative unit numbers are reserved for internal units IIRC. I will have to
check to see where we should check that we have an actual unit structure
created before trying to close it.

[Bug c++/119503] Error on decltype of lambda expression in variadic NTTP

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

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

eczbek.void at gmail dot com changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from eczbek.void at gmail dot com ---
Nevermind, this is IFNDR
https://eel.is/c++draft/temp.res.general#6.5

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from qingzhe huang  ---
https://www.doubao.com/thread/a21ec011ef239

获取Outlook for Android

From: pinskia at gcc dot gnu.org 
Sent: Friday, March 28, 2025 8:36:46 AM
To: nickhuan...@hotmail.com 
Subject: [Bug c++/104255] parsing function signature fails when it uses a
function parameter outside of an unevaluated context

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/133208

--
You are receiving this mail because:
You reported the bug.

[Bug libstdc++/119505] New: : Undefined backreferences should match empty string

[blubban at gmail dot com via Gcc-bugs]

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

Bug ID: 119505
   Summary: : Undefined backreferences should match empty
string
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

#include 
#include 

int main()
{
std::string s{"a"};
std::regex r{"(b)?\\1"};
std::smatch m;
bool result = std::regex_search(s, m, r);
printf("search=%d\n", result);
}


Expected: Return true, because the capture group fails to match and is skipped,
and the backreference then matches the empty string, per
https://262.ecma-international.org/5.1/#sec-15.10.2.9 5.3.

Actual: Returns false.

https://godbolt.org/z/5v8Yjqnd6

libc++ has the same bug. https://github.com/llvm/llvm-project/issues/133360

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > Created attachment 60904 [details]
> > the musttail patch for GCC 15
> 
> This one didn't work for LTO. Back to the board.

So while deciding to inline or not for LTO callstmt of the edge is not
available yet. The only way I can think of having that info there is to have a
bit in the edge for musttail that gets copied from the callstmt and verfied if
it is the same as the callstmt.

There are at least 2 spare bits in cgraphedge (if I counted correctly). The
only question is do we want to do this just for this workaround or I missing a
better way of getting this same issue?

[Bug modula2/119504] New: ICE when attempting to access an element of a constant string

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

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

Bug ID: 119504
   Summary: ICE when attempting to access an element of a constant
string
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Forwarded from the mailing list consider the following code:

$ cat WriteOctHex.mod
MODULE WriteOctHex;
FROM STextIO IMPORT WriteChar, WriteLn;

VAR
Done : BOOLEAN;

PROCEDURE WriteOctOrHex(v: CARDINAL; w: CARDINAL; oh : CARDINAL);
CONST MAXCHARS=80;
CONST OHstr = "0123456789ABCDEF";
VAR str : ARRAY [0..MAXCHARS] OF CHAR;
i,j : CARDINAL;
BEGIN
Done:=TRUE;
i:=0;
REPEAT
str[i]:=OHstr[v MOD oh];
v:=v DIV oh;
INC(i);
UNTIL (v=0) OR (i>MAXCHARS);
IF (v#0) AND (i>MAXCHARS) THEN
Done:=FALSE;
RETURN
END;
IF (w>0) AND (i

[Bug modula2/119504] ICE when attempting to access an element of a constant string

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

Modula-2 does not allow these kind of constant string to be accessed as arrays.
 However
it obviously shouldn't ICE under any circumstances.


For completeness ISO Modula-2 does allow constant strings to be accessed, but
they must be constructed using an array type.  For example:

CONST
   HexDigits = "0123456789ABCDEF" ;

TYPE
   ArrayType = ARRAY [0..HIGH (HexDigits)] OF CHAR ;

CONST
   HexArray = ArrayType { HexDigits } ;

VAR
   ch: CHAR ;
BEGIN
   ch := HexArray[4]
END 

[Bug libstdc++/119506] New: : \cA matches wrong byte

[blubban at gmail dot com via Gcc-bugs]

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

Bug ID: 119506
   Summary: : \cA matches wrong byte
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blubban at gmail dot com
  Target Milestone: ---

#include 
#include 

int main()
{
std::regex r{"\\cA"};
std::cmatch m;
bool result1 = std::regex_search("\x01", m, r);
printf("search=%d\n", result1);
bool result2 = std::regex_search("A", m, r);
printf("search=%d\n", result2);
try {
std::regex r2{"\\c+"};
puts("valid");
} catch (const std::exception&) {
puts("invalid");
}
}


Expected: True, false, invalid.

Actual: False, true, valid. libstdc++-v3/include/bits/regex_scanner.tcc line
351 just takes the character after \c as a literal.

https://godbolt.org/z/h7M76dej5

[Bug middle-end/119485] OpenACC offloading compilation failure/ICE for C++ templated library functions

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

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

--- Comment #1 from Thomas Schwinge  ---
Created attachment 60897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60897&action=edit
pre-processed, reduced

[Bug middle-end/119472] Pointers to distinct live objects compare equal

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

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

--- Comment #4 from Richard Biener  ---
So is there a _real_ testcase where, apart from strictly non-conformance, not
coalescing a and b is meaningful?

[Bug target/119477] RISC-V: -fno-tree-vectorize -fno-tree-loop-vectorize -fno-tree-slp-vectorize can't turn off auto-vectorization

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
As said this is not a bug.

[Bug rtl-optimization/119291] [12/13/14/15 regression] wrong code at -O{2,3} on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug libgcc/119396] libgcc: Shared objects are being built for target that doesn't support shared libs

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

[Bug libstdc++/119488] 25_algorithms/stable_sort/constexpr.cc test fails (error: non-constant condition for static assertion)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dangelog at gmail dot com

--- Comment #2 from Jonathan Wakely  ---
Presumably caused by r15-8933-ga264c270fde292

[Bug web/119227] Does the generated HTML for cobol get installed to the website?

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

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

--- Comment #16 from Jakub Jelinek  ---
And even the make html COBOL stuff is misplaced.
When I do
make html
most of the html is generated in HTML/gcc-15.0.1 subdirectory:
ls HTML/gcc-15.0.1/
ada  cpp  cppinternals  gcc  gccinstall  gccint  gdc  gfortran  go  m2
The only exception is cobol, which puts
gcobol.html  gcobol-io.html
in the gcc build subdirectory, i.e. the same directory as contains HTML
subdirectory.
I think there should be HTML/gcc-15.0.1/cobol/ subdirectory and those 2 files
should be in there, together with some index.html that references those two.
And similarly we should have gcc.gnu.org/onlinedocs/cobol/ which would have
that index.html and the two converted pages.

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to 康桓瑋 from comment #13)
> I'm not sure it's reasonable or trivial for alias_view to be sized_range,

I don't think it is necessary. Is there a use case for needing to know how many
aliases there are, where ranges::distance isn't sufficient? What code would you
write differently?

> If it's trivial to make it satisfy sized_range, then perhaps we should
> submit to the LWG to require it.

It would require inspecting the aliases on construction, and then storing the
size (or the end iterator). That would mean std::text_encoding::aliases() is
not O(1).

Why would it be an improvement?

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

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

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

--- Comment #14 from Jonathan Wakely  ---
The standard says "text_encoding::aliases_view models copyable, ranges::view,
ranges::random_access_range, and ranges::borrowed_range."

So that's what it's required to satisfy. Anything else is not required. The
standard doesn't specify that it's a common_range, so it's unspecified (that's
what unspecified means!) Similarly, it doesn't specify that it's a sized_range,
so it's unspecified.

I don't like the suggestion that we need to be explicit about all the concepts
that a type does *not* satisfy. If we don't specify it satisfies something,
then it doesn't need to satisfy it. That should be clear enough and I'm
regretting adding the note about common_range and default_initializable now.

[Bug target/118520] compiles with clang on openmp target, but gcc fails to compile with unresolved symbol __cxa_throw_bad_array_new_length

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 CC||tschwinge at gcc dot gnu.org
   Keywords||openmp

--- Comment #2 from Thomas Schwinge  ---
Benjamin, thanks for this one, too.  This now works with (the upcoming) GCC 15:
compiles, executes (tested Nvidia GPU) without error, produces output (that
I've not verified in detail).

I'm curious about a few of your comments, please feel free to provide some more
context if you'd like:

> interestingly, local arrays on the stack work on clang in target regions.

Yes, that's expected to work.  (Within the smallish GPU stack size
constraints.)

> interestingly, with clang, one can do pointer arithmetic on target regions, 
> so the pointers are really target pointers now..

Yes, that's expected to behave according to base language standards.

> interestingly, ['new'] works on clang on target regions. On gcc, this 
> apparently does not work.

Now it does (PR101544).

> also, one can allocate memory in the target region with omp alloc.

Yes.

> ['device' clause confusion]

I can't comment on what LLVM is doing, but with GCC this is expected to behave
as documented by OpenMP.

[Bug target/119494] New: z196: Inefficient implementation for __builtin_parityll for z196 < z15

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 119494
   Summary: z196: Inefficient implementation for
__builtin_parityll for z196 < z15
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

bool parityll(unsigned long long x)
{
return __builtin_parityll(x);
}

Code generation for z15 and above is optimal:
bool parityll(unsigned long long x)
{
return __builtin_popcountll(x) & 1;
}

parityll(unsigned long long):
popcnt  %r2,%r2,8
risbg   %r2,%r2,63,128+63,0
br

But for < z15:
parityll(unsigned long long):
popcnt  %r2,%r2
sllg%r1,%r2,32
agr %r2,%r1
sllg%r0,%r2,16
agr %r2,%r0
sllg%r3,%r2,8
agr %r2,%r3
risbg   %r2,%r2,64-1,128+63,7+1
br  %r14

It should use rxsbg
bool parity_z196(unsigned long long x)
{
   __asm__("popcnt %0,%1":"=r"(x):"r"(x):"cc");
   x ^= (x >> 32);
   x ^= (x >> 16);
   x ^= (x >> 8);
   return x & 1;
}

parity_z196(unsigned long long):
popcnt %r2,%r2
rxsbg   %r2,%r2,32,63,32
rxsbg   %r2,%r2,16,63,48
rxsbg   %r2,%r2,8,63,56
risbg   %r2,%r2,63,128+63,0
br  %r14

[Bug tree-optimization/119351] [15 Regression] Wrong code in GROMACS for AArch64 generic SVE VLS target

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

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

--- Comment #8 from Tamar Christina  ---
Looking at it some more, I think the loop is valid to vectorize. But we don't
seem to vectorize the reduction jumping back to the outerloop:

;;   basic block 384, loop depth 3, count 8598980 (estimated locally, freq
26.9637), maybe hot
;;prev block 383, next block 458, flags: (NEW, REACHABLE, VISITED)
;;pred:   387 [94.5% (guessed)]  count:8598980 (estimated locally, freq
26.9637) (TRUE_VALUE,EXECUTABLE)
  # RANGE [irange] int [1, +INF]
  _1643 = ci_y_1924 + 1;
  _3519 = vect_vec_iv_.4957_3520 + { 4, 4, 4, 4 };
  # PT = nonlocal escaped null
  vectp.4959_3503 = vectp.4959_3504 + 16;
  ivtmp_3495 = ivtmp_3496 + 4;
  _3493 = (unsigned int) ivtmp_3495;
  next_mask_3470 = .WHILE_ULT (_3493, _3494, { 0, 0, 0, 0 });
  if (next_mask_3470 == { 0, 0, 0, 0 })
goto ; [5.50%]
  else
goto ; [94.50%]
;;succ:   844 [5.5% (guessed)]  count:472944 (estimated locally, freq
1.4830) (TRUE_VALUE,EXECUTABLE)
;;458 [94.5% (guessed)]  count:8126036 (estimated locally, freq
25.4807) (FALSE_VALUE,EXECUTABLE)

;;   basic block 458, loop depth 3, count 8126036 (estimated locally, freq
25.4807), maybe hot
;;prev block 384, next block 844, flags: (NEW, REACHABLE, VISITED)
;;pred:   384 [94.5% (guessed)]  count:8126036 (estimated locally, freq
25.4807) (FALSE_VALUE,EXECUTABLE)
  goto ; [100.00%]
;;succ:   387 [always]  count:8126036 (estimated locally, freq 25.4807)
(FALLTHRU,DFS_BACK,EXECUTABLE)

;;   basic block 844, loop depth 2, count 472944 (estimated locally, freq
1.4830), maybe hot
;;prev block 458, next block 840, flags: (NEW, VISITED)
;;pred:   384 [5.5% (guessed)]  count:472944 (estimated locally, freq
1.4830) (TRUE_VALUE,EXECUTABLE)
  # RANGE [irange] int [1, +INF]
  # _3469 = PHI <_1643(384)>
  _3538 = niters.4954_3792;
  _3536 = (intD.10) _3538;
  tmp.4955_3537 = ci_y_1923 + _3536;
  if (_3538 == niters.4954_3792)
goto ; [25.00%]
  else
goto ; [75.00%]

where

  _1643 = ci_y_1924 + 1;

has stayed scalar and so LCSSA code inserts a PHI here:

  # _3469 = PHI <_1643(384)>

which is unused, as BB 384 is considered the main exit. So it assumes that if
you exit from 384 -> 844 that you've done all iterations and so it just uses
niters + ci_y_1923.
i.e. just adds the number of iterations to ci_y. So I don't think that's
wrong..

I could use some help here richi in whether this loop *is* valid to vectorize
or not.  I've not yet been able to create a small reproducer but the loop looks
like:

(gdb) p debug_loop (loop, 3)
loop_48 (header = 387, latch = 458, finite_p
upper_bound 2147483647
likely_upper_bound 2147483647
iterations by profile: 8.347976 (unreliable, maybe flat) entry count:1081571
(estimated locally, freq 3.3915))
{
  bb_384 (preds = {bb_387 }, succs = {bb_385 bb_458 })
  {
 [local count: 9554422]:
_1643 = ci_y_1924 + 1;
if (_1643 == _1649)
  goto ; [5.50%]
else
  goto ; [94.50%]

  }
  bb_458 (preds = {bb_384 }, succs = {bb_387 })
  {
 [local count: 9028929]:
goto ; [100.00%]

  }
  bb_387 (preds = {bb_458 bb_386 }, succs = {bb_384 bb_388 })
  {
 [local count: 10110500]:
# ci_y_1924 = PHI <_1643(458), ci_y_1923(386)>
_1651 = _1650 + ci_y_1924;
_1652 = _1651 + 1;
_1653 = (long unsigned int) _1652;
_1655 = _1653 * 4;
_1656 = _1654 + _1655;
# VUSE <.MEM_1725>
_1657 = *_1656;
if (_1657 <= ci_1918)
  goto ; [94.50%]
else
  goto ; [5.50%]

  }
}

(gdb) p debug_bb_n_slim (388)
;; basic block 388, loop depth 1
;;  pred:   387
# ci_x_1703 = PHI 
# _2327 = PHI <_1651(387)>
# ci_y_2179 = PHI 
if (_333 != 0)
  goto ; [50.00%]
else
  goto ; [50.00%]
;;  succ:   61
;;  62

(gdb) p debug_bb_n_slim (385)
;; basic block 385, loop depth 2
;;  pred:   384
_1646 = ci_x_1920 + 1;
;;  succ:   386

(gdb) p debug_bb_n_slim (386)
;; basic block 386, loop depth 2
;;  pred:   382
;;  385
# ci_x_1920 = PHI 
# ci_y_1923 = PHI 
_1650 = _1649 * ci_x_1920;
;;  succ:   387

(gdb) p debug (pre_header)
 387)>

So the reduction values look sane, and the vector code looks sane, I'll instead
focus first on values that change during the loop

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-27
   Keywords||openacc, openmp
 Ever confirmed|0   |1
 Target|nvptx   |GCN, nvptx
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 CC||tschwinge at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #10 from Thomas Schwinge  ---
Indeed for '-O0' compilation, you currently need host-side '-fno-exceptions' to
prevent GCN as well as nvptx offloading compilation to fail with 'sorry,
unimplemented: exception handling not supported', which I'm aware we should
resolve properly.

With optimizations enabled, or '-O0 -fno-exceptions', this code now works with
(the upcoming) GCC 15: compiles, executes successfully (tested Nvidia GPU),
produces output (that I've not verified in detail, but have 'diff'ed to host
output: matches, apart from a few numeric differences for E-14 etc. numbers;
probably rounding differences).

[Bug target/119495] New: 8% slowdown of 436.cactusADM on AMD Zen2 since r15-7895-gb191e8bdecf881

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

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

Bug ID: 119495
   Summary: 8% slowdown of 436.cactusADM on AMD Zen2 since
r15-7895-gb191e8bdecf881
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ra
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

As seen here (the first spike of March):

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

there was an 8% slowdown of 436.cactusADM SPEC 2006 benchmark on AMD Zen2 when
run with options -O2 -march=native -flto

I've bisected this to
r15-7895-gb191e8bdecf881

Author: Richard Sandiford 
Date:   Thu Mar 6 11:06:25 2025 +

ira: Add new hooks for callee-save vs spills [PR117477]

Following on from the discussion in: 

  https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675256.html

this patch removes TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE and 
replaces it with two hooks: one that controls the cost of using an
extra callee-saved register and one that controls the cost of allocating
a frame for the first spill.

(The patch does not attempt to address the shrink-wrapping part of
the thread above.)

On AArch64, this is enough to fix PR117477, as verified by the new tests.
The patch does not change the SPEC2017 scores significantly.  (I saw a
slight improvement in fotonik3d and roms, but I'm not convinced that
the improvements are real.)

The patch makes IRA use caller saves for gcc.target/aarch64/pr103350-1.c,
which is a scan-dump correctness test that relies on not using
caller saves.  The decision to use caller saves looks appropriate,
and saves an instruction, so I've just added -fno-caller-saves
to the test options.

The x86 parts were written by Honza.  ix86_callee_save_cost is updated
by H.J. to replace gcc_checking_assert with returning 1 if mem_cost <= 2.

However:

1. This isn't a regression against GCC 14.  Comparison here:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1033.100.0&plot.9=290.100.0&;

2. cactusADM performance is prone to change a lot with minor changes to how
registers are allocated (I source this information from Richard Biener's
comment in pr119044 :)).

So my understanding is that this slowdown isn't really that important. 
However, it seemed reasonable to at least notify Richard Sandiford about this
in case he wants to investigate it.  Otherwise, I would be fine with closing
this as WONTFIX or something like that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

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

--- Comment #20 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

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

commit r15-8963-gaccbc1b90bd942aa36ac1485a21056b774ce02df
Author: Martin Uecker 
Date:   Sun Mar 16 10:54:17 2025 +0100

c: Fix tagname confusion for typedef redefinitions [PR118765]

When we redefine a typedef for a tagged type that has just been
redefined, merge_decls may produce invalid TYPE_DECLS that are not
consistent with what set_underlying_type produces.  This is fixed
by updating DECL_ORIGINAL_TYPE.

PR c/118765

gcc/c/ChangeLog:
* c-decl.cc (merge_decls): For TYPE_DECLS copy
DECL_ORIGINAL_TYPE from the old declaration.
* c-typeck.cc (tagged_types_tu_compatible_p): Add
checking assertions.

gcc/testsuite/ChangeLog:
* gcc.dg/pr118765-2.c: New test.
* gcc.dg/pr118765-3.c: New test.
* gcc.dg/typedef-redecl3.c: New test.

[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #10 from chenglulu  ---
(In reply to Xi Ruoyao from comment #9)
> Ok for a backport into the 14 branch (where __float128 has been added)?

I will backpoint as soon as possible if there is no problem in the test.

[Bug target/119010] [15 Regression] 444.namd shows a huge compile-time regression with -mtune=znver5

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |rguenth at gcc dot 
gnu.org

--- Comment #11 from Richard Biener  ---
With two more scheduled fixes we're down to

 scheduling 2   :   1.68 (  3%)   801k (  0%)

IMO no need to cut the number of reservations.

[Bug libstdc++/116399] C++26 text_encoding​::​aliases_view is not default-constructible

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #13 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #12)
> Implementation-defined means the implementation must define it (and document
> it).
> 
> If the implementation says the types are different, then they're different,
> and it's not a common range.

I found that in the original paper, the implementation experience of alias_view
was designed to be sized_range, but the implementation of libstdc++ was not.

I'm not sure it's reasonable or trivial for alias_view to be sized_range, the
standard does not specify it, perhaps we should explicitly say so just like
common_range.

If it's trivial to make it satisfy sized_range, then perhaps we should submit
to the LWG to require it.

[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported

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

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

--- Comment #9 from Xi Ruoyao  ---
Ok for a backport into the 14 branch (where __float128 has been added)?

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #46 from LIU Hao  ---
(In reply to John Platts from comment #28)
> The correct way to align the stack to a 32-byte or 64-byte boundary on
> 64-bit Windows is to use a frame pointer in a function that requires stack
> realignment and then realign the stack to the required alignment once the
> frame pointer is set and all of the non-volatile registers used in the
> function are saved.
> 

Please don't suggest that. There's assumption that `QWORD PTR [rbp]` points to
the previous frame, and in your code it would be `QWORD PTR [rbp + 8 * 2]`.

Here's Microsoft doc:
https://learn.microsoft.com/en-us/cpp/build/prolog-and-epilog?view=msvc-170#epilog-code

They use `r13` as the frame pointer but anyway, an epilogue must start with
either `add rsp, ` or `lea rsp, [rbp + ]`, followed by a
sequence of zero or more `pop`s, followed by either `ret` or `jmp` (indirect
jumps require REX prefixes). By this definition, the difference between `rsp`
and `rbp` is a fixed value. Since `rsp` can only be subtracted by a constant
value in the prologue, we can't change `rbp` otherwise.

[Bug middle-end/119482] slow compilation on ladybird interpreter

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

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

--- Comment #3 from ak at gcc dot gnu.org ---
I ran a full comparison now. There is actually a significant regression between
g++-13 and g++-14, but -15 is roughly the same as -14. All are significantly
slower than clang:

clang++-19 -std=gnu++20 Interpreter.cpp -I ../../.. -I ../.. -w -S -o x.s -O2
ran
1.17 ± 0.19 times faster than clang++-18 -std=gnu++20 Interpreter.cpp -I
../../.. -I ../.. -w -S -o x.s -O2
5.10 ± 0.51 times faster than g++-13 -std=gnu++20 Interpreter.cpp -I
../../.. -I ../.. -w -S -o x.s -O2
5.91 ± 0.60 times faster than g++-15 -std=gnu++20 Interpreter.cpp -I
../../.. -I ../.. -w -S -o x.s -O2
6.15 ± 0.61 times faster than g++-14 -std=gnu++20 Interpreter.cpp -I
../../.. -I ../.. -w -S -o x.s -O2

For clang flatten just based on cfi_startproc gcc actually generates more
functions:

% grep -c cfi_startproc interpreter-clang.s 
570
% grep -c cfi_startproc interpreter-gcc.s 
610

but gcc indeed generates much more code:

   textdata bss dec hex filename
 3115911536   1  313128   4c728 interpreter-clang.o
 783346   8   2  783356   bf3fc interpreter-gcc.o

So yes there might be a difference in flatten semantics

I'm attaching a input file that works for clang if you want to look yourself.

[Bug tree-optimization/119483] musttail vs noreturn discovery

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-27
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested support for tail calling or tail recursion of musttail noreturn calls.

[Bug libstdc++/101587] ranges::uninitialized_copy/move incorrectly uses std::min

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-8980-gf4b6acfc36fb1f72fdd5bf4da208515e6495a062
Author: Jonathan Wakely 
Date:   Wed Mar 26 11:47:05 2025 +

libstdc++: Replace use of std::min in ranges::uninitialized_xxx algos
[PR101587]

Because ranges can have any signed integer-like type as difference_type,
it's not valid to use std::min(diff1, diff2). Instead of calling
std::min with an explicit template argument, this adds a new __mindist
helper that determines the common type and uses that with std::min.

libstdc++-v3/ChangeLog:

PR libstdc++/101587
* include/bits/ranges_uninitialized.h (__detail::__mindist):
New function object.
(ranges::uninitialized_copy, ranges::uninitialized_copy_n)
(ranges::uninitialized_move, ranges::uninitialized_move_n): Use
__mindist instead of std::min.
*
testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc:
Check ranges with difference difference types.
*
testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
Likewise.

[Bug c++/119490] g++.dg/template/explicit-args6.C fails test for warnings once directive fixed

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Last reconfirmed||2025-03-27

[Bug c++/119490] g++.dg/template/explicit-args6.C fails test for warnings once directive fixed

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
We already say
explicit-args6.C:22:19: note: the comparison reduces to ‘(-1 == 1)’
so the dg-message line just needs another fix:

--- a/gcc/testsuite/g++.dg/template/explicit-args6.C
+++ b/gcc/testsuite/g++.dg/template/explicit-args6.C
@@ -20,7 +20,7 @@ constexpr unsigned
 frob()
 {
   static_assert(N == 1, "user-friendly diagnostic"); // { dg-error
"user-friendly" }
-  // { dg-message { "-1 == 1" "" { target *-*-* } .-1 } }
+  // { dg-message "-1 == 1" "" { target *-*-* } .-1 }

   // narrowing check, reject negative values
   return unsigned{N};  // { dg-prune-output "narrowing" }

[Bug target/119474] GCN 'libgomp.oacc-c++/pr96835-1.C' ICE 'during GIMPLE pass: ivopts'

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

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

--- Comment #5 from Richard Biener  ---
Created attachment 60901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60901&action=edit
verifier

This verifier patch shows

pr96835-1.C: In function ‘main._omp_fn.0’:
pr96835-1.C:36:11: error: inconsistent TYPE_ADDR_SPACE
   36 |   #pragma acc serial copyout(res)
  |   ^~~
# VUSE <.MEM_21>
_15 = v1.values_[i_9];
during GIMPLE pass: oaccdevlow
dump file: pr96835-1.C.103t.oaccdevlow
pr96835-1.C:36:11: internal compiler error: verify_gimple failed

[Bug c++/119498] New: Incompatible FMV functions not diagnosed

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

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

Bug ID: 119498
   Summary: Incompatible FMV functions not diagnosed
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alfierichards at gcc dot gnu.org
  Target Milestone: ---

Cases such as 

```c
__attribute__ ((target_version("default")))
int foo (int a) {
return 1;
}

__attribute__ ((target_version("sve")))
int foo (int a) {
return 1;
}

__attribute__ ((target_version("sme")))
float foo (int a) {
return 1;
}
```

There the return type is inconsistent and should not be compatible are not
diagnosed and create invalid output.

Aarch64 example
https://godbolt.org/z/E8s71Y1jK

X86 example:
https://godbolt.org/z/nbadoTTMW

[Bug target/117596] avr support for BitInt

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Georg-Johann Lay from comment #1)
> All I can find is TARGET_C_BITINT_TYPE_INFO.
> 
> * Where to specify that addition should be implemented by a libgcc function
> like addbitint3?

Nowhere, the _BitInt lowering code has no support of library calls except for
multiplication, division and conversions to/from floating point (including
decimal floating point).

> * There are libgcc modules like _mulbitint3.o but they are empty. How to add
> them to, say LIB1ASMFUNCS?

They shouldn't be empty if __BITINT_MAXWIDTH__ etc. macros are predefined.
And those macros are predefined when
targetm.c.bitint_type_info (WIDE_INT_MAX_PRECISION - 1, &info)
is true.

> * Where to specify the limb size for libgcc functions?

Just in the bitint_type_info hook.

(In reply to Georg-Johann Lay from comment #2)
> ...what I currently have for trying is this addition to avr.cc:
> 
> static bool
> avr_c_bitint_type_info (int n, struct bitint_info *info)
> {
>   info->abi_limb_mode = QImode;
>   info->limb_mode = QImode;
>   info->big_endian = false;
>   info->extended = false;
> 
>   return n <= 1024;

Why?  If you just return true; here, it should work (at least perhaps with some
minor libgcc Makefile fragment tweaks so that all the needed routines are
built).

[Bug middle-end/119482] slow compilation on ladybird interpreter

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

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

--- Comment #4 from ak at gcc dot gnu.org ---
Created attachment 60902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60902&action=edit
input file for clang testing

[Bug libstdc++/119488] 25_algorithms/stable_sort/constexpr.cc test fails (error: non-constant condition for static assertion)

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

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

Giuseppe D'Angelo  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |peppe at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Giuseppe D'Angelo  ---
Fixed on trunk.

[Bug libstdc++/119488] 25_algorithms/stable_sort/constexpr.cc test fails (error: non-constant condition for static assertion)

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

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

--- Comment #7 from Giuseppe D'Angelo  ---
(In reply to Sam James from comment #5)
> (In reply to Giuseppe D'Angelo from comment #4)
> > Hi,
> > 
> > Apologies for the testsuite regression; I think this is fixed now in trunk
> > by r15-8971-g6acfb68dc0a479 .
> 
> Thank you! By the way, if you change your email on BZ to pe...@gcc.gnu.org,
> you'll get permissions to modify bugs.

Got it! Done that, thank you.

[Bug target/119474] GCN 'libgomp.oacc-c++/pr96835-1.C' ICE 'during GIMPLE pass: ivopts'

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Thu, 27 Mar 2025, ams at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119474
> 
> --- Comment #6 from Andrew Stubbs  ---
> The address space has to be introduced "late" because it's done in the
> accelerator compiler, so post-IPA.  The pass is "oaccdevlow" (currently
> no.103).
> 
> The address space is selected via the TARGET_GOACC_ADJUST_PRIVATE_DECL hook.

Ugh.  I see oacc_rewrite_var_decl copies TYPE_QUALs in incomplete ways.
I'll note that in case there are ADDR_EXPRs all uses of such address
are not updated it seems?  Like

 _1 = &to_rewrite_decl;
 _2 = *_1;

where do we rewrite *_1?

It seems to be a quite fragile machinery^Whack.

[Bug tree-optimization/119491] missed tail call due to exceptions which is empty

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think it would be useful to do one cleanup_eh far earlier after IPA, right
now we have cleanup_eh before IPA (but after tailr) and another one only a few
passes after tailc almost at the end of GIMPLE passes.
Inlining can introduce cases where EH needs to be cleaned up and perhaps the
lack of that hurts even other optimizations than just tailc.
So perhaps around vrp1 (i.e. after some cleanups of the post IPA IL (ccp,
forwprop, fre))?

Another possibility is what you have but have a special version of the pass
guarded on cfun->has_musttail (though that won't help other tail calls, just
musttail).

Or yet another possibility is not to handle musttail calls during tailc (so,
pretty much set diag_musttail only in musttail; then it would be the same thing
as only_musttail and could be merged into just one flag) pass and do it always
in the musttail pass.  This won't help tail calls other than musttail as well.

Now the second or third option are maybe slightly safer this late in stage4,
but perhaps we have still time to add another cleanup_eh.

Richi, what do you think about this?

[Bug tree-optimization/119492] missing tail call due to address of the argument taken but NOT escaping

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

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

--- Comment #2 from Jakub Jelinek  ---
I mean the https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679182.html
one.

[Bug target/118734] RISC-V: Vector broadcast via strided load.

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

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||gkm at rivosinc dot com,
   ||vineetg at gcc dot gnu.org

--- Comment #3 from Vineet Gupta  ---
Trivial testcase

-O3 -march=rv64gcv

void f(int8_t* a, int8_t* b)
{
  for (int i = 0; i < 512; ++i)
  {
   b[i] = *a;
  }
}

addi a5,a0,1
bgeu a1,a5,.L17
addi a5,a1,512
bltu a0,a5,.L6

.L7:
vsetivli zero,16,e8,m1,ta,ma
vlse8.v v1,0(a0),zero  <
.L4:
vse8.v v1,0(a1)
addi a1,a1,16
bne a1,a5,.L4
ret
.L6:
lb a4,0(a0)
addi a1,a1,1
sb a4,-1(a1)
bne a5,a1,.L6
ret
.L17:
addi a5,a1,512
j .L7

[Bug c++/119497] Improve diagnostic for failed assert(expr) in constexpr context

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #6 from Arthur O'Dwyer  ---
Here's a proposed behavior for Clang (as I implemented in my Clang fork
yesterday).

:30:15: error: constexpr variable 'val' must be initialized by a
constant expression
   30 | constexpr int val = square(2);
  |   ^ ~
:26:3: note: assertion failed during constant evaluation
   26 |   assert(result == 42); // expected-note {{assertion failed during
constant evaluation}}
  |   ^
:11:24: note: expanded from macro 'assert'
   11 |((cond) ? (void)0 : __assert_fail(#cond, __FILE__, __LINE__,
__func__))
  |^
:30:21: note: in call to 'square(2)'
   30 | constexpr int val = square(2);
  | ^

Points to note:

- I think "assertion failed during constant evaluation" is the clearest English
wording.

- With a static_assert, there can be a "message" attached. But C's assert(x)
cannot have a message: the "message" printed at runtime is always just the
stringification of #x, which is invariably visible to the end-user on the very
next line of GCC's output. So you needn't (and IMNSHO shouldn't) repeat that
string in the "assertion failed" message.

- The stringification of #x is not always the first argument; different
platforms put it in different positions (and Microsoft makes it a wchar_t
string literal). That's another reason not to try to repeat the stringification
of #x in GCC's compiler output.

- I'm ambivalent about whether the following note about "expanded from macro
assert" should be silenced or not. In Clang's case I think it was actually
difficult to silence, but even supposing we *could* silence it, *should* we? or
is it potentially useful?

- It would be *VERY* cool if the top-level error was not "constexpr variable
'val' must be initialized by a constant expression" but instead skipped
straight to the good part, e.g. "error: assertion failed during evaluation of
this constant expression". In C++26, you'll also want to do something like that
for an uncaught `throw` during constant evaluation. But that, also, seems
difficult in Clang.

@jwakely is correct that on OSX/Darwin the macro is named `__assert_rtn`.

[Bug tree-optimization/119491] missed tail call due to exceptions which is empty

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

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

Sam James  changed:

   What|Removed |Added

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

[Bug c++/119497] Improve diagnostic for failed assert(expr) in constexpr context

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Arthur O'Dwyer  ---
> @jwakely is correct that on OSX/Darwin the macro is named `__assert_rtn`.

...er, sorry, the *non-constexpr function called by the `assert` macro* is
named `__assert_rtn`.

[Bug tree-optimization/119492] missing tail call due to address of the argument taken but NOT escaping

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2025-03-27
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> Why for GCC 16?  Can't it be simply only done at least for now for musttail
> calls?
> With [[clang::musttail]] being recognized we can regress on compiling
> real-world code.
> E.g. could the extra eh cleanup pass be guarded on cfun->has_musttail and
> the tailc pass changes either as well, or done only if the tail call or
> recursion is musttail in the particular case.

I was not thinking of musttail when I filed this bug report :).

[Bug tree-optimization/119492] missing tail call due to address of the argument taken but NOT escaping

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

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

--- Comment #1 from Jakub Jelinek  ---
The PR119376 patch ought to handle this (for musttail only of course, otherwise
unless we can prove it escaped but isn't observable by the potential tail call
callee, we can't do a tail call).

[Bug target/119425] [15 Regression] ICE: in extract_constrain_insn, at recog.cc:2783 insn does not satisfy its constraints: {avx2_pblenddv8si} since r15-1679

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

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

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

Bug ID: 119502
   Summary: Runtime segfault when closing invalid unit
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

The following code crashes with a segfault:

program foo
  integer :: iun = -1
  close (iun)
end

Excerpt from valgrind:

==28254== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==28254==at 0x4A3E41C: __pthread_kill_implementation (in /lib64/libc.so.6)
==28254==by 0x49EC841: raise (in /lib64/libc.so.6)
==28254==by 0x49EC8FF: ??? (in /lib64/libc.so.6)
==28254==by 0x40699B: _gfortrani_close_share (unix.c:1889)
==28254==by 0x404060: _gfortran_st_close (close.c:87)

We could handle this more graciously...

[Bug testsuite/119489] g++.dg/strub-internal-pr112938.C test fails once fixed to actually run

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed by r15-8988-g50f8148a2754a1

[Bug c++/118672] ICE on template lambda expression return a lambda type

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Dup.

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

[Bug c++/119503] New: Error on decltype of lambda expression in variadic NTTP

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

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

Bug ID: 119503
   Summary: Error on decltype of lambda expression in variadic
NTTP
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eczbek.void at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/MfEqT64an

```cpp
template int x;

int main() {}
```

```
:1:19: error: lambda-expression in template parameter type
1 | template int x;
  |   ^
```

[Bug c++/119437] [12/13/14/15 regression] ICE in build_base_path, at cp/class.cc:302

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #3 from Simon Martin  ---
Working on this "funny" one.

[Bug target/117596] avr support for BitInt

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

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

--- Comment #2 from Georg-Johann Lay  ---
...what I currently have for trying is this addition to avr.cc:

static bool
avr_c_bitint_type_info (int n, struct bitint_info *info)
{
  info->abi_limb_mode = QImode;
  info->limb_mode = QImode;
  info->big_endian = false;
  info->extended = false;

  return n <= 1024;
}


#undef  TARGET_C_BITINT_TYPE_INFO
#define TARGET_C_BITINT_TYPE_INFO avr_c_bitint_type_info

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

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

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

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

No problem. Thank you for testing! I will close this as resolved.

[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases

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

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

--- Comment #7 from Andrew Pinski  ---
Created attachment 60904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60904&action=edit
the musttail patch for GCC 15

[Bug tree-optimization/117287] [13 Regression] assume attribute related miscompilation

[amacleod at redhat dot com via Gcc-bugs]

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

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

(In reply to Sam James from comment #10)
> The testcase from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287#c0
> still fails for me on releases/gcc-13. Is the change back portable there too?

There are some issues previous to GCC 14.  It requires the new lazy_ssa_cache
from GCC 14, which is dependent on some other changes in range storage
allocators.

I did convert the new cache code and isolated it all to the new assume pass
file, tree-assume.cc.   This should, in theory, not impact any other part of
the compiler.

I've attached the patch.  I will also submit it, although I debated not doing
so.  I will leave it up to the release managers whether they want this added to
GCC 13 or not.   Feel free to use it on your own compiler however, it *should*
work :-)

[Bug c++/119490] g++.dg/template/explicit-args6.C fails test for warnings once directive fixed

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed by r15-8986-g4242ea1916fffb.  I forgot to add the PR marker, sigh.