Jonathan Wakely [Thu, 10 Apr 2025 10:00:36 +0000 (11:00 +0100)]
libstdc++: Adjust value of __cpp_lib_constrained_equality for C++20
The P3379R0 bump to __cpp_lib_constrained_equality relates to changes
that only affect std::expected, so there's no reason to define the
updated value in C++20.
This change restores the previous value (202403) for C++20, and only
uses the new value (202411) for C++23 and later.
Also remove the TODO comments, because I correctly predicted that the
final value would be 202411.
libstdc++-v3/ChangeLog:
* include/bits/version.def (constrained_equality): Only define
as 202411 for C++23 and later, use 202403 for C++20.
* include/bits/version.h: Regenerate.
* testsuite/20_util/expected/equality_constrained.cc: Remove
TODO comment.
Jason Merrill [Wed, 9 Apr 2025 17:22:56 +0000 (13:22 -0400)]
c++: lambda in constraint of lambda [PR119175]
Here when we went to mangle the constraints of from<0>, the outer lambda has
no mangling scope, but the inner one was treated as having the outer one as
its scope. And mangling the outer one means mangling its constraints, which
include the inner one. So infinite recursion.
But a lambda closure type isn't a scope that anything should have for
mangling, the inner lambda should also have no mangling scope.
PR c++/119175
gcc/cp/ChangeLog:
* mangle.cc (decl_mangling_context): Look through lambda type.
Richard Biener [Thu, 10 Apr 2025 11:30:42 +0000 (13:30 +0200)]
middle-end/119706 - allow POLY_INT_CST as is_gimple_mem_ref_addr
We currently only INTEGER_CST, but not POLY_INT_CST, which leads
to the situation that when the POLY_INT_CST is only indrectly
present via a SSA def the IL is valid but when propagated it's not.
That's unsustainable.
PR middle-end/119706
* gimple-expr.cc (is_gimple_mem_ref_addr): Also allow
POLY_INT_CST.
Iain Sandoe [Sat, 15 Mar 2025 22:58:46 +0000 (22:58 +0000)]
libgcobol: Allow libgcobol to use libquadmath [PR119244].
Many of the changes are mechanical:
1. 'GCOB_FP128' in place of _Float128.
2. Using FP128_FUNC to represent the spelling of intrinsics.
3. Using GCOB_FP128_LITERAL() to choose the suffix for literals.
This allows for:
__float128 and 'q' as the suffix when libquadmath is configured.
_Float128 / 'f128' when IEC-60559 is available in libc
long double / 'l' when long double is ieee753 128b.
Add libquadmath to libgcobol.spec and its dependencies where the
platform needs it.
PR cobol/119244
libgcobol/ChangeLog:
* Makefile.am: Add support for libquadmath.
* Makefile.in: Regenerate.
* acinclude.m4: Add support for libquadmath.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Configure libquadmath support.
* gmath.cc: Use GCOB_FP128 to represent the configured
128b floating point type. Use FP128_FUNC to represent
the naming of intrinsics in the configure 128b floating
point type. Render literals with GCOB_FP128_LITERAL.
* intrinsic.cc: Likewise.
* libgcobol.cc: Likewise.
* libgcobol.h: Likewise.
* libgcobol-fp.h: New file.
* gfileio.cc: Include libgcobol-fp.h.
* libgcobol.spec.in: Add libquadmath configure output.
Avoid using POINTER_DIFF_EXPR for overlap checks [PR119399]
In r10-4803-g8489e1f45b50600c I'd used POINTER_DIFF_EXPR to subtract
the two pointers involved in an overlap test. I'm not sure whether
I'd specifically chosen that over MINUS_EXPR or not; if so, the only
reason I can think of is that it is probably faster on targets with
PSImode pointers. Regardless, as the PR points out, subtracting
unrelated pointers using POINTER_DIFF_EXPR is undefined behaviour.
gcc/
PR tree-optimization/119399
* tree-data-ref.cc (create_waw_or_war_checks): Use a MINUS_EXPR
on two converted pointers, rather than converting a POINTER_DIFF_EXPR
on the pointers.
gcc/testsuite/
PR tree-optimization/119399
* gcc.dg/vect/pr119399.c: New test.
Kito Cheng [Thu, 10 Apr 2025 08:58:49 +0000 (16:58 +0800)]
RISC-V: Fix the behavior for multilib-generator with --cmodel=large on rv32
Large code model is only supported on RV64, so we don't need to
generate the multilibs for RV32 with --cmodel=large. And the compact
code model is something we don't supported on upstream (which is
accidentally added in the past), so we need to remove it.
gcc/ChangeLog:
* config/riscv/multilib-generator: Remove the compact code model
and check large code model for RV32.
Patrick Palka [Wed, 9 Apr 2025 21:48:05 +0000 (17:48 -0400)]
libstdc++: Fix constraint recursion in basic_const_iterator operator- [PR115046]
It was proposed in PR112490 to also adjust basic_const_iterator's friend
operator-(sent, iter) overload alongside the r15-7757-g4342c50ca84ae5
adjustments to its comparison operators, but we lacked a concrete
testcase demonstrating fixable constraint recursion there. It turns out
Hewill Kang's PR115046 is such a testcase! So this patch makes the same
adjustments to that overload as well, fixing PR115046. The LWG 4218 P/R
will need to get adjusted too.
PR libstdc++/115046
PR libstdc++/112490
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (basic_const_iterator::operator-):
Replace non-dependent basic_const_iterator function parameter with
a dependent one of type basic_const_iterator<_It2> where _It2
matches _It.
* testsuite/std/ranges/adaptors/as_const/1.cc (test04): New test.
Patrick Palka [Wed, 9 Apr 2025 21:47:34 +0000 (17:47 -0400)]
c++: ICE with nested default targ lambdas [PR119574]
Here we substitute into the inner lambda twice, first during default
argument substitution for the outer template parameters, then during
that for the inner template parameters.
For the second testcase (which is easier to follow/debug), the first
substitution into the inner lambda is with the template arguments
{0, NULL_TREE}, which we defer because it's an incremental substitution.
For the second and final substitution we have the template arguments
{1, NULL_TREE}, which we try combining via add_extra_args and ICE on
the checking assert because TREE_STATIC isn't set on the deferred
arguments but the template arguments are considered dependent.
The template arguments aren't dependent however -- they're just
incomplete because when we deferred them we were in the middle of
deduction, and we consider a NULL_TREE template argument as dependent.
If we remove this checking assert, we go on to correctly merge the
template arguments into {{0, NULL_TREE}, {1, NULL_TREE}}. So this
patch just removes this imprecise assert.
PR c++/119574
gcc/cp/ChangeLog:
* pt.cc (add_extra_args): Remove checking assert.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ13.C: New test.
* g++.dg/cpp2a/lambda-targ13a.C: New test.
* g++.dg/cpp2a/lambda-targ13b.C: New test.
Bob Dubner [Wed, 9 Apr 2025 20:23:53 +0000 (16:23 -0400)]
cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682]
gcc/cobol
PR cobol/119682
* genapi.cc: (cobol_compare): Change the call to __gg__compare().
libgcobol
PR cobol/119682
* common-defs.h: Define the REFER_T_REFMOD constant.
* intrinsic.cc: (__gg__max): Change the calls to __gg__compare_2(),
(__gg__min): Likewise, (__gg__ord_min): Likewise,
(__gg__ord_max): Likewise.
* libgcobol.cc: (__gg__compare_2): Change definition of calling
parameters, eliminate separate flag bit for ALL and ADDRESS_OF,
change comparison of alphanumeric to numeric when the numeric
is a refmod.
* libgcobol.h: Change declaration of __gg__compare_2.
Jakub Jelinek [Wed, 9 Apr 2025 20:03:50 +0000 (22:03 +0200)]
modula2: FIx a comment typo
During make gcc.pot I've noticed among tons of other warnings (e.g. because
can't appears in non-C/C++ style comment and so gettext considers it
unterminated) a warning where the lack of " looked unintentional.
Jakub Jelinek [Wed, 9 Apr 2025 20:01:30 +0000 (22:01 +0200)]
libquadmath: Fix up THREEp96 constant in expq
Here is a cherry-pick from glibc [BZ #32411] fix.
As mentioned by the reporter in a pull request against gcc-mirror,
the THREEp96 constant in e_expl.c is incorrect, it is actually 0x3.p+94f128
rather than 0x3.p+96f128.
The algorithm uses that to compute the t2 integer (tval2), by whose
delta it adjusts the x+xl pair and then in the result uses the precomputed
exp value for that entry.
Using 0x3.p+94f128 rather than 0x3.p+96f128 results in tval2 sometimes
being one smaller, sometimes one larger than the desired value, thus can mean
the x+xl pair after adjustment will be larger in absolute value than it
should be.
DesWursters created a test program for this
https://github.com/DesWurstes/comparefloats
and his results were
total: 1135000000 not_equal: 4322 earlier_score: 674 later_score: 3648
I've modified this so with
https://sourceware.org/bugzilla/show_bug.cgi?id=32411#c3
so that it actually tests pseudo-random _Float128 values with range
(-16384.,16384) with strong bias on values larger than 0.0002 in absolute
value (so that tval1/tval2 aren't zero most of the time) and that gave
total: 10000000000 not_equal: 29861 earlier_score: 4606 later_score: 25255
So, in both cases, in most cases the change doesn't result in any differences,
and in those rare cases where does, about 85% have smaller ulp than without
the patch.
Additionally I've tried
https://sourceware.org/bugzilla/show_bug.cgi?id=32411#c4
and in 2 billion iterations it didn't find any case where x+xl after the
adjustments without this change would be smaller in absolute value compared
to x+xl after the adjustments with this change.
Jakub Jelinek [Wed, 9 Apr 2025 20:00:35 +0000 (22:00 +0200)]
h8300: Fix up bit test and jump splitter [PR119664]
r12-2601 has added this define_insn_and_split and corresponding
(define_insn ""
[(set (reg:CCZ CC_REG)
(eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r")
(const_int 1)
(match_operand 1 "const_int_operand" "n"))
(const_int 0)))]
"INTVAL (operands[1]) < 16"
"btst %Z1,%Y0"
[(set_attr "length" "2")])
pattern into which the define_insn_and_split wants to splut in addition
to a conditional jump.
But as can be seen, the btst define_insn uses HSI mode iterator while
define_insn_and_split QHSI, so for QImode it splits into something that
can't be recognized.
This was probably latent since r12-2601 and on the attached testcase
is reproduceable starting with r15-1945 - a late combiner change.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
PR target/119664
* config/h8300/jumpcall.md (bit test and jump define_insn_and_split):
Use HSI iterator rather than QHSI.
d: Fix forward referenced enums missing type names in debug info [PR118309]
Calling `rest_of_type_compilation' as the D types were built meant that
debug info was being emitted before all forward references were
resolved, resulting in DW_AT_name's to be missing.
Instead, defer outputting type debug information until all modules have
been parsed and generated in `d_finish_compilation'.
PR d/118309
gcc/d/ChangeLog:
* modules.cc: Include debug.h
(d_finish_compilation): Call debug_hooks->type_decl on all TYPE_DECLs.
* types.cc: Remove toplev.h include.
(finish_aggregate_type): Don't call rest_of_type_compilation or
rest_of_decl_compilation on type.
(TypeVisitor::visit (TypeEnum *)): Likewise.
Harald Anlauf [Tue, 8 Apr 2025 20:30:15 +0000 (22:30 +0200)]
Fortran: fix issue with impure elemental subroutine and interface [PR119656]
PR fortran/119656
gcc/fortran/ChangeLog:
* interface.cc (gfc_compare_actual_formal): Fix front-end memleak
when searching for matching interfaces.
* trans-expr.cc (gfc_conv_procedure_call): If there is a formal
dummy corresponding to an absent argument, use its type, and only
fall back to inferred type otherwise.
Jeff Law [Wed, 9 Apr 2025 14:33:17 +0000 (08:33 -0600)]
[RISC-V] Fix more fallout from combine.c changes
Trivial fallout from the recent combine work. We end up with a srai rather
than an xor in some of the saturation sequences. Both variants look equally
performant, so I'm just adjusting the expected test output.
Jonathan Yong [Mon, 7 Apr 2025 15:40:05 +0000 (15:40 +0000)]
deref-before-check-pr113253.c: Fix bogus warnings on lp32
Warnings about pointer sizes cause the test to fail
incorrectly. A dummy return value is also added to
set_marker_internal for completeness to suppress a
-Wreturn-type warning even though gcc does not issue
it by default.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
PR analyzer/113253
* gcc.dg/analyzer/deref-before-check-pr113253.c:
(ptrdiff_t): use stddef.h type.
(uintptr_t): ditto.
(EMACS_INT): ditto.
(set_marker_internal): Add dummy 0 to suppress -Wreturn-type.
Jakub Jelinek [Wed, 9 Apr 2025 13:43:48 +0000 (15:43 +0200)]
riscv: Fix r15-9270 fallout on RISC-V
On Wed, Apr 09, 2025 at 02:38:01PM +0200, Mark Wielaard wrote:
> Unfortunately this seems to have broken the riscv bootstrap:
> https://builder.sourceware.org/buildbot/#/builders/337/builds/105
>
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_MAP’ not handled in switch [-Werror=switch]
> 4730 | switch (context)
> | ^
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_MAP_IMP_REF’ not handled in switch [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_PRIVATE’ not handled in switch [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_FIRSTPRIVATE’ not handled in switch [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_DEVICE_ADDR’ not handled in switch [-Werror=switch]
> cc1plus: all warnings being treated as errors
Indeed, riscv-vector-builtins.cc IMHO needs pretty much the same
changes as aarch64, just with s/SVE/RVV/g.
I've also left out default: break; so that it is caught next time
somebody adds further enumerators.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
* config/riscv/riscv-vector-builtins.cc (verify_type_context):
Diagnose RVV types for a given OpenMP context.
Richard Biener [Wed, 9 Apr 2025 12:36:19 +0000 (14:36 +0200)]
rtl-optimization/119689 - compare-debug failure with LRA
The previous change to fix LRA rematerialization broke compare-debug
for i586 bootstrap. Fixed by using prev_nonnote_nondebug_insn
instead of prev_nonnote_insn.
PR rtl-optimization/119689
PR rtl-optimization/115568
* lra-remat.cc (create_cands): Use prev_nonnote_nondebug_insn
to check whether insn2 is directly before insn.
d: Use CONSTRUCTOR_ZERO_PADDING_BITS in the D FE [PR117832]
Adds a new wrapper function for `build_constructor', and calls it
instead to ensure that all CONSTRUCTOR nodes explicitly created by the
front-end have CONSTRUCTOR_ZERO_PADDING_BITS set.
Some places may not be necessary as it's guaranteed for there to be no
padding in the type, such as D dynamic arrays. Other places this gets
turned into a double-memset when optimizations are turned off, as the
front-end already generates a memset call to zero out all padding on
initializing a variable. The optimizer sees through this so will
correctly clear all bits once, so this can be improved later as-needed.
Jakub Jelinek [Wed, 9 Apr 2025 10:27:38 +0000 (12:27 +0200)]
libcpp: Fix error recovery after use of __VA_ARGS__ as macro argument [PR118674]
The following testcase ICEs after emitting one pedwarn (about using
__VA_ARGS__ in a place where it shouldn't be used) and one error.
The error is emitted by _cpp_save_parameter where it sees the node
has been used already earlier. But unlike the other _cpp_save_parameter
caller which does goto out; if it returns false, this call with explicit
__VA_ARGS__ doesn't and if it increments number of parameters etc. after
the error, we then try to unsave it twice.
The following patch fixes it by doing the goto out in that case too,
the macro will then not be considered as variable arguments macro,
but for error recovery I think that is fine.
The other option would be before the other _cpp_save_parameter caller
check if the node is pfile->spec_nodes.n__VA_ARGS__ and in that case
also error and goto out, but that seems more expensive than this for
the common case that the macro definition is correct.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/118674
* macro.cc (parse_params) <case CPP_ELLIPSIS>: If _cpp_save_parameter
failed for __VA_ARGS__, goto out.
Paul Thomas [Wed, 9 Apr 2025 08:50:04 +0000 (09:50 +0100)]
Fortran: Fix some problems with the reduce intrinsic [PR119460]
2025-04-09 Paul Thomas <pault@gcc.gnu.org>
and Harald Anlauf <anlauf@gcc.gnu.org>
gcc/fortran
PR fortran/119460
* iresolve.cc (generate_reduce_op_wrapper): Increase the size
of 'tname'. Change intent of 'a' and 'b' to intent_in.
* trans-decl.cc (add_argument_checking): Do not test artificial
formal symbols.
* trans-expr.cc (gfc_conv_procedure_call): Remove reduce_scalar
and the blocks triggered by it.
* trans-intrinsic.cc (gfc_conv_intrinsic_function): Set the
result of non-character, scalar reduce to be allocatable.
gcc/testsuite/
PR fortran/119460
* gfortran.dg/reduce_2.f90: Add test to check that deferred len
characters cannot slip through.
* gfortran.dg/reduce_3.f90: New test
* gfortran.dg/reduce_4.f90: New test
libgfortran/
PR libfortran/119460
* intrinsics/reduce.c (reduce): Correct error message about
mismatch between dim and the rank of array. Output the values
of both. Correct the evaluation of the result stride and
extent.
(reduce_scalar): The front end treats the result as an
allocatable so eliminate memcpy and free. Return the base-addr
of the local descriptor.
(reduce_c): Correct the type of the string lengths.
(reduce_scalar_c): Correct the type of the string lengths.Test
to see if 'res' is allocated. If not then return the base_addr
of the local descriptor.
Richard Biener [Tue, 8 Apr 2025 12:57:05 +0000 (14:57 +0200)]
bootstrap/119680 - fix cross-compiler build with --enable-host-shared
It seems that at least when cross-compiling at least collect2 pulls
in objects from libbacktrace.a which is linked via LIBDEPS. But
libbacktrace for the host is only built -fPIC with --enable-host-shared
but not -fPIE with --enable-host-pie so this fails. The following
teaches libbacktrace about --enable-host-pie and handles it similar
to libcpp.
PR bootstrap/119680
libbacktrace/
* configure.ac (--enable-host-pie): Handle by setting PIC_FLAG
to -fPIE.
* configure: Regenerate.
Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]
Implement LOCAL and LOCAL_INIT; we locally replace the tree declaration by
a local declaration of the outer variable. The 'local_init' then assigns
the value at the beginning of each loop iteration from the outer
declaration.
Note that the current implementation does not handle LOCAL with types that
have a default initializer and LOCAL/LOCAL_INIT for assumed-shape arrays;
this is diagnosed with a sorry error.
PR fortran/101602
gcc/fortran/ChangeLog:
* resolve.cc (resolve_locality_spec): Remove 'sorry, unimplemented'.
* trans-stmt.cc (struct symbol_and_tree_t): New.
(gfc_trans_concurrent_locality_spec): New.
(gfc_trans_forall_1): Call it; update to handle local and local_init.
* trans-decl.cc (gfc_start_saved_local_decls,
gfc_stop_saved_local_decls): New; moved code from ...
(gfc_process_block_locals): ... here. Call it.
* trans.h (gfc_start_saved_local_decls,
gfc_stop_saved_local_decls): Declare.
gcc/testsuite/ChangeLog:
* gfortran.dg/do_concurrent_8_f2023.f90: Update for removed 'sorry,
unimplemented'.
* gfortran.dg/do_concurrent_9.f90: Likewise.
* gfortran.dg/do_concurrent_all_clauses.f90: Likewise.
* gfortran.dg/do_concurrent_local_init.f90: Likewise.
* gfortran.dg/do_concurrent_locality_specs.f90: Likewise.
* gfortran.dg/do_concurrent_11.f90: New test.
* gfortran.dg/do_concurrent_12.f90: New test.
* gfortran.dg/do_concurrent_13.f90: New test.
* gfortran.dg/do_concurrent_14.f90: New test.
* gfortran.dg/do_concurrent_15.f90: New test.
Jason Merrill [Tue, 8 Apr 2025 19:53:34 +0000 (15:53 -0400)]
c++: lambda in concept [PR118698]
When normalizing is_foo for <T>, we get to normalizing
callable<decltype(...),T> for <T,foo>, which means substituting <T,foo> into
<decltype(...),T>.
Since r14-9938, because in_template_context is false we return the lambda
unchanged, just with LAMBDA_EXPR_EXTRA_ARGS set, so the closure type still
refers to the is_specialization_of tparms in its CLASSTYPE_TEMPLATE_INFO.
So then in normalize_atom caching find_template_parameters walks over the
parameter mapping; any_template_parm_r walks into the TREE_TYPE of a
LAMBDA_EXPR without considering EXTRA_ARGS and finds a template parm from
the wrong parameter list.
But since r15-3530 we expect to set tf_partial when substituting with
dependent arguments, so we should set that when normalizing. And then
tf_partial causes TREE_STATIC to be set on the EXTRA_ARGS, meaning that
those args will replace all the template parms in the rest of the lambda, so
we can walk just the EXTRA_ARGS and ignore the rest.
In previous years, I've tried to update the guality tests
so that they give clean results on aarch64-linux-gnu with
a recent version of GDB. This patch does the same thing for
GCC 15. The version of GDB I used was 16.2.
As before, there are no PRs for the XFAILs. The idea is that
anyone who is interested in working in this area can see the
current XFAILs by grepping the tests.
The issue is specifically about a missing word, but I spotted other
copy-editing issues like misplaced hyphens in nearby text. I also
thought that the -Wimplicit example was anachronistic because it's a
hard error in modern C dialects rather than a warning, and replaced it
with something users are more likely to run into.
gcc/ChangeLog
PR c++/90468
* doc/invoke.texi (Warning Options): Clean up text describing
-Wno-xxx.
Jakub Jelinek [Tue, 8 Apr 2025 13:57:45 +0000 (15:57 +0200)]
cobol: Further fixes for cobol cross-compilation from 32-bit arches [PR119364]
On top of
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680256.html
patch this brings make check-cobol when using the cross compiler from
32-bit host to x86_64-linux to the following:
Running /home/jakub/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/group1/declarative_1.cob -O0 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O1 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O2 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: cobol.dg/group1/declarative_1.cob -O3 -g execution test
FAIL: cobol.dg/group1/declarative_1.cob -Os execution test
=== cobol Summary ===
# of expected passes 3123
# of unexpected failures 6
# of expected failures 6
(which has some analysis but not a fix yet).
This patch fixes various cases where host size of various types
(void *, int, size_t, unsigned char) is used in place where
size of those types in bytes on the target should be used instead.
At least the size of void * and size_t actually differns between
ilp32 hosts and lp64 targets, int could be different in theory as well
but we actually don't support 16-bit ints on the host side and only support
lp64 targets right now for cobol, and finally sizeof(unsigned char) is
always 1, so there is no point to multiply by that and it is still
wrong to use host sizeof for the target decisions.
2025-04-08 Jakub Jelinek <jakub@redhat.com>
PR cobol/119364
* genapi.cc (function_handle_from_name): Use sizeof_pointer.
(parser_file_add): Use int_size_in_bytes(VOID_P) and
int_size_in_bytes(int).
(inspect_tally): Use int_size_in_bytes(VOID_P).
(inspect_replacing): Likewise.
(gg_array_of_field_pointers): Likewise.
(gg_array_of_file_pointers): Likewise.
(parser_set_pointers): Use sizeof_pointer.
* cobol1.cc (create_our_type_nodes_init): Use
int_size_in_bytes(SIZE_T) and int_size_in_bytes(VOID_P).
* gengen.cc (gg_array_of_size_t): Use int_size_in_bytes(SIZE_T).
(gg_array_of_bytes): Just use N, don't multiply it by
sizeof(unsigned char).
* parse.y: Include tree.h. Use int_size_in_bytes(ptr_type_node).
Jakub Jelinek [Tue, 8 Apr 2025 13:14:58 +0000 (15:14 +0200)]
simplify-rtx: Fix up POPCOUNT optimization [PR119672]
The gcc.dg/vect/pr113281-1.c test and many others ICE on riscv since
presumably the r15-9238 change which allowed more cases of vector modes
in simplify_const_relational_operation.
In the testcase it is EQ of
(popcount:SI (unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:RVVMF32BI 147 [ mask__6.8_35 ]))
(reg:SI 143 [ _41 ])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE))
and
(const_int 0 [0])
which it tries to fold as EQ comparison of
(unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:RVVMF32BI 147 [ mask__6.8_35 ]))
(reg:SI 143 [ _41 ])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
with
(const_int 0 [0])
which ICEs because const0_rtx isn't a vector.
Fixed by using CONST0_RTX, so that we pass
(const_vector:RVVMF32BI repeat [
(const_int 0 [0])
])
instead.
2025-04-08 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/119672
* simplify-rtx.cc (simplify_context::simplify_relational_operation_1):
For POPCOUNT == 0 or != 0 optimizations use
CONST0_RTX (GET_MODE (XEXP (op0, 0))) rather than const0_rtx.
Martin Uecker [Fri, 4 Apr 2025 19:01:48 +0000 (21:01 +0200)]
c: fix checking for a tag for variably modified tagged types [PR119612]
The checking assertion added for PR118765 did not take into account
that add_decl_expr can change TYPE_NAME to a TYPE_DECL with no name
for certain cases of variably modified types. This also implies that we
might sometimes not reliably detect the absence of a tag when only
considering TYPE_NAME. This patch introduces a new helper function
c_type_tag to reliable compute the tag for a tagged types and uses it
for code where the switch to C23 may cause regressions.
PR c/119612
gcc/c/ChangeLog:
* c-tree.h (c_type_tag): Add prototype.
* c-typeck.cc (c_type_tag): New function.
(tagged_types_tu_compatible_p, composite_type_internal): Use
c_type_tag.
* c-decl.cc (c_struct_hasher::hash, previous_tag): Use c_type_tag.
gcc/testsuite/ChangeLog:
* gcc.dg/gnu23-tag-6.c: New test.
* gcc.dg/pr119612.c: New test.
OpenMP: Fix append_args handling in modify_call_for_omp_dispatch
At tree level, the addr ref is also required for array dummy arguments,
contrary to C; the GOMP_interop calls in modify_call_for_omp_dispatch
were updated accordingly (using build_fold_addr_expr).
As the GOMP_interop calls had no location data associated with them,
the init call happened as soon as executing the previous line of code,
which was confusing; solution: use the location data of the function
call itself.
PR middle-end/119662
gcc/ChangeLog:
* gimplify.cc (modify_call_for_omp_dispatch): Fix GOMP_interop
arg passing; add location info to function calls.
libgomp/ChangeLog:
* testsuite/libgomp.c/append-args-fr-1.c: New test.
* testsuite/libgomp.c/append-args-fr.h: New test.
Jason Merrill [Mon, 7 Apr 2025 18:35:14 +0000 (14:35 -0400)]
c++: self-dependent alias template [PR117530]
Here, instantiating B<short> means instantiating A<short>, which means
instantiating B<short>. And then when we go to register the initial
instantiation, it conflicts with the inner one. Fixed by checking after
tsubst whether there's already something in the hash table. We already did
something much like this in tsubst_decl, but that doesn't handle this case.
While I was here, I noticed that we had a pop_deferring_access_checks on one
early exit but not another, and since I wanted to add yet another I switched
to using deferring_access_check_sentinel.
PR c++/117530
gcc/cp/ChangeLog:
* pt.cc (instantiate_template): Check retrieve_specialization after
tsubst.
Jakub Jelinek [Tue, 8 Apr 2025 10:39:16 +0000 (12:39 +0200)]
riscv: Fix a typo in config/riscv/freebsd.h [PR119678]
The r15-1124 commit had a typo in one of the FBSD_LINK_PG_NOTE
macro uses.
Fixed thusly, tested with
../configure --target riscv64-unknown-freebsd14 --disable-bootstrap --enable-languages=c --disable-libsanitizer --disable-libgomp
make -j32
Before it failed while compiling gcc.cc:
In file included from ./tm.h:44,
from ../../gcc/gcc.cc:35:
../../gcc/config/riscv/freebsd.h:45:5: error: expected ‘,’ or ‘;’ before ‘FBSD_LINK_PG_NOTES’
45 | " FBSD_LINK_PG_NOTES " \
| ^~~~~~~~~~~~~~~~~~
../../gcc/gcc.cc:1211:32: note: in expansion of macro ‘LINK_SPEC’
Now it fails later on during libgcc configury because I don't have
corresponding binutils.
2025-04-08 Jakub Jelinek <jakub@redhat.com>
PR target/119678
* config/riscv/freebsd.h (LINK_SPEC): Use FBSD_LINK_PG_NOTE rather
than non-existing FBSD_LINK_PG_NOTES.
ld: error: undefined symbol: _Unwind_RaiseException
>>> referenced by eh_throw.cc:93 ([...]/source-gcc/libstdc++-v3/libsupc++/eh_throw.cc:93)
>>> eh_throw.o:(__cxa_throw) in archive /srv/data/tschwinge/amd-instinct2/gcc/build/submit-light-target_gcn/build-gcc/amdgcn-amdhsa/gfx908/libstdc++-v3/src/.libs/libstdc++.a
[...]
collect2: error: ld returned 1 exit status
..., and/or:
ld: error: undefined symbol: _Unwind_Resume_or_Rethrow
>>> referenced by eh_throw.cc:129 ([...]/source-gcc/libstdc++-v3/libsupc++/eh_throw.cc:129)
>>> eh_throw.o:(__cxa_rethrow) in archive /srv/data/tschwinge/amd-instinct2/gcc/build/submit-light-target_gcn/build-gcc/amdgcn-amdhsa/gfx908/libstdc++-v3/src/.libs/libstdc++.a
[...]
collect2: error: ld returned 1 exit status
..., and nvptx:
unresolved symbol _Unwind_RaiseException
collect2: error: ld returned 1 exit status
..., or:
unresolved symbol _Unwind_Resume_or_Rethrow
collect2: error: ld returned 1 exit status
For both GCN, nvptx, this each progresses ~25 'check-gcc-c++',
and ~10 'check-target-libstdc++-v3' test cases:
[-FAIL:-]{+PASS:+} [...] (test for excess errors)
..., with (if applicable, for most of them):
[-UNRESOLVED:-]{+PASS:+} [...] [-compilation failed to produce executable-]{+execution test+}
..., or some 'FAIL: [...] execution test' where these test cases now FAIL when
attempting to use these interfaces, or, if applicable, FAIL due to run-time
'GCC/nvptx: sorry, unimplemented: dynamic stack allocation not supported'.
Thomas Schwinge [Tue, 18 Mar 2025 09:10:30 +0000 (10:10 +0100)]
GCN, nvptx: Define '_Unwind_DeleteException'
This resolves GCN:
ld: error: undefined symbol: _Unwind_DeleteException
>>> referenced by eh_catch.cc:109 ([...]/source-gcc/libstdc++-v3/libsupc++/eh_catch.cc:109)
>>> eh_catch.o:(__cxa_end_catch) in archive [...]/build-gcc/amdgcn-amdhsa/libstdc++-v3/src/.libs/libstdc++.a
[...]
collect2: error: ld returned 1 exit status
..., and nvptx:
unresolved symbol _Unwind_DeleteException
collect2: error: ld returned 1 exit status
For both GCN, nvptx, this each progresses ~100 'check-gcc-c++',
and ~500 'check-target-libstdc++-v3' test cases:
[-FAIL:-]{+PASS:+} [...] (test for excess errors)
..., with (if applicable, for most of them):
[-UNRESOLVED:-]{+PASS:+} [...] [-compilation failed to produce executable-]{+execution test+}
..., or just a few 'FAIL: [...] execution test' where these test cases now
FAIL for unrelated reasons, or, if applicable, FAIL due to run-time
'GCC/nvptx: sorry, unimplemented: dynamic stack allocation not supported'.
Thomas Schwinge [Mon, 7 Apr 2025 10:39:33 +0000 (12:39 +0200)]
nvptx: In offloading compilation, special-case certain host-setup symbol aliases: avoid unused label 'emit_ptx_alias' diagnostic
Minor fix-up for commit 65b31b3fff2fced015ded1026733605f34053796
"nvptx: In offloading compilation, special-case certain host-setup symbol aliases [PR101544]",
as of which we see for non-offloading configurations:
+[...]/source-gcc/gcc/config/nvptx/nvptx.cc: In function 'void nvptx_asm_output_def_from_decls(FILE*, tree, tree)':
+[...]/source-gcc/gcc/config/nvptx/nvptx.cc:7769:2: warning: label 'emit_ptx_alias' defined but not used [-Wunused-label]
+ 7769 | emit_ptx_alias:
+ | ^~~~~~~~~~~~~~
libgomp: Add -Wno-c-binding-type for omp_lib.f90 compilation
Silence the overeager "Warning: Variable 'depobj_list' at (1) is a dummy
argument of the BIND(C) procedure ... but may not be C interoperable
[-Wc-binding-type]" when compiling omp_lib.f90(.in).
The argument is of integer kind 'omp_depend_kind = @OMP_DEPEND_KIND@'.
Jakub Jelinek [Tue, 8 Apr 2025 09:55:13 +0000 (11:55 +0200)]
cse: Fix up delete_trivially_dead_insns [PR119594]
The following testcase is miscompiled by delete_trivially_dead_insns,
latently since r0-6313, actually since r15-1575.
The problem is in that r0-6313 change, which made count_reg_usage not
count uses of the pseudo which the containing SET sets. That is needed
so we can delete those instructions as trivially dead if they are really
dead, but has the following problem. After fwprop proper we have:
(insn 7 2 8 2 (set (reg/v:DI 101 [ g ])
(const_int -1 [0xffffffffffffffff])) "pr119594.c":8:10 95 {*movdi_internal}
(nil))
...
(insn 26 24 27 7 (set (reg:DI 104 [ g ])
(zero_extend:DI (subreg:SI (reg/v:DI 101 [ g ]) 0))) "pr119594.c":11:8 175 {*zero_extendsidi2}
(expr_list:REG_EQUAL (const_int 4294967295 [0xffffffff])
(expr_list:REG_DEAD (reg/v:DI 101 [ g ])
(nil))))
(insn 27 26 28 7 (set (reg/v:DI 101 [ g ])
(zero_extend:DI (subreg:SI (reg/v:DI 101 [ g ]) 0))) "pr119594.c":11:8 175 {*zero_extendsidi2}
(expr_list:REG_EQUAL (const_int 4294967295 [0xffffffff])
(expr_list:REG_UNUSED (reg/v:DI 101 [ g ])
(nil))))
and nothing else uses or sets the 101 and 104 pseudos. The subpass doesn't
look at REG_UNUSED or REG_DEAD notes (correctly, as they aren't guaranteed
to be accurate). The last change in the IL was forward propagation of
(reg:DI 104 [ g ]) value into the following insn.
Now, count_reg_usage doesn't count anything on insn 7, the SET_DEST is a
reg, so we don't count that and SET_SRC doesn't contain any regs.
On insn 26 it counts one usage of pseudo 101 (so counts[101] = 1) and
on insn 27 since r0-6313 doesn't count anything as that insn sets
pseudo 101 to something that uses it, it isn't a side-effect instruction
and can't throw.
Now, after counting reg usages the subpass walks the IL from end to start,
sees insn 27, counts[101] is non-zero, so insn_live_p is true, nothing is
deleted. Then sees insn 26, counts[104] is zero, insn_live_p is false,
we delete the insn and decrease associated counts, in this case counts[101]
becomes zero. And finally later we process insn 7, counts[101] is now zero,
insn_live_p is false, we delete the insn (and decrease associated counts,
which aren't any).
Except that this resulted in insn 27 staying in the IL but using a REG
which is no longer set (and worse, having a REG_EQUAL note of something we
need later in the same bb, so we then assume pseudo 101 contains 0xffffffff,
which it no longer does.
Now, if insn 26 was after insn 27, this would work just fine, we'd first
delete that and then insn 27 and then insn 7, which is why most of the time
it happens to work fine.
The following patch fixes it by detecting the cases where there are
self-references after a pseudo has been used at least once outside of the
self-references or just as REG_P SET_DEST and in that case only increases
the count for the pseudo, making it not trivially deletable.
2025-04-08 Eric Botcazou <botcazou@adacore.com>
Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/119594
* cse.cc (count_reg_usage): Count even x == dest regs if they have
non-zero counts already and incr is positive.
gccrs: Change optional to expected for parse_loop_label
gcc/rust/ChangeLog:
* parse/rust-parse-impl.h (Parser::parse_loop_label): Change function
return type to expected.
(Parser::parse_labelled_loop_expr): Adapt call location to new return
type.
* parse/rust-parse.h (enum class): Update function prototype.
gccrs: Resolve labels within break or continue expressions
gcc/rust/ChangeLog:
* resolve/rust-late-name-resolver-2.0.cc (Late::visit): Add call
to label resolution if there is one label.
(Late::resolve_label): Look for labels and emit an error message on
failure.
* resolve/rust-late-name-resolver-2.0.h: Add function prototypes.
A loop label error state was in use to represent missing loop label but
this may be easily forgotten and the optional nature of the label was
misrepresented.
gcc/rust/ChangeLog:
* ast/rust-ast-builder.cc (Builder::block): Call with a nullopt instead
of an error loop label.
(WhileLetLoopExpr::as_string): Use getter function and adapt to
newtype.
* ast/rust-ast.cc (WhileLoopExpr::as_string): Likewise.
(LoopExpr::as_string): Likewise.
(BreakExpr::as_string): Likewise.
(ForLoopExpr::as_string): Likewise.
* ast/rust-expr.h (class BlockExpr): Make loop label optional.
(class BreakExpr): Likewise.
* expand/rust-derive-clone.cc (DeriveClone::clone_fn): Use nullopt.
* expand/rust-derive-debug.cc (DeriveDebug::stub_debug_fn): Likewise.
* expand/rust-derive-default.cc (DeriveDefault::default_fn): Likewise.
* expand/rust-derive-eq.cc: Likewise.
* parse/rust-parse-impl.h (Parser::parse_block_expr): Use optional
for arguments.
(Parser::parse_loop_expr): Likewise.
(Parser::parse_while_loop_expr): Likewise.
(Parser::parse_while_let_loop_expr): Likewise.
(Parser::parse_for_loop_expr): Likewise.
(Parser::parse_labelled_loop_expr): Likewise.
(Parser::parse_loop_label): Return an optional.
* parse/rust-parse.h: Update function prototype and use nullopt for
default values.
* resolve/rust-ast-resolve-base.h (redefined_error): created a function for
rust_error_at for redefined at multiple times.
* resolve/rust-ast-resolve-implitem.h: changed rust_error_at to redefined_error.
* resolve/rust-ast-resolve-stmt.cc (ResolveStmt::visit): changed rust_error_at to
redefined_error.
* resolve/rust-ast-resolve-stmt.h: changed rust_error_at to redefined_error.
* resolve/rust-ast-resolve-toplevel.h: changed rust_error_at to redefined_error.
Signed-off-by: Sri Ganesh Thota <sriganeshthota12345@gmail.com>
Owen Avery [Sun, 30 Mar 2025 23:08:45 +0000 (19:08 -0400)]
gccrs: nr2.0: Improve test script
gcc/testsuite/ChangeLog:
* rust/compile/nr2/compile.exp: Avoid absolute paths in output,
adjust phrasing of output, and avoid false XPASS output when
tests are run in parallel.
* ast/rust-ast-visitor.cc
(DefaultASTVisitor::visit): Remove explicit visitation of a
function's self parameter, as if it exists it'll be visited as
one of the function parameters.
* resolve/rust-ast-resolve-type.cc (ResolveRelativeTypePath::go): fix error msg
* typecheck/rust-substitution-mapper.cc (SubstMapper::Resolve): add validation
(SubstMapper::valid_type): new check
(SubstMapper::visit): check if can resolve
* typecheck/rust-substitution-mapper.h: new prototype
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: nr2 is missing type path error
* rust/compile/issue-3643.rs: New test.
* rust/compile/issue-3646.rs: New test.
* rust/compile/issue-3654.rs: New test.
* rust/compile/issue-3663.rs: New test.
* rust/compile/issue-3671.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Wed, 2 Apr 2025 17:21:46 +0000 (18:21 +0100)]
gccrs: Fix recusive type query and nullptr on type path
This was a small fix to sort out the segfault to check for nullptr on the
TypePath cases for query type. But when this happened opened up a few bugs
that were hidden under the carpet namely: compile/issue-2905-{1,2}.rs which
has a recursive type query which needs to ne handled but now and error
message is being output for the type path. This happens because we start
resolving a generic struct:
struct Wierd<T>(A<(T,)>);
So the child field A is also generic and the generic argument of the tuple
of T needs to be applied to this generic field. This causes a chunk of
code to do bounds checking to ensure the bounds are ok, this is also
something that probably might change as generic types will have the bounds
secified anyway but thats besides the case right now. So once this bounds
checking occurs we endup looking at the impl block for Wierd<i32> which is
also grand but we still havent finished resolving the parent type of Wierd
which is recusive. But the query type system needs to check for that.
The other issue was: compile/issue-3022.rs which is a resolution issue:
impl<T: Foo<U>, U> Foo<U> for Bar<T, U>
The bound of Foo<T> is added to T before U is resolved but this was hidden
before the new error message was added. So now we have a generic
arguements handler being used correctly all over the code base apart from
1 last case for Traits but we will deal with that later. This handles the
case by setting up the type parameters upfront then sorting out their
bounds.
Fixes Rust-GCC#3625
gcc/rust/ChangeLog:
* typecheck/rust-hir-trait-resolve.cc (TraitResolver::resolve_trait): new argument
* typecheck/rust-hir-type-check-base.cc (TypeCheckBase::TypeCheckBase): new helper
* typecheck/rust-hir-type-check-base.h: new helper prototype
* typecheck/rust-hir-type-check-implitem.cc (TypeCheckTopLevelExternItem::visit):
remove comment out code
* typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::resolve_root_path): check for null
* typecheck/rust-hir-type-check-type.cc (TypeCheckType::resolve_root_path): likewise
(TypeResolveGenericParam::Resolve): new args
(TypeResolveGenericParam::ApplyAnyTraitBounds): new helper
(TypeResolveGenericParam::apply_trait_bounds): new field
(TypeResolveGenericParam::visit): update
* typecheck/rust-hir-type-check-type.h: new args
* typecheck/rust-hir-type-check.cc (TraitItemReference::get_type_from_fn): reuse helper
* typecheck/rust-type-util.cc (query_type): check for recursive query
* typecheck/rust-tyty-subst.cc (SubstitutionParamMapping::SubstitutionParamMapping):
remove const
(SubstitutionParamMapping::get_generic_param): likewise
* typecheck/rust-tyty-subst.h: likewise
* typecheck/rust-tyty-variance-analysis.cc (GenericTyVisitorCtx::process_type): likewise
gcc/testsuite/ChangeLog:
* rust/compile/issue-3625.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Wed, 2 Apr 2025 15:16:47 +0000 (16:16 +0100)]
gccrs: Fix ICE when there are 2 functions named main
We need to setup the main_identifier_node for MAIN_DECL_P checks in the
middle-end. But it is valid to have a main function/method on impl blocks.
So we need to flag if this is a "root" item or not, which is one that is
jsut an HIR::Function on part of the Crate::items as oppposed to a
HIR::Function which is part of an HIR::ImplBlock as part of the HIR::Crate.
Some small cleanups have been added here too.
Fixes Rust-GCC#3648
gcc/rust/ChangeLog:
* backend/rust-compile-base.cc: new flag is_root_item
* backend/rust-compile-base.h: update prototype
* backend/rust-compile-implitem.cc (CompileTraitItem::visit): update call
* backend/rust-compile-implitem.h: remove old debug internal error
* backend/rust-compile-item.cc (CompileItem::visit): update call
* backend/rust-compile-item.h: remove old debug
* backend/rust-compile-resolve-path.cc (HIRCompileBase::query_compile): update calls
* backend/rust-compile.cc: likewise
* typecheck/rust-hir-trait-resolve.cc (TraitResolver::resolve_path_to_trait):
remove assertion and error
gcc/testsuite/ChangeLog:
* rust/compile/issue-3648.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Mon, 31 Mar 2025 16:58:24 +0000 (17:58 +0100)]
gccrs: Fix ICE when doing shift checks on const decl
Const decls are just delcarations wrapping the value into the DECL_INITIAL
and the shift checks we have assume no decls are involved and its just flat
values. This patch simply unwraps the constant values if they exist.
Jonathan Wakely [Mon, 7 Apr 2025 18:52:55 +0000 (19:52 +0100)]
libstdc++: Fix use-after-free in std::format [PR119671]
When formatting floating-point values to wide strings there's a case
where we invalidate a std::wstring buffer while a std::wstring_view is
still referring to it.
libstdc++-v3/ChangeLog:
PR libstdc++/119671
* include/std/format (__formatter_fp::format): Do not invalidate
__wstr unless _M_localized returns a valid string.
* testsuite/std/format/functions/format.cc: Check wide string
formatting of floating-point types with classic locale.
Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com>
Tejas Belagod [Wed, 27 Mar 2024 10:02:51 +0000 (15:32 +0530)]
AArch64: Diagnose OpenMP offloading when SVE types involved.
The target clause in OpenMP is used to offload loop kernels to accelarator
peripeherals. target's 'map' clause is used to move data from and to the
accelarator. When the data is SVE type, it may not be suitable because of
various reasons i.e. the two SVE targets may not agree on vector size or
some targets don't support variable vector size. This makes SVE unsuitable
for use in OMP's 'map' clause. This patch diagnoses all such cases and issues
an error where SVE types are not suitable.
Co-authored-by: Andrea Corallo <andrea.corallo@arm.com>
gcc/ChangeLog:
* target.h (type_context_kind): Add new context kinds for target clauses.
(omp_type_context): Query if the context is of OMP kind.
* config/aarch64/aarch64-sve-builtins.cc (verify_type_context): Diagnose
SVE types for a given OpenMP context.
(omp_type_context): New.
* gimplify.cc (omp_notice_variable): Diagnose implicitly-mapped SVE
objects in OpenMP regions.
(gimplify_scan_omp_clauses): Diagnose SVE types for various target
clauses.
Various parts of the omp code checked whether the size of a decl
was an INTEGER_CST in order to determine whether the decl was
variable-sized or not. If it was variable-sized, it was expected
to have a DECL_VALUE_EXPR replacement, as for VLAs.
This patch uses poly_int_tree_p instead, so that variable-length
SVE vectors are treated like constant-length vectors. This means
that some structures become poly_int-sized, with some fields at
poly_int offsets, but we already have code to handle that.
An alternative would have been to handle the data via indirection
instead. However, that's likely to be more complicated, and it
would contradict is_variable_sized, which already uses a check
for TREE_CONSTANT rather than INTEGER_CST.
gimple_add_tmp_var should probably not add a safelen of 1
for SVE vectors, but that's really a separate thing and might
be hard to test.
Co-authored-by: Tejas Belagod <tejas.belagod@arm.com>
gcc/
PR middle-end/101018
* poly-int.h (can_and_p): New function.
* fold-const.cc (poly_int_binop): Use it to optimize BIT_AND_EXPRs
involving POLY_INT_CSTs.
* gimplify.cc (omp_notice_variable): Use poly_int_tree_p instead
of INTEGER_CST when checking for constant-sized omp data.
(gimplify_adjust_omp_clauses_1): Likewise.
(gimplify_adjust_omp_clauses): Likewise.
* omp-low.cc (scan_sharing_clauses): Likewise.
Haochen Jiang [Fri, 28 Mar 2025 08:16:27 +0000 (16:16 +0800)]
i386: Add PTA_AVX10_1_256 to PTA_DIAMONDRAPIDS
For -march= handling, PTA_AVX10_1 will not imply PTA_AVX10_1_256,
resulting in TARGET_AVX10_1 becoming true while TARGET_AVX10_1_256
false. Since we will check TARGET_AVX10_1_256 in GCC 15 for AVX512
feature enabling for AVX10, -march=diamondrapids will not enable
512 bit register and x/ymm16+.
Since AVX10 will get a further clean up in GCC 16 and will help
PTA_DIAMONDRAPIDS reusing PTA_GRANITERAPIDS_D, the imply would become
obvious again, I plan not to add the testcase but just to fix the issue
in GCC 15.
Jin Ma [Mon, 7 Apr 2025 06:21:50 +0000 (14:21 +0800)]
RISC-V: Disable unsupported vsext/vzext patterns for XTheadVector.
XThreadVector does not support the vsext/vzext instructions; however,
due to the reuse of RVV optimizations, it may generate these instructions
in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2',"
we should disable these patterns.
V2:
Change the value of dg-do in the test case from assemble to compile, and
remove the -save-temps option.
gcc/ChangeLog:
* config/riscv/vector.md: Disable vsext/vzext for XTheadVector.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/vsext.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vzext.c: New test.
projects / thirdparty / gcc.git / log
