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_".
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.
projects / thirdparty / gcc.git / log
