Fortran/OpenMP: Support automatic mapping allocatable components (deep mapping)
When mapping an allocatable variable (or derived-type component), explicitly
or implicitly, all its allocated allocatable components will automatically be
mapped. The patch implements the target hooks, added for this feature to
omp-low.cc with commit r15-3895-ge4a58b6f28383c.
Namely, there is a check whether there are allocatable components at all:
gfc_omp_deep_mapping_p. Then gfc_omp_deep_mapping_cnt, counting the number
of required mappings; this is a dynamic value as it depends on array
bounds and whether an allocatable is allocated or not.
And, finally, the actual mapping: gfc_omp_deep_mapping.
Polymorphic variables are partially supported: the mapping of the _data
component is fully supported, but only components of the declared type
are processed for additional allocatables. Additionally, _vptr is not
touched. This means that everything needing _vtab information requires
unified shared memory; in particular, _size data is required when
accessing elements of polymorphic arrays.
However, for scalar arrays, accessing components of the declare type
should work just fine.
As polymorphic variables are not (really) supported and OpenMP 6
explicitly disallows them, there is now a warning (-Wopenmp) when
they are encountered. Unlimited polymorphics are rejected (error).
Additionally, PRIVATE and FIRSTPRIVATE are not quite supported for
allocatable components, polymorphic components and as polymorphic
variable. Thus, those are now rejected as well.
gcc/fortran/ChangeLog:
* f95-lang.cc (LANG_HOOKS_OMP_DEEP_MAPPING,
LANG_HOOKS_OMP_DEEP_MAPPING_P, LANG_HOOKS_OMP_DEEP_MAPPING_CNT):
Define.
* openmp.cc (gfc_match_omp_clause_reduction): Fix location setting.
(resolve_omp_clauses): Permit allocatable components, reject
them and polymorphic variables in PRIVATE/FIRSTPRIVATE.
* trans-decl.cc (add_clause): Set clause location.
* trans-openmp.cc (gfc_has_alloc_comps): Add ptr_ok and
shallow_alloc_only Boolean arguments.
(gfc_omp_replace_alloc_by_to_mapping): New.
(gfc_omp_private_outer_ref, gfc_walk_alloc_comps,
gfc_omp_clause_default_ctor, gfc_omp_clause_copy_ctor,
gfc_omp_clause_assign_op, gfc_omp_clause_dtor): Update call to it.
(gfc_omp_finish_clause): Minor cleanups, improve location data,
handle allocatable components.
(gfc_omp_deep_mapping_map, gfc_omp_deep_mapping_item,
gfc_omp_deep_mapping_comps, gfc_omp_gen_simple_loop,
gfc_omp_get_array_size, gfc_omp_elmental_loop,
gfc_omp_deep_map_kind_p, gfc_omp_deep_mapping_int_p,
gfc_omp_deep_mapping_p, gfc_omp_deep_mapping_do,
gfc_omp_deep_mapping_cnt, gfc_omp_deep_mapping): New.
(gfc_trans_omp_array_section): Save array descriptor in case
deep-mapping lang hook will need it.
(gfc_trans_omp_clauses): Likewise; use better clause location data.
* trans.h (gfc_omp_deep_mapping_p, gfc_omp_deep_mapping_cnt,
gfc_omp_deep_mapping): Add function prototypes.
libgomp/ChangeLog:
* libgomp.texi (5.0 Impl. Status): Mark mapping alloc comps as 'Y'.
* testsuite/libgomp.fortran/allocatable-comp.f90: New test.
* testsuite/libgomp.fortran/map-alloc-comp-3.f90: New test.
* testsuite/libgomp.fortran/map-alloc-comp-4.f90: New test.
* testsuite/libgomp.fortran/map-alloc-comp-5.f90: New test.
* testsuite/libgomp.fortran/map-alloc-comp-6.f90: New test.
* testsuite/libgomp.fortran/map-alloc-comp-7.f90: New test.
* testsuite/libgomp.fortran/map-alloc-comp-8.f90: New test.
* testsuite/libgomp.fortran/map-alloc-comp-9.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/map-alloc-comp-1.f90: Remove dg-error.
* gfortran.dg/gomp/polymorphic-mapping-2.f90: Update warn wording.
* gfortran.dg/gomp/polymorphic-mapping.f90: Change expected
diagnostic; some tests moved to ...
* gfortran.dg/gomp/polymorphic-mapping-1.f90: ... here as new test.
* gfortran.dg/gomp/polymorphic-mapping-3.f90: New test.
* gfortran.dg/gomp/polymorphic-mapping-4.f90: New test.
* gfortran.dg/gomp/polymorphic-mapping-5.f90: New test.
Kyrylo Tkachov [Thu, 27 Feb 2025 17:24:10 +0000 (09:24 -0800)]
Locality cloning pass: -fipa-reorder-for-locality
Implement partitioning and cloning in the callgraph to help locality.
A new -fipa-reorder-for-locality flag is used to enable this.
The majority of the logic is in the new IPA pass in ipa-locality-cloning.cc
The optimization has two components:
* Partitioning the callgraph so as to group callers and callees that frequently
call each other in the same partition
* Cloning functions that straddle multiple callchains and allowing each clone
to be local to the partition of its callchain.
The majority of the logic is in the new IPA pass in ipa-locality-cloning.cc.
It creates a partitioning plan and does the prerequisite cloning.
The partitioning is then implemented during the existing LTO partitioning pass.
To guide these locality heuristics we use PGO data.
In the absence of PGO data we use a static heuristic that uses the accumulated
estimated edge frequencies of the callees for each function to guide the
reordering.
We are investigating some more elaborate static heuristics, in particular using
the demangled C++ names to group template instantiatios together.
This is promising but we are working out some kinks in the implementation
currently and want to send that out as a follow-up once we're more confident
in it.
A new bootstrap-lto-locality bootstrap config is added that allows us to test
this on GCC itself with either static or PGO heuristics.
GCC bootstraps with both (normal LTO bootstrap and profiledbootstrap).
As this new pass enables a new partitioning scheme it is incompatible with
explicit -flto-partition= options so an error is introduced when the user
uses both flags explicitly.
With this optimization we are seeing good performance gains on some large
internal workloads that stress the parts of the processor that is sensitive
to code locality, but we'd appreciate wider performance evaluation.
Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for mainline?
Thanks,
Kyrill
Martin Jambor [Tue, 15 Apr 2025 13:55:34 +0000 (15:55 +0200)]
ipa-bit-cp: Fix adjusting value according to mask (PR119803)
In my fix for PR 119318 I put mask calculation in
ipcp_bits_lattice::meet_with_1 above a final fix to value so that all
the bits in the value which are meaningless according to mask have
value zero, which has tripped a validator in PR 119803. This patch
fixes that by moving the adjustment down.
Even thought the fix for PR 119318 did a similar thing in
ipcp_bits_lattice::meet_with, the same is not necessary because that
code path then feeds the new value and mask to
ipcp_bits_lattice::set_to_constant which does the final adjustment
correctly.
In both places, however, Jakup proposed a better way of calculating
cap_mask and so I have changed it accordingly.
gcc/ChangeLog:
2025-04-15 Martin Jambor <mjambor@suse.cz>
PR ipa/119803
* ipa-cp.cc (ipcp_bits_lattice::meet_with_1): Move m_value adjustmed
according to m_mask below the adjustment of the latter according to
cap_mask. Optimize the calculation of cap_mask a bit.
(ipcp_bits_lattice::meet_with): Optimize the calculation of cap_mask a
bit.
d: Fix internal compiler error: in visit, at d/decl.cc:838 [PR119799]
This was caused by a check in the D front-end disallowing static
VAR_DECLs with a size `0'.
While empty structs in D are give the size `1', the same symbol coming
from ImportC modules do infact have no size, so allow C variables to
pass the check as well as array objects.
PR d/119799
gcc/d/ChangeLog:
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Check front-end
type size before building the VAR_DECL. Allow C symbols to have a
size of `0'.
gcc/testsuite/ChangeLog:
* gdc.dg/import-c/pr119799.d: New test.
* gdc.dg/import-c/pr119799c.c: New test.
When remapping existing specializations of a hidden template friend from
a previous declaration to the new definition, we must remap only those
specializations that match this new definition, but currently we
remap all specializations (since they all appear in the same
DECL_TEMPLATE_INSTANTIATIONS list of the most general template).
Concretely, in the first testcase below, we form two specializations of
the friend A::f, one with arguments {{0},{bool}} and another with
arguments {{1},{bool}}. Later when instantiating B, we need to remap
these specializations. During the B<0> instantiation we only want to
remap the first specialization, and during the B<1> instantiation only
the second specialization, but currently we remap both specializations
twice.
tsubst_friend_function needs to determine if an existing specialization
matches the shape of the new definition, which is tricky in general,
e.g. if the outer template parameters may not match up. Fortunately we
don't have to reinvent the wheel here since is_specialization_of_friend
seems to do exactly what we need. We can check this unconditionally,
but I think it's only necessary when dealing with specializations formed
from a class template scope previous declaration, hence the
TMPL_ARGS_HAVE_MULTIPLE_LEVELS check.
PR c++/119807
PR c++/112288
gcc/cp/ChangeLog:
* pt.cc (tsubst_friend_function): Skip remapping an
existing specialization if it doesn't match the shape of
the new friend definition.
gcc/testsuite/ChangeLog:
* g++.dg/template/friend86.C: New test.
* g++.dg/template/friend87.C: New test.
d: Fix ICE in dwarf2out_imported_module_or_decl, at dwarf2out.cc:27676 [PR119817]
The ImportVisitor method for handling the importing of overload sets was
pushing NULL_TREE to the array of import decls, which in turn got passed
to `debug_hooks->imported_module_or_decl', triggering the observed
internal compiler error.
NULL_TREE is returned from `build_import_decl' when the symbol was
ignored for being non-trivial to represent in debug, for example,
template or tuple declarations. So similarly "skip" adding the symbol
when this is the case for overload sets too.
PR d/119817
gcc/d/ChangeLog:
* imports.cc (ImportVisitor::visit (OverloadSet *)): Don't push
NULL_TREE to vector of import symbols.
gcc/testsuite/ChangeLog:
* gdc.dg/debug/imports/m119817/a.d: New test.
* gdc.dg/debug/imports/m119817/b.d: New test.
* gdc.dg/debug/imports/m119817/package.d: New test.
* gdc.dg/debug/pr119817.d: New test.
Jakub Jelinek [Tue, 15 Apr 2025 12:56:30 +0000 (14:56 +0200)]
ipa-cp: Fix up ipcp_print_widest_int
On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
> This patch just introduces a form of dumping of widest ints that only
> have zeros in the lowest 128 bits so that instead of printing
> thousands of f's the output looks like:
>
> Bits: value = 0xffff, mask = all ones folled by 0xffffffffffffffffffffffffffff0000
>
> and then makes sure we use the function not only to print bits but
> also to print masks where values like these can also occur.
Shouldn't that be followed by instead?
And the widest_int checks seems to be quite expensive (especially for
large widest_ints), I think for the first one we can just == -1
and for the second one wi::arshift (value, 128) == -1 and the zero extension
by using wi::zext.
Anyway, I wonder if it wouldn't be better to use something shorter,
the variant patch uses 0xf..f prefix before the 128-bit hexadecimal
number (maybe we could also special case the even more common bits 64+
are all ones case). Or it could be 0xf*f prefix. Or printing such
numbers as -0x prefixed negative, though that is not a good idea for masks.
This version doesn't print e.g.
0xf..fffffffffffffffffffffffffffff0000
but just
0xf..f0000
(of course, for say mask of
0xf..f0000000000000000000000000000ffff
it prints it like that, doesn't try to shorten the 0 digits.
But if the most significant bits aren't set, it will be just
0xffff.
2025-04-15 Jakub Jelinek <jakub@redhat.com>
* ipa-cp.cc (ipcp_print_widest_int): Print values with all ones in
bits 128+ with "0xf..f" prefix instead of "all ones folled by ".
Simplify wide_int check for -1 or all ones above least significant
128 bits.
Jakub Jelinek [Tue, 15 Apr 2025 12:09:55 +0000 (14:09 +0200)]
tailc: Fix up musttail calls vs. -fsanitize=thread [PR119801]
Calls with musttail attribute don't really work with -fsanitize=thread in
GCC. The problem is that TSan instrumentation adds
__tsan_func_entry (__builtin_return_address (0));
calls at the start of each instrumented function and
__tsan_func_exit ();
call at the end of those and the latter stands in a way of normal tail calls
as well as musttail tail calls.
Looking at what LLVM does, for normal calls -fsanitize=thread also prevents
tail calls like in GCC (well, the __tsan_func_exit () call itself can be
tail called in GCC (and from what I see not in clang)).
But for [[clang::musttail]] calls it arranges to move the
__tsan_func_exit () before the musttail call instead of after it.
The following patch handles it similarly. If we for -fsanitize=thread
instrumented function detect __builtin_tsan_func_exit () call, we process
it normally (so that the call can be tail called in function returning void)
but set a flag that the builtin has been seen (only for cfun->has_musttail
in the diag_musttail phase). And then let tree_optimize_tail_calls_1
call find_tail_calls again in a new mode where the __tsan_func_exit ()
call is ignored and so we are able to find calls before it, but only
accept that if the call before it is actually a musttail. For C++ it needs
to verify that EH cleanup if any also has the __tsan_func_exit () call
and if all goes well, the musttail call is registered for tailcalling with
a flag that it has __tsan_func_exit () after it and when optimizing that
we emit __tsan_func_exit (); call before the musttail tail call (or musttail
tail recursion).
2025-04-15 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/119801
* sanitizer.def (BUILT_IN_TSAN_FUNC_EXIT): Use BT_FN_VOID rather
than BT_FN_VOID_PTR.
* tree-tailcall.cc: Include attribs.h and asan.h.
(struct tailcall): Add has_tsan_func_exit member.
(empty_eh_cleanup): Add eh_has_tsan_func_exit argument, set what
it points to to 1 if there is exactly one __tsan_func_exit call
and ignore that call otherwise. Adjust recursive call.
(find_tail_calls): Add RETRY_TSAN_FUNC_EXIT argument, pass it
to recursive calls. When seeing __tsan_func_exit call with
RETRY_TSAN_FUNC_EXIT 0, set it to -1. If RETRY_TSAN_FUNC_EXIT
is 1, initially ignore __tsan_func_exit calls. Adjust
empty_eh_cleanup caller. When looking through stmts after the call,
ignore exactly one __tsan_func_exit call but remember it in
t->has_tsan_func_exit. Diagnose if EH cleanups didn't have
__tsan_func_exit and normal path did or vice versa.
(optimize_tail_call): Emit __tsan_func_exit before the tail call
or tail recursion.
(tree_optimize_tail_calls_1): Adjust find_tail_calls callers. If
find_tail_calls changes retry_tsan_func_exit to -1, set it to 1
and call it again with otherwise the same arguments.
Jonathan Yong [Sun, 13 Apr 2025 02:41:36 +0000 (02:41 +0000)]
Wbuiltin-declaration-mismatch-4.c: accept long long in warning for llp64
llp64 targets like mingw-w64 will print:
gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-4.c:80:17: warning: ‘memset’ argument 3 promotes to ‘ptrdiff_t’ {aka ‘long long int’} where ‘long long unsigned int’ is expected in a call to built-in function declared without prototype [-
Wbuiltin-declaration-mismatch]
Change the regex pattern to accept it.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
* gcc.dg/Wbuiltin-declaration-mismatch-4.c: Make diagnostic
accept long long.
Jonathan Wakely [Fri, 11 Apr 2025 21:13:14 +0000 (22:13 +0100)]
libstdc++: Fix std::string construction from volatile char* [PR119748]
My recent r15-9381-g648d5c26e25497 change assumes that a contiguous
iterator with the correct value_type can be converted to a const charT*
but that's not true for volatile charT*. The optimization should only be
done if it can be converted to the right pointer type.
Additionally, some generic loops for non-contiguous iterators need an
explicit cast to deal with iterator reference types that do not bind to
the const charT& parameter of traits_type::assign.
libstdc++-v3/ChangeLog:
PR libstdc++/119748
* include/bits/basic_string.h (_S_copy_chars): Only optimize for
contiguous iterators that are convertible to const charT*. Use
explicit conversion to charT after dereferencing iterator.
(_S_copy_range): Likewise for contiguous ranges.
* include/bits/basic_string.tcc (_M_construct): Use explicit
conversion to charT after dereferencing iterator.
* include/bits/cow_string.h (_S_copy_chars): Likewise.
(basic_string(from_range_t, R&&, const Allocator&)): Likewise.
Only optimize for contiguous iterators that are convertible to
const charT*.
* testsuite/21_strings/basic_string/cons/char/119748.cc: New
test.
* testsuite/21_strings/basic_string/cons/wchar_t/119748.cc:
New test.
Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com>
Jakub Jelinek [Tue, 15 Apr 2025 05:55:55 +0000 (07:55 +0200)]
libgcobol: Handle long double as an alternate IEEE754 quad [PR119244]
I think there should be consistency in what we use, so like
libgcobol-fp.h specifies, IEEE quad long double should have highest
priority, then _Float128 with *f128 APIs, then libquadmath.
And when we decide to use say long double, we shouldn't mix that with
strfromf128/strtof128.
Additionally, given that the *l vs. *f128 vs. *q API decision is done
solely in libgcobol and not in the compiler (which is different from
the Fortran case where compiled code emits say sinq or sinf128 calls),
I think libgcobol.spec should only have -lquadmath in any form only in
the case when using libquadmath for everything. In the Fortran case
it is for backwards compatibility purposes, if something has been
compiled with older gfortran which used say sinq and link is done by
gfortran which has been configured against new glibc with *f128, linking
would fail otherwise.
2025-04-15 Jakub Jelinek <jakub@redhat.com>
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
PR cobol/119244
* acinclude.m4 (LIBGCOBOL_CHECK_FLOAT128): Ensure
libgcob_cv_have_float128 is not yes on targets with IEEE quad
long double. Don't check for --as-needed nor set LIBQUADSPEC
on targets which USE_IEC_60559.
* libgcobol-fp.h (FP128_FMT, strtofp128, strfromfp128): Define.
* intrinsic.cc (strtof128): Don't redefine.
(WEIRD_TRANSCENDENT_RETURN_VALUE): Use GCOB_FP128_LITERAL macro.
(__gg__numval_f): Use strtofp128 instead of strtof128.
* libgcobol.cc (strtof128): Don't redefine.
(format_for_display_internal): Use strfromfp128 instead of
strfromf128 or quadmath_snprintf and use FP128_FMT in the format
string.
(get_float128, __gg__compare_2, __gg__move, __gg__move_literala):
Use strtofp128 instead of strtof128.
* configure: Regenerate.
Doc: always_inline attribute vs multiple TUs and LTO [PR113203]
gcc/ChangeLog
PR ipa/113203
* doc/extend.texi (Common Function Attributes): Explain how to
use always_inline in programs that have multiple translation
units, and that LTO inlining additionally needs optimization
enabled.
Jason Merrill [Sat, 12 Apr 2025 15:35:18 +0000 (11:35 -0400)]
c++: shortcut constexpr vector ctor [PR113835]
Since std::vector became usable in constant evaluation in C++20, a vector
variable with static storage duration might be manifestly
constant-evaluated, so we properly try to constant-evaluate its initializer.
But it can never succeed since the result will always refer to the result of
operator new, so trying is a waste of time. Potentially a large waste of
time for a large vector, as in the testcase in the PR.
So, let's recognize this case and skip trying constant-evaluation. I do
this only for the case of an integer argument, as that's the case that's
easy to write but slow to (fail to) evaluate.
In the test, I use dg-timeout-factor to lower the default timeout from 300
seconds to 15; on my laptop, compilation without the patch takes about 20
seconds versus about 2 with the patch.
PR c++/113835
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_outermost_constant_expr): Bail out early
for std::vector(N).
Thomas Schwinge [Fri, 28 Mar 2025 08:20:49 +0000 (09:20 +0100)]
GCN, nvptx: Support '-mfake-exceptions', and use it for offloading compilation [PR118794]
With '-mfake-exceptions' enabled, the user-visible behavior in presence of
exception handling constructs changes such that the compile-time
'sorry, unimplemented: exception handling not supported' is skipped, code
generation proceeds, and instead, exception handling constructs 'abort' at
run time. (..., or don't, if they're in dead code.)
PASS: gcc.dg/dg-output-file-1.c (test for excess errors)
PASS: dg-output-file-1-lp64.txt output file test
PASS: gcc.dg/dg-output-file-1.c execution test
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O0 (test for excess errors)
PASS: COMP-6_arithmetic.out output file test
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O0 execution test
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O1 (test for excess errors)
PASS: COMP-6_arithmetic.out output file test
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O1 execution test
[Etc.]
Notice that the 'PASS: [...] output file test' lines easily produce duplicate
test names, or might even produce PASS plus FAIL for the same test names.
Make the "output file test" use the same "descriptive name" as the other parts,
and get properly sorted with parallel-testing 'contrib/dg-extract-results.sh'
processing:
PASS: c-c++-common/zero-scratch-regs-leafy-2.c -Wc++-compat (test for excess errors)
-PASS: dg-output-file-1-lp64.txt output file test
PASS: gcc.dg/20000108-1.c (test for excess errors)
[...]
PASS: gcc.dg/devnull-dump.c (test for excess errors)
PASS: gcc.dg/dg-output-file-1.c (test for excess errors)
PASS: gcc.dg/dg-output-file-1.c execution test
+PASS: gcc.dg/dg-output-file-1.c output file test
PASS: gcc.dg/dg-test-1.c (test for excess errors)
..., and gets de-duplicated test names, for example:
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O0 (test for excess errors)
-PASS: COMP-6_arithmetic.out output file test
+PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O0 output file test
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O0 execution test
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O1 (test for excess errors)
-PASS: COMP-6_arithmetic.out output file test
+PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O1 output file test
PASS: cobol.dg/group2/COMP-6_arithmetic.cob -O1 execution test
[Etc.]
(Given that only ever a single 'dg-output-file' directive is active, don't
print the output filename.)
gcc/testsuite/
* lib/gcc-dg.exp (${tool}_load): Polish 'dg-output-file' test
logs.
Jakub Jelinek [Mon, 14 Apr 2025 17:35:20 +0000 (19:35 +0200)]
testsuite: Fix up ipa/pr119530.c testcase [PR119318]
I'm seeing
+FAIL: gcc.dg/ipa/pr119530.c execution test
on i686-linux. The problem is that when long is just 32-bit and
so is unsigned, the testcase then behaves differently and should abort.
Fixed by making the argument long long instead.
While at it, just in case I've changed type of d variable to signed char
as well just in case there is -funsigned-char 8-bit int target or something
similar.
2025-04-14 Jakub Jelinek <jakub@redhat.com>
PR ipa/119318
* gcc.dg/ipa/pr119530.c (d): Change type from char to signed char.
(e): Change argument type from long to long long.
Jakub Jelinek [Mon, 14 Apr 2025 17:34:22 +0000 (19:34 +0200)]
expmed: Always use QImode for init_expmed set_zero_cost [PR119785]
This is a regression on some targets introduced I believe by r6-2055
which added mode argument to set_src_cost.
The problem here is that in the first iteration, mode is always QImode
and we get as -Os zero cost set_src_cost (const0_rtx, QImode, false).
But then we use the mode variable for iterating over int, partial int
and vector int modes, so for the second iteration we call set_src_cost
with mode which is at that time (machine_mode) (MAX_MODE_VECTOR_INT + 1).
In the x86 case that happens to be V2HFmode and we don't crash (and
compute the same 0 cost as we would for QImode).
But e.g. in the SPARC case (machine_mode) (MAX_MODE_VECTOR_INT + 1) is
MAX_MACHINE_MODE and that does all kinds of weird things especially
when doing ubsan bootstrap.
Fixed by always using QImode.
2025-04-14 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/119785
* expmed.cc (init_expmed): Always pass QImode rather than mode to
set_src_cost passed to set_zero_cost.
Jakub Jelinek [Mon, 14 Apr 2025 17:33:11 +0000 (19:33 +0200)]
cobol: Fix -fmax-errors option [PR119776]
There seems to be inconsistency in the -fmax-errors option
naming. It is a generic option in common.opt (so applies
to all languages) but with the = character in it.
The gcobol.1 man page in one spot documents the generic
option (in the syntax, -fmax-errors=nerror) but in another
spot without the = character.
In common.opt it is
fmax-errors=
Common Joined RejectNegative UInteger Var(flag_max_errors)
-fmax-errors=<number> Maximum number of errors to report.
I hope the cobol addition is just a mistake, having -fmax-errors variant
without = character when Joined Separate would allow to specify
-fmax-errors 10 with the same meaning as -fmax-errors=10
but also -fmax-errors10 with the same meaning which is just weird.
Also, there is no UInteger and RejectNegative on it, so one can
also specific -fno-max-errors42 or -fmax-errors blah.
So, unless the spelling without = is intentional, here is a patch
to just remove it, the common option already should have arranged
for flag_max_errors to be set to the right number.
Or if it is intentional, I guess we'd need to at least add
RejectNegative UInteger (plus using atoi is generally undesirable
anywhere in the compiler because it does no error checking).
And the man page would need to be updated to specify both forms.
Jakub Jelinek [Mon, 14 Apr 2025 17:32:43 +0000 (19:32 +0200)]
cobol: Fix up COBOL -include [PR119777]
I was looking through options.cc diff between GCC 14 and 15, looking for
entries with added CL_Cobol where at least one other language is present
and was present before too. Besides the -fsyntax-only changes this is
the only other one I found, COBOL adds Var(cobol_include) to something
which didn't have a Var at all before and IMHO it is actively harmful.
Because one can specify multiple -include file1 -include file2 options,
both in C/C++ etc. and in COBOL as well (as documented in the man
page). A Var can track just one entry. cobol_langhook_handle_option
should use arg instead.
2025-04-14 Jakub Jelinek <jakub@redhat.com>
PR cobol/119777
* lang.opt (include): Remove Var(cobol_include).
* cobol1.cc (cobol_langhook_handle_option) <case OPT_include>: Use
arg instead of cobol_include.
Jakub Jelinek [Mon, 14 Apr 2025 17:32:06 +0000 (19:32 +0200)]
cobol: Drop -fsyntax-only from COBOL lang.opt [PR119777]
The comment is incorrect, fsyntax-only is not documented in c.opt,
but in common.opt:
fsyntax-only
Common Var(flag_syntax_only)
Check for syntax errors, then stop.
and as such it applies to all languages, so adding CL_Cobol to
the CL_COMMON is both unnecessary and because of RejectNegative which
contradicts the generic option very harmful, because it makes
-fno-syntax-only invalid for all languages.
Jakub Jelinek [Mon, 14 Apr 2025 17:31:23 +0000 (19:31 +0200)]
pretty-print, expand: Print [must tail call] for CALL_EXPRs and fix up maybe_complain_about_tail_call [PR119718]
Andrew P. mentioned earlier he'd like to see in the dump files a note
whether it was a failed must tail call or not.
We already print that on the tailc/musttail pass side, because
print_gimple_stmt prints [must tail call] after the musttail calls.
The first hunk below does it for GENERIC CALL_EXPRs too (which is needed
for the expand diagnostics). That isn't enough though, because the
error on it was done first and then CALL_EXPR_MUST_TAIL_CALL flag was
cleared, so the dump didn't have it anymore. I've reordered the
dump printing with error, so that it works properly.
2025-04-14 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119718
* tree-pretty-print.cc (dump_generic_node) <case CALL_EXPR>: Dump
also CALL_EXPR_MUST_TAIL_CALL flag.
* calls.cc (maybe_complain_about_tail_call): Emit error about
CALL_EXPR_MUST_TAIL_CALL only after emitting dump message, not before
it.
Arthur Cohen [Wed, 9 Apr 2025 12:48:55 +0000 (14:48 +0200)]
gccrs: nr2.0: Only insert derive macros if they exist
This causes an assertion failure when compiling core with nr2.0, but should
probably be improved. I'm not sure how this code enables built-in derive
macros to be resolved so this is a temporary fix.
Arthur Cohen [Fri, 4 Apr 2025 12:18:33 +0000 (14:18 +0200)]
gccrs: nr2.0: Do not resolve modules this run if they are unloaded
Instead, mark the visitor as dirty and wait for the next round of the fixed point to take care of
them. This avoids issues with module items being loaded while not being stripped yet.
gcc/rust/ChangeLog:
* resolve/rust-toplevel-name-resolver-2.0.cc (TopLevel::visit): Return if module
is unloaded.
Arthur Cohen [Thu, 3 Apr 2025 14:22:10 +0000 (16:22 +0200)]
gccrs: typecheck: Properly select methods when dealing with specialization
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-expr.cc (is_default_fn): New.
(emit_ambiguous_resolution_error): New.
(handle_multiple_candidates): Properly handle multiple candidates in
the case of specialization.
(TypeCheckExpr::visit): Call `handle_multiple_candidates`.
gcc/testsuite/ChangeLog:
* rust/execute/torture/min_specialization2.rs: New test.
* rust/execute/torture/min_specialization3.rs: New test.
Andrew Pinski [Thu, 20 Mar 2025 00:30:02 +0000 (17:30 -0700)]
rust: Add comment inside block [PR119342]
Inside a BLOCK node, all of the variables of the scope/block
are chained together and that connects them to the block.
This just adds a comment to that effect as reading the code
it is not so obvious why they need to be chained together.
gcc/rust/ChangeLog:
PR rust/119342
* rust-gcc.cc (block): Add comment on why chaining
the variables of the scope toether.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Thu, 20 Mar 2025 00:30:01 +0000 (17:30 -0700)]
rust: use range for inside rust-gcc.cc [PR119341]
There are some places inside rust-gcc.cc which are candidates
to use range for instead of iterators directly. This changes
the locations I saw and makes the code slightly more readable.
Andrew Pinski [Thu, 20 Mar 2025 00:29:59 +0000 (17:29 -0700)]
rust: Use FLOAT_TYPE_P instead of manual checking
This moves is_floating_point over to using FLOAT_TYPE_P instead
of manually checking. Note before it would return true for all
COMPLEX_TYPE but complex types' inner type could be integral.
Also fixes up the comment to be in more of the GNU style.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/rust/ChangeLog:
* rust-gcc.cc (is_floating_point): Use FLOAT_TYPE_P
instead of manually checking the type.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 14 Apr 2025 15:40:24 +0000 (08:40 -0700)]
testcase: Add testcase for already fixed PR [PR118476]
This testcase was fixed by r15-3052-gc7b76a076cb2c6ded but is
a testcase that failed in a different fashion and a much older
failure than the one added with r15-3052.
Pushed as obvious after a quick test.
PR tree-optimization/118476
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr118476-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Patrick Palka [Mon, 14 Apr 2025 15:20:13 +0000 (11:20 -0400)]
c++: wrong targs in satisfaction diagnostic context line [PR99214]
In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' won't correspond with
'args' after we augment the latter via add_outermost_template_args, and
so the instantiation context that we push via push_tinst_level isn't
quite correct: 'args' is a complete set of template arguments, but 't'
is not necessarily the most general template. This manifests as
misleading diagnostic context lines when issuing a satisfaction failure
error, e.g. the below testcase without this patch we emit:
In substitution of '... void A<int>::f<U>() ... [with U = int]'
and with this patch we emit:
In substitution of '... void A<int>::f<U>() ... [with U = char]'.
This patch fixes this by passing the original 'args' to push_tinst_level,
which ought to properly correspond to 't'.
PR c++/99214
gcc/cp/ChangeLog:
* constraint.cc (satisfy_declaration_constraints): Pass the
original ARGS to push_tinst_level.
Martin Jambor [Mon, 14 Apr 2025 12:21:15 +0000 (14:21 +0200)]
ipa-cp: Use the collected pass-through types to propgate constants (PR118097)
This patch revisits the fix for PR 118097 and instead of deducing the
necessary operation type it just uses the value collected and streamed
by an earlier patch.
It is bigger than the ones for propagating value ranges and known bits
because we track constants both in parameters themselves and also in
memory they point to or within aggregates, we clone functions for them
and we do fancy things for some types of recursive calls.
In the case of constants in aggregates or passed by reference, the
situation should not change because the code creating jump functions
for them does not allow type-casts, unlike for the plain ones.
However, this patch changes how we handle them for the sake of
consistency and also so that we can try and eliminate this limitation
in the next stage 1.
gcc/ChangeLog:
2025-03-20 Martin Jambor <mjambor@suse.cz>
PR ipa/118097
* ipa-cp.cc (ipa_get_jf_arith_result): Require res_operand for
anything except NOP_EXPR or ADDR_EXPR, document it and remove the code
trying to deduce it.
(ipa_value_from_jfunc): Use the stored and streamed type of arithmetic
pass-through functions.
(ipa_agg_value_from_jfunc): Use the stored and streamed type of
arithmetic pass-through functions, convert to the type used to store
the value if necessary.
(get_val_across_arith_op): New parameter op_type, pass it to
ipa_get_jf_arith_result.
(propagate_vals_across_arith_jfunc): New parameter op_type, pass it to
get_val_across_arith_op.
(propagate_vals_across_pass_through): Use the stored and streamed type
of arithmetic pass-through functions.
(propagate_aggregate_lattice): Likewise.
(push_agg_values_for_index_from_edge): Use the stored and streamed
type of arithmetic pass-through functions, convert to the type used to
store the value if necessary.
Martin Jambor [Mon, 14 Apr 2025 12:21:15 +0000 (14:21 +0200)]
ipa-cp: Use the stored and streamed pass-through types in ipa-vr (PR118785)
This patch revisits the fix for PR 118785 and intead of deducing the
necessary operation type it just uses the value collected and streamed
by an earlier patch. The main advantage is that we do not rely on
expr_type_first_operand_type_p enumarating all operations.
gcc/ChangeLog:
2025-03-20 Martin Jambor <mjambor@suse.cz>
PR ipa/118785
* ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Use the stored
and streamed type of arithmetic pass-through functions.
Martin Jambor [Mon, 14 Apr 2025 12:21:15 +0000 (14:21 +0200)]
ipa-cp: Make dumping of widest_ints even more sane
This patch just introduces a form of dumping of widest ints that only
have zeros in the lowest 128 bits so that instead of printing
thousands of f's the output looks like:
Bits: value = 0xffff, mask = all ones folled by 0xffffffffffffffffffffffffffff0000
and then makes sure we use the function not only to print bits but
also to print masks where values like these can also occur.
gcc/ChangeLog:
2025-03-21 Martin Jambor <mjambor@suse.cz>
* ipa-cp.cc (ipcp_print_widest_int): Also add a truncated form of
dumping of widest ints which only have zeros in the lowest 128 bits.
Update the comment.
(ipcp_bits_lattice::print): Also dump the mask using
ipcp_print_widest_int.
(ipcp_store_vr_results): Likewise.
Martin Jambor [Mon, 14 Apr 2025 12:21:15 +0000 (14:21 +0200)]
ipa-cp: Make propagation of bits in IPA-CP aware of type conversions (PR119318)
After the propagation of constants and value ranges, it turns out
that the propagation of known bits also needs to be made aware of any
intermediate types in which any arithmetic operations are made and
must limit its precision there. This implements just that, using the
newly collected and streamed types of the operations involved.
This version removed the extra check that the type of a formal
parameter is known pointed out in Honza in his review because I agree
it is currently always known. I have also added the testcase of PR
119530 which is a duplicate of this bug.
gcc/ChangeLog:
2025-04-11 Martin Jambor <mjambor@suse.cz>
PR ipa/119318
* ipa-cp.cc (ipcp_bits_lattice::meet_with_1): Set all mask bits
not covered by precision to one.
(ipcp_bits_lattice::meet_with): Likewise.
(propagate_bits_across_jump_function): Use the stored operation
type to perform meet with other lattices.
gcc/testsuite/ChangeLog:
2025-04-11 Martin Jambor <mjambor@suse.cz>
PR ipa/119318
* gcc.dg/ipa/pr119318.c: New test.
* gcc.dg/ipa/pr119530.c: Likwise.
Martin Jambor [Mon, 14 Apr 2025 12:21:14 +0000 (14:21 +0200)]
ipa: Record and stream result types of arithemetic jump functions
In order to replace the use of somewhat unweildy
expr_type_first_operand_type_p we need to record and stream the types
of results of operations recorded in arithmetic jump functions. This
is necessary so that we can then simulate them at the IPA stage with
the corresponding precision and signedness. This patch does the
recorsing and streaming, the following one adds the use of the date.
Per Honza's request this version also checks that we do not put VLA
types into the global LTO stream, even though I was not able to
actually craft a test-case that would do that without them.
gcc/ChangeLog:
2025-04-11 Martin Jambor <mjambor@suse.cz>
PR ipa/118097
PR ipa/118785
PR ipa/119318
* lto-streamer.h (lto_variably_modified_type_p): Declare.
* ipa-prop.h (ipa_pass_through_data): New field op_type.
(ipa_get_jf_pass_through_op_type): New function.
* ipa-prop.cc: Include lto-streamer.h.
(ipa_dump_jump_function): Dump also pass-through
operation types, if any. Dump pass-through operands only if not NULL.
(ipa_set_jf_simple_pass_through): Set op_type accordingly.
(compute_complex_assign_jump_func): Set op_type of arithmetic
pass-through jump_functions.
(analyze_agg_content_value): Update lhs when walking assighment
copies. Set op_type of aggregate arithmetic pass-through
jump_functions.
(update_jump_functions_after_inlining): Also transfer the operation
type from the source arithmentic pass-through jump function to the
destination jump function.
(ipa_write_jump_function): Stream also the op_type when necessary.
(ipa_read_jump_function): Likewise.
(ipa_agg_pass_through_jf_equivalent_p): Also compare operation types.
* lto-streamer-out.cc (lto_variably_modified_type_p): Make public.
Jonathan Wakely [Fri, 11 Apr 2025 10:08:34 +0000 (11:08 +0100)]
libstdc++: Document thread-safety for COW std::string [PR21334]
The gcc4-compatible copy-on-write std::string does not conform to the
C++11 requirements on data race avoidance in standard containers.
Specifically, calling non-const member functions such as begin() and
data() needs to do the "copy on write" operation and so is most
definitely a modification of the object. As such, those non-const
members must not be called concurrently with any other uses of the
string object.
libstdc++-v3/ChangeLog:
PR libstdc++/21334
* doc/xml/manual/using.xml: Document that container data race
avoidance rules do not apply to COW std::string.
* doc/html/*: Regenerate.
Tomasz Kamiński [Mon, 14 Apr 2025 06:43:58 +0000 (08:43 +0200)]
libstdc++: Use UTF-32BE as wide encoding for big-endian machines [PR119725]
This changes the `dg-options` line so UTF-32 with byte order native to the
machine is used as wide encoding.
We still do not handle mismatch in the byte order of the Unicode encodings
(UTF32-BE on little-endian machines). This would require larger changes,
as for example `unicode-data.h` tables are encoded with native byte order.
Richard Biener [Mon, 14 Apr 2025 09:42:18 +0000 (11:42 +0200)]
tree-optimization/119778 - properly mark abnormal edge sources during inlining
When inlining a call that abnormally transfers control-flow we make
all inlined calls that can possibly transfer abnormal control-flow
do so as well. But we failed to mark the calls as altering
control-flow. This results in inconsistent behavior later and
possibly wrong-code (we'd eventually prune those edges).
PR tree-optimization/119778
* tree-inline.cc (copy_edges_for_bb): Mark calls that are
source of abnormal edges as altering control-flow.
Gaius Mulley [Mon, 14 Apr 2025 09:13:40 +0000 (10:13 +0100)]
PR modula2/119779 ASM examples no longer work
This patch introduces four dejagnu tests matching four
documentation examples. Both asm examples are added and only built if
the x86_64 target is available. The other two are hello world using
libc and StrIO. The doc/gm2.texi asm examples are changed to
use eax rather than rax.
gcc/ChangeLog:
PR modula2/119779
* doc/gm2.texi (Interface to assembly language): Use eax
rather than rax in both examples.
gcc/testsuite/ChangeLog:
PR modula2/119779
* gm2.dg/doc/examples/pass/doc-examples-pass.exp: New test.
* gm2.dg/doc/examples/pass/exampleadd.mod: New test.
* gm2.dg/doc/examples/pass/exampleadd2.mod: New test.
* gm2.dg/doc/examples/pass/hello.mod: New test.
* gm2.dg/doc/examples/pass/hellopim.mod: New test.
Jakub Jelinek [Mon, 14 Apr 2025 08:18:13 +0000 (10:18 +0200)]
driver: On linux hosts disable ASLR during -freport-bug [PR119727]
Andi had a useful comment that even with the PR119727 workaround to
ignore differences in libbacktrace printed addresses, it is still better
to turn off ASLR when easily possible, e.g. in case some address leaks
in somewhere in the ICE message elsewhere, or to verify the ICE doesn't
depend on a particular library/binary load addresses.
The following patch adds a configure check and uses personality syscall
to turn off randomization for further -freport-bug subprocesses.
2025-04-14 Jakub Jelinek <jakub@redhat.com>
PR driver/119727
* configure.ac (HOST_HAS_PERSONALITY_ADDR_NO_RANDOMIZE): New check.
* gcc.cc: Include sys/personality.h if
HOST_HAS_PERSONALITY_ADDR_NO_RANDOMIZE is defined.
(try_generate_repro): Call
personality (personality (0xffffffffU) | ADDR_NO_RANDOMIZE)
if HOST_HAS_PERSONALITY_ADDR_NO_RANDOMIZE is defined.
* config.in: Regenerate.
* configure: Regenerate.
Eric Botcazou [Mon, 14 Apr 2025 07:32:20 +0000 (09:32 +0200)]
Fix implementation of Win32 thread model for C++ modules
This applies the same magic to config/i386/gthr-win32.h that was applied
to gthr-posix.h (https://gcc.gnu.org/cgit/gcc/commit/?id=6a4d1c374eed17)
for the sake of C++ modules.
Jerry DeLisle [Sun, 13 Apr 2025 02:51:23 +0000 (19:51 -0700)]
Fortran: Fix runtime segfault closing negative unit
When closing a UNIT with an invalid negative unit
number, a segfault ensued. This patch adds checks
for these conditions and issues errors.
PR libfortran/119502
libgfortran/ChangeLog:
* io/close.c (st_close): Issue an error and avoid
calling close_share when there is no stream assigned.
* io/open.c (st_open): If there is no stream assigned
to the unit, unlock the unit and issue an error.
Patrick Palka [Sun, 13 Apr 2025 15:04:46 +0000 (11:04 -0400)]
c++: improve constexpr call caching [PR115639]
For the testcase from this PR, checking
static_assert(0 == big_calc());
takes twice as much time as
constexpr int ret = big_calc();
static_assert(0 == ret);
ultimately because in the former, we first constant evaluate big_calc()
with mce_unknown (as part of warning-dependent folding from
cp_build_binary_op). We then constant evaluate it a second time, with
mce_true, during finish_static_assert. The result of the first
evaluation isn't reused because of the different mce_value, which in
general can give a different result.
But big_calc() here doesn't depend on mce_value at all (i.e. there's no if
consteval or __builtin_is_constant_evaluated calls, nested or otherwise)
so we should be able to reuse the result in such cases. Specifically if a
constexpr call with mce_unknown succeeds, we can safely reuse the result
during a subsequent mce_true or mce_false evaluation.
This patch implements this by also caching a successful mce_unknown call
result into the corresponding mce_true and mce_false slots, so that such
a subsequent evaluation effectively reuses the mce_unknown result. To
make it more convenient to access the cache slot for the same call with
different mce_value, this patch gives each constexpr_call entry three
result slots, one per mce_value, instead of having a distinct
constexpr_call entry for each mce_value. And we can no longer use
NULL_TREE to denote the call is in progress; instead use unknown_type_node.
After this patch compile time for the above two fragments is the same.
PR c++/115639
gcc/cp/ChangeLog:
* constexpr.cc (struct constexpr_call): Add NSDMIs to each
field. Replace 'result' data member with 3-element 'results'
array and a 'result' accessor function. Remove
'manifestly_const_eval' data member.
(constexpr_call_hasher::equal): Adjust after constexpr_call
layout change.
(cxx_eval_call_expression): Likewise. Define some local
variables closer to their first use. Use unknown_type_node
instead of NULL_TREE as the "in progress" result. After
successully evaluating a call with mce_unknown, also cache the
result in the corresponding mce_true and mce_false slots.
cobol/valconv.cc: In function ‘bool __gg__string_to_numeric_edited(char*, char*, int, int, const char*)’:
cobol/valconv.cc:856:40: error: ‘index’ was not declared in this scope; did you mean ‘Rindex’?
856 | const char *decimal_location = index(dest, __gg__decimal_point); | ^~~~~
| Rindex
On Solaris, it's only declared in <strings.h>. While one could get that
included, it's way easier to just use strchr as is already the case in
other instances.
Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
c++/modules: More fixes for merging DECL_MAYBE_DELETED functions
My change in r15-9216 broke the case where we imported an uninstantiated
defaulted function over the top of one we had already finished. This
patch ensures that we don't error for mismatches in this case.
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Don't check for
mismatches when importing a DECL_MAYBE_DELETED function over one
that's already finished.
gcc/testsuite/ChangeLog:
* g++.dg/modules/noexcept-4_a.H: New test.
* g++.dg/modules/noexcept-4_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
c++/modules: Give more specific diagnostics in is_matching_decl
This patch also rephrases the diagnostics to talk about "imported
declarations" rather than "global module declarations", since as the
FIXME noted we can also get mismatches with some declarations attached
to modules. Ideally I'd like to revisit the way this is structured
entirely but that won't be appropriate for GCC 15.
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Add custom errors for
different kinds of mismatches.
The recently announced IBM z17 processor implements the architecture
already supported as arch15. This patch adds support for z17 as an
alternative architecture name for arch15.
Thomas Koenig [Sun, 13 Apr 2025 08:22:07 +0000 (10:22 +0200)]
Fix ICE in compare_parameter.
This patch fixes an ICE by setting the typespec of a dummy argument
from a global function if known. plus setting the correct flag.
This also removes the corresponding assert. I'm not quite sure
that the code with the subroutine attribute can be reached, but
I thought better safe than sorry.
gcc/fortran/ChangeLog:
PR fortran/119669
* interface.cc (compare_parameter): Error when mismatch between
formal argument as subroutine and function. If the dummy
argument is a known function, set its typespec.
gcc/testsuite/ChangeLog:
PR fortran/119669
* gfortran.dg/interface_59.f90: New test.
d: Add option to include imported modules in the compilation [PR109023]
Adds the ability to include imported modules in the compilation, as if
they were given on the command line. When this option is enabled, all
imported modules are compiled except those that are part of libphobos.
PR d/109023
gcc/d/ChangeLog:
* d-compiler.cc: Include dmd/errors.h.
(Compiler::onImport): Implement.
* d-lang.cc (d_handle_option): Handle -finclude-imports.
(d_parse_file): Run semantic on included imports.
* gdc.texi: Document -finclude-imports.
* lang.opt: Add finclude-imports.
* lang.opt.urls: Regenerate.
gcc/testsuite/ChangeLog:
* gdc.dg/torture/imports/pr109023.d: New test.
* gdc.dg/torture/pr109023.d: New test.
d: Fix -fonly= argument only matches when including full path [PR119758]
Using `strcmp' to match the `-fonly=' argument with the input source
file made the feature inflexible to use. By mistake, the driver was
also found to omit all other modules on the command line as well, which
differed from the documentation on the flag:
Tell the compiler to parse and run semantic analysis on all modules
on the command line, but only generate code for the given argument.
New tests added to check the feature, which didn't exist before.
PR d/119758
gcc/d/ChangeLog:
* d-lang.cc (d_parse_file): Use endswith in test for -fonly= argument.
* d-spec.cc (lang_specific_driver): Rework -fonly= and pass all input
files to the front-end compiler when the option is seen.
gcc/testsuite/ChangeLog:
* gdc.dg/driver_fonly1.d: New test.
* gdc.dg/driver_fonly2.d: New test.
* gdc.dg/driver_fonly3.d: New test.
* gdc.dg/imports/fonly.d: New test.
Andrew Pinski [Sat, 12 Apr 2025 19:26:26 +0000 (12:26 -0700)]
testsuite: unxfail ira-shrinkwrap-prep-[12].c for x86_64 [PR117706]
When late combine was enabled for x86_64 (r15-1735-ge62ea4fb8ffcab),
these 2 testcases start to xpass in a similar fashion as when late
combine was added and the testcase was updated for aarch64 not to
xfail them there.
Pushed as obvious after a test to make sure the testcase no longer xpass.
PR testsuite/117706
gcc/testsuite/ChangeLog:
* gcc.dg/ira-shrinkwrap-prep-1.c: Unxfail for i?68-*-* and x86_64-*-*.
* gcc.dg/ira-shrinkwrap-prep-2.c: Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Patrick Palka [Sat, 12 Apr 2025 18:06:56 +0000 (14:06 -0400)]
c++: improve constexpr prvalue folding [PR116416]
This patch improves upon r15-6052-g12de1942a0a673 by performing prvalue
folding with mce_false rather than mce_unknown when it's safe to do so
(i.e. ff_mce_false is set), so that we can also fold temporary initializers
that call is_constant_evaluated etc.
In passing I noticed constexpr-prvalue1.C could more precisely verify the
optimization happened by inspecting what the front end spits out instead
of inspecting the optimized assembly -- that there's no constructor call
doesn't necessarily imply the constructor has been completely folded away,
only that its body has been inlined.
PR c++/116416
gcc/cp/ChangeLog:
* constexpr.cc (maybe_constant_init_1): Generalize type of
of manifestly_const_eval parameter from bool to mce_value.
(maybe_constant_init): Define 3-parameter version taking a
manifestly_const_eval instead of bool parameter.
(cxx_constant_init): Adjust.
* cp-gimplify.cc (cp_fold_r) <case TARGET_EXPR>: Pass mce_false
to maybe_constant_init during prvalue folding if ff_mce_false is
set.
* cp-tree.h (maybe_constant_init): Declare new overload.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-prvalue1.C: Adjust to instead inspect
the 'original' dump.
* g++.dg/cpp1y/constexpr-prvalue1a.C: New test.
Doc: Explicitly document extensions implied by -march=x86_64 [PR97585]
gcc/ChangeLog
PR target/97585
* doc/invoke.texi (x86 Options): Document list of extensions
supported by -march=x86_64, according to the declaration of
PTA_X86_64_BASELINE in config/i386/i386.h.
Jakub Jelinek [Sat, 12 Apr 2025 11:15:13 +0000 (13:15 +0200)]
driver: Fix up -freport-bug for ASLR [PR119727]
With --enable-host-pie -freport-bug almost never prepares preprocessed
source and instead emits
The bug is not reproducible, so it is likely a hardware or OS problem.
message even for bogus which are 100% reproducible.
The way -freport-bug works is that it reruns it 3 times, capturing stdout
and stderr from each and then tries to compare the outputs in between
different runs.
The libbacktrace emitted hexadecimal addresses at the start of the lines
can differ between runs due to ASLR, either of the PIE executable, or
even if not PIE if there is some frame with e.g. libc function (say
crash in strlen/memcpy etc.).
The following patch fixes it by ignoring such differences at the start of
the lines.
2025-04-12 Jakub Jelinek <jakub@redhat.com>
PR driver/119727
* gcc.cc (files_equal_p): Rewritten using fopen/fgets/fclose instead
of open/fstat/read/close. At the start of lines, ignore lowercase
hexadecimal addresses followed by space.
Jakub Jelinek [Sat, 12 Apr 2025 11:13:53 +0000 (13:13 +0200)]
bitintlower: Fix up handling of SSA_NAME copies in coalescing [PR119722]
The following patch is miscompiled, because during the limited
SSA name coalescing the bitintlower pass does we incorrectly don't
register a conflict.
This is on
<bb 4> [local count: 1073741824]:
# b_17 = PHI <b_19(3), 8(2)>
g.4_13 = g;
_14 = g.4_13 >> 50;
_15 = (unsigned int) _14;
_21 = b_17;
_16 = (unsigned int) _21;
s_22 = _15 + _16;
return s_22;
basic block where in the map->bitint bitmap we track 14, 17 and 19.
The build_bitint_stmt_ssa_conflicts "hook" has special code where
it tracks uses at the final statements of mergeable operations, so
e.g. the
_16 = (unsigned int) _21;
statement is considered to be use of b_17 because _21 is not in
map->bitmap (or large_huge.m_names), i.e. is mergeable.
The problem is that build_ssa_conflict_graph has special code to handle
SSA_NAME copies and _21 = b_17; is gimple_assign_copy_p. In such cases
it calls live_track_clear_var on the rhs1. The problem is that
on the above bb, after we note in the _16 = (unsigned int) _21;
stmt we need b_17 the generic code makes us forget that because
of the copy statement, and then build_bitint_stmt_ssa_conflicts
ignores it completely (because _21 is large/huge bitint and is
not in map->bitint, so assumed to be handled by a later stmt in the
bb, for backwards walk like this before this one).
As the b_17 use is ignored, the coalescing thinks it can put
all of b_17, b_19 and _14 into the same partition, which is wrong,
while we can and should coalesce b_17 and b_19, _14 needs to be a different
temporary because b_17 is set before and used after _14 has been written.
The following patch fixes it by handling gimple_assign_copy_p in two
separate spots, move the generic coalesce handling of it after
build_ssa_conflict_graph (where build_ssa_conflict_graph handling
doesn't fall through to that, it does continue after the call) and
inside of build_ssa_conflict_graph it performs it too, but only if
the lhs is not mergeable large/huge bitint.
2025-04-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119722
* gimple-lower-bitint.h (build_bitint_stmt_ssa_conflicts): Add
CLEAR argument.
* gimple-lower-bitint.cc (build_bitint_stmt_ssa_conflicts): Add
CLEAR argument. Call clear on gimple_assign_copy_p rhs1 if lhs
is large/huge bitint unless lhs is not in names.
* tree-ssa-coalesce.cc (build_ssa_conflict_graph): Adjust
build_bitint_stmt_ssa_conflicts caller. Move gimple_assign_copy_p
handling to after the build_bitint_stmt_ssa_conflicts call.
Jakub Jelinek [Sat, 12 Apr 2025 11:12:56 +0000 (13:12 +0200)]
tailc, expand: Small incremental tweak to tail call dump [PR119718]
Here is an optional incremental tweak to the previous patch.
Instead of
./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ; grep -B1 '^\(;; \)\?Cannot tail-call:' pr119718.c.*
pr119718.c.222t.tailc-_7 = bar (0);
pr119718.c.222t.tailc:Cannot tail-call: call invocation refers to locals
--
pr119718.c.270r.expand-;; foo (1, 2, 3, 4, 5, 6, 7) [tail call]
pr119718.c.270r.expand:;; Cannot tail-call: callee required more stack slots than the caller
this dumps
./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ; grep '^\(;; \)\?Cannot tail-call:' pr119718.c.*
pr119718.c.222t.tailc:Cannot tail-call: call invocation refers to locals: _7 = bar (0);
pr119718.c.270r.expand:;; Cannot tail-call: callee required more stack slots than the caller: foo (1, 2, 3, 4, 5, 6, 7) [tail call]
2025-04-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119718
* tree-tailcall.cc (maybe_error_musttail): Dump the GIMPLE at the
end of the Cannot tail-call line rather than on the line before it.
* calls.cc (maybe_complain_about_tail_call): Dump the GENERIC
at the end of the ;; Cannot tail-call line rather than on the
line before it.
The following patch makes some adjustments so that users can analyze what
calls weren't tail called even without using musttail attribute (though I'm
still not convinced it should be a warning, because we don't distinguish
between calls in return call (...); statements vs. calls that just happened
to end up in tail positions because something has been optimized away etc.
E.g. for
int foo (int, int, int, int, int, int, int);
int bar (int);
void qux (int *);
int
baz (int x)
{
if (x)
return foo (1, 2, 3, 4, 5, 6, 7);
else
{
int y;
qux (&y);
return bar (x);
}
}
./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ; grep -B1 '^\(;; \)\?Cannot tail-call:' pr119718.c.*
pr119718.c.222t.tailc-_7 = bar (0);
pr119718.c.222t.tailc:Cannot tail-call: call invocation refers to locals
--
pr119718.c.270r.expand-;; foo (1, 2, 3, 4, 5, 6, 7) [tail call]
pr119718.c.270r.expand:;; Cannot tail-call: callee required more stack slots than the caller
The changes are:
1) in tailc pass use wording more consistent with the musttail error wording
2) do it only in *-details dump
3) add similar diagnostics on the expand side, but this time only for the
CALL_EXPR_TAILCALL calls, if something wasn't marked that way, it is up
to tailc pass to emit message about it, if it was and it still can't be
tail called, let it tell users about that; in this case I need
to use the ;; prefix because it will appear in the middle of
the IL dump and ;; is what is used for such purposes in other spots
4) I've tried to improve formatting of the maybe_error_musttail and
maybe_complain_about_tail_call calls
2025-04-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119718
* tree-tailcall.cc (maybe_error_musttail): Only dump into dump_file
if dump_flags & TDF_DETAILS. Use "Cannot tail-call: " prefix instead
of "Cannot convert: ".
(find_tail_calls, tree_optimize_tail_calls_1): Formatting fixes
for maybe_error_musttail calls.
* calls.cc (maybe_complain_about_tail_call): Emit also a message
into dump_file when dump_flags & TDF_DETAILS for CALL_EXPR_TAILCALL
calls.
(initialize_argument_information): Formatting fix for
maybe_complain_about_tail_call calls.
(can_implement_as_sibling_call_p, expand_call): Likewise.
Eric Botcazou [Sat, 12 Apr 2025 09:35:44 +0000 (11:35 +0200)]
Ada: Natural/Positive not ignored in subprogram renaming
The language says that the profile of a subprogram renaming-as-declaration
must be mode conformant with that of the renamed subprogram, and that the
parameter subtypes are taken from the renamed subprogram.
GNAT implements the rule, except when Natural and Positive are involved,
which may lead to the wrong conclusion that it does not.
gcc/ada/
PR ada/119643
* sem_ch8.adb (Inherit_Renamed_Profile): Add guard against the
peculiarities of Natural and Positive.
gcc/testsuite/
* gnat.dg/renaming17.adb: New test.
Bob Dubner [Fri, 11 Apr 2025 20:00:42 +0000 (16:00 -0400)]
cobol: Eliminate many getenv() calls. [PR119694]
Many debugging calls to getenv() are eliminated. The debugging calls that
remain use gcobol_getenv(...) ). Environment variables available to the user
are mostly prefixed "GCOBOL_".
projects / thirdparty / gcc.git / log
