| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
(cherry picked from commit 36f5ea5806d246d78555e65273a057718833e3cd)
|
|
D front-end changes:
- Import latest fixes from dmd.
D runtime changes:
- Import latest fixes from druntime.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd ffbad272b6.
* d-tree.h (make_location_t): Add overload taking a const SourceLoc &.
* d-codegen.cc (make_location_t): Likewise.
* d-diagnostic.cc (d_diagnostic_report_diagnostic): Change first
parameter type to const SourceLoc &.
(verrorReport): Update for new front-end interface.
(verrorReportSupplemental): Likewise.
* d-frontend.cc (eval_builtin): Likewise.
(getTypeInfoType): Likewise.
* d-lang.cc (d_parse_file): Likewise.
* d-target.cc (Target::va_listType): Likewise.
(Target::getTargetInfo): Likewise.
* decl.cc (build_decl_tree): Likewise.
* imports.cc (ImportVisitor::visit (Module *)): Likewise.
* modules.cc (get_internal_fn): Likewise.
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime ffbad272b6.
|
|
|
|
D front-end changes:
- Error messages related to operator overloading have been improved.
D runtime changes:
- Import latest fixes from druntime.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd d29e3eca45.
* d-codegen.cc (can_elide_copy_p): Update for new front-end interface.
* d-lang.cc (d_handle_option): Likewise.
* expr.cc (class ExprVisitor): Likewise.
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime d29e3eca45.
|
|
D front-end changes:
- `delete' is no longer a keyword.
- Initializing a field with itself has been deprecated.
D runtime changes:
- Add Windows BCrypt bindings under `core.sys.windows.bcrypt'.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream b7e3b3b617.
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream b7e3b3b617.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES_WINDOWS): Add
core/sys/windows/bcrypt.d.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/gcc/sections/elf.d (sizeofTLS): Give function the same
mangling as gcc.sections.sizeofTLS.
* libdruntime/gcc/sections/package.d: Import core.internal.traits.
(pinLoadedLibraries): Mangle as function from rt.sections_elf_shared.
(unpinLoadedLibraries): Likewise.
(inheritLoadedLibraries): Likewise.
(cleanupLoadedLibraries): Likewise.
(sizeOfTLS): Add forward declaration.
|
|
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.
|
|
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.
Signed-off-by: Pan Li <pan2.li@intel.com>
|
|
|
|
gcc/po/
* gcc.pot: Regenerate.
libcpp/po/
* cpplib.pot: Regenerate.
|
|
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.
|
|
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.
gcc/testsuite/ChangeLog:
2025-03-13 Martin Jambor <mjambor@suse.cz>
PR ipa/116572
* g++.dg/ipa/pr116572.C: New test.
|
|
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.
* gcc.dg/pr119287.c: New test.
|
|
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.
* c-c++-common/pr119120.c: New test.
|
|
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.
* c-c++-common/analyzer/pr119278.c: New test.
|
|
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
|
|
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.
This also reverts Subversion r221362
(Git commit d94fae044da071381b73a2ee8afa874b14fa3820) "No libstdc++ for nvptx",
and commit 2f4f3c0e9345805160ecacd6de527b519a8c9206 "No libstdc++ for GCN".
With libstdc++ now available, libgrust gets enabled, which we in turn again
have to disable, for 'sorry, unimplemented: exception handling not supported'
reasons.
PR target/92713
PR target/101544
* configure.ac [GCN, nvptx] (noconfigdirs): Don't add
'target-libstdc++-v3'. Add 'target-libgrust'.
* configure: Regenerate.
gcc/
* config/gcn/gcn.h (LIBSTDCXX): Don't set.
* config/nvptx/nvptx.h (LIBSTDCXX): Likewise.
|
|
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.
* g++.dg/opt/pr119274.C: New testcase.
|
|
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:
.L3:
ldp q31, q0, [x0]
add w3, w3, 1
ldp q29, q30, [x1], 32
orr v30.16b, v0.16b, v30.16b
add v31.2d, v29.2d, v31.2d
stp q31, q30, [x0], 32
cmp w2, w3
bhi .L3
instead of:
.L4:
ld4 {v28.2d - v31.2d}, [x2]
ld4 {v24.2d - v27.2d}, [x3], 64
add v24.2d, v28.2d, v24.2d
add v25.2d, v29.2d, v25.2d
orr v26.16b, v30.16b, v26.16b
orr v27.16b, v31.16b, v27.16b
st4 {v24.2d - v27.2d}, [x2], 64
cmp x2, x5
bne .L4
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.
|
|
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.
* gcc.dg/vect/pr119155.c: New testcase.
|
|
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.
|
|
|
|
gcc/c-family/
PR ada/119265
* c-ada-spec.cc (dump_ada_node) <INTEGER_TYPE>: Deal with typedefs
of unsigned __int128.
|
|
* de.po: Update.
|
|
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.
|
|
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.
gcc/testsuite/ChangeLog:
* gfortran.dg/bounds_check_26.f90: Update test.
|
|
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.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
|
|
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.
|
|
2025-03-13 Matthias Klose <doko@ubuntu.com>
gcc/cobol/
* Make-lang.in (cobol.install-common, cobol.install-man): Honor
GCOBOL_INSTALL_NAME.
|
|
When I changed DECL_GIMPLE_REG_P over to DECL_NOT_GIMPLE_REG_P I
failed to update its description.
* tree.h (DECL_NOT_GIMPLE_REG_P): Update description.
|
|
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.
gcc/testsuite/
* gcc.target/aarch64/sve/pr96357.c: Add -fno-tree-sink.
|
|
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>
|
|
'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).
gcc/testsuite/
* lib/gcc-dg.exp (find-dg-do-what): Move...
* lib/target-supports-dg.exp: ... here.
|
|
We have long had the fold:
/* 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.
The test was added as part of r14-4713-g4b39aeef594f311e (patch A).
Before patch A we had:
mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
_263 = .COND_MUL (mask__109.48_201, vect_iftmp.45_195, vect_cst__198, { 0.0, ... });
vect_prephitmp_153.50_205 = .VCOND (vect_distbb_170.43_191, { 0.0, ... }, _263, vect_cst__198, 112);
which, expanding the .VCOND, is equivalent to:
mask__102.46_197 = vect_distbb_170.43_191 >= { 0.0, ... };
mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
_263 = .COND_MUL (mask__109.48_201, vect_iftmp.45_195, vect_cst__198, { 0.0, ... });
vect_prephitmp_153.50_205 = mask__102.46_197 ? _263 : vect_cst__198
After patch A we had:
mask__102.46_197 = vect_distbb_170.43_191 >= { 0.0, ... };
mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
_70 = mask__102.46_197 & mask__109.48_201;
vect_prephitmp_153.50_205 = .COND_MUL (_70, vect_iftmp.45_195, vect_cst__198, { 0.0, ... });
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.
gcc/testsuite/
PR testsuite/115248
* gcc.target/aarch64/sve/pre_cond_share_1.c: Delete
|
|
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.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr119115.c: New test.
|
|
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.
|
|
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.
* cobol.dg/pr119229.cob: New testcase.
|
|
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.
|
|
Structured binding is a C++17 feature but the GCC code base is in C++14.
gcc/ChangeLog:
PR target/119238
* config/loongarch/simd.md (<su>dot_prod<wvec_half><mode>):
Stop using structured binding.
|
|
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>
|
|
|
|
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.
* g++.dg/cpp2a/consteval41.C: New test.
|
|
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>
|
|
[PR119154]
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>
|
|
build_over_call has:
t = build2 (MODIFY_EXPR, void_type_node,
build2 (MEM_REF, array_type, arg0, alias_set),
build2 (MEM_REF, array_type, arg, alias_set));
val = build2 (COMPOUND_EXPR, TREE_TYPE (to), t, to);
which creates an expression that can look like:
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.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
[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.
gcc/testsuite:
PR target/117931
* gcc.target/arm/lp1243022.c: Delete non-functional test.
|
|
gcc/testsuite/ChangeLog:
PR fortran/119078
* gfortran.dg/binding_label_tests_26b.f90: Remove bogus dg-error
statements.
|
