* backend/rust-compile-expr.cc (check_match_scrutinee): check for empty match
(CompileExpr::visit): fix assertion
* checks/errors/rust-hir-pattern-analysis.cc (check_match_usefulness): check for empty
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): resolve to !
gcc/testsuite/ChangeLog:
* rust/compile/exhaustiveness1.rs: remove bad check
* rust/compile/issue-2567-1.rs: New test.
* rust/compile/issue-2567-2.rs: New test.
* rust/compile/issue-2567-3.rs: New test.
* rust/compile/issue-3231.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
* backend/rust-compile-expr.cc (CompileExpr::visit): Change call.
(CompileExpr::resolve_operator_overload): Update function arguments.
* backend/rust-compile-expr.h: Change the function's prototype to use
a reference wrapper instead of a reference within the optional.
Condition was inverted, we should retrieve the locus only if we have a
pattern.
gcc/rust/ChangeLog:
* typecheck/rust-tyty-call.cc (TypeCheckCallExpr::visit): Do not
get a reference if the pattern does not exist.
(TypeCheckMethodCallExpr::check): Likewise.
* typecheck/rust-tyty.h: Reverse monomorphization during cloning and
make a new function to explicitly monomorphize.
* typecheck/rust-tyty.cc: Use monomorphization when required.
* hir/rust-ast-lower-type.cc (ASTLowerGenericParam::visit): Forward
an optional to the constructor.
* hir/tree/rust-hir-item.cc (TypeParam::TypeParam): Use an optional
in the constructor.
(TypeParam::operator=): Ensure the TypeParam has a type properly.
(TypeParam::get_type_mappings): Likewise.
* hir/tree/rust-hir-item.h: Wrap the type smart pointer into an
optional.
* hir/tree/rust-hir.cc (TypeParam::as_string): Unwrap optional type
correctly.
gccrs: Fixes some tests appearing with a moved variant
A variant being moved lead to a null being created and a segfault later
down the line.
gcc/rust/ChangeLog:
* backend/rust-compile-expr.cc (CompileExpr::visit): Call getter
instead of size function.
* checks/errors/privacy/rust-privacy-reporter.cc (PrivacyReporter::visit):
Only check privacy if the type is present.
* hir/rust-ast-lower-stmt.cc (ASTLoweringStmt::visit): Use an optional.
* hir/tree/rust-hir-generic-param.h: Assert type before getting it.
* hir/tree/rust-hir-item.h: Assert pointers before dereference, fix
has_type condition.
* hir/tree/rust-hir-path.h: Add more assertions.
* hir/tree/rust-hir-stmt.cc: Change constructor with optionals.
* hir/tree/rust-hir-stmt.h: Use optionals over smart pointers to
emphasize these fields might be missing.
* hir/tree/rust-hir.cc (LetStmt::as_string): Use getters.
* typecheck/rust-hir-type-check-expr.cc: Clone structures to prevent
parent's fields from being nulled by the move operation.
* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::visit): Use
optionals.
* typecheck/rust-tyty.cc: Likewise.
* typecheck/rust-tyty.h: Likewise.
gccrs: Refactor hir to avoid raw pointers and unneeded fwd
Refactor the hir tree files to remove raw pointer usage and most forward
declarations. Move implementation out of headers and split headers into
smaller and more manageable units.
gcc/rust/ChangeLog:
* Make-lang.in: Add new files.
* hir/tree/rust-hir-item.h: Move Item definition and remove
implementations to their corresponding cc file.
* hir/tree/rust-hir-expr.h: Move implementation to the corresponding
cc file.
* hir/tree/rust-hir-path.h: Likewise.
* hir/tree/rust-hir-pattern.h: Likewise.
* hir/tree/rust-hir-stmt.h: Likewise.
* hir/tree/rust-hir-type.h: Likewise.
* hir/tree/rust-hir-visitor.h: Likewise.
* hir/tree/rust-hir.h: Likewise.
* hir/tree/rust-hir.cc (Crate::Crate): Add implementations from Crate
and remove ConstGenericParam implementations to move them to their
own file.
* hir/tree/rust-hir-attrs.h: New file.
* hir/tree/rust-hir-bound-abstract.h: New file.
* hir/tree/rust-hir-bound.h: New file.
* hir/tree/rust-hir-expr-abstract.h: New file.
* hir/tree/rust-hir-expr.cc: New file.
* hir/tree/rust-hir-generic-param.cc: New file.
* hir/tree/rust-hir-generic-param.h: New file.
* hir/tree/rust-hir-item.cc: New file.
* hir/tree/rust-hir-literal.h: New file.
* hir/tree/rust-hir-node.h: New file.
* hir/tree/rust-hir-path.cc: New file.
* hir/tree/rust-hir-pattern-abstract.h: New file.
* hir/tree/rust-hir-simple-path.h: New file.
* hir/tree/rust-hir-stmt.cc: New file.
* hir/tree/rust-hir-trait-bound.h: New file.
* hir/tree/rust-hir-type-abstract.cc: New file.
* hir/tree/rust-hir-type-abstract.h: New file.
* hir/tree/rust-hir-type-no-bounds.h: New file.
* hir/tree/rust-hir-type.cc: New file.
* hir/tree/rust-hir-visibility.h: New file.
* hir/tree/rust-hir-visitable.h: New file.
* checks/lints/rust-lint-marklive.h: Use References.
* hir/rust-ast-lower-expr.cc (ASTLoweringExpr::visit): Reformat
vectors.
* hir/rust-hir-dump.cc (Dump::visit): Use reference.
* typecheck/rust-hir-type-check-struct.cc (TypeCheckStructExpr::resolve):
Use references.
* typecheck/rust-tyty-bounds.cc: Likewise.
gccrs: Refactor HIR with optionals, references & newtypes
The HIR made heavy use of pair and other unamed types which can be
difficult to read.
gcc/rust/ChangeLog:
* backend/rust-compile-base.cc: Use FnParam getter.
* backend/rust-compile-expr.cc (CompileExpr::visit): Likewise.
* backend/rust-compile-intrinsic.cc: Likewise.
* backend/rust-compile-type.cc: Likewise.
* checks/errors/privacy/rust-privacy-reporter.cc (PrivacyReporter::visit):
Only visit childrens if not missing.
* checks/errors/rust-unsafe-checker.cc (UnsafeChecker::visit): Use
a reference instead of a raw pointer.
* hir/tree/rust-hir-expr.h: Add presence function for return
expression.
* hir/tree/rust-hir-item.h: Remove take_param_name.
* hir/tree/rust-hir.h: Make mapping getter const.
* typecheck/rust-hir-dot-operator.cc (MethodResolver::Select): Use
getter.
* typecheck/rust-hir-type-check-expr.cc: Likewise.
* typecheck/rust-hir-type-check-implitem.cc: Use FnParam vector instead
of std::pair of Pattern and BaseType.
* typecheck/rust-hir-type-check-item.cc: Likewise.
* typecheck/rust-hir-type-check.cc: Likewise.
* typecheck/rust-tyty-call.cc (TypeCheckCallExpr::visit): Use getters.
(TypeCheckMethodCallExpr::check): Likewise.
* typecheck/rust-tyty-cmp.h: Likewise.
* typecheck/rust-tyty.cc: Use FnParam.
* typecheck/rust-tyty.h (class FnParam): Add FnParam to handle function
parameters instead of handling std::pairs.
* typecheck/rust-unify.cc (UnifyRules::expect_fndef): Use getters.
(UnifyRules::expect_fnptr): Likewise.
Owen Avery [Mon, 11 Nov 2024 21:19:44 +0000 (16:19 -0500)]
gccrs: Improve handling of static items in toplevel 2.0
gcc/rust/ChangeLog:
* resolve/rust-toplevel-name-resolver-2.0.cc
(TopLevel::visit): Use DefaultResolver::visit and avoid a call
to Identifier::as_string while handling instances of StaticItem.
Philip Herron [Tue, 12 Nov 2024 12:16:40 +0000 (12:16 +0000)]
gccrs: Fix bad handling for recursive type query
When resolving a type like this which is generic it causes the argument
substitution to go through bounds checking which is expected. But this
can call a type bounds probe which again calls a type query which will be
on the Impl Type on an impl block which can result in a recursive type
query which does eventually get caught and errors correctly. But this then
triggers some old error diagnositcs which are not valid error codes but old
error messages we used to catch simple errors very early on which do not
apply for this senario.
Fixes Rust-GCC#2905
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::resolve_impl_block_substitutions):
dont check for unconstrained when the self is not resolved
* typecheck/rust-hir-type-check-type.cc (TypeCheckType::resolve_root_path):
remove bad debug error diagnostic
* typecheck/rust-tyty-subst.cc: likewise
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: nr2 cant handle this
* rust/compile/issue-2905-1.rs: New test.
* rust/compile/issue-2905-2.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Wed, 6 Nov 2024 11:08:27 +0000 (11:08 +0000)]
gccrs: add test case to show issue is fixed
The original test case 1773 has been moved to a new issue 3242 which
is still open and test-case is skipped. The original issue in 1773 is
fixed so this will close out that issue
Fixes Rust-Gcc#1773
gcc/testsuite/ChangeLog:
* rust/compile/issue-1773.rs: new test case
* rust/compile/nr2/exclude: nr2 cant handle this
* rust/compile/issue-3242.rs: old test ranamed to match issue.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Owen Avery [Sun, 27 Oct 2024 00:52:31 +0000 (20:52 -0400)]
gccrs: Use name resolver 2.0 for module descendance checks
gcc/rust/ChangeLog:
* checks/errors/privacy/rust-privacy-reporter.cc:
Include rust-immutable-name-resolution-context.h.
(is_child_module): Use ForeverStack::is_module_descendant if name
resolution 2.0 is enabled.
* resolve/rust-forever-stack.h
(ForeverStack::is_module_descendant): Add.
(ForeverStack::dfs_node): Add.
* resolve/rust-forever-stack.hxx
(ForeverStack::dfs_rib): Use ForeverStack::dfs_node.
(ForeverStack::dfs_node): Add.
(ForeverStack::is_module_descendant): Add.
Owen Avery [Tue, 5 Nov 2024 02:52:14 +0000 (21:52 -0500)]
gccrs: Use name resolver 2.0 in VisibilityResolver
gcc/rust/ChangeLog:
* checks/errors/privacy/rust-visibility-resolver.cc:
Add includes.
(VisibilityResolver::resolve_module_path): Use name resolver 2.0
(when enabled) to lookup path resolutions.
Philip Herron [Mon, 4 Nov 2024 14:43:25 +0000 (14:43 +0000)]
gccrs: fix bad type inference on local patterns
We do not need to inject inference variables on generic patterns
with generic blocks. This will just cause unconstrained inference
variables as they may not unify against something.
Fixes Rust-GCC#2323
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::resolve_root_path): dont infer here
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: nr2 cant handle this
* rust/compile/issue-2323.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Fri, 1 Nov 2024 14:07:54 +0000 (14:07 +0000)]
gccrs: add test case to show method resolution is working
The issue here was that the impl block for Cell<T> defines that T must have
the bound of Copy implemented. But simultaneously if you do an deref
you get direct access to the unsafe cell which also defines a get method
so these are two valid ways of accessing the method in question but
when Copy is implementet the simplest case is prefered so it does resolve
to Cell<T>::get.
Fixes #3033
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: nr can't handle this
* rust/compile/issue-3033.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Owen Avery [Sat, 26 Oct 2024 23:53:42 +0000 (19:53 -0400)]
gccrs: Use name resolver 2.0 in CompileTraitItem
gcc/rust/ChangeLog:
* backend/rust-compile-implitem.cc
(CompileTraitItem::visit): Use name resolver 2.0 (when enabled)
to obtain canonical paths for instances of TraitItemConst and
TraitItemFunc.
Owen Avery [Sun, 27 Oct 2024 19:55:48 +0000 (15:55 -0400)]
gccrs: Use name resolution 2.0 in TraitItemReference
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check.cc: Add includes.
(TraitItemReference::get_type_from_fn): Use
ForeverStack::to_canonical_path when name resolution 2.0 is
enabled.
Philip Herron [Fri, 11 Oct 2024 16:53:50 +0000 (17:53 +0100)]
gccrs: Fix bad recursive operator overload call
When we are typechecking the impl block for DerefMut for &mut T
the implementation follows the usual operator overload check
but this ended up just resolving directly to the Trait definition
which ends up being recursive which we usually handle. The issue
we had is that a dereference call can be for either the DEREF
or DEREF_MUT lang item here it was looking for a recurisve call
to the DEREF lang item but we were in the DEREF_MUT lang item
so this case was not accounted for.
Fixes #3032
gcc/rust/ChangeLog:
* typecheck/rust-hir-trait-reference.h: new get locus helper
* typecheck/rust-hir-trait-resolve.cc (AssociatedImplTrait::get_locus): implemention
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::resolve_operator_overload):
fix overload
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: nr2 cant handle this
* rust/compile/issue-3032-1.rs: New test.
* rust/compile/issue-3032-2.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Jakub Jelinek [Fri, 21 Mar 2025 11:18:35 +0000 (12:18 +0100)]
icf: Punt for musttail call flag differences in ICF [PR119376]
The following testcase shows we were ignoring musttail flags on calls
when deciding if two functions are the same.
That can result in problems in both directions, either we silently
lose musttail attribute because there is a similar function without it
earlier and then we e.g. don't diagnose if it can't be tail called
or don't try harder to do a tail call, or we get it even in functions
which didn't have it before.
The following patch for now just punts if it differs. Perhaps we could
just merge it and get musttail flag if any of the merged functions had
one in such position, but it feels to me that it is now too late in GCC 15
cycle to play with this.
2025-03-21 Jakub Jelinek <jakub@redhat.com>
PR ipa/119376
* ipa-icf-gimple.cc (func_checker::compare_gimple_call): Return false
for gimple_call_must_tail_p mismatches.
Jakub Jelinek [Fri, 21 Mar 2025 11:17:45 +0000 (12:17 +0100)]
fnsplit: Set musttail call during function splitting if there are musttail calls [PR119376]
The just posted inliner patch can regress musttail calls if we perform
function splitting and then inline the outlined body back into the original
(or inline both the small function and outlined large body into something
else).
If there are any musttail calls, I think we need to call the outlined
body using a musttail call, so that the inliner will preserve musttail
attributes in the body.
2025-03-21 Jakub Jelinek <jakub@redhat.com>
PR ipa/119376
* ipa-split.cc (split_function): Call gimple_call_set_must_tail
on the call to outlined partition if has_musttail and
!add_tsan_func_exit.
Jakub Jelinek [Fri, 21 Mar 2025 11:17:01 +0000 (12:17 +0100)]
inliner: Silently drop musttail flag on calls during inlining unless the inlined routine was musttail called [PR119376]
As discussed in the PR, some packages fail to build because they use
musttail attribute on calls in functions which we inline, and if they
are inlined into a middle of the function, that results in an error
because we have a musttail call in the middle of a function and so it
can't be tail called there.
Now, guess the primary intent of the musttail attribute is ensuring
we don't get an extra stack frame in the backtrace. Inlining itself
removes one extra stack frame from the backtrace as well (sure, not
counting virtual backtraces in gdb), so I think erroring out on that
is unnecessary.
Except when we are inlining a musttail call which has musttail calls
in it, in that case we are being asked to remove 2 stack frames from
the backtrace, inlining removes one, so we need to keep musttail
on the calls so that another stack frame is removed through a tail call.
The following patch implements that, keeping previous behavior when
id->call_stmt is NULL (i.e. when versioning/cloning etc.).
2025-03-21 Jakub Jelinek <jakub@redhat.com>
PR ipa/119376
* tree-inline.cc (remap_gimple_stmt): Silently clear
gimple_call_must_tail_p on inlined call stmts if id->call_stmt
is a call without that flag set.
Jonathan Wakely [Wed, 19 Mar 2025 22:05:28 +0000 (22:05 +0000)]
libstdc++: Fix localized %c formatting for non-UTC times [PR117214]
The previous commit fixed most cases of %c formatting, but it
incorrectly prints times using the system's local time zone. This only
matters if the locale's %c format includes %Z, but some do.
To print a correct value for %Z we can set tm.tm_zone to either "UTC" or
the abbreviation passed to the formatter in the local-time-format-t
structure.
For local times with no info and for systems that don't support tm_zone
(which is new in POSIX.1-2024) we just set tm_isdst = -1 so that no zone
name is printed.
In theory, a locale's %c format could use %z which should print a +hhmm
offset from UTC. I'm unsure how to control that though. The new
tm_gmtoff field in combination with tm_isdst != -1 seems like it should
work, but using that without also setting tm_zone causes the system zone
to be used for %Z again. That means local_time_format(lt, nullptr, &off)
might work for a locale that uses %z but prints the wrong thing for %Z.
This commit doesn't set tm_gmtoff even if _M_offset_sec is provided for
a local-time-format-t value.
libstdc++-v3/ChangeLog:
PR libstdc++/117214
* configure.ac: Use AC_STRUCT_TIMEZONE.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Set
tm_isdst and tm_zone.
* testsuite/std/time/format/pr117214.cc: Check %c formatting of
zoned_time and local time.
XU Kailiang [Sat, 1 Mar 2025 05:23:21 +0000 (13:23 +0800)]
libstdc++: Fix localized D_T_FMT %c formatting for <chrono> [PR117214]
Formatting a time point with %c was implemented by calling
std::vprint_to with format string constructed from locale's D_T_FMT
string, but in some locales this string contains strftime specifiers
which are not valid for chrono-specs, e.g. %l. So just use _M_locale_fmt
to avoid this problem.
libstdc++-v3/ChangeLog:
PR libstdc++/117214
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Use
_M_locale_fmt to format %c time point.
* testsuite/std/time/format/pr117214.cc: New test.
Signed-off-by: XU Kailiang <xu2k3l4@outlook.com> Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
Jonathan Wakely [Wed, 19 Mar 2025 19:38:15 +0000 (19:38 +0000)]
libstdc++: Use formatting locale for std::time_put formats
When using std::time_put to format a chrono value, we should imbue the
formatting locale into the stream. This ensures that when
std::time_put::do_put uses a ctype or __timepunct facet from the locale,
it gets the correct facets.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_locale_fmt):
Imbue locale into ostringstream.
* testsuite/std/time/format/localized.cc: Check that correct
locale is used for call to time_put::put.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tomasz suggested replacing this constructor with just append_range(rg),
after using a delegating constructor so that the destructor will run if
append_range exits via an exception.
This is slightly less simple than his suggestion, because I want to
avoid the overhead of reserve's slow path and the ASan annotations.
Neither of those is needed for this constructor, because we have no
existing storage to reallocate and no unused capacity to tell ASan
about.
libstdc++-v3/ChangeLog:
* include/bits/stl_vector.h (vector(from_range_t, Alloc)): Use
delegating constructor instead of RAII guards. Use append_range
for unsized input range case.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Fri, 21 Mar 2025 09:48:10 +0000 (10:48 +0100)]
cobol: Rename COB_{BLOCK,UNSIGNED,SIGNED} to {BLOCK,UNSIGNED,SIGNED}_kw for consistency
On Wed, Mar 19, 2025 at 06:03:24PM -0400, James K. Lowden wrote:
> Elsewhere in the parser where there was a conflict like that, I renamed
> the token. For example, the COBOL word TRUE uses a token named
> TRUE_kw. I don't mind either way; your solution has less impact on the
> parser.
I think consistency is good and when it is a suffix rather than prefix,
it also sorts alphabetically together with the actual keywords.
2025-03-21 Jakub Jelinek <jakub@redhat.com>
* parse.y: Rename COB_BLOCK to BLOCK_kw, COB_SIGNED to SIGNED_kw and
COB_UNSIGNED to UNSIGNED_kw.
* scan.l: Likewise.
* token_names.h: Regenerate.
Richard Biener [Thu, 20 Mar 2025 09:48:38 +0000 (10:48 +0100)]
move global data to symbol_table_init
The following avoids early runtime initialization of cbl_field_t
objects which, when using tree to represent the current _Float128
data, segfaults as tree data like float128_type_node is not yet
initialized. The solution is to move the global data to
symbol_table_init which is the only user and it already has one
such instance locally, the 'constants' array.
* symbols.cc (empty_float, empty_comp5, empty_literal,
empty_conditional, debug_registers, special_registers): Move
global cbl_field_t typed data to ...
(symbol_table_init): ... local scope here.
Richard Biener [Wed, 19 Mar 2025 14:09:03 +0000 (15:09 +0100)]
make sources coretypes.h and tree.h clean
The following removes HOWEVER_GCC_DEFINES_TREE and the alternate
definition of tree from symbols.h and instead ensures that both
coretypes.h and tree.h are included where required. This required
putting GCCs own 'NONE' in a scoped enum (see separate patch) and
renaming the cobol use of UNSIGNED, SIGNED and BLOCK which conflict
with enums from tree.h.
There's a few things in conflict with options.h defines, notably
cobol_dialect and cobol_exceptions but also yy_flex_debug (wherever
that comes from). I've chosen to simply #undef those where
appropriate. I've refrained from putting the coretypes.h and
tree.h includes in cobol-system.h since not all files require this.
This helps in making use of real.h instead of using _Float128.
PR cobol/119241
gcc/cobol/
* symbols.h: Do not typedef tree.
* cdf.y: Include coretypes.h and tree.h.
* symbols.cc: Likewise.
* symfind.cc: Likewise.
* util.cc: Likewise.
* parse.y: Include coretypes.h and tree.h where appropriate.
Rename BLOCK to COB_BLOCK, SIGNED to COB_SIGNED, UNSIGNED
to COB_UNSIGNED.
* scan.l: Likewise.
* token_names.h: Likewise.
* cobol1.cc: Do not define HOWEVER_GCC_DEFINES_TREE.
* except.cc: Likewise.
* genapi.cc: Likewise.
* gengen.cc: Likewise.
* genmath.cc: Likewise.
* genutil.cc: Likewise.
* structs.cc: Likewise.
Fortran: Fix double free on polymorphic array dummy argument [PR119349]
Calling elemental routines with polymorphic formals leads to generation
of a temporary polymorphic variable and code for its deallocation.
Sourcing this element from an array constructor the latter now is
prevented from generating a second deallocation.
PR fortran/119349
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): Prevent deallocation
of array temporary for polymorphic temporary argument.
Andrew Pinski [Thu, 20 Feb 2025 00:10:31 +0000 (16:10 -0800)]
combine: Add REG_DEAD notes to the last instruction after a split [PR118914]
So gcc.target/aarch64/rev16_2.c started to fail after r15-268-g9dbff9c05520a7,
the problem is combine now rejects the instruction combine. This happens because
after a different combine which uses a define_split and that define_split creates
a new pseudo register. That new pseudo register is dead after the last instruction
in the stream BUT combine never creates a REG_DEAD for it. So combine thinks it is
still needed after and now with the i2 not changing, combine rejects the combine.
Now combine should be creating a REG_DEAD for the new pseudo registers for the last
instruction of the split. This fixes rev16_2.c and also improves the situtation in
other cases by removing other dead instructions.
Bootstrapped and tested on aarch64-linux-gnu and x86_64-linux-gnu.
gcc/ChangeLog:
PR rtl-optimization/118914
* combine.cc (recog_for_combine): Add old_nregs and new_nregs
argument (defaulting to 0). Update call to recog_for_combine_1.
(combine_split_insns): Add old_nregs and new_nregs arguments,
store the old and new max registers to them.
(try_combine): Update calls to combine_split_insns and
pass old_nregs and new_nregs for the i3 call to recog_for_combine.
(find_split_point): Update call to combine_split_insns; ignoring
the values there.
(recog_for_combine_1): Add old_nregs and new_nregs arguments,
if the insn was recognized (and not to no-op move), add the
REG_DEAD notes to pnotes argument.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Gaius Mulley [Thu, 20 Mar 2025 20:10:31 +0000 (20:10 +0000)]
PR modula2/118600 Assigning to a record causes alignment exception
This patch recursively tests every assignment (of a constructor
to a designator) to ensure the types are GCC equivalent. If they
are equivalent then it uses gimple assignment and if not then it
copies a structure by field and uses __builtin_strncpy to copy a
string cst into an array. Unions are copied by __builtin_memcpy.
gcc/m2/ChangeLog:
PR modula2/118600
* gm2-compiler/M2GenGCC.mod (PerformCodeBecomes): New procedure.
(CodeBecomes): Refactor and call PerformCodeBecomes.
* gm2-gcc/m2builtins.cc (gm2_strncpy_node): New global variable.
(DoBuiltinStrNCopy): New function.
(m2builtins_BuiltinStrNCopy): New function.
(m2builtins_init): Initialize gm2_strncpy_node.
* gm2-gcc/m2builtins.def (BuiltinStrNCopy): New procedure
function.
* gm2-gcc/m2builtins.h (m2builtins_BuiltinStrNCopy): New
function.
* gm2-gcc/m2statement.cc (copy_record_fields): New function.
(copy_array): Ditto.
(copy_strncpy): Ditto.
(copy_memcpy): Ditto.
(CopyByField_Lower): Ditto.
(m2statement_CopyByField): Ditto.
* gm2-gcc/m2statement.def (CopyByField): New procedure function.
* gm2-gcc/m2statement.h (m2statement_CopyByField): New function.
* gm2-gcc/m2type.cc (check_record_fields): Ditto.
(check_array_types): Ditto.
(m2type_IsGccStrictTypeEquivalent): Ditto.
* gm2-gcc/m2type.def (IsGccStrictTypeEquivalent): New procedure
function.
* gm2-gcc/m2type.h (m2type_IsAddress): Replace return type int
with bool.
The intention of -m31 -mesa and -m31 -mzarch was that they are (ABI)
compatible which is almost true except as it turns out they are not for
attribute mode(word).
After doing some archaeology and digging out an over 18 year old thread
[1,2] which is about this very attribute, I come to the conclusion to
revert this patch. The intention by deprecating and eventually removing
ESA/390 support was to prepare for a future removal of -m31; though in
smaller steps. Thus, instead of introducing some potential hick ups
along the route, I will revert this patch and will revisit this topic
when time for -m31 in its entirety has come---independent of
-mesa/-mzarch.
Filip Kastl [Thu, 20 Mar 2025 10:54:59 +0000 (11:54 +0100)]
gimple: sccopy: Don't increment i after vec::unordered_remove()
I increment the index variable in a loop even when I do
vec::unordered_remove() which causes the vector traversal to miss some
elements. Mikael notified me of this mistake I made in my last patch.
gcc/ChangeLog:
* gimple-ssa-sccopy.cc (scc_copy_prop::propagate): Don't
increment after vec::unordered_remove().
Reported-by: Mikael Morin <mikael@gcc.gnu.org> Signed-off-by: Filip Kastl <fkastl@suse.cz>
Jakub Jelinek [Thu, 20 Mar 2025 08:06:17 +0000 (09:06 +0100)]
openmp: Fix up cloning of dynamic C++ initializers for OpenMP target [PR119370]
The following testcase ICEs, because we emit the dynamic initialization twice,
once for host and once for target initialization, and although we use
copy_tree_body_r to unshare it, e.g. for the array initializers it can contain
TARGET_EXPRs with local temporaries (or local temporaries alone).
Now, these temporaries were created when current_function_decl was NULL,
they are outside of any particular function, so they have DECL_CONTEXT NULL.
That is normally fine, gimple_add_tmp_var will set DECL_CONTEXT for them
later on to the host __static_init* function into which they are gimplified.
The problem is that the copy_tree_body_r cloning happens before that (and has
to, gimplification is destructive and so we couldn't gimplify the same tree
again in __omp_static_init* function) and uses auto_var_in_fn_p to see what
needs to be remapped. But that means it doesn't remap temporaries with
NULL DECL_CONTEXT and having the same temporaries in two different functions
results in ICEs (sure, one can e.g. use parent function's temporaries in a
nested function).
The following patch just arranges to set DECL_CONTEXT on the temporaries
to the host dynamic initialization function, so that they get remapped.
If gimplification cared whether DECL_CONTEXT is NULL or not, we could
remember those that we've changed in a vector and undo it afterwards,
but seems it doesn't really care.
2025-03-20 Jakub Jelinek <jakub@redhat.com>
PR c++/119370
* decl2.cc (set_context_for_auto_vars_r): New function.
(emit_partial_init_fini_fn): Call walk_tree with that function
on &init before walk_tree with copy_tree_body_r.
liuhongt [Tue, 18 Mar 2025 05:47:11 +0000 (22:47 -0700)]
Use ix86_fp_comparison_operator in cbranchbf4 to avoid ICE.
*jcc only supports ix86_fp_comparison_operator for CCFP, when
comparison code is LT, there's an ICE. W/o AVX10.2, it's ok since
do_compare_rtx_and_jump will transform LT to GT, but w/ AVX10.2 it
goes directly into ix86_expand_branch which doesn't handle it.
Use ix86_fp_comparison_operator in cbranchbf4.
gcc/ChangeLog:
PR target/117452
* config/i386/i386.md (cbranchbf4): Use
ix86_fp_comparison_operator instead of comparison_operator.
Jason Merrill [Wed, 19 Mar 2025 09:15:00 +0000 (05:15 -0400)]
c++: mangling of array new [PR119316]
Because we build an array type to represent an array new, we hit a VLA
error in compute_array_index_type for a variable length array new. To avoid
this, let's build the MINUS_EXPR and index type directly.
I also noticed that the non-constant case in write_array_type was assuming
MINUS_EXPR without verifying it, so I added a checking_assert.
I also noticed that Clang doesn't mangle the length of an array new at all,
so I opened https://github.com/itanium-cxx-abi/cxx-abi/issues/199 to clarify
this.
PR c++/119316
gcc/cp/ChangeLog:
* mangle.cc (write_expression) [NEW_EXPR]: Avoid using
compute_array_index_type.
(write_array_type): Add checking_assert.
François Dumont [Wed, 19 Mar 2025 18:10:48 +0000 (19:10 +0100)]
libstdc++: Activate a __cpp_lib_ranges_to_container dependent test
Now that std::set has support for __cpp_lib_ranges_to_container we can
activate a test using it in a fancy allocator pointer context.
libstdc++-v3/ChangeLog
* testsuite/23_containers/set/requirements/explicit_instantiation/alloc_ptr.cc:
Activate the template member tests involving __cpp_lib_ranges_to_container
support.
Jonathan Wakely [Mon, 17 Mar 2025 15:02:12 +0000 (15:02 +0000)]
libstdc++: Make <stdbit.h> test use <climits> instead of <limits.h>
Our <climits> ensures that LLONG_MIN, LLONG_MAX, and ULLONG_MAX are
defined even if the C library's <limits.h> doesn't define them. Our
<limits.h> then includes <climits>, which should mean that <limits.h>
and <climits> always define the same macros. However, we only install
our own version of <limits.h> for --enable-cheaders=c and not for the
default --enable-cheaders=c_global setting that everybody uses.
This means that if the C library's <limits.h> is not C++-aware, or if
the C library doesn't provide it and GCC's own gcc/glimits.h is used
instead, then <climits> defines the macros for long long types but
<limits.h> does not.
This causes the new 20_util/stdbit/1.cc test to fail for arm-non-eabi
because it uses gcc/glimits.h which is not C++-aware, only checking
__STDC_VERSION__ when deciding whether to declare the long long macros.
If gcc/glimits.h also checked __cplusplus it would be OK, and we would
not need our own <limits.h> to be installed.
This commit just changes the new test to use <climits> instead of
<limits.h>, but we should ensure that gcc/glimits.h is made to work
(i.e. define the long long macros) for C++, and/or install our own
<limits.h> for the --enable-cheaders=c_global configuration.
libstdc++-v3/ChangeLog:
* testsuite/20_util/stdbit/1.cc: Include <climits> instead of
<limits.h>.
[PR119270][IRA]: Ignore equiv init insns for cost calculation for invariants only
My previous patch for PR114991 contains code ignoring equiv init insns
for increasing cost of usage the equivalence. Although common sense says
it is right thing to do, this results in more aggressive usage of
memory equivalence and significant performance degradation of SPEC2017
cactuBSSM. Given patch restores previous cost calculation for all
equivalences except for invariant ones.
gcc/ChangeLog:
PR target/119270
* ira-costs.cc (calculate_equiv_gains): Ignore equiv init insns
only for invariants.
David Malcolm [Wed, 19 Mar 2025 19:03:42 +0000 (15:03 -0400)]
diagnostics: fix crash in urlifier with -Wfatal-errors [PR119366]
diagnostic_context's dtor assumed that it owned the m_urlifier pointer
and would delete it.
As of r15-5988-g5a022062d22e0b this isn't always the case -
auto_urlify_attributes is used in various places in the C/C++ frontends
and in the middle-end to temporarily override the urlifier with an
on-stack instance, which would lead to delete-of-on-stack-buffer crashes
with -Wfatal-errors as the global_dc was cleaned up.
Fix by explicitly tracking the stack of urlifiers within
diagnostic_context, tracking for each node whether the pointer is
owned or borrowed.
gcc/ChangeLog:
PR c/119366
* diagnostic-format-sarif.cc (test_message_with_embedded_link):
Convert diagnostic_context from one urlifier to a stack of
urlifiers, where each node in the stack tracks whether the
urlifier is owned or borrowed.
* diagnostic.cc (diagnostic_context::initialize): Likewise.
(diagnostic_context::finish): Likewise.
(diagnostic_context::set_urlifier): Delete.
(diagnostic_context::push_owned_urlifier): New.
(diagnostic_context::push_borrowed_urlifier): New.
(diagnostic_context::pop_urlifier): New.
(diagnostic_context::get_urlifier): Reimplement in terms of stack.
(diagnostic_context::override_urlifier): Delete.
* diagnostic.h (diagnostic_context::set_urlifier): Delete decl.
(diagnostic_context::override_urlifier): Delete decl.
(diagnostic_context::push_owned_urlifier): New decl.
(diagnostic_context::push_borrowed_urlifier): New decl.
(diagnostic_context::pop_urlifier): New decl.
(diagnostic_context::get_urlifier): Make return value const; hide
implementation.
(diagnostic_context::m_urlifier): Replace with...
(diagnostic_context::urlifier_stack_node): ... this and...
(diagnostic_context::m_urlifier_stack): ...this.
* gcc-urlifier.cc
(auto_override_urlifier::auto_override_urlifier): Reimplement.
(auto_override_urlifier::~auto_override_urlifier): Reimplement.
* gcc-urlifier.h (class auto_override_urlifier): Reimplement.
(auto_urlify_attributes::auto_urlify_attributes): Update for
pass-by-reference.
* gcc.cc (driver::global_initializations): Update for
reimplementation of urlifiers in terms of a stack.
* toplev.cc (general_init): Likewise.
gcc/testsuite/ChangeLog:
PR c/119366
* gcc.dg/Wfatal-bad-attr-pr119366.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jakub Jelinek [Wed, 19 Mar 2025 18:21:38 +0000 (19:21 +0100)]
c: pedwarn on flexible array member initialization with {} for C23+ [PR119350]
Even in C23/C2Y any initialization of flexible array member is still
invalid, so we should emit a pedwarn on it. But we no longer do for
initialization with {}. The reason is that for C17 and earlier,
we already emitted a pedwarn on the {} initializer and so emitting
another pedwarn on the flexible array member initialization would
be diagnosing the same thing multiple times.
In C23 we no longer pedwarn on {}, it is standard.
The following patch arranges a pedwarning for that for C23+, so that
at least one pedwarning is emitted.
So that we don't "regress" from C17 to C23 on nested flexible array
member initialization with no -pedantic/-pedantic-errors/-Wpedantic,
the patch emits even the
initialization of flexible array member in a nested context
diagnostic as pedwarn in the {} case, after all, it doesn't cause
much trouble, we just ignore it like before, it wouldn't initialize
anything.
2025-03-19 Jakub Jelinek <jakub@redhat.com>
PR c/119350
* c-typeck.cc (pop_init_level): Don't ignore empty brackets for
flag_isoc23, still set constructor_type to NULL in that case but
emit a pedwarn_init in that case.
* gcc.dg/pr119350-1.c: New test.
* gcc.dg/pr119350-2.c: New test.
* gcc.dg/pr119350-3.c: New test.
Eric Botcazou [Wed, 19 Mar 2025 17:15:29 +0000 (18:15 +0100)]
Fix formatting of version message for gnat driver
Like the main driver (as well as gccgo, gccrs, gcov, etc) the gnat driver
prints the standard version message in response to the --version switch,
but it is not properly formatted.
projects / thirdparty / gcc.git / log
