Tomasz Kamiński [Fri, 7 Mar 2025 10:54:38 +0000 (11:54 +0100)]
libstdc++: Fix views::zip_transform constraints for empty range pack [PR111138]
Add missing move_constructible && regular_invocable constrains on functor type,
and is_object on functor result type for invocations of views::zip_transform
without range arguments.
PR libstdc++/111138
libstdc++-v3/ChangeLog:
* include/std/ranges (_ZipTransform::operator()):
Create separate overload for calls with empty range pack,
and add move_constructible, regular_invocable and
is_object_v<invoke_result_t<...>>> constraints.
* testsuite/std/ranges/zip_transform/1.cc: New tests
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Robert Dubner [Fri, 14 Mar 2025 01:03:46 +0000 (21:03 -0400)]
Prevent use of ASM_EXPR for optimized COBOL compilations [PR119214]
The creation of assembler labels using ASM_EXPR causes name collisions in the
assembly language because some optimizations repeat code, and those labels
can get repeated. Use of "if( !optimize )" prevents (at least) that problem when
it cropped up with "-O -ftrace"
gcc/cobol:
PR cobol/119214
* gengen.cc: applies if( !optimize ) test
Richard Biener [Fri, 14 Mar 2025 12:09:31 +0000 (13:09 +0100)]
cobol/119281 - make sure $(gcc_version) is set for libgcobol install
When using --enable-version-specific-runtime-libs at least it's
required that $(gcc_version) is set to be able to expand
toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
The following fixes this by adjusting configure.ac to call GCC_BASE_VER
and Makefile.am to include a definition for gcc_version.
Thomas Schwinge [Mon, 11 Jul 2022 20:36:39 +0000 (22:36 +0200)]
GCN, nvptx: Don't default-disable libstdc++ build
In addition to making libstdc++ itself available, this, via enabling
'build-gcc/*/libstdc++-v3/scripts/testsuite_flags', in particular also makes
the standard C++ headers available to 'make check-gcc-c++'. With that, there
are a lot of FAIL/UNRESOLVED -> PASS progressions, where we previously ran
into, for example:
FAIL: g++.dg/coroutines/co-await-syntax-00-needs-expr.C (test for errors, line 6)
FAIL: g++.dg/coroutines/co-await-syntax-00-needs-expr.C (test for excess errors)
Excess errors:
[...]/gcc/testsuite/g++.dg/coroutines/coro.h:132:10: fatal error: cstdlib: No such file or directory
Similarly, there are a lot of FAIL/UNRESOLVED -> UNSUPPORTED "progressions" due
to 'sorry, unimplemented: exception handling not supported'.
The 'make check-target-libstdc++-v3' results don't look too bad, either.
With libstdc++ now available, libgrust gets enabled, which we in turn again
have to disable, for 'sorry, unimplemented: exception handling not supported'
reasons.
The following improves how VN performs its dominance queries to
determine availability, exploiting edges considered unreachable.
The function already contains code to handle the leader block
forking the CFG, but that looks like a situation that won't
help the dominance query ever. The following adds handling
of the more useful case where this block forwards to a CFG
merge with the forwarder being the only executable entry.
This helps optimizing the code so the spurious array diagnostic
does no longer appear.
PR tree-optimization/119274
* tree-ssa-sccvn.cc (dominated_by_p_w_unex): Handle the
top block being the only executable forwarder to a CFG
merge.
vect_slp_prefer_store_lanes_p allows an SLP tree to be split even
if the tree could use store-lanes, provided that one of the new
groups would operate on full vectors for each scalar iteration.
That heuristic is no longer firing for gcc.target/aarch64/pr99873_2.c.
The test contains:
void __attribute ((noipa))
foo (uint64_t *__restrict x, uint64_t *__restrict y, int n)
{
for (int i = 0; i < n; i += 4)
{
x[i] += y[i];
x[i + 1] += y[i + 1];
x[i + 2] |= y[i + 2];
x[i + 3] |= y[i + 3];
}
}
and wants us to use V2DI for the first two elements and V2DI for
the second two elements, rather than LD4s and ST4s. This gives:
The first loop only handles half the amount of data per iteration,
but it requires far fewer internal permutations.
One reason the heuristic no longer fired looks like a typo: the call
to vect_slp_prefer_store_lanes_p was passing "1" as the new group size,
instead of "i".
However, even with that fixed, vect_analyze_slp later falls back on
single-lane SLP with load/store lanes. I think that heuristic too
should use vect_slp_prefer_store_lanes_p (but it otherwise looks good).
The question is whether every load should pass
vect_slp_prefer_store_lanes_p or whether just one is enough.
I don't have an example that would make the call either way,
so I went for the latter, given that it's the smaller change
from the status quo.
This also appears to improve fotonik3d and roms from SPEC2017
(cross-checked against two different systems).
gcc/
* tree-vect-slp.cc (vect_build_slp_instance): Pass the new group
size (i) rather than 1 to vect_slp_prefer_store_lanes_p.
(vect_analyze_slp): Only force the use of load-lanes and
store-lanes if that is preferred for at least one load/store pair.
libstdc++: fix compile error when converting std::weak_ptr<T[]>
A std::weak_ptr<T[]> can be converted to a compatible
std::weak_ptr<U[]>. This is implemented by having suitable converting
constructors to std::weak_ptr which dispatch to the __weak_ptr base
class (implementation detail).
In __weak_ptr<T[]>, lock() is supposed to return a __shared_ptr<T[]>,
not a __shared_ptr<element_type> (that is, __shared_ptr<T>).
Unfortunately the return type of lock() and the type of the returned
__shared_ptr were mismatching and that was causing a compile error: when
converting a __weak_ptr<T[]> to a __weak_ptr<U[]> through __weak_ptr's
converting constructor, the code calls lock(), and that simply fails to
build.
Fix it by removing the usage of element_type inside lock(), and using
_Tp instead.
Note that std::weak_ptr::lock() itself was already correct; the one in
__weak_ptr was faulty (and that is the one called by __weak_ptr's
converting constructors).
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_base.h (lock): Fixed a compile error
when calling lock() on a weak_ptr<T[]>, by removing an
erroneous usage of element_type from within lock().
* testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc:
Add more tests for array types.
* testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/shared_ptr/requirements/1.cc: New test.
* testsuite/20_util/weak_ptr/requirements/1.cc: New test.
Richard Biener [Fri, 7 Mar 2025 11:57:42 +0000 (12:57 +0100)]
tree-optimization/119155 - wrong aligned access for vectorized packed access
When doing strided SLP vectorization we use the wrong alignment for
the possibly piecewise access of the vector elements for loads and
stores. While we are carefully using element aligned loads and
stores that isn't enough for the case the original scalar accesses
are packed. The following instead honors larger alignment when
present but correctly falls back to the original scalar alignment
used.
PR tree-optimization/119155
* tree-vect-stmts.cc (vectorizable_store): Do not always
use vector element alignment for VMAT_STRIDED_SLP but
a more correct alignment towards both ends.
(vectorizable_load): Likewise.
Sandra Loosemore [Wed, 12 Mar 2025 23:36:17 +0000 (23:36 +0000)]
Doc: Remove redundant info from documentation of -ansi.
The -ansi option has essentially been superseded by the more general
-std= option, and all the additional information about its effects is
already covered elsewhere in the manual. I also cleaned up some
confusing text about alternate keywords that I noticed while
confirming this.
gcc/ChangeLog
* doc/extend.texi (Alternate Keywords): Clean up text and remove
discussion of "restrict", which is not a GNU extension at all.
* doc/invoke.texi (C Dialect Options): Remove detailed discussion.
Patrick Palka [Thu, 13 Mar 2025 23:55:00 +0000 (19:55 -0400)]
libstdc++: Work around C++20 tuple<tuple<any>> constraint recursion [PR116440]
The type tuple<tuple<any>> is clearly copy/move constructible, but for
reasons that are not yet completely understood checking this triggers
constraint recursion with our C++20 tuple implementation (but not the
C++17 implementation).
It turns out this recursion stems from considering the non-template
tuple(const _Elements&) constructor during the copy/move constructibility
check. Considering this constructor is ultimately redundant, since the
defaulted copy/move constructors are better matches.
GCC has a non-standard "perfect candidate" optimization[1] that causes
overload resolution to shortcut considering template candidates if we
find a (non-template) perfect candidate. So to work around this issue
(and as a general compile-time optimization) this patch turns the
problematic constructor into a template so that GCC doesn't consider it
when checking for copy/move constructibility of this tuple type.
Changing the template-ness of a constructor can affect overload
resolution (since template-ness is a tiebreaker) so there's a risk this
change could e.g. introduce overload resolution ambiguities. But the
original C++17 implementation has long defined this constructor as a
template (in order to constrain it etc), so doing the same thing in the
C++20 mode should naturally be quite safe.
The testcase still fails with Clang (in C++20 mode) since it doesn't
implement said optimization.
Jan Hubicka [Thu, 13 Mar 2025 19:11:02 +0000 (20:11 +0100)]
Fix speculation_useful_p
This patch fixes issue with speculation and x264. With profile feedback
we first introduce speculative calls to mc_chroma which is called indirectly.
Then we propagate constants acorss these calls (which is useful transform) but
then speculation_useful_p decides that these speculations are not useful and
we end up calling unspecialized version.
This patch updates speculation_useful_p to consider edges redirected earlier
to clones as useful, since we can expect that ipa-cp knows what it is doing
(originally it only looked for inlined calls). I also noticed that we want
to keep edges even if they are not hot.
Finally I noticed a typo in computing target in code which intends to keep
devirtualized calls to functions where we propagated pureness/constness. Newly
we also track ipa-modref summaries as they also may be useful.
gcc/ChangeLog:
PR ipa/119147
* ipa-inline.cc: Include ipa-modref-tree.h and
ipa-modref.h.
(speculation_useful_p): If target is a clone, speculation is usef;
fix mixup of caller and callee; speculate also calls not considered
hot; consider modref summary also possibly useful for optimization.
* ipa-profile.cc (ipa_profile): Keep non-hot speculations.
Harald Anlauf [Thu, 13 Mar 2025 17:46:54 +0000 (18:46 +0100)]
Fortran: improve checking of substring bounds [PR119118]
Commit r15-7873 copy-pasted erroneous code containing a non-terminating
loop that did not progress its control variable, and a switch statement
with an unhandled case leading to a gcc_unreachable () with suitable input.
PR fortran/119118
gcc/fortran/ChangeLog:
* dependency.cc (contains_forall_index_p): Let loop over elements
of a constructor update its control variable. Handle REF_INQUIRY
in switch statement.
(gfc_contains_implied_index_p): Likewise.
Iain Sandoe [Mon, 10 Mar 2025 08:44:41 +0000 (08:44 +0000)]
testsuite, gm2: Use -B option for libstdc++ where required.
We need to add testsuite options to locate gm2 libs and libstdc++.
Usually '-L' options are added to point to the relevant directories for
the uninstalled libraries.
In cases where libraries are available as both shared and convenience some
additional checks are made.
For some targets -static-xxxx options are handled by specs substitution and
need a '-B' option rather than '-L'. For Darwin, when embedded runpaths are
in use (the default for all versions after macOS 10.11), '-B' is also needed
to provide the runpath.
When '-B' is used, this results in a '-L' for each path that exists (so that
appending a '-L' as well is a needless duplicate). There are also cases
where tools warn for duplicates, leading to spurious fails.
Therefore the objective of the code here is to add just one '-L' or '-B' for
each of the libraries.
Currently, we are forcing the full paths to each of the gm2 convenience libs
onto the link line and therefore the B/L logic is not needed there. It would
need to be added if/when gm2 is tested with shared libraries
gcc/testsuite/ChangeLog:
* lib/gm2.exp: Arrange for a '-B' option to be added for the
libstdc++ paths on targets that need it.
Among other things, this testcase tests an addition of the four
values (n*4+[0:3])*9//2 for each n in [0:99]. The addition is
done in multiple integer and floating-point types and the test
is compiled with -ffast-math.
One of the floating-point types is _Float16, and as Andrew says
in the PR, _Float16's limited precision means that the order of the
additions begins to matter for higher n. Specifically, some orders
begin to give different results from others at n=38, and at many
higher n as well.
This patch uses 5/3 rather than 9/2. I tested locally that
all addition orders give the same result over the test range.
gcc/testsuite/
PR testsuite/113965
* gcc.target/aarch64/sve/mask_struct_load_3_run.c: Use an
input range that is suitable for _Float16.
Jonathan Wakely [Thu, 13 Mar 2025 14:10:00 +0000 (14:10 +0000)]
libstdc++: Implement <stdckdint.h> for C++26 (P3370R1)
This is the second part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N2683.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implementations, this change defines them in namespace __gnu_cxx and
then adds them to the global namespace.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add stdckdint.h.
* include/Makefile.in: Regenerate.
* src/c++23/std.compat.cc.in: Export <stdckdint.h> functions.
* include/c_compatibility/stdckdint.h: New file.
* testsuite/26_numerics/stdckdint/1.cc: New test.
* testsuite/26_numerics/stdckdint/2_neg.cc: New test.
Jonathan Wakely [Thu, 13 Mar 2025 13:34:55 +0000 (13:34 +0000)]
libstdc++: Implement <stdbit.h> for C++26 (P3370R1)
This is the first part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N3022.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implementations, this change defines them in namespace __gnu_cxx and
then adds them to the global namespace.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add stdbit.h.
* include/Makefile.in: Regenerate.
* src/c++23/std.compat.cc.in: Export <stdbit.h> functions.
* include/c_compatibility/stdbit.h: New file.
* testsuite/20_util/stdbit/1.cc: New test.
* testsuite/20_util/stdbit/2_neg.cc: New test.
Wilco Dijkstra [Mon, 24 Feb 2025 16:38:02 +0000 (16:38 +0000)]
libgcc: Remove PREDRES and LS64 from AArch64 cpuinfo
Change AArch64 cpuinfo to follow the latest updates to the FMV spec [1]:
Remove FEAT_PREDRES and FEAT_LS64*. Preserve the ordering in enum CPUFeatures.
[1] https://github.com/ARM-software/acle/pull/382
gcc:
* common/config/aarch64/cpuinfo.h: Remove FEAT_PREDRES and FEAT_LS64*.
* config/aarch64/aarch64-option-extensions.def: Remove FMV support
for PREDRES.
libgcc:
* config/aarch64/cpuinfo.c (__init_cpu_features_constructor):
Remove FEAT_PREDRES and FEAT_LS64* support.
gcc.target/aarch64/sve/pr96357.c started failing after r15-518-g99b1daae18c095d6, which tweaked the heuristics
about when to sink code. The testcase has:
double i = d, j = 1.0 - f, k = j ? d : j;
if (k == 1.0)
i = 0.0;
*l = *n = *g = *h = i * 0.5;
where k == 1.0 is false if j is zero (since k is then also 0).
So we end up with a diamond whose condition is j != 0 && d == 1.
The else branch of the diamond is the only one that uses the result
of i = d, so after the patch, we sink the conversion to there.
And that seems like a reasonable thing to do.
However, aarch64 doesn't yet allow int->double conversions to be
predicated, so ifcvt cannot handle the sunk form, meaning that we
can no longer vectorise.
The testcase is highly artificial and so shouldn't IMO be used
to tune the sinking heuristics. Instead I think we should just
disable sinking for the test. An alternative would be to add
-ffast-math, but I think that would interfere more with the
original intent.
Patrick Palka [Thu, 13 Mar 2025 13:15:21 +0000 (09:15 -0400)]
libstdc++: Fix ref_view branch of views::as_const [PR119135]
Unlike for span<X> and empty_view<X>, the range_reference_t of
ref_view<X> doesn't correspond to X. This patch fixes the ref_view
branch of views::as_const to correctly query its underlying range
type X.
PR libstdc++/119135
libstdc++-v3/ChangeLog:
* include/std/ranges: Include <utility>.
(views::__detail::__is_ref_view): Replace with ...
(views::__detail::__is_constable_ref_view): ... this.
(views::_AsConst::operator()): Replace bogus use of element_type
in the ref_view branch.
* testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend
test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Andrew Pinski [Thu, 13 Mar 2025 00:04:47 +0000 (17:04 -0700)]
aarch64: xfail pr109072_1.c's s16x4_2 [PR117092]
The fix for this depends on much more infrastructure which won't
be done for another few weeks. Pengxuan is working on the fix for GCC 16.
So let's xfail the testcase since it is a minor code quality regression.
we get:
```
movi v0.2s, 0
ins v0.h[0], w0
```
vs what we should get:
```
and x0, x0, 65535
fmov d0, x0
```
or
```
fmov h0, x0
```
Tested for aarch64-linux-gnu.
PR target/117092
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr109072_1.c: xfail s16x4_2.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Thomas Schwinge [Wed, 5 Mar 2025 17:28:53 +0000 (18:28 +0100)]
Move 'find-dg-do-what' from 'gcc/testsuite/lib/gcc-dg.exp' into 'gcc/testsuite/lib/target-supports-dg.exp'
This was added in commit f553b1aaa2b1b925c918e5dcf966290b045321c2
"Refactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'",
for use by 'gcc/testsuite/lib/target-supports.exp'. The latter is used by
several test suites, 'gcc/testsuite/lib/gcc-dg.exp' however doesn't get loaded
for 'make check-target-libstdc++-v3', for example, and testing ERRORs out:
ERROR: (DejaGnu) proc "find-dg-do-what" does not exist.
The error code is TCL LOOKUP COMMAND find-dg-do-what
The info on the error is:
invalid command name "find-dg-do-what"
while executing
"::tcl_unknown find-dg-do-what"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"
Fix this by moving 'find-dg-do-what' into the DejaGnu interfacing file
corresponding to 'gcc/testsuite/lib/target-supports.exp':
'gcc/testsuite/lib/target-supports-dg.exp' (next to other related procedures).
/* Pattern match
tem = (sizetype) ptr;
tem = tem & algn;
tem = -tem;
... = ptr p+ tem;
and produce the simpler and easier to analyze with respect to alignment
... = ptr & ~algn; */
But the gimple in gcc.target/aarch64/sve/pr98119.c has a variant in
which a constant is added before the conversion, giving:
tem = (sizetype) (ptr p+ CST);
tem = tem & algn;
tem = -tem;
... = ptr p+ tem;
This case is also valid if algn fits within the trailing zero bits
of CST. Adding CST then has no effect.
Similarly the testcase has:
tem = (sizetype) (ptr p+ CST1);
tem = tem & algn;
tem = CST2 - tem;
... = ptr p+ tem;
This folds to:
... = (ptr & ~algn) p+ CST2;
if algn fits within the trailing zero bits of both CST1 and CST2.
An alternative would be:
... = (ptr p+ CST2) & ~algn;
but I would expect the alignment to be more easily shareable than
the CST2 addition, given that the CST2 addition wasn't being applied
by a POINTER_PLUS_EXPR.
gcc/
* match.pd: Extend pointer alignment folds so that they handle
the case where a constant is added before or after the alignment.
gcc/testsuite/
* gcc.dg/pointer-arith-11.c: New test.
* gcc.dg/pointer-arith-12.c: Likewise.
Using a combination of rules, we were able to fold
((X >> C1) & C2) * (1 << C1) --> X & (C2 << C1)
if everything was done at the same precision, but we couldn't fold
it if the AND was done at a different precision. The optimisation is
often (but not always) valid for that case too.
This patch adds a dedicated rule for the case where different precisions
are involved.
An alternative would be to extend the individual folds that together
handle the same-precision case so that those rules handle differing
precisions. But the risk is that that could replace narrow operations
with wide operations, which would be especially harmful on targets
like avr. It's also not obviously free of cycles.
I also wondered whether the converts should be non-optional.
gcc/
* match.pd: Fold ((X >> C1) & C2) * (1 << C1) to X & (C2 << C1).
gcc/testsuite/
* gcc.dg/fold-mul-and-lshift-1.c: New test.
* gcc.dg/fold-mul-and-lshift-2.c: Likewise.
gcc.target/aarch64/sve/pre_cond_share_1.c started failing after r15-276-gbed6ec161be8c5ca. However, that was incidental.
The test's inner loop is duplicated by -fswitch-loops and
that patch happened to change the copy of the loop that was
not the original focus of the test.
But this changes the behaviour when vect_distbb_170.43_191 < { 0.0, ... }.
In that case, the original code would pick an else value of vect_cst__198,
whereas the new code would pick an else value of { 0.0, ... }.
That was fixed in r14-8668-g8123f3ca3fd89103 (PR113607, patch B),
but fixing the bug (rightly) reverted the code to the previous output.
Patch B therefore XFAILed the thing that patch A was originally testing.
Since the test was added for patch A and since patch A seems to generate
incorrect code for the test, I think we should just remove it.
Tomasz Kamiński [Mon, 10 Mar 2025 15:51:57 +0000 (16:51 +0100)]
libstdc++: Hide 128-bit int and float types behind handle for basic_format_arg visitation [PR108053]
Implement visit_format_arg and basic_format_arg::visit function,
in terms of _M_visit_user member functions, that wraps any type
stored inside basic_format_arg, that is not specified in the standard,
into the handle. This affects __int128, unsigned __int128,
PowerPC specific __ieee128 and __ibm128, and _Float128 for architectures
where long double is not 128bits.
The bfloat16, _Float16, _Float32, _Float32, and _Float128 for
128bits long double are not are not addressed, as they
are transformed into a standard floating point types.
For internal purposes __format::__visit_format_arg function is
used, that provides an unmodified access to stored object.
PR libstdc++/108053
libstdc++-v3/ChangeLog:
* include/std/format (basic_format_arg::_M_visit_user):
Helper function for wrapping extension types into handle.
(visit_format_arg): Call `_M_visit_user` instead of `_M_visit`.
(basic_format_arg::visit): As above.
(__format::__visit_format_arg): Provides direct access to
values stored in basic_format_arg.
(__format::__int_from_arg): Use __format::__visit_format_arg
instead of std::visit_format_arg.
(_Formatting_scanner::_M_format_arg): As above.
(_Checking_scanner::__do_vformat_to): As above.
* testsuite/std/format/arguments/args.cc: New tests.
* testsuite/std/format/string.cc: Test for using __int128
as width/precision.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Robin Dapp [Wed, 5 Mar 2025 17:16:57 +0000 (18:16 +0100)]
RISC-V: Do not delete fused vsetvl if it has uses [PR119115].
In PR119115 we end up with an orphaned
vsetvli zero,t1,e16,m1,ta,ma.
t1 originally came from another vsetvl that was fused from
vsetvli a4,a3,e8,mf2,ta,ma
vsetvli t1,a3,e8,mf2,ta,ma (1)
to
vsetvli zero,a3,e16,m1,ta,ma.
This patch checks if t1, the VL operand of (1), has AVL uses and does
not delete the vsetvl if so. While doing so, it also wraps the search
for VL uses into two new functions reg_used and reg_single_use_in_avl.
PR target/119115
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (reg_used): New function.
(reg_single_use_in_avl): Ditto.
(pre_vsetvl::fuse_local_vsetvl_info): Use reg_single_use_in_avl
when checking if vsetvl can be deleted.
Robin Dapp [Tue, 25 Feb 2025 11:55:08 +0000 (12:55 +0100)]
RISC-V: Adjust LMUL when using maximum SEW [PR117955].
When merging two vsetvls that both only demand "SEW >= ..." we
use their maximum SEW and keep the LMUL. That may lead to invalid
vector configurations like
e64, mf4.
As we make sure that the SEW requirements overlap we can use the SEW
and LMUL of the configuration with the larger SEW.
Ma Jin already touched this merge rule some weeks ago and fixed the
ratio calculation (r15-6873). Calculating the ratio from an invalid
SEW/LMUL combination lead to an overflow in the ratio variable, though.
I'd argue the proper fix is to update SEW and LMUL, keeping the ratio
as before. This "breaks" bug-10.c but its check only checked for a
workaround anyway so I turned it into a run test.
Ma Jin helped minify the PR's test and provided a larger test case for
bug-10.
PR target/117955
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Use LMUL/ratio from vsetvl with
larger SEW.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/bug-10.c: Convert to run test.
* gcc.target/riscv/rvv/base/bug-10-2.c: New test.
* gcc.target/riscv/rvv/base/pr117955.c: New test.
Richard Biener [Wed, 12 Mar 2025 12:46:14 +0000 (13:46 +0100)]
cobol/119229 - fix external variable declaration
The following makes vs_external_reference behave like documented,
declare a variable defined elsewhere which means not setting
TREE_STATIC but DECL_EXTERNAL.
Built on x86_64-unknown-linux-gnu, tested with the cobol.dg
testsuite (which doesn't mean much). The removed comment mentions
'stderr', possibly the NIST testsuite has coverage.
OK for trunk?
Thanks,
Richard.
PR cobol/119229
* gengen.cc (gg_declare_variable): Use DECL_EXTERNAL and
drop TREE_STATIC for vs_external_reference.
Matthias Klose [Thu, 13 Mar 2025 06:22:02 +0000 (07:22 +0100)]
Allow to build libgccjit with a soname bound to the GCC major version
When configuring GCC with --program-suffix=-$(BASE_VERSION) to allow
installation multiple GCC versions in parallel, the executable of the
driver (gcc-$(BASE_VERSION)) gets recorded in the libgccjit.so.0
library. Assuming, that you only install the libgccjit.so.0 library
from the newest GCC, you have a libgccjit installed, which always calls
back to the newest installed version of GCC. I'm not saying that the
ABI is changing, but I'd like to see the libgccjit calling out to the
corresponding compiler, and therefore installing a libgccjit with a
soname that matches the GCC major version.
The downside is having to rebuild packages built against libgccjit with
each major GCC version, but looking at the reverse dependencies, at
least for package builds, only emacs is using libgccjit.
My plan to use this feature is to build a libgccjit0 using the default
GCC (e.g. gcc-14), and a libgccjit15, when building a newer GCC. When
changing the GCC default to 15, building a libgccjit0 from gcc-15, and a
libgccjit14 from gcc-14.
When configuring without --enable-versioned-jit, the behavior is unchanged.
2025-03-13 Matthias Klose <doko@ubuntu.com>
gcc/
* configure.ac: Add option --enable-versioned-jit.
* configure: Regenerate.
* Makefile.in: Move from jit/Make-lang.in, setting value from
configure.ac.
* doc/install.texi: Document option --enable-versioned-jit.
gcc/jit/
* Make-lang.in (LIBGCCJIT_VERSION_NUM): Move to ../Makefile.in.
David Malcolm [Thu, 13 Mar 2025 00:51:06 +0000 (20:51 -0400)]
analyzer: support RAW_DATA_CST [PR117262]
gcc/analyzer/ChangeLog:
PR analyzer/117262
* region-model-manager.cc
(region_model_manager::get_or_create_constant_svalue): Use
NULL_TREE for the types of constant_svalue for RAW_DATA_CST.
(region_model_manager::maybe_fold_sub_svalue): Generalize
STRING_CST logic to also handle RAW_DATA_CST.
(region_model_manager::maybe_get_char_from_cst): New.
(region_model_manager::maybe_get_char_from_raw_data_cst): New.
* region-model-manager.h
(region_model_manager::maybe_get_char_from_cst): New decl.
(region_model_manager::maybe_get_char_from_raw_data_cst): New decl.
* region-model.cc (region_model::get_rvalue_1): Handle
RAW_DATA_CST.
* store.cc (get_subregion_within_ctor_for_ctor_pair): New.
(binding_map::apply_ctor_pair_to_child_region): Call
get_subregion_within_ctor_for_ctor_pair so that we handle
RAW_DATA_CST.
gcc/testsuite/ChangeLog:
PR analyzer/117262
* c-c++-common/analyzer/raw-data-cst-pr117262-1.c: New test.
* c-c++-common/analyzer/raw-data-cst-pr117262-2.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jakub Jelinek [Wed, 12 Mar 2025 23:42:54 +0000 (00:42 +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 <jakub@redhat.com>
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.
Nathaniel Shead [Sat, 8 Feb 2025 13:37:48 +0000 (00:37 +1100)]
c++/modules: Better handle no-linkage decls in unnamed namespaces [PR118799]
There are two issues with no-linkage decls (e.g. explicit type aliases)
in unnamed namespaces that this patch fixes.
Firstly, we don't currently handle exporting no-linkage decls in unnamed
namespaces. This should be ill-formed in [module.export], since having
an exported declaration within a namespace-definition makes the
namespace definition exported (p2), but an unnamed namespace has
internal linkage thus violating p3.
Secondly, by the standard it appears to be possible to emit unnamed
namespaces from named modules in certain scenarios, for instance when
they contain a type alias (which is not itself an entity). This patch
makes the adjustments needed to ensure we don't error in this scenario.
PR c++/118799
gcc/cp/ChangeLog:
* module.cc (depset::hash::is_tu_local_entity): Only types,
functions, variables, and template (specialisations) can be
TU-local. Explicit type aliases are TU-local iff the type they
refer to are.
(module_state::write_namespaces): Allow unnamed namespaces in
named modules.
(check_module_decl_linkage): Error for all exported declarations
in an unnamed namespace.
gcc/testsuite/ChangeLog:
* g++.dg/modules/export-6.C: Adjust error message, add check for
no-linkage decls in namespace.
* g++.dg/modules/internal-4_b.C: Allow exposing a namespace with
internal linkage. Type aliases are not entities and so never
exposures.
* g++.dg/modules/using-30_a.C: New test.
* g++.dg/modules/using-30_b.C: New test.
* g++.dg/modules/using-30_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Currently, note_vague_linkage_fn is called on all definitions imported
from modules. This is not correct, however; among other things, a
gnu_inline function does not have vague linkage, and causes an ICE if
its treated as such.
There are other things that we seem to potentially miss (e.g. dllexport
handling), so it seems sensible to stop trying to manage linkage in such
an ad-hoc manner but to use the normal interfaces more often. While
looking at this I also found that we seem to miss marking vague linkage
variables as COMDAT, so this patch fixes that as well.
The change to use expand_or_defer_fn exposes a checking-only ICE in
trees_in::assert_definition, where we forget that we already installed a
definition for a function. We work around this by instead of clearing
DECL_SAVED_TREE entirely in expand_or_defer_fn_1, we instead set it to a
dummy value. This way we can also avoid the check for !TREE_ASM_WRITTEN
beforehand.
PR c++/119154
gcc/cp/ChangeLog:
* decl2.cc (vague_linkage_p): Don't treat gnu_inline functions
as having vague linkage.
* module.cc (trees_out::core_bools): Clear DECL_INTERFACE_KNOWN
for vague-linkage entities.
(read_var_def): Maybe set comdat linkage for imported var
definitions.
(module_state::read_cluster): Use expand_or_defer_fn instead of
ad-hoc linkage management.
(post_load_processing): Likewise.
* semantics.cc (expand_or_defer_fn_1): Don't forget that we had
a definition at all.
gcc/testsuite/ChangeLog:
* g++.dg/modules/linkage-3_a.C: New test.
* g++.dg/modules/linkage-3_b.C: New test.
* g++.dg/modules/pr119154_a.C: New test.
* g++.dg/modules/pr119154_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
d = MEM <unsigned char[4]> [(struct A *)&TARGET_EXPR <D.2894, foo()]
= MEM <unsigned char[4]> [(struct A *)(const struct A &) &e],
TARGET_EXPR <D.2894, foo()>
that is, a COMPOUND_EXPR where a TARGET_EXPR is used twice, and its
address is taken in the left-hand side operand, so it can't be elided.
But set_target_expr_eliding simply recurses on the second operand of
a COMPOUND_EXPR and marks the TARGET_EXPR as eliding. This then causes
a crash.
cp_build_indirect_ref_1 should not be changing the value category.
While *&TARGET_EXPR is an lvalue, folding it into TARGET_EXPR would
render is a prvalue of class type.
PR c++/117512
gcc/cp/ChangeLog:
* typeck.cc (cp_build_indirect_ref_1): Only do the *&e -> e
folding if the result would be an lvalue.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alignas23.C: New test.
* g++.dg/ext/align3.C: New test.
* g++.dg/ext/align4.C: New test.
* g++.dg/ext/align5.C: New test.
Simon Martin [Wed, 12 Mar 2025 19:15:39 +0000 (20:15 +0100)]
c++: Look through capture proxy from outer lambda instead of erroring out [PR110584]
We've been rejecting this valid code since r8-4571:
=== cut here ===
void foo (float);
int main () {
constexpr float x = 0;
(void) [&] () {
foo (x);
(void) [] () {
foo (x);
};
};
}
=== cut here ===
The problem is that when processing X in the inner lambda,
process_outer_var_ref errors out even though it does find the constant
capture from the enclosing lambda.
This patch makes sure that process_outer_var_ref properly looks through
normal capture proxies, if any.
PR c++/110584
gcc/cp/ChangeLog:
* cp-tree.h (strip_normal_capture_proxy): Declare.
* lambda.cc (strip_normal_capture_proxy): New function to look
through normal capture proxies.
(build_capture_proxy): Use it.
* semantics.cc (process_outer_var_ref): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-nested10.C: New test.
This test has been failing since gcc-6. The test was always very
fragile anyway since it relied on an auto-inc being created and then
split by the subreg2 (later the subreg3) pass. But the code to get
precisely these conditions was very long-winded and unlikely to be
immune to other changes in the compiler (as proved to be the case).
There's no obvious way to recreate the exact conditions we were
testing for, so just remove the test.
Marek Polacek [Fri, 7 Mar 2025 16:26:46 +0000 (11:26 -0500)]
c++: ICE with lambda in fold expression in requires [PR119134]
The r12-8258 fix assumes that DECL_CONTEXT of 'pack' in
check_for_bare_parameter_packs is going to be an operator()
but as this test shows, it can be empty.
This change makes the check_dynamic_spec precondition checks slightly
faster to compile, and avoids those checks entirely for the common cases
of calling check_dynamic_spec_integral or check_dynamic_spec_string.
Instead of checking for unique types by keeping counts in an array and
looping over that array, we can just keep a sum of how many valid types
are present, and check that it equals the total number of types in the
pack.
The diagnostic is slightly worse now, because there's only a single
"invalid template argument types" string that appears in the output,
where previously we had either "non-unique template argument type" or
"disallowed template argument type", depending on the failure mode.
Given that most users will never use this function directly, and
probably won't use invalid types anyway, the inferior diagnostic seems
acceptable.
libstdc++-v3/ChangeLog:
* include/std/format (basic_format_parse_context::__once): New
variable template.
(basic_format_parse_context::__valid_types_for_check_dynamic_spec):
New function template for checking argument types.
(basic_format_parse_context::__check_dynamic_spec): New function
template to implement the common check_dynamic_spec logic.
(basic_format_parse_context::check_dynamic_spec_integral): Call
__check_dynamic_spec instead of check_dynamic_spec.
(basic_format_parse_context::check_dynamic_spec_string):
Likewise. Use _CharT instead of char_type consistently.
(basic_format_parse_context::check_dynamic_spec): Use
__valid_types_for_check_dynamic_spec for precondition checks and
call __check_dynamic_spec for checking the arg id.
* testsuite/std/format/parse_ctx_neg.cc: Adjust expected errors.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Mon, 10 Mar 2025 14:29:36 +0000 (14:29 +0000)]
libstdc++: Add static_assert to std::packaged_task::packaged_task(F&&)
LWG 4154 (approved in Wrocław, November 2024) fixed the Mandates:
precondition for std::packaged_task::packaged_task(F&&) to match what
the implementation actually requires. We already gave a diagnostic in
the right cases as required by the issue resolution, so strictly
speaking we don't need to do anything. But the current diagnostic comes
from inside the implementation of std::__invoke_r and could be more
user-friendly.
For C++17 (when std::is_invocable_r_v is available) add a static_assert
to the constructor, so the error is clear:
Jonathan Wakely [Fri, 12 Jan 2024 16:57:41 +0000 (16:57 +0000)]
libstdc++: Update tzdata to 2025a
Import the new 2025a tzdata.zi file. The leapseconds file was also
updated to have a new expiry (no new leap seconds were added).
libstdc++-v3/ChangeLog:
* include/std/chrono (__detail::__get_leap_second_info): Update
expiry date for leap seconds list.
* src/c++20/tzdata.zi: Import new file from 2025a release.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds)
Update expiry date for leap seconds list.
Jason Merrill [Tue, 11 Mar 2025 21:43:35 +0000 (17:43 -0400)]
contrib: relpath.sh /lib /include [PR119081]
Previously, if the common ancestor of the two paths is / we would print the
absolute second argument, but this PR asks for a relative path in that case
as well, which makes sense for the libstdc++.modules.json use case.
Alex Coplan [Mon, 10 Mar 2025 16:44:15 +0000 (16:44 +0000)]
df: Treat partial defs as uses in df_simulate_defs [PR116564]
The PR shows us spinning in dce.cc:fast_dce at the start of combine.
This spinning appears to be because of a disagreement between the fast_dce code
and the code in df-problems.cc:df_lr_bb_local_compute. Specifically, they
disagree on the treatment of partial defs. For the testcase in the PR, we have
the following insn in bb 3:
i.e. it models partial defs as a RMW operation; thus for the def arising
from i10 above, it records a use of r104; hence it ends up in the
live-in set for bb 3.
However, as it stands, the code in dce.cc:fast_dce (and its callee
dce_process_block) has no such provision for DF_REF_PARTIAL defs. It
does not treat these as a RMW and does not compute r104 above as being
live-in to bb 3. At the end of dce_process_block we compute the
following "did something happen" condition used to decide termination of
the analysis:
because of the disagreement between df_lr_local_compute and the local
analysis done by fast_dce, we invariably have r104 in DF_LR_IN, but not
in local_live. Hence we always return true here, call
df_analyze_problem (which re-computes DF_LR_IN according to
df_lr_bb_local_compute, re-adding r104), and so the analysis never
terminates.
This patch therefore adjusts df_simulate_defs (called from
dce_process_block) to match the behaviour of df_lr_bb_local_compute in
this respect, namely we make it model partial defs as RMW operations by
setting the relevant register live. This fixes the spinning in fast_dce
for this testcase.
gcc/ChangeLog:
PR rtl-optimization/116564
* df-problems.cc (df_simulate_defs): For partial defs, mark the
register live (treat it as a RMW operation).
gcc/testsuite/ChangeLog:
PR rtl-optimization/116564
* gcc.target/aarch64/torture/pr116564.c: New test.
- Import phobos v2.111.0-beta.1.
- Added `bitCast' function to `std.conv'.
- Added `readfln' and `File.readfln' functions to `std.stdio'.
- New procedural API for `std.sumtype'.
Richard Earnshaw [Mon, 10 Mar 2025 14:12:38 +0000 (14:12 +0000)]
arm: allow type-punning subregs in vpr_register_operand [PR115439]
Subregs that only change the mode of an operand (ie don't change the
size) should be safe for the VPR register. If we don't permit them
we may end up with some redundant copy instructions.
Fortran: Add F2018 TEAM_NUMBER to coindexed expressions [PR98903]
Add missing parsing and code generation for a[..., TEAM_NUMBER=...] as
defined from F2015 onwards. Because F2015 is not used as dedicated
standard in GFortran add it to the F2018 standard feature set.
PR fortran/98903
gcc/fortran/ChangeLog:
* array.cc (gfc_copy_array_ref): Copy team, team_type and stat.
(match_team_or_stat): Match a single team(_number)= or stat=.
(gfc_match_array_ref): Add switching to image_selector_parsing
and error handling when indices come after named arguments.
* coarray.cc (move_coarray_ref): Move also team_type.
* expr.cc (gfc_free_ref_list): Free team and stat expression.
(gfc_find_team_co): Find team or team_number in array-ref.
* gfortran.h (enum gfc_array_ref_team_type): New enum to
distinguish unset, team or team_number expression.
(gfc_find_team_co): Default searching to team= expressions.
* resolve.cc (resolve_array_ref): Check for type correctness of
team(_number) and stats in coindices.
* trans-array.cc (gfc_conv_array_ref): Ensure stat is cleared
when fcoarray=single is used.
* trans-intrinsic.cc (conv_stat_and_team): Including team_number
in conversion.
(gfc_conv_intrinsic_caf_get): Propagate team_number to ABI
routine.
(conv_caf_send_to_remote): Same.
(conv_caf_sendget): Same.
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/coindexed_2.f90: New test.
* gfortran.dg/coarray/coindexed_3.f08: New test.
* gfortran.dg/coarray/coindexed_4.f08: New test.
Tomasz Kamiński [Tue, 11 Mar 2025 10:59:36 +0000 (11:59 +0100)]
libstdc++: Correct preprocessing checks for floatX_t and bfloat_16 formatting
Floating points types _Float16, _Float32, _Float64, and bfloat16,
can be formatted only if std::to_chars overloads for such types
were provided. Currently this is only the case for architectures
where float and double are 32-bits and 64-bits IEEE floating points types.
This patch updates the preprocessing checks for formatters
for above types to check _GLIBCXX_FLOAT_IS_IEEE_BINARY32
and _GLIBCXX_DOUBLE_IS_IEEE_BINARY64. Making them non-formattable
on non-IEEE architectures.
Remove a potential UB, where we could produce basic_format_arg
with _M_type set to _Arg_fp32 or _Arg_fp64, that was later not
handled by `_M_visit`.
libstdc++-v3/ChangeLog:
* include/std/format (formatter<_Float16, _CharT>): Define only if
_GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is defined.
(formatter<_Float16, _CharT>): As above.
(formatter<__gnu_cxx::__bfloat16_t, _CharT>): As above.
(formatter<_Float64, _CharT>): Define only if
_GLIBCXX_DOUBLE_IS_IEEE_BINARY64 is defined.
(basic_format_arg::_S_to_arg_type): Normalize _Float32 and _Float64
only to float and double respectivelly.
(basic_format_arg::_S_to_enum): Remove handling of _Float32 and _Float64.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Mark Wielaard [Wed, 12 Mar 2025 11:29:24 +0000 (12:29 +0100)]
Regenerate cobol/lang.opt.urls
With the COBOL: Frontend (commit 3c5ed996a) came a lang.opt.urls,
which is different from what regenerate-opt-urls.py generates. Make
the CI bot happy by regenerating it.
Longer term, the COBOL docs need to be sorted out (see e.g. PR119227)
and then perhaps regenerate-opt-urls.py adjusted so that it can deal
with the COBOL docs.
Simon Martin [Wed, 12 Mar 2025 08:09:35 +0000 (09:09 +0100)]
cobol: Remove unnecesssary CPPFLAGS update and restore MacOS build
The build currently fails on MacOS even when the Cobol front-end and
libgcobol builds are disabled.
The problem is that gcc/cobol/Make-lang.in adds -Iinclude to CPPFLAGS,
which somehow makes clang unhappy about the include order:
error: <cstddef> tried including <stddef.h> but didn't find libc++'s
<stddef.h> header. This usually means that your header search paths
are not configured properly.
It turns out that this addition is unnecessary: simply removing it fixes
the build on MacOS, without impacting the build x86_64-pc-linux-gnu when
configured with --enable-languages=default,cobol.
It feels like there might be more cleanup opportunities there, but they
can be taken care of later.
Jonathan Wakely [Tue, 11 Mar 2025 17:29:01 +0000 (17:29 +0000)]
libstdc++: Prevent dangling references in std::unique_ptr::operator*
LWG 4148 (approved in Wrocław, November 2024) makes it ill-formed to
dereference a std::unique_ptr if that would return a dangling reference.
That can happen with a custom pointer type and a const-qualified
element_type, such that std::add_lvalue_reference_t<element_type> is a
reference-to-const that could bind to a short-lived temporary.
In C++26 the compiler diagnoses this as an error anyway:
bits/unique_ptr.h:457:16: error: returning reference to temporary [-Wreturn-local-addr]
But that can be disabled with -Wno-return-local-addr so the
static_assert ensures it is enforced consistently.
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (unique_ptr::operator*): Add
static_assert to check for dangling reference, as per LWG 4148.
* testsuite/20_util/unique_ptr/lwg4148.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Tue, 11 Mar 2025 15:47:21 +0000 (15:47 +0000)]
libstdc++: Make range adaptor __has_arrow helper use a const type
LWG 4112 (approved in Wrocław, November 2024) changes the has-arrow
helper to require operator-> to be valid on a const-qualified lvalue.
This affects the constraints for filter_view::_Iterator::operator-> and
join_view::_Iterator::operator-> so that they can only be used if the
underlying iterator supports operator-> on const.
The change also adds semantic (i.e. not checkable and not enforced)
requirements that operator-> must have the same semantics whether called
on a const or non-const value, and on an lvalue or rvalue (due to the
implicit expression variation rules in [concepts.equality]).
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (ranges::_detail::__has_arrow):
Require operator->() to be valid on const-qualified type, as per
LWG 4112.
* testsuite/std/ranges/adaptors/lwg4112.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
LWG 4142 (approved in Wrocław, November 2024) made it ill-formed to call
basic_format_parse_context::check_dynamic_spec with an empty template
argument list.
This adds a static_assert to enforce that, and adjusts the tests.
libstdc++-v3/ChangeLog:
* include/std/format
(basic_format_parse_context::check_dynamic_spec): Require a
non-empty parameter pack, as per LWG 4142.
* testsuite/std/format/parse_ctx.cc: Remove call of
check_dynamic_spec with empty template argument list.
* testsuite/std/format/parse_ctx_neg.cc: Add dg-error to call of
check_dynamic_spec with empty template argument list.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
aarch64: Make latency account for synthetic VEC_PERM_EXPRs [PR116901]
Another problem in pr110625_[24].c was that the latency calculations
were ignoring VEC_PERM_EXPRs that had no associated stmt_vec_info.
Such VEC_PERM_EXPRs are common and expected for SLP these days.
After this change, the number of general ops in the testcases seems
to be accurate apart from one remaining detail: we assume that the
extension in a permuted extending load is free, even though the
extension happens after the permutation. Fixing that would require
more information from the vectoriser and so isn't GCC 15 material.
It also should cease to be a problem if we do end up moving the
permutation to its own node, rather than keeping it as part of
the load.
gcc/
PR target/116901
* config/aarch64/aarch64.cc (aarch64_vector_costs::count_ops): Allow
stmt_info to be null.
(aarch64_vector_costs::add_stmt_cost): Call count_ops even if
stmt_info is null.
vect: Fix ncopies when costing SLP reductions [PR116901]
pr110625_[24].c started failing after r15-1329-gd66b820f392aa9a7,
which switched to single def-use cycles for single-lane SLP.
The problem is that we only costed one vector accumulator
operation for an N-vector cycle.
The problem seems to have been latent, and meant that we also
only costed one FADDA for reduc_strict_4.c and reduc_strict_5.c,
even though they need 4 and 6 FADDAs respectively.
I'm not sure why:
if ((double_reduc || reduction_type != TREE_CODE_REDUCTION)
&& ncopies > 1)
was previously only necessary for non-SLP, but the patch preserves
that for safety.
gcc/
PR tree-optimization/116901
* tree-vect-loop.cc (vectorizable_reduction): Set ncopies to
SLP_TREE_NUMBER_OF_VEC_STMTS for SLP.
Before r14-2877-gbf67bf4880ce5be0, the aarch64 code assumed that
every multi-vector reduction would use single def-use cycles.
The patch fixed it to test what the vectoriser actually planned
to do, using newly provided information.
At the time, we didn't try to use single def-use cycles for any costed
variant in the associated testcase (gcc.target/aarch64/pr110625_1.c),
so it was enough to check that the single-def-use latency was never
printed to the dump file. However, we do now consider using single
def-use cycles for the single-lane SLP fallback.
This patch therefore switches to a positive test of the
non-single-def-use latency. I checked that the test still failed
in this form before r14-2877-gbf67bf4880ce5be0.
gcc/testsuite/
* gcc.target/aarch64/pr110625_1.c: Turn into a positive test for
a vector latency of 2, rather than a negative test for a vector
latency of 8.
Richard Biener [Tue, 11 Mar 2025 08:39:06 +0000 (09:39 +0100)]
Simple cobol.dg testsuite
The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has three tests, two execution test and
one test exercising dg-error. The existing FAIL is due to an assembling
error, tracked by PR119214.
Jakub Jelinek [Wed, 12 Mar 2025 07:27:17 +0000 (08:27 +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 <jakub@redhat.com>
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).
Jakub Jelinek [Wed, 12 Mar 2025 07:01:09 +0000 (08:01 +0100)]
c++: Handle RAW_DATA_CST in modules.cc [PR119076]
The following testcases (one with #embed, one with large initializer
turned into RAW_DATA_CST) show that I forgot to handle RAW_DATA_CST in
module streaming.
Similar to the PCH case we need to stream out RAW_DATA_CST with NULL
RAW_DATA_OWNER (i.e. a tree which has data owned by libcpp buffer) so
that it will be streamed back in as STRING_CST which owns the data,
but because the data can be really large (hopefully not so much for
header modules though), without actually trying to build a STRING_CST
on the module writing side because that would mean another large
allocation and copying of the large data.
RAW_DATA_CST with RAW_DATA_OWNER then needs to be streamed out and in
by streaming the owner and offset from owner's data and length.
* g++.dg/modules/pr119076-1_a.H: New test.
* g++.dg/modules/pr119076-1_b.C: New test.
* g++.dg/modules/pr119076-2_a.H: New test.
* g++.dg/modules/pr119076-2_b.C: New test.
Jakub Jelinek [Wed, 12 Mar 2025 06:46:25 +0000 (07:46 +0100)]
preprocessor: Fix up diagnostic typo in convert_oct [PR119202]
In r15-4286 I've introduced a typo, part of the change was
- cpp_error (pfile, CPP_DL_ERROR, "'\\o' not followed by '{'");
+ cpp_error (pfile, CPP_DL_ERROR, "%<\\o%> not followed by %<}%>");
which turned { into }. This patch fixes it back.
2025-03-12 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/119202
* charset.cc (convert_oct): Fix up typo in diagnostics about \o
not followed by {.
My/Kees' earlier patches adjusted -Wunterminated-string-initialization
warning so that it doesn't warn about initializers of nonstring decls
and that nonstring attribute is allowed on multi-dimensional arrays.
Unfortunately as this testcase shows, we still warn about initializers
of multi-dimensional array nonstring decls.
The problem is that in that case field passed to output_init_element
is actually INTEGER_CST, index into the array.
For RECORD_OR_UNION_TYPE_P (constructor_type) field is a FIELD_DECL
which we want to use, but otherwise (in arrays) IMHO we want to use
constructor_fields (which is the innermost FIELD_DECL whose part
is being initialized), or - if that is NULL - constructor_decl, the
whole decl being initialized with multi-dimensional array type.
2025-03-11 Jakub Jelinek <jakub@redhat.com>
PR c/117178
* c-typeck.cc (output_init_element): Pass field to digest_init
only for record/union types, otherwise pass constructor_fields
if non-NULL and constructor_decl if constructor_fields is NULL.
* gcc.dg/Wunterminated-string-initialization-2.c: New test.
Andrew Pinski [Tue, 11 Mar 2025 06:10:01 +0000 (23:10 -0700)]
aarch64: Fix DFP constants [PR119131]
After r15-6660-g45d306a835cb3f865, in some cases
DFP constants would cause an ICE. This is due to
do a mismatch of a few things. The predicate of the move
uses aarch64_valid_fp_move to say if the constant is valid or not.
But after reload/LRA when can_create_pseudo_p returns false; aarch64_valid_fp_move
would return false for constants that were valid for the constraints
of the instruction. A strictor predicate compared to the constraint is wrong.
In this case `Uvi` is the constraint while aarch64_valid_fp_move allows it
via aarch64_can_const_movi_rtx_p for !DECIMAL_FLOAT_MODE_P, there is no such check
for DECIMAL_FLOAT_MODE_P.
The fix is to remove the check !DECIMAL_FLOAT_MODE_P in aarch64_valid_fp_move
and in the define_expand. As now the predicate allows a superset of what is allowed
by the constraints.
aarch64_float_const_representable_p should be rejecting DFP modes as they can't be used
with instructions like `mov s0, 1.0`.
Changes since v1:
* v2: Add check to aarch64_float_const_representable_p for DFP.
Built and tested on aarch64-linux-gnu with no regressions.
Jason Merrill [Mon, 10 Mar 2025 18:10:52 +0000 (14:10 -0400)]
c++: constexpr caching deleted pointer [PR119162]
In this testcase, we pass the checks for mismatched new/delete because the
pointer is deleted before it is returned. And then a subsequent evaluation
uses the cached value, but the deleted heap var isn't in
ctx->global->heap_vars anymore, so cxx_eval_outermost_constant_expr doesn't
run find_heap_var_refs, and ends up with garbage.
Fixed by not caching a reference to deleted.
I considered rejecting such a reference immediately as non-constant, but I
don't think that's valid; an invalid pointer value isn't UB until we try to
do something with it or it winds up in the final result of constant
evaluation.
I also considered not caching other heap references (i.e. using
find_heap_var_refs instead of adding find_deleted_heap_var), which would
include heap pointers passed in from the caller, but those don't have the
same heap_vars problem. We might want cxx_eval_outermost_constant_expr to
prune constexpr_call entries that refer to objects created during the
evaluation, but that applies to local variables and temporaries just as much
as heap "variables".
PR c++/119162
gcc/cp/ChangeLog:
* constexpr.cc (find_deleted_heap_var): New.
(cxx_eval_call_expression): Don't cache a
reference to heap_deleted.
Sandra Loosemore [Tue, 11 Mar 2025 16:36:22 +0000 (16:36 +0000)]
OpenMP/C: Store location in cp_parser_omp_var_list for kind=0 [PR118579]
This patch is the C equivalent of commit r15-6512-gcf94ba812ca496 for C++,
to improve the location information for individual items in an OpenMP
variable list.
gcc/c/ChangeLog
PR c/118579
* c-parser.cc (c_parser_omp_variable_list): Capture location
information when KIND is OMP_CLAUSE_ERROR.
(c_parser_oacc_data_clause_deviceptr): Use the improved location
for diagnostics, and remove the FIXME.
(c_finish_omp_declare_variant): Likewise.
(c_parser_omp_threadprivate): Likewise.
gcc/testsuite/ChangeLog
PR c/118579
* c-c++-common/gomp/pr118579.c: New testcase.
Jonathan Wakely [Thu, 6 Mar 2025 20:28:07 +0000 (20:28 +0000)]
contrib: Clean up outdated parts of gcc-git-customization.sh
It's very unlikely that anybody is still using the old remotes/$user Git
repo setup and still needs this script to be able to migrate it to the
remotes/users/$user structure. Simplify the script by removing those
parts.
This fixes an error that gets displayed in some circumstances:
fatal: no such section: remote.me
contrib/ChangeLog:
* gcc-git-customization.sh: Delete outdated commands for
migrating from very old git setups.
Iain Buclaw [Tue, 11 Mar 2025 16:56:18 +0000 (17:56 +0100)]
d: Fix regression returning from function with invariants [PR119139]
An optimization was added in GDC-12 which sets the TREE_READONLY flag on
all local variables with the storage class `const' assigned. For some
reason, const is also being added by the front-end to `__result'
variables in non-virtual functions, which ends up getting wrong code by
the gimplify pass promoting the local to static storage.
A bug has been raised upstream, as this looks like an error in the AST.
For now, turn off setting TREE_READONLY on all result variables.
PR d/119139
gcc/d/ChangeLog:
* decl.cc (get_symbol_decl): Don't set TREE_READONLY for __result
declarations.
Harald Anlauf [Mon, 10 Mar 2025 21:24:27 +0000 (22:24 +0100)]
Fortran: reject SAVE of a COMMON in a BLOCK construct [PR119199]
PR fortran/119199
gcc/fortran/ChangeLog:
* decl.cc (gfc_match_save): Reject SAVE statement of a COMMON block
when in a BLOCK construct.
* trans-common.cc (translate_common): Avoid NULL pointer dereference.
gcc/testsuite/ChangeLog:
* gfortran.dg/common_30.f90: New test.
* gfortran.dg/common_31.f90: New test.
gcc.target/aarch64/sve/pred-not-gen-[14].c started failing after r15-268-g9dbff9c05520a74e, but we didn't look at it in time for
GCC 15. This patch marks the failures as expected for now.
We should revisit for GCC 16.
See the PR for some discussion about what a GCC 16 fix might
look like.
Thomas Koenig [Tue, 11 Mar 2025 16:40:57 +0000 (17:40 +0100)]
Abstract interfaces and dummy arguments are not global.
The attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.
gcc/fortran/ChangeLog:
PR fortran/119078
* frontend-passes.cc (check_against_globals): Do not check
for abstract interfaces or dummy arguments.
* resolve.cc (gfc_verify_binding_labels): Adjust comment.
Do not put abstract interfaces or dummy argument into global
namespace.
gcc/testsuite/ChangeLog:
PR fortran/119078
* gfortran.dg/interface_58.f90: New test.
For many functions in tbz_2.c, it doesn't matter whether the code
tests a 32-bit or a 64-bit register. g6-g8 have started testing
32-bit registers, but the others could in future too.
gcc/testsuite/
* gcc.target/aarch64/tbz_2.c: Accept both 32-bit and 64-bit registers.
Juergen Christ [Mon, 10 Mar 2025 09:03:36 +0000 (10:03 +0100)]
s390: fix delegitimization of addresses
In legitimize_pic_address we create a
(const (unspec ... UNSPEC_GOTENT))
in the GOT offset might be >= 4k. However, the
s390_delegitimize_address does not contain a case for this scenario.
Jakub Jelinek [Tue, 11 Mar 2025 13:34:01 +0000 (14:34 +0100)]
cobol: Fix up libgcobol configure [PR119216]
Sorry, seems I've screwed up the earlier libgcobol/configure.tgt change.
Looking in more detail, the way e.g. libsanitizer/configure.tgt works is
that it is sourced twice, once at toplevel and there it just sets
UNSUPPORTED=1 for fully unsupported triplets, and then inside of
libsanitizer/configure where it decides to include or not include the
various sublibraries depending on the *_SUPPORTED flags.
So, the following patch attempts to do the same for libgcobol as well.
The BIULD_LIBGCOBOL automake conditional was unused, this patch guards it
on LIBGCOBOL_SUPPORTED as well and guards with it
toolexeclib_LTLIBRARIES = libgcobol.la
Also, AM_CFLAGS has been changed to AM_CXXFLAGS as there are just C++
sources in the library.
2025-03-11 Jakub Jelinek <jakub@redhat.com>
PR cobol/119216
* configure.ac: Check for UNSUPPORTED set by libgcobol/configure.tgt
rather than LIBGCOBOL_SUPPORTED.
* configure: Regenerate.
libgcobol/
* configure.tgt: On fully unsupported targets set UNSUPPORTED=1.
* configure.ac: Add AC_CHECK_SIZEOF([void *]), source in
configure.tgt and set BUILD_LIBGCOBOL also based on
LIBGCOBOL_SUPPORTED.
* Makefile.am (toolexeclib_LTLIBRARIES): Conditionalize on
BUILD_LIBGCOBOL.
(AM_CFLAGS): Rename to ...
(AM_CXXFLAGS): ... this.
(%.lo: %.cc): Use $(AM_CXXFLAGS) rather than $(AM_CFLAGS).
* configure: Regenerate.
* Makefile.in: Regenerate.
Jakub Jelinek [Tue, 11 Mar 2025 13:25:19 +0000 (14:25 +0100)]
cobol: libgcobol/Makefile.am cleanups
Looking at libgcobol.la, I see a lot of cruft, stuff that just shouldn't
be there because automake generates it otherwise right, but also stuff
using undefined variables etc.
libgcobol.{a,so*} seems to build and install the same as before.
Note, I stull see DT_RUNPATH in the installed libgcobol.so.1 before/after
this patch and I'd prefer not to see it, not seeing it in other libraries
like libstdc++.so.6 etc. Dunno if that is because of the dependency on
libstdc++ (but e.g. libstdc++ has dependency on libgcc_s and doesn't do
that).
projects / thirdparty / gcc.git / log
