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_".
Andrew Pinski [Fri, 17 Jan 2025 07:47:36 +0000 (23:47 -0800)]
testcase: Add testcase for shrink wrapping of vector<int>::push_back [PR118502]
LLVM folks noticed that GCC was shrink wrapping the call to vector<int>::push_back.
So I thought it was a good idea to commit a testcase to make sure GCC does not regress
in this area unknowning.
Note the shrink wrapping started with r15-1619-g3b9b8d6cfdf593.
Note this enables the testcase for x86_64 (!ia32), powerpc, aarch64 and riscv which I tested
via godbolt to see the shrink wrapping occurs. Also tested the testcase for both
x86_64-linux-gnu and aarch64-linux-gnu to make sure I got the target selects correct.
Changes since v1:
* v2: Fix some comments typos that was mentioned in the bug report.
PR rtl-optimization/118502
gcc/testsuite/ChangeLog:
* g++.dg/opt/shrink-wrapping-vector-1.C: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Jeff Law [Fri, 11 Apr 2025 14:28:22 +0000 (08:28 -0600)]
[committed] [RISC-V] Fix testsuite fallout from recent changes
Recent changes have started triggering:
> Tests that now fail, but worked before (3 tests):
>
> unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: gcc.target/riscv/rvv/base/pr115068-run.c (test for excess errors)
> unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: gcc.target/riscv/rvv/base/pr115068.c (test for excess errors)
> unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc: gcc.target/riscv/rvv/base/vwaddsub-1.c (test for excess errors)
We're emitting a pedantic diagnostic on the #include_next. This just turns off the pedantic warnings.
Jason Merrill [Thu, 10 Apr 2025 22:16:37 +0000 (18:16 -0400)]
c++: avoid ARM -Wunused-value [PR114970]
Because of the __builtin_is_constant_evaluated, maybe_constant_init in
expand_default_init fails, so the constexpr constructor isn't folded until
cp_fold, which then calls cp_build_init_expr_for_ctor, which builds a
COMPOUND_EXPR in case the enclosing expression is relying on the ARM
behavior of returning 'this'.
As in other places, avoid -Wunused-value on artificial COMPOUND_EXPR.
PR c++/114970
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_build_init_expr_for_ctor): Suppress warnings on
return_this COMPOUND_EXPR.
Jonathan Wakely [Thu, 10 Apr 2025 11:21:26 +0000 (12:21 +0100)]
libstdc++: Use constexpr-if for std::basic_string::_S_copy_chars
For C++11 and later we can remove four overloads of _S_copy_chars and
use constexpr-if in the generic _S_copy_chars. This simplifies overload
resolution for _S_copy_chars, and also means that we use the optimized
memcpy path for other iterators such as std::vector<char>::iterator.
We still need all the _S_copy_chars overloads to be part of the explicit
instantiation definition, so make them depend on the macro that is
defined by src/c++11/string-inst.cc for that purpose.
For C++98 the _S_copy_chars overloads are still needed, but the macros
_GLIBCXX_NOEXCEPT and _GLIBCXX20_CONSTEXPR do nothing for C++98, so this
change removes them from those overloads. When instantiated in
src/c++11/string-inst.cc the removed _GLIBCXX_NOEXCEPT macros would
expand to 'noexcept', but in practice that doesn't make any difference
for those instantiations. At -O2 the instantiations inline all the calls
to _S_copy_chars and the presence or absence of noexcept doesn't change
anything in the generated code.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (_S_copy_chars): Replace overloads
with constexpr-if and extend optimization to all contiguous
iterators.
* src/c++11/string-inst.cc: Extend comment.
Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com>
Tomasz Kamiński [Fri, 21 Mar 2025 11:55:48 +0000 (12:55 +0100)]
libstdc++: Define __cpp_lib_containers_ranges in appropriate headers [PR111055]
This is final piece of P1206R7, adding a feature test macros,
as range constructors and member operations are now implemented for
all containers and adaptors.
For consistency with the proposal, all new container operations and
helpers are now defined if __glibcxx_containers_ranges, instead
of __glibcxx_ranges_to_container.
Tomasz Kamiński [Wed, 2 Apr 2025 12:19:26 +0000 (14:19 +0200)]
libstdc++: Implement debug format for strings and characters formatters [PR109162]
This patch implements part P2286R8 that specified debug (escaped)
format for the strings and characters sequences. This include both
handling of the '?' format specifier and set_debug_format member.
To indicate partial support we define __glibcxx_format_ranges macro
value 1, without defining __cpp_lib_format_ranges.
We provide two separate escaping routines depending on the literal
encoding for the corresponding character types. If the character
encoding is Unicode, we follow the specification for the standard
(__format::__write_escaped_unicode).
For other encodings, we escape only characters in range [0x00, 0x80),
interpreting them as ASCII values: [0x00, 0x20), 0x7f and '\t', '\r',
'\n', '\\', '"', '\'' are escaped. We assume every character outside
this range is printable (__format::_write_escaped_ascii).
In particular we do not yet implement special handling of shift
sequences.
For Unicode escaping a new __unicode::__escape_edges table is introduced,
that encodes information if character belongs to General_Category that is
escaped by the standard (Control or Other). This table is generated from
DerivedGeneralCategory.txt provided by Unicode. Only boolean flag is
preserved to reduce the number of entries. The additional rules for escaping
are handled by __format::__should_escape_unicode.
When width or precision is specified, we emit escaped string to the temporary
buffer and format the resulting string according to the format spec.
For characters use a fixed size stack buffer, for which a new _Fixedbuf_sink is
introduced. For strings, we use _Str_sink and to avoid allocations,
we compute the estimated size of (possibly truncated) input, and if it is
larger than width field we print directly.
PR libstdc++/109162
contrib/ChangeLog:
* unicode/README: Mentioned DerivedGeneralCategory.txt.
* unicode/gen_libstdcxx_unicode_data.py: Generation __escape_edges
table from DerivedGeneralCategory.txt. Update file name in comments.
* unicode/DerivedGeneralCategory.txt: Copy of file distributed by
Unicode Consortium.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__detail::_Widen): Moved to std/format file.
* include/bits/unicode-data.h: Regnerate.
* include/bits/unicode.h (__unicode::_Utf_iterator::_M_units)
(__unicode::__should_escape_category): Define.
* include/std/format (_GLIBCXX_WIDEN_, _GLIBCXX_WIDEN): Copied from
include/bits/chrono_io.h.
(__format::_Widen): Moved from include/bits/chrono_io.h.
(__format::_Term_char, __format::_Escapes, __format::_Separators)
(__format::__should_escape_ascii, __format::__should_escape_unicode)
(__format::__write_escape_seq, __format::__write_escaped_char)
(__format::__write_escaped_acii, __format::__write_escaped_unicode)
(__format::__write_escaped): Define.
(__formatter_str::_S_trunc): Extracted truncation of character
sequences.
(__formatter_str::format): Handle _Pres_esc.
(__formatter_int::_M_do_parse) [__glibcxx_format_ranges]: Parse '?'.
(__formatter_int::_M_format_character_escaped): Define.
(formatter<_CharT, _CharT>::format, formatter<char, wchar_t>::format):
Handle _Pres_esc.
(__formatter_str::set_debug_format, formatter<...>::set_debug_format)
Guard with __glibcxx_format_ranges.
(__format::_Fixedbuf_sink): Define.
* testsuite/23_containers/vector/bool/format.cc: Use __format::_Widen
and remove unnecessary <chrono> include.
* testsuite/std/format/debug.cc: New test.
* testsuite/std/format/debug_nonunicode.cc: New test.
* testsuite/std/format/parse_ctx.cc (escaped_strings_supported): Define
to true if __glibcxx_format_ranges is defined.
* testsuite/std/format/string.cc (escaped_strings_supported): Define to
true if __glibcxx_format_ranges is defined.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Fri, 11 Apr 2025 06:27:55 +0000 (08:27 +0200)]
bitintlower: Fix up handling of nested casts in m_upward_2limbs cases [PR119707]
The following testcase is miscompiled I believe starting with
PR112941 r14-6742. That commit fixed the bitint-55.c testcase.
The m_first initialization for such conversion initializes 2 SSA_NAMEs,
one is PHI result on the loop (m_data[save_data_cnt]) and the other
(m_data[save_data_cnt+1]) is the argument of that PHI from the latch
edge initialized somewhere in the loop. Both of these are used to
propagate sign extension (i.e. either 0 or all ones limb) from the
iteration with the sign bit of a narrower type to following iterations.
The bitint-55.c testcase was ICEing with invalid SSA forms as it was
using unconditionally the PHI argument SSA_NAME even in places which
weren't dominated by that. And the code which was touched is about
handling constant idx, so if e.g. there are nested casts and the
outer one does conditional code based on index comparison with
a particular constant index.
In the following testcase there are 2 nested casts, one from signed
_BitInt(129) to unsigned _BitInt(255) and the outer from unsigned
_BitInt(255) to unsigned _BitInt(256). The m_upward_2limbs case which
is used for handling mergeable arithmetics (like +-|&^ and casts etc.)
one loop iteration handles 2 limbs, the first half the even ones, the
second half the odd ones.
And for these 2 conversions, the special one for the inner conversion
on x86_64 is with index 2 where the sign bit of _BitInt(129) is present,
while for the outer one index 3 where we need to mask off the most
significant bit.
The r15-6742 change started using m_data[save_data_cnt] for all constant
indexes if it is still inside of the loop (and it is sign extension).
But that doesn't work correctly for the case where the inner conversion
produces the sign extension limb in the loop for an even index and
the outer conversion needs to special case the immediately next conversion,
because in that case using the PHI result will see still 0 there rather
than the updated value from the handling of previous limb.
So the following patch special cases this and uses the other SSA_NAME.
Commented IL, trying to lower
_1 = (unsigned _BitInt(255)) y_4(D);
_2 = (unsigned _BitInt(256)) _1;
_3 = _2 + x_5(D);
<retval> = _3;
we were emitting
<bb 3> [local count: 1073741824]:
# _8 = PHI <0(2), _9(12)> // This is the limb index
# _10 = PHI <0(2), _11(12)> // Sign extension limb from inner cast (0 or ~0UL)
# _22 = PHI <0(2), _23(12)> // Overflow bit from addition of previous limb
if (_8 <= 2)
goto <bb 4>; [80.00%]
else
goto <bb 7>; [20.00%]
<bb 11> [local count: 214748360]:
// And HERE is the actual bug. Using _10 for idx 3 will mean it is always
// zero there and doesn't contain the _18 value propagated to it.
// It should be
// _30 = (<unnamed-unsigned:63>) _11;
// Now if the outer conversion had special iteration say 5, we could
// have used _10 fine here, by that time it already propagates through
// the PHI.
_30 = (<unnamed-unsigned:63>) _10;
_31 = (unsigned long) _30;
PR tree-optimization/119707
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Only use
m_data[save_data_cnt] instead of m_data[save_data_cnt + 1] if
idx is odd and equal to low + 1. Remember tree_to_uhwi (idx) in
a temporary instead of calling the function multiple times.
Jennifer Schmitz [Thu, 10 Apr 2025 13:46:15 +0000 (06:46 -0700)]
aarch64: Add test case.
This patch adds a test case to the testsuite for PR119706.
The bug was already fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680573.html.
OK for mainline?
Signed-off-by: Jennifer Schmitz <jschmitz@nvidia.com>
gcc/testsuite/
PR tree-optimization/119706
* g++.target/aarch64/sve/pr119706.C: New test.
Jonathan Yong [Wed, 9 Apr 2025 14:21:22 +0000 (14:21 +0000)]
realloc-1.c: accept long long in warning for llp64
llp64 targets like mingw-w64 will print:
warning: ignoring return value of ‘void* __builtin_realloc(void*, long long unsigned int)’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
Change the regex pattern to accept it.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/realloc-1.c: Make diagnostic accept
long long for __builtin_realloc warning.
Doc: Discourage the use of -ffloat-store [PR14708]
gcc/ChangeLog
PR middle-end/14708
* doc/invoke.texi (Optimize Options): List -fexcess-precision
before -ffloat-store, moving some background discussion to the
former from the latter. Recommend using -fexcess-precision=standard
instead of -ffloat-store.
Jason Merrill [Thu, 10 Apr 2025 18:34:35 +0000 (14:34 -0400)]
c++: nested lambda capture pack [PR119345]
tsubst_stmt already registers a local capture proxy as a
local_specialization of both an outer capture proxy and the captured
variable; we also need to do that in add_extra_args.
PR c++/119345
gcc/cp/ChangeLog:
* pt.cc (add_extra_args): Also register a specialization
of the captured variable.
The new SVE tests didn't explicitly force SVE to be enabled,
which meant that they wouldn't work on targets that aren't
configured for SVE by default. The least invasive way of
fixing that is to add a pragma, which works for most tests.
However, for udr-sve.c, the global:
which is interesting, and maybe worthy of a PR if there isn't one
already. It seems we have to force SVE (and thus an architecture)
on the command line instead.
However, with that fixed, udr-sve.c fails execution. One problem
seems to be a missing accumulation in for_reduction. Fixing that
is enough to reach the final inscan_reduction_incl, but that fails
for reasons I haven't investigated yet. I would need to read up
more to understand what the loop is doing.
It also looks like there might be a missing "+" in simd_reduction:
#pragma omp simd reduction (+:va, i)
for (j = 0; j < 16; j++)
va = svld1_s32 (svptrue_b32 (), a);
res = svaddv_s32 (svptrue_b32 (), va);
if (res != 8)
__builtin_abort ();
since AFAICT the loop is not doing a reduction as things stand.
But perhaps that's deliberate, since it does match the != 8 test.
libgomp/
* testsuite/libgomp.c-target/aarch64/firstprivate.c: Add +sve pragma.
* testsuite/libgomp.c-target/aarch64/lastprivate.c: Likewise.
* testsuite/libgomp.c-target/aarch64/private.c: Likewise.
* testsuite/libgomp.c-target/aarch64/shared.c: Likewise.
* testsuite/libgomp.c-target/aarch64/simd-aligned.c: Likewise.
* testsuite/libgomp.c-target/aarch64/simd-nontemporal.c: Likewise.
* testsuite/libgomp.c-target/aarch64/threadprivate.c: Likewise.
* testsuite/libgomp.c-target/aarch64/udr-sve.c: Add an -march option.
(for_reduction): Use "+=" in the reduction loop.
With inherited CTAD the set of guides may be a two-dimensional overload
set (i.e. OVERLOADs of OVERLOADs) so alias_ctad_tweaks (which also does
the inherited CTAD transformation) needs to use the 2D-aware lkp_iterator
instead of ovl_iterator, or better yet use the more idiomatic lkp_range.
PR c++/119687
gcc/cp/ChangeLog:
* pt.cc (alias_ctad_tweaks): Use lkp_range / lkp_iterator
instead of ovl_iterator.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/class-deduction-inherited8.C: New test.
Jakub Jelinek [Thu, 10 Apr 2025 16:39:52 +0000 (18:39 +0200)]
c++: Use G_ instead of _ around cp/errors.cc gcc-internal-format strings [PR119684]
These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything done through them should be translated
(e.g. its use for dump files shouldn't be).
In addition, composing translatable messages from
"in requirements " and later on "with " might make it harder to be
translated.
I've verified these strings (at least those which don't use format
specifiers added post GCC 4.3 which gettext doesn't handle) are properly
marked as gcc-internal-format in gcc.pot. The lack of that caused
ICEs on German translation of the "%s%s%sIn instantiation of %q#D:\n"
message because it contained too many %s.
2025-04-10 Jakub Jelinek <jakub@redhat.com>
PR translation/119684
* error.cc (cp_print_error_function): Use G_ instead of _ for
pp_printf arguments.
(function_category): Use G_ instead of _.
(print_instantiation_full_context): Use G_ instead of _ in pp_verbatim
arguments.
(print_location): Likewise.
(print_instantiation_partial_context): Likewise.
(maybe_print_constexpr_context): Likewise.
(print_constrained_decl_info): Use G_() around pp_verbatim argument.
(print_concept_check_info): Likewise.
(print_constraint_context_head): Likewise.
(print_requires_expression_info): Likewise. Merge separate pp_verbatim
"in requirements " and "with " into one with conditional messages.
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.
projects / thirdparty / gcc.git / log
