Tobias Burnus [Mon, 17 Mar 2025 09:12:44 +0000 (10:12 +0100)]
Move gfortran.dg/gomp/declare-variant-mod-1*.f90 to libgomp.fortran/ [PR115271]
The test is a supposed to be a compile-only test but as dg-additional-sources
does not work with dg-compile (due to compiling with '-o'), dg-link had to
be used; as the code actually compiles (no diagnostic error), the linker
is actually invoked, which fails unless the system compiler by chance
provides the required files. Solution: move the test to libgomp.
PR fortran/115271
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/declare-variant-mod-1-use.f90: Move to
libgomp/testsuite/libgomp.fortran/.
* gfortran.dg/gomp/declare-variant-mod-1.f90: Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/declare-variant-mod-1-use.f90: Moved
from gcc/testsuite/gfortran.dg/gomp/.
* testsuite/libgomp.fortran/declare-variant-mod-1.f90: Likewise.
Robin Dapp [Tue, 11 Mar 2025 13:30:48 +0000 (14:30 +0100)]
RISC-V: Mask values before initializing bitmask vector [PR119114].
In the somewhat convoluted vector code of PR119114 we extract a
<signed-boolean:1> mask value from a vector mask. After some middle-end
simplifications we end up with a value of -2. Its lowest bit is
correctly unset representing "false". When initializing a bitmak vector
from values we compare the full value/register against zero instead of
just the last bit. This causes erroneous mask values.
This patch masks the values by & 0x1 before comparing against 0.
PR target/119114
gcc/ChangeLog:
* config/riscv/autovec.md: Apply & 0x1 mask when initializing
bitmask vector.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr119114.c: New test.
Ayan Shafqat [Mon, 17 Mar 2025 08:28:27 +0000 (09:28 +0100)]
Aarch64: Add FMA and FMAF intrinsic and corresponding tests
This patch introduces inline definitions for the __fma and __fmaf
functions in arm_acle.h for Aarch64 targets. These definitions rely on
__builtin_fma and __builtin_fmaf to ensure proper inlining and to meet
the ACLE requirements [1].
The patch has been tested locally using a crosstool-NG sysroot for
Aarch64, confirming that the generated code uses the expected fused
multiply-accumulate instructions (fmadd).
Richard Biener [Thu, 13 Mar 2025 13:29:06 +0000 (14:29 +0100)]
Add -[DU]_FORTIFY_SOURCE[=n] to DW_AT_producer
The following makes sure to record -D_FORTIFY_SOURCE=n and
-U_FORTIFY_SOURCE in the DW_AT_producer debuginfo attribute when
present on the compiler command line.
* opts.cc (gen_producer_string): Record -D and -U
with _FORTIFY_SOURCE prefix.
Jeff Law [Sun, 16 Mar 2025 23:43:48 +0000 (17:43 -0600)]
[RISC-V][PR target/116256][V4] Fix minor code quality regression in reassociated arithmetic
Arggh. This time add arguments for rv32. Hand edited the testcase part of the
patch, but I think I got it right.
One. More. Time.
-pedantic-errors this time ;( Adding an explicit -std=gnu23 to shut that up.
Part of me wants to know why that's getting added by the pre-commit, but not
enough to chase it down.
--
This failed pre-commit CI the first time through. The only change is in the
return type in the test bool -> _Bool.
The patch for target/116256 significantly simplified the condition and, I guess
not too surprisingly, exposed a minor code quality regression.
Specifically the split part of the define_insn_and_split only splits after
reload (because we use a match_scratch). So there's nothing to combine the
load-immediate with the subsequent add into an addi when the immediate fits
into a simm12 field.
This patch adjusts the split code to handle that scenario directly and generate
the more efficient code. We can squeeze out the slli in this test with a bit
more work, but that's out of scope right now since that isn't a regression.
Tested in my tester. Waiting on pre-commit testing to render a verdict.
PR target/116256
gcc
* config/riscv/riscv.md (reassociation splitters): Do not load the
adjusted addend into a register if it fits in a simm12.
gcc/testsuite
* gcc.target/riscv/pr116256-1.c: New test.
Harald Anlauf [Sat, 15 Mar 2025 14:11:22 +0000 (15:11 +0100)]
Fortran: fix bogus dependency check in ALLOCATE statement [PR60560]
Restrict dependency check of ALLOCATE object to variables in the same
statement, but exclude check of length type parameter that might be
set in the declaration and could lead to a bogus cyclic dependency.
PR fortran/60560
gcc/fortran/ChangeLog:
* expr.cc (gfc_traverse_expr): Do not descend into length type
parameter for negative values of auxiliary parameter f.
* resolve.cc (gfc_find_var_in_expr): New helper function to check
dependence of an expression on given variable.
(resolve_allocate_expr): Use it to determine if array bounds in an
ALLOCATE statement depend explicitly on a variable.
Andrew Pinski [Sat, 15 Mar 2025 23:37:41 +0000 (16:37 -0700)]
discriminators: Fix assigning discriminators on edge [PR113546]
The problem here is there was a compare debug since the discriminators
would still take into account debug statements. For the edge we would look
at the first statement after the labels and that might have been a debug statement.
So we need to skip over debug statements otherwise we could get different
discriminators # with and without -g.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR middle-end/113546
gcc/ChangeLog:
* tree-cfg.cc (first_non_label_stmt): Rename to ...
(first_non_label_nondebug_stmt): This and use gsi_start_nondebug_after_labels_bb.
(assign_discriminators): Update call to first_non_label_nondebug_stmt.
gcc/testsuite/ChangeLog:
* c-c++-common/torture/pr113546-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Gaius Mulley [Sun, 16 Mar 2025 15:56:48 +0000 (15:56 +0000)]
PR modula2/115111 Incorrect line debugging locations at the end of the WHILE loop
This fix corrects the END token position used during the GotoOp at the
bottom of the WHILE loop. The fix is to pass the relative token position
down to M2Quads. This method should be replicated for the other loops
END or UNTIL keywords and possibly the END statements for
conditional statements.
gcc/m2/ChangeLog:
PR modula2/115111
* gm2-compiler/M2GenGCC.mod (CodeStatementNote): Add debugging.
* gm2-compiler/M2Quads.def (BuildEndWhile): New parameter reltokpos.
* gm2-compiler/M2Quads.mod (BuildEndWhile): Reimplement using new parameter.
* gm2-compiler/P3Build.bnf (WhileStatement): Call BuildEndWhile
with -1 relative position.
* gm2-gcc/m2block.cc (do_add_stmt): Tidy comment.
(GetGlobals): Ditto.
(flush_pending_note): Remove #if 0 code.
* gm2-gcc/m2pp.cc (m2pp_nop_expr): New function.
(m2pp_statement): New case clause call m2pp_nop_expr.
gcc/testsuite/ChangeLog:
PR modula2/115111
* gm2/pim/pass/whilestep.mod: New test.
Iain Sandoe [Sun, 9 Mar 2025 09:24:34 +0000 (09:24 +0000)]
Darwin: Pass -macos_version_min to the linker [PR119172].
For binaries to be notarised, the SDK version must be available.
Since we do not, at present, parse this information we have been
passing "0.0" to ld64. This now results in a warning and a fail
to notarise. As a quick-fix, we can fall back to letting ld64
figure out the SDK version (which it does for -macos_version_min).
TODO: Parse the SDKSetting.plist at some point.
PR target/119172
gcc/ChangeLog:
* config.in: Regenerate.
* config/darwin.h (DARWIN_PLATFORM_ID): Add the option to
use -macos_version_min where available.
* configure: Regenerate.
* configure.ac: Check for ld64 support of -macos_version_min.
Tobias Burnus [Sat, 15 Mar 2025 07:53:18 +0000 (08:53 +0100)]
contrib/gcc-changelog: Fix Git.AutoInterrupt - sys.meta_path is None exception
I think the following message is new with Python 3.13, at least I starting
seeing the following exception, which could be fixed by a simple call
to 'repo.close()'.
Seemingly the issue was that the lifetime of the destructor exceeded the
object lifetime.
Exception ignored in: <function Git.AutoInterrupt.__del__ at 0x7ff995aa4f40>
Traceback (most recent call last):
File "/usr/lib/python3.13/site-packages/git/cmd.py", line 790, in __del__
File "/usr/lib/python3.13/site-packages/git/cmd.py", line 781, in _terminate
File "/usr/lib64/python3.13/subprocess.py", line 2227, in terminate
ImportError: sys.meta_path is None, Python is likely shutting down
contrib/ChangeLog:
* gcc-changelog/git_repository.py (parse_git_revisions): Destroy the
Repo object by calling repo.close() at the end of the function.
Tobias Burnus [Sat, 15 Mar 2025 07:28:11 +0000 (08:28 +0100)]
Fortran: Store OpenMP's 'declare variant' in module file [PR115271]
Write the 'omp declare variant' data into the .mod file: Base function,
variant function(s), supporting the clauses match, append_args, and
adjust_args.
PR fortran/115271
gcc/fortran/ChangeLog:
* module.cc (mio_omp_declare_simd_clauses): New, moved from ...
(mio_omp_declare_simd): ... here. Update call, write empty '( )'
if there is no declare simd but a declare variant.
(mio_omp_declare_variant): New.
(mio_symbol): Call it.
* openmp.cc (gfc_match_omp_context_selector): Add comment about
module.cc to TODO note.
* trans-stmt.h (gfc_trans_omp_declare_variant): Take additional
parent_ns argument.
* trans-decl.cc (create_function_arglist,
gfc_create_function_decl): Update call.
* trans-openmp.cc (gfc_trans_omp_declare_variant): Take new
argument, add some special case handling for attr.use_assoc.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/declare-variant-mod-1-use.f90: New test.
* gfortran.dg/gomp/declare-variant-mod-1.f90: New test.
* gfortran.dg/gomp/declare-variant-mod-2-use.f90: New test.
* gfortran.dg/gomp/declare-variant-mod-2.f90: New test.
Pan Li [Wed, 12 Mar 2025 03:26:52 +0000 (11:26 +0800)]
RISC-V: Refine the testcases for cond_widen_complicate-3
Rearrange the test cases of cond_widen_complicate-3 by different types
into different files, instead of put all types together. Then we can
easily reduce the range when asm check fails.
The below test suites are passed locally, let's wait online CI says.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.c: Removed.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i32.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i8.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u16.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u32.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u8.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.h: New test.
Patrick Palka [Fri, 14 Mar 2025 20:10:35 +0000 (16:10 -0400)]
libstdc++: Missing 'constexpr' in vector's from_range ctor [PR119282]
A missing 'constexpr' in the non-forward (and non-sized) branch of our
recently implemented vector from_range ctor was causing this valid example
to be rejected with a cryptic error.
PR libstdc++/119282
libstdc++-v3/ChangeLog:
* include/bits/stl_vector.h (vector::vector(from_range_t)): Add
missing 'constexpr' to local class _Clear.
* testsuite/std/ranges/conv/1.cc (test_pr119282): New test.
Jakub Jelinek [Fri, 14 Mar 2025 19:32:43 +0000 (20:32 +0100)]
cobol: Don't run cobol tests with -m32 or -mx32 [PR119290]
The following patch adds cobol effective target and uses it to guard main
loop in cobol.dg/dg.exp, so that we don't run the tests on unsupported
multilibs.
Tested on x86_64-linux with
make check-cobol RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp'
which previously had all FAILs in the -m32 case and now doesn't report
any PASSes/FAILs/XFAILs/XPASSes etc, while for -m64 the testsuite is run
normally.
2025-03-14 Jakub Jelinek <jakub@redhat.com>
PR cobol/119290
* lib/target-supports.exp (check_compile): Use *.cob extension for
"*> COBOL" comment.
* lib/cobol-dg.exp (check_effective_target_cobol): New procedure.
* cobol.dg/dg.exp: Guard main loop with [check_effective_target_cobol]
test.
Martin Jambor [Fri, 14 Mar 2025 15:07:01 +0000 (16:07 +0100)]
ipa: Do not modify cgraph edges from thunk clones during inlining (PR116572)
In PR 116572 we hit an assert that a thunk which does not have a body
looks like it has one. It does not, but the call_stmt of its outgoing
edge points to a statement, which should not. In fact it has several
outgoing call graph edges, which cannot be. The problem is that the
code updating the edges to reflect inlining into the master clone (an
ex-thunk, unlike the clone, which is still an unexpanded thunk) is
being updated during inling into the master clone. This patch simply
makes the code to skip unexpanded thunk clones.
gcc/ChangeLog:
2025-03-13 Martin Jambor <mjambor@suse.cz>
PR ipa/116572
* cgraph.cc (cgraph_update_edges_for_call_stmt): Do not update
edges of clones that are unexpanded thunk. Assert that the node
passed as the parameter is not an unexpanded thunk.
Jakub Jelinek [Fri, 14 Mar 2025 14:34:32 +0000 (15:34 +0100)]
match.pd: Fix up r15-8025 simplification [PR119287]
The following testcase ICEs since r15-8025.
tree_nop_conversion_p doesn't imply TREE_TYPE (@0) is uselessly convertible
to type, e.g. they could be INTEGER_TYPEs with the same precision but
different TYPE_SIGN.
The following patch just adds a convert so that it creates a valid IL
even in those cases.
2025-03-14 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119287
* match.pd (((X >> C1) & C2) * (1 << C1) to X & (C2 << C1)): Use
(convert @0) instead of @0 in the substitution.
Jakub Jelinek [Fri, 14 Mar 2025 14:31:47 +0000 (15:31 +0100)]
c, c++: Set DECL_NOT_GIMPLE_REG_P on *PART_EXPR operand on lhs of MODIFY_EXPR [PR119120]
The PR119190 patch I've posted regresses the PR119120 testcase (not adding
to testsuite, as it is fairly hard to scan for that problem).
The issue is that for the partial setting of _Complex floating vars
through __real__ on it first and __imag__ later (or vice versa) and since
we forced all complex vars into SSA form we often have undefined (D)
arguments of those COMPLEX_EXPRs. When we don't DCE them (for -O0 debug
info reasons), their expansion will copy both the real and imag parts
using the floating mode and on some targets like 387 that copying alone can
unfortunately trigger exceptions on sNaNs or other problematic bit patterns
and for uninitialized memory it can be triggered randomly based on whatever
is on the stack before.
The following patch sets DECL_NOT_GIMPLE_REG_P flag in the FEs during
genericization.
I think Fortran doesn't have a way to modify just real or just complex
part separately.
The patch is for code like
_ComplexT __t;
__real__ __t = __z.real();
__imag__ __t = __z.imag();
_M_value *= __t;
return *this;
at -O0 which used to appear widely even in libstdc++ before GCC 9
and happens in real-world code. At -O0 for debug info reasons (see
PR119190) we don't want to aggressively DCE statements and when we
since r0-100845 try to rewrite vars with COMPLEX_TYPE into SSA form
aggressively, the above results in copying of uninitialized data
when expanding COMPLEX_EXPRs added so that the vars can be in SSA form.
The patch detects during genericization the partial initialization and
doesn't rewrite such vars to SSA at -O0. This has to be done before
gimplification starts, otherwise e.g. the attached testcase ICEs.
2025-03-14 Jakub Jelinek <jakub@redhat.com>
PR target/119120
* c-gimplify.cc (c_genericize_control_r): Set DECL_NOT_GIMPLE_REG_P
on {REAL,IMAG}PART_EXPR is_gimple_reg operand at -O0 if it is lhs
of a MODIFY_EXPR.
* cp-gimplify.cc (cp_genericize_r): Set DECL_NOT_GIMPLE_REG_P
on {REAL,IMAG}PART_EXPR is_gimple_reg operand at -O0 if it is lhs
of a MODIFY_EXPR.
Jakub Jelinek [Fri, 14 Mar 2025 14:30:43 +0000 (15:30 +0100)]
analyzer: Fix ICE in cmp_csts_same_type on RAW_DATA_CST [PR119278]
The following testcase ICEs in cmp_csts_same_type because RAW_DATA_CST
isn't handled there. As TREE_TYPE (cst1) in that case is INTEGER_TYPE,
e.g. char/signed char/unsigned char, the type itself doesn't imply
the size, so the length is compared first, followed by comparing the
data.
While at it, I've noticed STRING_CST handling is wrong, because STRING_CST
can represent even string literals with embedded nul characters.
We shouldn't stop at those, hence memcmp.
While for STRING_CST TREE_TYPE should likely already imply the length
and so same type should imply same TREE_STRING_LENGTH, I've repeated
the comparisons in there just in case.
2025-03-14 Jakub Jelinek <jakub@redhat.com>
PR analyzer/119278
* svalue.cc (cmp_csts_same_type): For STRING_CST, compare
TREE_STRING_LENGTH first just in case and use memcmp rather
than strcmp. Handle RAW_DATA_CST.
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>
projects / thirdparty / gcc.git / log
