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.
Richard Biener [Wed, 9 Apr 2025 12:36:19 +0000 (14:36 +0200)]
rtl-optimization/119689 - compare-debug failure with LRA
The previous change to fix LRA rematerialization broke compare-debug
for i586 bootstrap. Fixed by using prev_nonnote_nondebug_insn
instead of prev_nonnote_insn.
PR rtl-optimization/119689
PR rtl-optimization/115568
* lra-remat.cc (create_cands): Use prev_nonnote_nondebug_insn
to check whether insn2 is directly before insn.
d: Use CONSTRUCTOR_ZERO_PADDING_BITS in the D FE [PR117832]
Adds a new wrapper function for `build_constructor', and calls it
instead to ensure that all CONSTRUCTOR nodes explicitly created by the
front-end have CONSTRUCTOR_ZERO_PADDING_BITS set.
Some places may not be necessary as it's guaranteed for there to be no
padding in the type, such as D dynamic arrays. Other places this gets
turned into a double-memset when optimizations are turned off, as the
front-end already generates a memset call to zero out all padding on
initializing a variable. The optimizer sees through this so will
correctly clear all bits once, so this can be improved later as-needed.
Jakub Jelinek [Wed, 9 Apr 2025 10:27:38 +0000 (12:27 +0200)]
libcpp: Fix error recovery after use of __VA_ARGS__ as macro argument [PR118674]
The following testcase ICEs after emitting one pedwarn (about using
__VA_ARGS__ in a place where it shouldn't be used) and one error.
The error is emitted by _cpp_save_parameter where it sees the node
has been used already earlier. But unlike the other _cpp_save_parameter
caller which does goto out; if it returns false, this call with explicit
__VA_ARGS__ doesn't and if it increments number of parameters etc. after
the error, we then try to unsave it twice.
The following patch fixes it by doing the goto out in that case too,
the macro will then not be considered as variable arguments macro,
but for error recovery I think that is fine.
The other option would be before the other _cpp_save_parameter caller
check if the node is pfile->spec_nodes.n__VA_ARGS__ and in that case
also error and goto out, but that seems more expensive than this for
the common case that the macro definition is correct.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/118674
* macro.cc (parse_params) <case CPP_ELLIPSIS>: If _cpp_save_parameter
failed for __VA_ARGS__, goto out.
Paul Thomas [Wed, 9 Apr 2025 08:50:04 +0000 (09:50 +0100)]
Fortran: Fix some problems with the reduce intrinsic [PR119460]
2025-04-09 Paul Thomas <pault@gcc.gnu.org>
and Harald Anlauf <anlauf@gcc.gnu.org>
gcc/fortran
PR fortran/119460
* iresolve.cc (generate_reduce_op_wrapper): Increase the size
of 'tname'. Change intent of 'a' and 'b' to intent_in.
* trans-decl.cc (add_argument_checking): Do not test artificial
formal symbols.
* trans-expr.cc (gfc_conv_procedure_call): Remove reduce_scalar
and the blocks triggered by it.
* trans-intrinsic.cc (gfc_conv_intrinsic_function): Set the
result of non-character, scalar reduce to be allocatable.
gcc/testsuite/
PR fortran/119460
* gfortran.dg/reduce_2.f90: Add test to check that deferred len
characters cannot slip through.
* gfortran.dg/reduce_3.f90: New test
* gfortran.dg/reduce_4.f90: New test
libgfortran/
PR libfortran/119460
* intrinsics/reduce.c (reduce): Correct error message about
mismatch between dim and the rank of array. Output the values
of both. Correct the evaluation of the result stride and
extent.
(reduce_scalar): The front end treats the result as an
allocatable so eliminate memcpy and free. Return the base-addr
of the local descriptor.
(reduce_c): Correct the type of the string lengths.
(reduce_scalar_c): Correct the type of the string lengths.Test
to see if 'res' is allocated. If not then return the base_addr
of the local descriptor.
Richard Biener [Tue, 8 Apr 2025 12:57:05 +0000 (14:57 +0200)]
bootstrap/119680 - fix cross-compiler build with --enable-host-shared
It seems that at least when cross-compiling at least collect2 pulls
in objects from libbacktrace.a which is linked via LIBDEPS. But
libbacktrace for the host is only built -fPIC with --enable-host-shared
but not -fPIE with --enable-host-pie so this fails. The following
teaches libbacktrace about --enable-host-pie and handles it similar
to libcpp.
PR bootstrap/119680
libbacktrace/
* configure.ac (--enable-host-pie): Handle by setting PIC_FLAG
to -fPIE.
* configure: Regenerate.
Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]
Implement LOCAL and LOCAL_INIT; we locally replace the tree declaration by
a local declaration of the outer variable. The 'local_init' then assigns
the value at the beginning of each loop iteration from the outer
declaration.
Note that the current implementation does not handle LOCAL with types that
have a default initializer and LOCAL/LOCAL_INIT for assumed-shape arrays;
this is diagnosed with a sorry error.
PR fortran/101602
gcc/fortran/ChangeLog:
* resolve.cc (resolve_locality_spec): Remove 'sorry, unimplemented'.
* trans-stmt.cc (struct symbol_and_tree_t): New.
(gfc_trans_concurrent_locality_spec): New.
(gfc_trans_forall_1): Call it; update to handle local and local_init.
* trans-decl.cc (gfc_start_saved_local_decls,
gfc_stop_saved_local_decls): New; moved code from ...
(gfc_process_block_locals): ... here. Call it.
* trans.h (gfc_start_saved_local_decls,
gfc_stop_saved_local_decls): Declare.
gcc/testsuite/ChangeLog:
* gfortran.dg/do_concurrent_8_f2023.f90: Update for removed 'sorry,
unimplemented'.
* gfortran.dg/do_concurrent_9.f90: Likewise.
* gfortran.dg/do_concurrent_all_clauses.f90: Likewise.
* gfortran.dg/do_concurrent_local_init.f90: Likewise.
* gfortran.dg/do_concurrent_locality_specs.f90: Likewise.
* gfortran.dg/do_concurrent_11.f90: New test.
* gfortran.dg/do_concurrent_12.f90: New test.
* gfortran.dg/do_concurrent_13.f90: New test.
* gfortran.dg/do_concurrent_14.f90: New test.
* gfortran.dg/do_concurrent_15.f90: New test.
Jason Merrill [Tue, 8 Apr 2025 19:53:34 +0000 (15:53 -0400)]
c++: lambda in concept [PR118698]
When normalizing is_foo for <T>, we get to normalizing
callable<decltype(...),T> for <T,foo>, which means substituting <T,foo> into
<decltype(...),T>.
Since r14-9938, because in_template_context is false we return the lambda
unchanged, just with LAMBDA_EXPR_EXTRA_ARGS set, so the closure type still
refers to the is_specialization_of tparms in its CLASSTYPE_TEMPLATE_INFO.
So then in normalize_atom caching find_template_parameters walks over the
parameter mapping; any_template_parm_r walks into the TREE_TYPE of a
LAMBDA_EXPR without considering EXTRA_ARGS and finds a template parm from
the wrong parameter list.
But since r15-3530 we expect to set tf_partial when substituting with
dependent arguments, so we should set that when normalizing. And then
tf_partial causes TREE_STATIC to be set on the EXTRA_ARGS, meaning that
those args will replace all the template parms in the rest of the lambda, so
we can walk just the EXTRA_ARGS and ignore the rest.
In previous years, I've tried to update the guality tests
so that they give clean results on aarch64-linux-gnu with
a recent version of GDB. This patch does the same thing for
GCC 15. The version of GDB I used was 16.2.
As before, there are no PRs for the XFAILs. The idea is that
anyone who is interested in working in this area can see the
current XFAILs by grepping the tests.
The issue is specifically about a missing word, but I spotted other
copy-editing issues like misplaced hyphens in nearby text. I also
thought that the -Wimplicit example was anachronistic because it's a
hard error in modern C dialects rather than a warning, and replaced it
with something users are more likely to run into.
gcc/ChangeLog
PR c++/90468
* doc/invoke.texi (Warning Options): Clean up text describing
-Wno-xxx.
Jakub Jelinek [Tue, 8 Apr 2025 13:57:45 +0000 (15:57 +0200)]
cobol: Further fixes for cobol cross-compilation from 32-bit arches [PR119364]
On top of
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680256.html
patch this brings make check-cobol when using the cross compiler from
32-bit host to x86_64-linux to the following:
Running /home/jakub/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/group1/declarative_1.cob -O0 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O1 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O2 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: cobol.dg/group1/declarative_1.cob -O3 -g execution test
FAIL: cobol.dg/group1/declarative_1.cob -Os execution test
=== cobol Summary ===
# of expected passes 3123
# of unexpected failures 6
# of expected failures 6
(which has some analysis but not a fix yet).
This patch fixes various cases where host size of various types
(void *, int, size_t, unsigned char) is used in place where
size of those types in bytes on the target should be used instead.
At least the size of void * and size_t actually differns between
ilp32 hosts and lp64 targets, int could be different in theory as well
but we actually don't support 16-bit ints on the host side and only support
lp64 targets right now for cobol, and finally sizeof(unsigned char) is
always 1, so there is no point to multiply by that and it is still
wrong to use host sizeof for the target decisions.
2025-04-08 Jakub Jelinek <jakub@redhat.com>
PR cobol/119364
* genapi.cc (function_handle_from_name): Use sizeof_pointer.
(parser_file_add): Use int_size_in_bytes(VOID_P) and
int_size_in_bytes(int).
(inspect_tally): Use int_size_in_bytes(VOID_P).
(inspect_replacing): Likewise.
(gg_array_of_field_pointers): Likewise.
(gg_array_of_file_pointers): Likewise.
(parser_set_pointers): Use sizeof_pointer.
* cobol1.cc (create_our_type_nodes_init): Use
int_size_in_bytes(SIZE_T) and int_size_in_bytes(VOID_P).
* gengen.cc (gg_array_of_size_t): Use int_size_in_bytes(SIZE_T).
(gg_array_of_bytes): Just use N, don't multiply it by
sizeof(unsigned char).
* parse.y: Include tree.h. Use int_size_in_bytes(ptr_type_node).
Jakub Jelinek [Tue, 8 Apr 2025 13:14:58 +0000 (15:14 +0200)]
simplify-rtx: Fix up POPCOUNT optimization [PR119672]
The gcc.dg/vect/pr113281-1.c test and many others ICE on riscv since
presumably the r15-9238 change which allowed more cases of vector modes
in simplify_const_relational_operation.
In the testcase it is EQ of
(popcount:SI (unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:RVVMF32BI 147 [ mask__6.8_35 ]))
(reg:SI 143 [ _41 ])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE))
and
(const_int 0 [0])
which it tries to fold as EQ comparison of
(unspec:RVVMF32BI [
(and:RVVMF32BI (const_vector:RVVMF32BI repeat [
(const_int 1 [0x1])
])
(reg:RVVMF32BI 147 [ mask__6.8_35 ]))
(reg:SI 143 [ _41 ])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
with
(const_int 0 [0])
which ICEs because const0_rtx isn't a vector.
Fixed by using CONST0_RTX, so that we pass
(const_vector:RVVMF32BI repeat [
(const_int 0 [0])
])
instead.
2025-04-08 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/119672
* simplify-rtx.cc (simplify_context::simplify_relational_operation_1):
For POPCOUNT == 0 or != 0 optimizations use
CONST0_RTX (GET_MODE (XEXP (op0, 0))) rather than const0_rtx.
Martin Uecker [Fri, 4 Apr 2025 19:01:48 +0000 (21:01 +0200)]
c: fix checking for a tag for variably modified tagged types [PR119612]
The checking assertion added for PR118765 did not take into account
that add_decl_expr can change TYPE_NAME to a TYPE_DECL with no name
for certain cases of variably modified types. This also implies that we
might sometimes not reliably detect the absence of a tag when only
considering TYPE_NAME. This patch introduces a new helper function
c_type_tag to reliable compute the tag for a tagged types and uses it
for code where the switch to C23 may cause regressions.
PR c/119612
gcc/c/ChangeLog:
* c-tree.h (c_type_tag): Add prototype.
* c-typeck.cc (c_type_tag): New function.
(tagged_types_tu_compatible_p, composite_type_internal): Use
c_type_tag.
* c-decl.cc (c_struct_hasher::hash, previous_tag): Use c_type_tag.
gcc/testsuite/ChangeLog:
* gcc.dg/gnu23-tag-6.c: New test.
* gcc.dg/pr119612.c: New test.
OpenMP: Fix append_args handling in modify_call_for_omp_dispatch
At tree level, the addr ref is also required for array dummy arguments,
contrary to C; the GOMP_interop calls in modify_call_for_omp_dispatch
were updated accordingly (using build_fold_addr_expr).
As the GOMP_interop calls had no location data associated with them,
the init call happened as soon as executing the previous line of code,
which was confusing; solution: use the location data of the function
call itself.
PR middle-end/119662
gcc/ChangeLog:
* gimplify.cc (modify_call_for_omp_dispatch): Fix GOMP_interop
arg passing; add location info to function calls.
libgomp/ChangeLog:
* testsuite/libgomp.c/append-args-fr-1.c: New test.
* testsuite/libgomp.c/append-args-fr.h: New test.
Jason Merrill [Mon, 7 Apr 2025 18:35:14 +0000 (14:35 -0400)]
c++: self-dependent alias template [PR117530]
Here, instantiating B<short> means instantiating A<short>, which means
instantiating B<short>. And then when we go to register the initial
instantiation, it conflicts with the inner one. Fixed by checking after
tsubst whether there's already something in the hash table. We already did
something much like this in tsubst_decl, but that doesn't handle this case.
While I was here, I noticed that we had a pop_deferring_access_checks on one
early exit but not another, and since I wanted to add yet another I switched
to using deferring_access_check_sentinel.
PR c++/117530
gcc/cp/ChangeLog:
* pt.cc (instantiate_template): Check retrieve_specialization after
tsubst.
Jakub Jelinek [Tue, 8 Apr 2025 10:39:16 +0000 (12:39 +0200)]
riscv: Fix a typo in config/riscv/freebsd.h [PR119678]
The r15-1124 commit had a typo in one of the FBSD_LINK_PG_NOTE
macro uses.
Fixed thusly, tested with
../configure --target riscv64-unknown-freebsd14 --disable-bootstrap --enable-languages=c --disable-libsanitizer --disable-libgomp
make -j32
Before it failed while compiling gcc.cc:
In file included from ./tm.h:44,
from ../../gcc/gcc.cc:35:
../../gcc/config/riscv/freebsd.h:45:5: error: expected ‘,’ or ‘;’ before ‘FBSD_LINK_PG_NOTES’
45 | " FBSD_LINK_PG_NOTES " \
| ^~~~~~~~~~~~~~~~~~
../../gcc/gcc.cc:1211:32: note: in expansion of macro ‘LINK_SPEC’
Now it fails later on during libgcc configury because I don't have
corresponding binutils.
2025-04-08 Jakub Jelinek <jakub@redhat.com>
PR target/119678
* config/riscv/freebsd.h (LINK_SPEC): Use FBSD_LINK_PG_NOTE rather
than non-existing FBSD_LINK_PG_NOTES.
ld: error: undefined symbol: _Unwind_RaiseException
>>> referenced by eh_throw.cc:93 ([...]/source-gcc/libstdc++-v3/libsupc++/eh_throw.cc:93)
>>> eh_throw.o:(__cxa_throw) in archive /srv/data/tschwinge/amd-instinct2/gcc/build/submit-light-target_gcn/build-gcc/amdgcn-amdhsa/gfx908/libstdc++-v3/src/.libs/libstdc++.a
[...]
collect2: error: ld returned 1 exit status
..., and/or:
ld: error: undefined symbol: _Unwind_Resume_or_Rethrow
>>> referenced by eh_throw.cc:129 ([...]/source-gcc/libstdc++-v3/libsupc++/eh_throw.cc:129)
>>> eh_throw.o:(__cxa_rethrow) in archive /srv/data/tschwinge/amd-instinct2/gcc/build/submit-light-target_gcn/build-gcc/amdgcn-amdhsa/gfx908/libstdc++-v3/src/.libs/libstdc++.a
[...]
collect2: error: ld returned 1 exit status
..., and nvptx:
unresolved symbol _Unwind_RaiseException
collect2: error: ld returned 1 exit status
..., or:
unresolved symbol _Unwind_Resume_or_Rethrow
collect2: error: ld returned 1 exit status
For both GCN, nvptx, this each progresses ~25 'check-gcc-c++',
and ~10 'check-target-libstdc++-v3' test cases:
[-FAIL:-]{+PASS:+} [...] (test for excess errors)
..., with (if applicable, for most of them):
[-UNRESOLVED:-]{+PASS:+} [...] [-compilation failed to produce executable-]{+execution test+}
..., or some 'FAIL: [...] execution test' where these test cases now FAIL when
attempting to use these interfaces, or, if applicable, FAIL due to run-time
'GCC/nvptx: sorry, unimplemented: dynamic stack allocation not supported'.
projects / thirdparty / gcc.git / log
