| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
The following makes sure to not mix masked/non-masked stmts when
forming a SLP node.
PR tree-optimization/119757
* tree-vect-slp.cc (vect_build_slp_tree_1): Record and compare
whether a stmt uses a maks.
* gcc.dg/vect/pr119757.c: New testcase.
|
|
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.
* g++.dg/torture/pr119778.C: New testcase.
|
|
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.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
|
|
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.
|
|
It demonstrates a serious LTO breakage for the Ada language.
gcc/testsuite/
PR lto/119792
* gnat.dg/lto29.adb: New test.
* gnat.dg/lto29_pkg.ads: New helper.
|
|
|
|
parse.h causes the COBOL build to break on Solaris:
cobol/parse.h:356:5: error: expected identifier before numeric constant
356 | OVERFLOW = 305, /* OVERFLOW */
| ^~~~~~~~
The problem is that <math.h> has
#define OVERFLOW 3
To avoid the conflict, this patch renames OVERFLOW to OVERFLOW_kw,
following existing praxis.
Btw., token_names.h has a comment claiming
// generated by ./token_names.h.gen ../../build/gcc/cobol/parse.h
but there's no token_names.h.gen anywhere in the tree, so I've updated
the file manually.
Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
2025-04-08 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/cobol:
PR cobol/119217
* parse.y: Rename OVERFLOW to OVERFLOW_kw.
Specify type name in %token directive.
* scan.l: Likewise.
* token_names.h: Regenerate.
Co-Authored-By: Simon Sobisch <simonsobisch@gnu.org>
|
|
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.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr119502.f90: New test.
|
|
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.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
util.cc doesn't compile on Solaris:
/vol/gcc/src/hg/master/local/gcc/cobol/util.cc:2135:7: error: using typedef-name ‘timespec_t’ after ‘class’
2135 | class timespec_t {
| ^~~~~~~~~~
This happens because <time.h> declares timespec_t itself. In fact,
POSIX.1 reserves every *_t identifier, so this is benign.
To avoid the problem, this patch renames the cobol timespec_t to
cbl_timespec.
Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
2025-04-08 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/cobol:
PR cobol/119217
* util.cc (class timespec_t): Rename to cbl_timespec.
|
|
When building COBOL on Solaris/sparcv9 with the native assembler, many
tests FAIL to assemble at -O0 like this:
FAIL: cobol.dg/data1.cob -O0 (test for excess errors)
Excess errors:
/usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: invalid character
(0x50)
/usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: unknown opcode
"PERFORM"
/usr/ccs/bin/as: "/var/tmp//ccUduuqd.s", line 302: error: statement syntax
The problem is that genapi.cc hardcodes # as assembler comment
character, which isn't valid in general.
Instead, this patch uses ASM_COMMENT_START.
Bootstrapped without regressions on sparcv9-sun-solaris2.11,
amd64-pc-solaris2.11, and x86_64-pc-linux-gnu.
2025-04-08 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/cobol:
* genapi.cc: Include target.h.
(section_label): Use ASM_COMMENT_START.
(paragraph_label): Likewise.
(parser_perform): Likewise.
(internal_perform_through): Likewise.
(hijack_for_development): Likewise.
|
|
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>
|
|
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.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-8_b.C: Adjust error.
* g++.dg/modules/leg-merge-4_c.C: Likewise.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
gcc/ChangeLog:
* config/s390/s390.cc: Add z17 scheduler description.
* config/s390/s390.h: Ditto.
* config/s390/s390.md: Ditto.
* config/s390/9175.md: New file.
|
|
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.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename arch15 to z17.
* config.gcc: Add z17.
* config/s390/driver-native.cc: Detect z17 machine.
* config/s390/s390-builtins.def (B_VXE3): Rename arch15 to z17.
* config/s390/s390-c.cc (s390_resolve_overloaded_builtin): Ditto.
* config/s390/s390-opts.h (enum processor_type): Ditto.
* config/s390/s390.cc: Ditto.
* config/s390/s390.h: Ditto.
* config/s390/s390.md: Ditto.
* config/s390/s390.opt: Add z17.
* doc/invoke.texi: Ditto.
|
|
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.
|
|
|
|
Synchronizes the D runtime library with upstream druntime 09ed02ce56,
and fixes a rename of the importC module missed in the r15-6559 merge.
PR d/119761
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime 09ed02ce56.
* libdruntime/Makefile.am (DRUNTIME_DISOURCES): Rename __builtins.di
to __importc_builtins.di.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/__builtins.di: Move to...
* libdruntime/__importc_builtins.di: ...here.
gcc/testsuite/ChangeLog:
* gdc.dg/import-c/import-c.exp: New test.
* gdc.dg/import-c/pr119761.d: New test.
* gdc.dg/import-c/pr119761c.c: New test.
|
|
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.
|
|
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.
|
|
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>
|
|
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.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
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.
|
|
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.
|
|
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.
* gcc.dg/torture/bitint-77.c: New test.
|
|
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.
|
|
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.
|
|
'static_assert' [PR101602]
Fix-up for commit 2d7e1d6e40a13a5f160b584336795b80f193ec3b
"Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]":
../../source-gcc/gcc/fortran/trans-stmt.cc: In function ‘void gfc_trans_concurrent_locality_spec(bool, stmtblock_t*, std::vector<symbol_and_tree_t>*, gfc_expr_list**)’:
../../source-gcc/gcc/fortran/trans-stmt.cc:5157:59: error: expected ‘,’ before ‘)’ token
static_assert (LOCALITY_LOCAL_INIT - LOCALITY_LOCAL == 1);
^
../../source-gcc/gcc/fortran/trans-stmt.cc:5157:59: error: expected string-literal before ‘)’ token
make[2]: *** [Makefile:1210: fortran/trans-stmt.o] Error 1
PR fortran/101602
gcc/fortran/
* trans-stmt.cc (gfc_trans_concurrent_locality_spec): Fix
'static_assert'.
|
|
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_".
gcc/cobol
PR cobol/119694
* cbldiag.h: Eliminate getenv() calls.
* cdf.y: Likewise.
* cobol1.cc: Likewise.
* except.cc: Likewise.
* genapi.cc: Likewise.
* lexio.cc: Likewise.
* parse.y: Likewise.
* scan_ante.h: Likewise.
* show_parse.h: Likewise.
* symbols.cc: Likewise.
* symfind.cc: Likewise.
* util.cc: Likewise.
gcc/testsuite
PR cobol/119694
* cobol.dg/group2/ACCEPT_DATE___DAY_and_intrinsic_functions__2_.cob: GCOBOL_CURRENT_DATE.
* cobol.dg/group2/ACCEPT_FROM_TIME___DATE___DAY___DAY-OF-WEEK__2_.cob: Likewise
* cobol.dg/group2/FUNCTION_DATE___TIME_OMNIBUS.cob: Likewise
libgcobol
PR cobol/119694
* gfileio.cc: Eliminate getenv() calls.
* libgcobol.cc: Likewise.
|
|
|
|
gcc/ChangeLog
PR c++/106618
* doc/invoke.texi (Option Summary): Remove -fargs-in-order, add
-fstrong-eval-order.
(C++ Dialect Options): Explicitly document that -fstrong-eval-order
takes an optional argument and what the choices are. Generalize
references to C++17.
|
|
gcc/ChangeLog
PR middle-end/105548
* doc/invoke.texi (Optimize Options): Delete misleading sentence
about conversions.
|
|
Removing ' from all m2 comments so that make gcc.pot does not
generate any warnings. Also hide %n from comments.
gcc/m2/ChangeLog:
PR modula2/119735
* gm2-compiler/M2MetaError.def: Hide %n from comment.
* gm2-compiler/SymbolTable.def (PutIncludedByDefinition): Remove '
from comment.
* gm2-gcc/m2expr.def (init): Ditto.
* gm2-libiberty/pexecute.def: Ditto.
* gm2-libs-coroutines/Executive.def (InitSemaphore): Ditto.
(Wait): Ditto.
* gm2-libs-iso/ClientSocket.def: Ditto.
* gm2-libs-log/BlockOps.def (BlockMoveBackward): Ditto.
* gm2-libs-log/InOut.def: Ditto.
* mc/mcFileName.def: Ditto.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
|
|
All arm effective-targets using check_runtime use the "_hw" or
"_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1m_lob_hw
for consistency.
Since "lob" applies only to M-profile, replace v8_1 with v8_1m in
arm_v8_1_lob_ok, arm_thumb2_no_arm_v8_1_lob and
arm_thumb2_ok_no_arm_v8_1_lob.
gcc/testsuite/ChangeLog
* lib/target-supports.exp: Rename arm_v8_1_lob_ok into
arm_v8_1m_lob_hw.
Rename arm_thumb2_no_arm_v8_1_lob into
arm_thumb2_no_arm_v8_1m_lob.
Rename arm_thumb2_ok_no_arm_v8_1_lob into
arm_thumb2_ok_no_arm_v8_1m_lob.
* gcc.target/arm/lob1.c: Likewise.
* gcc.target/arm/lob6.c: Likewise.
* gcc.target/arm/ivopts.c: Likewise.
* gcc.target/arm/unsigned-extend-2.c: Likewise.
|
|
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>
|
|
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.
Pushing as obvious.
gcc/testsuite
* gcc.target/riscv/rvv/base/pr115068-run.c: Turn off pedantic diagnostics.
* gcc.target/riscv/rvv/base/pr115068.c: Likewise.
* gcc.target/riscv/rvv/base/vwaddsub-1.c: Likewise.
|
|
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.
gcc/testsuite/ChangeLog:
* g++.dg/opt/is_constant_evaluated4.C: New test.
|
|
D front-end changes:
- Import latest fixes from dmd v2.111.1-rc.1.
Phobos changes:
- Import latest fixes from phobos v2.111.1-rc.1.
- Restore compatibility with older Linux platforms where
`getrandom' is unavailable.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd 1b34fea478.
libphobos/ChangeLog:
* src/MERGE: Merge upstream phobos 40ffbb364.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Call DRUNTIME_OS_FEATURES.
* libdruntime/Makefile.am (AM_DFLAGS): Add OS_DFLAGS.
* libdruntime/Makefile.in: Regenerate.
* m4/druntime/os.m4 (DRUNTIME_OS_FEATURES): Define.
* src/Makefile.am: Add OS_DFLAGS.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
* testsuite/testsuite_flags.in: Add OS_DFLAGS.
|
|
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 4> [local count: 1073741824]:
if (_8 == 2)
goto <bb 6>; [20.00%]
else
goto <bb 5>; [80.00%]
<bb 5> [local count: 1073741824]:
_12 = VIEW_CONVERT_EXPR<unsigned long[3]>(y)[_8]; // Full limbs in y
goto <bb 7>; [100.00%]
<bb 6> [local count: 214748360]:
_13 = MEM <unsigned long> [(_BitInt(129) *)&y + 16B]; // y[2] which
_14 = (<unnamed-signed:1>) _13; // needs to be
_15 = (unsigned long) _14; // sign extended
_16 = (signed long) _15; // to full
_17 = _16 >> 63; // limb
_18 = (unsigned long) _17;
<bb 7> [local count: 1073741824]:
# _19 = PHI <_12(5), _10(3), _15(6)> // Limb to add for result of casts
# _20 = PHI <0(5), _10(3), _18(6)> // Sign extension limb from previous limb
_11 = _20; // PHI _10 argument above
_21 = VIEW_CONVERT_EXPR<unsigned long[4]>(x)[_8];
_24 = .UADDC (_19, _21, _22);
_25 = IMAGPART_EXPR <_24>;
_26 = REALPART_EXPR <_24>;
VIEW_CONVERT_EXPR<unsigned long[4]>(<retval>)[_8] = _26;
_27 = _8 + 1;
if (_27 == 3) // For the outer cast limb 3 is special
goto <bb 11>; [20.00%]
else
goto <bb 8>; [80.00%]
<bb 8> [local count: 1073741824]:
if (_27 < 2)
goto <bb 9>; [80.00%]
else
goto <bb 10>; [20.00%]
<bb 9> [local count: 1073741824]:
_28 = VIEW_CONVERT_EXPR<unsigned long[3]>(y)[_27]; // These are used in full
<bb 10> [local count: 1073741824]:
# _29 = PHI <_28(9), _11(8)>
goto <bb 12>; [100.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;
<bb 12> [local count: 1073741824]:
# _32 = PHI <_29(10), _31(11)>
_33 = VIEW_CONVERT_EXPR<unsigned long[4]>(x)[_27];
_34 = .UADDC (_32, _33, _25);
_23 = IMAGPART_EXPR <_34>;
_35 = REALPART_EXPR <_34>;
VIEW_CONVERT_EXPR<unsigned long[4]>(<retval>)[_27] = _35;
_9 = _8 + 2;
if (_9 != 4)
goto <bb 3>; [0.05%]
else
goto <bb 13>; [99.95%]
2025-04-11 Jakub Jelinek <jakub@redhat.com>
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.
* gcc.dg/torture/bitint-76.c: New test.
|
|
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.
|
|
gcc/ChangeLog
PR tree-optimization/87909
* common.opt.urls: Regenerate.
* doc/invoke.texi (Option Summary): Add -ftree-cselim.
(Optimize Options): Likewise.
|
|
Both gcc and msvc agree that the struct size should
be 12, gcc is already correct.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
PR target/113633
* gcc.dg/bf-ms-attrib.c: Fix expected __ms_struct__ layout
size.
|
|
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.
|
|
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.
|
|
|
