]> git.ipfire.org Git - thirdparty/gcc.git/log
thirdparty/gcc.git
5 months agolibstdc++: Fix ranges::iter_move handling of rvalues [PR106612]
Jonathan Wakely [Fri, 28 Feb 2025 21:44:41 +0000 (21:44 +0000)] 
libstdc++: Fix ranges::iter_move handling of rvalues [PR106612]

The specification for std::ranges::iter_move apparently requires us to
handle types which do not satisfy std::indirectly_readable, for example
with overloaded operator* which behaves differently for different value
categories.

libstdc++-v3/ChangeLog:

PR libstdc++/106612
* include/bits/iterator_concepts.h (_IterMove::__iter_ref_t):
New alias template.
(_IterMove::__result): Use __iter_ref_t instead of
std::iter_reference_t.
(_IterMove::__type): Remove incorrect __dereferenceable
constraint.
(_IterMove::operator()): Likewise. Add correct constraints. Use
__iter_ref_t instead of std::iter_reference_t. Forward parameter
as correct value category.
(iter_swap): Add comments.
* testsuite/24_iterators/customization_points/iter_move.cc: Test
that iter_move is found by ADL and that rvalue arguments are
handled correctly.

Reviewed-by: Patrick Palka <ppalka@redhat.com>
5 months agolibstdc++: Fix ranges::move and ranges::move_backward to use iter_move [PR105609]
Jonathan Wakely [Thu, 27 Feb 2025 13:27:17 +0000 (13:27 +0000)] 
libstdc++: Fix ranges::move and ranges::move_backward to use iter_move [PR105609]

The ranges::move and ranges::move_backward algorithms are supposed to
use ranges::iter_move(iter) instead of std::move(*iter), which matters
for an iterator type with an iter_move overload findable by ADL.

Currently those algorithms use std::__assign_one which uses std::move,
so define a new ranges::__detail::__assign_one helper function that uses
ranges::iter_move.

libstdc++-v3/ChangeLog:

PR libstdc++/105609
* include/bits/ranges_algobase.h (__detail::__assign_one): New
helper function.
(__copy_or_move, __copy_or_move_backward): Use new function
instead of std::__assign_one.
* testsuite/25_algorithms/move/constrained.cc: Check that
ADL iter_move is used in preference to std::move.
* testsuite/25_algorithms/move_backward/constrained.cc:
Likewise.

5 months agolibstdc++: Add static_assertions to ranges::to adaptor factory [PR112803]
Jonathan Wakely [Thu, 27 Feb 2025 15:48:49 +0000 (15:48 +0000)] 
libstdc++: Add static_assertions to ranges::to adaptor factory [PR112803]

The standard requires that we reject attempts to create a ranges::to
adaptor for cv-qualified types and non-class types. Currently we only
diagnose it once the adaptor is used in a pipeline.

This adds static assertions to diagnose it immediately.

libstdc++-v3/ChangeLog:

PR libstdc++/112803
* include/std/ranges (ranges::to): Add static assertions to
enforce Mandates conditions.
* testsuite/std/ranges/conv/112803.cc: New test.

5 months agod: Fix comparing uninitialized memory in dstruct.d [PR116961]
Iain Buclaw [Fri, 28 Feb 2025 18:22:36 +0000 (19:22 +0100)] 
d: Fix comparing uninitialized memory in dstruct.d [PR116961]

Floating-point emulation in the D front-end is done via a type named
`struct longdouble`, which in GDC is a small interface around the
real_value type. Because the D code cannot include gcc/real.h directly,
a big enough buffer is used for the data instead.

On x86_64, this buffer is actually bigger than real_value itself, so
when a new longdouble object is created with

    longdouble r;
    real_from_string3 (&r.rv (), buffer, mode);
    return r;

there is uninitialized padding at the end of `r`.  This was never a
problem when D was implemented in C++ (until GCC 12) as comparing two
longdouble objects with `==' would be forwarded to the relevant
operator== overload that extracted the underlying real_value.

However when the front-end was translated to D, such conditions were
instead rewritten into identity comparisons

    return exp.toReal() is CTFloat.zero

The `is` operator gets lowered as a call to `memcmp() == 0', which is
where the read of uninitialized memory occurs, as seen by valgrind.

==26778== Conditional jump or move depends on uninitialised value(s)
==26778==    at 0x911F41: dmd.dstruct._isZeroInit(dmd.expression.Expression) (dstruct.d:635)
==26778==    by 0x9123BE: StructDeclaration::finalizeSize() (dstruct.d:373)
==26778==    by 0x86747C: dmd.aggregate.AggregateDeclaration.determineSize(ref const(dmd.location.Loc)) (aggregate.d:226)
[...]

To avoid accidentally reading uninitialized data, explicitly initialize
all `longdouble` variables with an empty constructor on C++ side of the
implementation before initializing underlying real_value type it holds.

PR d/116961

gcc/d/ChangeLog:

* d-codegen.cc (build_float_cst): Change new_value type from real_t to
real_value.
* d-ctfloat.cc (CTFloat::fabs): Default initialize the return value.
(CTFloat::ldexp): Likewise.
(CTFloat::parse): Likewise.
* d-longdouble.cc (longdouble::add): Likewise.
(longdouble::sub): Likewise.
(longdouble::mul): Likewise.
(longdouble::div): Likewise.
(longdouble::mod): Likewise.
(longdouble::neg): Likewise.
* d-port.cc (Port::isFloat32LiteralOutOfRange): Likewise.
(Port::isFloat64LiteralOutOfRange): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/pr116961.d: New test.

5 months agoc++: fix rejects-valid and ICE with constexpr NSDMI [PR110822]
Marek Polacek [Tue, 18 Feb 2025 17:18:31 +0000 (12:18 -0500)] 
c++: fix rejects-valid and ICE with constexpr NSDMI [PR110822]

Since r10-7718 the attached tests produce an ICE in verify_address:

  error: constant not recomputed when 'ADDR_EXPR' changed

but before that we wrongly rejected the tests with "is not a constant
expression".  This patch fixes both problems.

Since r10-7718 replace_decl_r can replace

  {._M_dataplus=&<retval>._M_local_buf, ._M_local_buf=0}

with

  {._M_dataplus=&HelloWorld._M_local_buf, ._M_local_buf=0}

The initial &<retval>._M_local_buf was not constant, but since
HelloWorld is a static VAR_DECL, the resulting &HelloWorld._M_local_buf
should have been marked as TREE_CONSTANT.  And since we're taking
its address, the whole thing should be TREE_ADDRESSABLE.

PR c++/114913
PR c++/110822

gcc/cp/ChangeLog:

* constexpr.cc (replace_decl_r): If we've replaced something
inside of an ADDR_EXPR, call cxx_mark_addressable and
recompute_tree_invariant_for_addr_expr on the resulting ADDR_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-nsdmi4.C: New test.
* g++.dg/cpp0x/constexpr-nsdmi5.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>
5 months agoc++: ICE in replace_decl [PR118986]
Marek Polacek [Wed, 26 Feb 2025 16:14:00 +0000 (11:14 -0500)] 
c++: ICE in replace_decl [PR118986]

Yet another problem that started with r15-6052, compile time evaluation of
prvalues.

cp_fold_r/TARGET_EXPR sees:

  TARGET_EXPR <D.2701, <<< Unknown tree: expr_stmt
    D.2701.__p = TARGET_EXPR <D.2684, <<< Unknown tree: aggr_init_expr
      3
      f1
      D.2684 >>>> >>>>

so when we call maybe_constant_init, the object we're initializing is D.2701,
and the init is the expr_stmt.  We unwrap the EXPR_STMT/INIT_EXPR/TARGET_EXPR
in maybe_constant_init_1 and so end up evaluating the f1 call.  But f1 returns
c2 whereas the type of D.2701 is ._anon_0 -- the closure.

So then we crash in replace_decl on:

  gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p
       (TREE_TYPE (decl), TREE_TYPE (replacement)));

due to the mismatched types.

cxx_eval_outermost_constant_expr is already ready for the types to be
different, in which case the result isn't constant.  But replace_decl
is called before that check.

I'm leaving the assert in replace_decl on purpose, maybe we'll find
another use for it.

PR c++/118986

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_call_expression): Check that the types match
before calling replace_decl, if not, set *non_constant_p.
(maybe_constant_init_1): Don't strip INIT_EXPR if it would change the
type of the expression.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/constexpr-prvalue1.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>
5 months agoipa-sra: Avoid clashes with ipa-cp when pulling accesses across calls (PR 118243)
Martin Jambor [Fri, 28 Feb 2025 16:34:10 +0000 (17:34 +0100)] 
ipa-sra: Avoid clashes with ipa-cp when pulling accesses across calls (PR 118243)

Among other things, IPA-SRA checks whether splitting out a bit of an
aggregate or something passed by reference would lead into a clash
with an already known IPA-CP constant a way which would cause problems
later on.  Unfortunately the test is done only in
adjust_parameter_descriptions and is missing when accesses are
propagated from callees to callers, which leads to miscompilation
reported as PR 118243 (where the callee is a function created by
ipa-split).

The matter is then further complicated by the fact that we consider
complex numbers as scalars even though they can be modified piecemeal
(IPA-CP can detect and propagate the pieces separately too) which then
confuses the parameter manipulation machinery furter.

This patch simply adds the missing check to avoid the IPA-SRA
transform in these cases too, which should be suitable for backporting
to all affected release branches.  It is a bit of a shame as in the PR
testcase we do propagate both components of the complex number in
question and the transformation phase could recover.  I have some
prototype patches in this direction but that is something for (a)
stage 1.

gcc/ChangeLog:

2025-02-10  Martin Jambor  <mjambor@suse.cz>

PR ipa/118243
* ipa-sra.cc (pull_accesses_from_callee): New parameters
caller_ipcp_ts and param_idx.  Check that scalar pulled accesses would
not clash with a known IPA-CP aggregate constant.
(param_splitting_across_edge): Pass IPA-CP transformation summary and
caller parameter index to pull_accesses_from_callee.

gcc/testsuite/ChangeLog:

2025-02-10  Martin Jambor  <mjambor@suse.cz>

PR ipa/118243
* g++.dg/ipa/pr118243.C: New test.

5 months agoc++: generic lambda, implicit 'this' capture, xobj memfn [PR119038]
Patrick Palka [Fri, 28 Feb 2025 15:56:49 +0000 (10:56 -0500)] 
c++: generic lambda, implicit 'this' capture, xobj memfn [PR119038]

When a generic lambda calls an overload set containing an iobj member
function we speculatively capture 'this'.  We need to do the same
for an xobj member function.

PR c++/119038

gcc/cp/ChangeLog:

* lambda.cc (maybe_generic_this_capture): Consider xobj
member functions as well, not just iobj.  Update function
comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/explicit-obj-lambda15.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>
5 months agolibstdc++: Improve optional's <=> constraint recursion workaround [PR104606]
Patrick Palka [Fri, 28 Feb 2025 15:15:45 +0000 (10:15 -0500)] 
libstdc++: Improve optional's <=> constraint recursion workaround [PR104606]

It turns out the reason the behavior of this testcase changed after CWG
2369 is because validity of the substituted return type is now checked
later, after constraints.  So a more reliable workaround for this issue
is to add a constraint to check the validity of the return type earlier,
matching the pre-CWG 2369 semantics.

PR libstdc++/104606

libstdc++-v3/ChangeLog:

* include/std/optional (operator<=>): Revert r14-9771 change.
Add constraint checking the validity of the return type
compare_three_way_result_t before the three_way_comparable_with
constraint.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
5 months agolibstdc++: Fix constraint recursion in basic_const_iterator relops [PR112490]
Patrick Palka [Fri, 28 Feb 2025 14:39:57 +0000 (09:39 -0500)] 
libstdc++: Fix constraint recursion in basic_const_iterator relops [PR112490]

Here for

  using RCI = reverse_iterator<basic_const_iterator<vector<int>::iterator>>
  static_assert(std::totally_ordered<RCI>);

we effectively need to check the requirement

  requires (RCI x) { x RELOP x; }  for each RELOP in {<, >, <=, >=}

which we expect to be straightforwardly satisfied by reverse_iterator's
namespace-scope relops.  But due to ADL we find ourselves also
considering the basic_const_iterator relop friends, which before CWG
2369 would be quickly discarded since RCI clearly isn't convertible to
basic_const_iterator.  After CWG 2369 though we must first check these
relops' constraints (with _It = vector<int>::iterator and _It2 = RCI),
which entails checking totally_ordered<RCI> recursively.

This patch fixes this by turning the problematic non-dependent function
parameters of type basic_const_iterator<_It> into dependent ones of
type basic_const_iterator<_It3> where _It3 is constrained to match _It.
Thus the basic_const_iterator relop friends now get quickly discarded
during deduction and before the constraint check if the second operand
isn't a specialization of basic_const_iterator (or derived from one)
like before CWG 2369.

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<_It3> where _It3
matches _It.
(basic_const_iterator::operator>): Likewise.
(basic_const_iterator::operator<=): Likewise.
(basic_const_iterator::operator>=): Likewise.
* testsuite/24_iterators/const_iterator/112490.cc: New test.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
5 months agoc++: Fix cxx_eval_store_expression {REAL,IMAG}PART_EXPR handling [PR119045]
Jakub Jelinek [Fri, 28 Feb 2025 14:22:47 +0000 (15:22 +0100)] 
c++: Fix cxx_eval_store_expression {REAL,IMAG}PART_EXPR handling [PR119045]

I've added the asserts that probe == target because {REAL,IMAG}PART_EXPR
always implies a scalar type and so applying ARRAY_REF/COMPONENT_REF
etc. on it further doesn't make sense and the later code relies on it
to be the last one in refs array.  But as the following testcase shows,
we can fail those assertions in case there is a reference or pointer
to the __real__ or __imag__ part, in that case we just evaluate the
constant expression and so probe won't be the same as target.
That case doesn't push anything into the refs array though.

The following patch changes those asserts to verify that refs is still
empty, which fixes it.

2025-02-28  Jakub Jelinek  <jakub@redhat.com>

PR c++/119045
* constexpr.cc (cxx_eval_store_expression) <case REALPART_EXPR>:
Assert that refs->is_empty () rather than probe == target.
(cxx_eval_store_expression) <case IMAGPART_EXPR>: Likewise.

* g++.dg/cpp1y/constexpr-complex2.C: New test.

5 months agoc++: Adjust #embed support for P1967R14
Jakub Jelinek [Fri, 28 Feb 2025 14:17:37 +0000 (15:17 +0100)] 
c++: Adjust #embed support for P1967R14

Now that the #embed paper has been voted in, the following patch
removes the pedwarn for C++26 on it (and adjusts pedwarn warning for
older C++ versions) and predefines __cpp_pp_embed FTM.

Also, the patch changes cpp_error to cpp_pedwarning with for C++
-Wc++26-extensions guarding, and for C add -Wc11-c23-compat warning
about #embed.

I believe we otherwise implement everything in the paper already,
except I'm really confused by the
 [Example:

 #embed <data.dat> limit(__has_include("a.h"))

 #if __has_embed(<data.dat> limit(__has_include("a.h")))
 // ill-formed: __has_include [cpp.cond] cannot appear here
 #endif

 — end example]
part.  My reading of both C23 and C++ with the P1967R14 paper in
is that the first case (#embed with __has_include or __has_embed in its
clauses) is what is clearly invalid and so the ill-formed note should be
for #embed.  And the __has_include/__has_embed in __has_embed is actually
questionable.
Both C and C++ have something like
"The identifiers __has_include, __has_embed, and __has_c_attribute
shall not appear in any context not mentioned in this subclause."
or
"The identifiers __has_include and __has_cpp_attribute shall not appear
in any context not mentioned in this subclause."
(into which P1967R14 adds __has_embed) in the conditional inclusion
subclause.  #embed is defined in a different one, so using those in there
is invalid (unless "using the rules specified for conditional inclusion"
wording e.g. in limit clause overrides that).
The reason why I think it is fuzzy for __has_embed is that __has_embed
is actually defined in the Conditional inclusion subclause (so that
would mean one can use __has_include, __has_embed and __has_*attribute
in there) but its clauses are described in a different one.

GCC currently accepts
 #embed __FILE__ limit (__has_include (<stdarg.h>))
 #if __has_embed (__FILE__ limit (__has_include (<stdarg.h>)))
 #endif
 #embed __FILE__ limit (__has_embed (__FILE__))
 #if __has_embed (__FILE__ limit (__has_embed (__FILE__)))
 #endif
Note, it isn't just about limit clause, but also about
prefix/suffix/if_empty, except that in those cases the "using the rules
specified for conditional inclusion" doesn't apply.

In any case, I'd hope that can be dealt with incrementally (and should
be handled the same for both C and C++).

2025-02-28  Jakub Jelinek  <jakub@redhat.com>

libcpp/
* include/cpplib.h (enum cpp_warning_reason): Add
CPP_W_CXX26_EXTENSIONS enumerator.
* init.cc (lang_defaults): Set embed for GNUCXX26 and CXX26.
* directives.cc (do_embed): Adjust pedwarn wording for embed in C++,
use cpp_pedwarning instead of cpp_error and add CPP_W_C11_C23_COMPAT
warning of cpp_pedwarning hasn't diagnosed anything.
gcc/c-family/
* c.opt (Wc++26-extensions): Add CppReason(CPP_W_CXX26_EXTENSIONS).
* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_pp_embed=202502
for C++26.
gcc/testsuite/
* g++.dg/cpp/embed-1.C: Adjust for pedwarn wording change and don't
expect any error for C++26.
* g++.dg/cpp/embed-2.C: Adjust for pedwarn wording change and don't
expect any warning for C++26.
* g++.dg/cpp26/feat-cxx26.C: Test __cpp_pp_embed value.
* gcc.dg/cpp/embed-17.c: New test.

5 months agolto/91299 - weak definition inlined with LTO
Richard Biener [Fri, 28 Feb 2025 13:09:29 +0000 (14:09 +0100)] 
lto/91299 - weak definition inlined with LTO

The following fixes a thinko in the handling of interposed weak
definitions which confused the interposition check in
get_availability by setting DECL_EXTERNAL too early.

PR lto/91299
gcc/lto/
* lto-symtab.cc (lto_symtab_merge_symbols): Set DECL_EXTERNAL
only after calling get_availability.

gcc/testsuite/
* gcc.dg/lto/pr91299_0.c: New testcase.
* gcc.dg/lto/pr91299_1.c: Likewise.

5 months agoipa/111245 - bogus modref analysis for store in call that might throw
Richard Biener [Fri, 28 Feb 2025 10:44:26 +0000 (11:44 +0100)] 
ipa/111245 - bogus modref analysis for store in call that might throw

We currently record a kill for

  *x_4(D) = always_throws ();

because we consider the store always executing since the appropriate
check for whether the stmt could throw is guarded by
!cfun->can_throw_non_call_exceptions.

PR ipa/111245
* ipa-modref.cc (modref_access_analysis::analyze_store): Do
not guard the check of whether the stmt could throw by
cfun->can_throw_non_call_exceptions.

* g++.dg/torture/pr111245.C: New testcase.

5 months agoifcvt: Fix ICE with (fix:SI (fix:DF (reg:DF))) [PR117712]
Jakub Jelinek [Fri, 28 Feb 2025 11:42:27 +0000 (12:42 +0100)] 
ifcvt: Fix ICE with (fix:SI (fix:DF (reg:DF))) [PR117712]

As documented in the manual, FIX/UNSIGNED_FIX from floating point
mode to integral mode has unspecified rounding and FIX from floating point
mode to the same floating point mode is expressing rounding toward zero.
So, some targets (arc, arm, csky, m68k, mmix, nds32, pdp11, sparc and
visium) use
(fix:SI (fix:SF (match_operand:SF 1 "..._operand")))
etc. to express the rounding toward zero during conversion to integer.
For some reason other targets don't use that.

Anyway, the 2 FIXes (or inner FIX with outer UNSIGNED_FIX) cause problems
since the r15-2890 which removed some strict checks in ifcvt.cc on what
SET_SRC can be actually conditionalized (I must say I'm still worried
about the change, don't know why one can't get e.g. inline asm or
something with UNSPEC or some complex backend specific RTLs that
force_operand can't handle), force_operand just ICEs on it, it can only
handle (through expand_fix) conversions from floating point to integral.

The following patch fixes this by detecting this case and just pretend
the inner FIX isn't there, i.e. call expand_fix with the inner FIX's
operand instead, which works and on targets like arm it will just
create the nested FIXes again.

2025-02-28  Jakub Jelinek  <jakub@redhat.com>

PR rtl-optimization/117712
* expr.cc (force_operand): Handle {,UNSIGNED_}FIX with
FIX operand using expand_fix on the inner FIX operand.

* gcc.dg/pr117712.c: New test.

5 months agotree-optimization/87984 - hard register assignments not preserved
Richard Biener [Fri, 28 Feb 2025 09:36:11 +0000 (10:36 +0100)] 
tree-optimization/87984 - hard register assignments not preserved

The following disables redundant store elimination to hard register
variables which isn't valid.

PR tree-optimization/87984
* tree-ssa-dom.cc (dom_opt_dom_walker::optimize_stmt): Do
not perform redundant store elimination to hard register
variables.
* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt):
Likewise.

* gcc.target/i386/pr87984.c: New testcase.

5 months agomiddle-end/66279 - gimplification clobbers shared asm constraints
Richard Biener [Fri, 28 Feb 2025 08:58:36 +0000 (09:58 +0100)] 
middle-end/66279 - gimplification clobbers shared asm constraints

When the C++ frontend clones a CTOR we do not copy ASM_EXPR constraints
fully as walk_tree does not recurse to TREE_PURPOSE of TREE_LIST nodes.
At this point doing that seems too dangerous so the following instead
avoids gimplification of ASM_EXPRs to clobber the shared constraints
and unshares it there, like it also unshares TREE_VALUE when it
re-writes a "+" output constraint to separate "=" output and matching
input constraint.

PR middle-end/66279
* gimplify.cc (gimplify_asm_expr): Copy TREE_PURPOSE before
rewriting it for "+" processing.

* g++.dg/pr66279.C: New testcase.

5 months agotestsuite: Remove -m32 from another i386/ test
Jakub Jelinek [Fri, 28 Feb 2025 09:13:57 +0000 (10:13 +0100)] 
testsuite: Remove -m32 from another i386/ test

I found another test which uses -m32 in gcc.target/i386/ .  Similarly
to the previously posted test, the test ought to be tested during i686-linux
testing or x86_64-linux test with --target_board=unix\{-m32,-m64\}
There is nothing ia32 specific on the test, so I've just dropped the -m32.

2025-02-28  Jakub Jelinek  <jakub@redhat.com>

* gcc.target/i386/strub-pr118006.c: Remove -m32 from dg-options.

5 months agotestsuite: Fix up gcc.target/i386/pr118940.c test [PR118940]
Jakub Jelinek [Fri, 28 Feb 2025 09:12:14 +0000 (10:12 +0100)] 
testsuite: Fix up gcc.target/i386/pr118940.c test [PR118940]

The testcase uses -m32 in dg-options, something we try hard not to do,
if something should be tested only for -m32, it is { target ia32 } test,
if it can be tested for -m64/-mx32 too, just some extra options are
needed for ia32, it should have dg-additional-options with ia32 target.

Also, the test wasn't reduced, so I've reduced it using cvise and manual
tweaks and verified the test still FAILs before r15-7700 and succeeds
with current trunk.

2025-02-28  Jakub Jelinek  <jakub@redhat.com>

PR target/118940
* gcc.target/i386/pr118940.c: Drop -w, -g and -m32 from dg-options, move
-march=i386 -mregparm=3 to dg-additional-options for ia32 and -fno-pie
to dg-additional-options for pie.  Reduce the test.

5 months agoFortran: Ensure finalizer is called for unreferenced variable [PR118730]
Andre Vehreschild [Thu, 27 Feb 2025 11:27:10 +0000 (12:27 +0100)] 
Fortran: Ensure finalizer is called for unreferenced variable [PR118730]

PR fortran/118730

gcc/fortran/ChangeLog:

* resolve.cc: Mark unused derived type variable with finalizers
referenced to execute finalizer when leaving scope.

gcc/testsuite/ChangeLog:

* gfortran.dg/class_array_15.f03: Remove unused variable.
* gfortran.dg/coarray_poly_7.f90: Adapt scan-tree-dump expr.
* gfortran.dg/coarray_poly_8.f90: Same.
* gfortran.dg/finalize_60.f90: New test.

5 months agoMAINTAINERS: add myself to write after approval and DCO
Giuseppe D'Angelo [Fri, 28 Feb 2025 07:37:25 +0000 (08:37 +0100)] 
MAINTAINERS: add myself to write after approval and DCO

ChangeLog:

* MAINTAINERS: Added myself as write after approval and DCO.

5 months agox86: Move TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P to i386.cc
H.J. Lu [Tue, 25 Feb 2025 21:57:13 +0000 (05:57 +0800)] 
x86: Move TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P to i386.cc

Move the TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P target hook from
i386.h to i386.cc.

* config/i386/i386.h (TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P):
Moved to ...
* config/i386/i386.cc (TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P):
Here.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
5 months agoDaily bump.
GCC Administrator [Fri, 28 Feb 2025 00:16:37 +0000 (00:16 +0000)] 
Daily bump.

5 months agoRISC-V: Fix bug for expand_const_vector interleave [PR118931]
Pan Li [Sat, 22 Feb 2025 11:34:52 +0000 (19:34 +0800)] 
RISC-V: Fix bug for expand_const_vector interleave [PR118931]

This patch would like to fix one bug when expanding const vector for the
interleave case.  For example, we have:

base1 = 151
step = 121

For vec_series, we will generate vector in format of v[i] = base + i * step.
Then the vec_series will have below result for HImode, and we can find
that the result overflow to the highest 8 bits of HImode.

v1.b = {151, 255, 7,  0, 119,  0, 231,  0, 87,  1, 199,  1, 55,   2, 167,   2}

Aka we expect v1.b should be:

v1.b = {151, 0, 7,  0, 119,  0, 231,  0, 87,  0, 199,  0, 55,   0, 167,   0}

After that it will perform the IOR with v2 for the base2(aka another series).

v2.b =  {0,  17, 0, 33,   0, 49,   0, 65,  0, 81,   0, 97,  0, 113,   0, 129}

Unfortunately, the base1 + i * step1 in HImode may overflow to the high
8 bits, and the high 8 bits will pollute the v2 and result in incorrect
value in const_vector.

This patch would like to perform the overflow to smode check before the
optimized interleave code generation.  If overflow or VLA, it will fall
back to the default merge approach.

The below test suites are passed for this patch.
* The rv64gcv fully regression test.

PR target/118931

gcc/ChangeLog:

* config/riscv/riscv-v.cc (expand_const_vector): Add overflow to
smode check and clean up highest bits if overflow.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr118931-run-1.c: New test.

Signed-off-by: Pan Li <pan2.li@intel.com>
5 months agolibphobos: Run unittest tests with dg-runtest.
Iain Buclaw [Thu, 27 Feb 2025 22:37:21 +0000 (23:37 +0100)] 
libphobos: Run unittest tests with dg-runtest.

Use `dg-runtest' test driver rather than `dg-test' to run the libphobos
unittest testsuite, same as all other libphobos tests.  This prevents
the tests from being ran multiple times when parallelized.

Set `libphobos_test_name' as well so that all tests get a unique name.

libphobos/ChangeLog:

* testsuite/libphobos.unittest/unittest.exp: Use `dg-runtest' rather
than `dg-test'.  Set `libphobos_test_name'.

5 months agolibstdc++: Fix outdated comment in <stacktrace>
Jonathan Wakely [Thu, 27 Feb 2025 21:58:09 +0000 (21:58 +0000)] 
libstdc++: Fix outdated comment in <stacktrace>

My r15-998-g2a83084ce55363 change replaced the use of nothrow
operator new with a call to __get_temporary_buffer, so update the
comment to match.

libstdc++-v3/ChangeLog:

* include/std/stacktrace (_Impl::_M_allocate): Fix outdated
comment.

5 months agogimple-fold: Fix a pasto in fold_truth_andor_for_ifcombine [PR119030]
Jakub Jelinek [Thu, 27 Feb 2025 21:11:51 +0000 (22:11 +0100)] 
gimple-fold: Fix a pasto in fold_truth_andor_for_ifcombine [PR119030]

The following testcase is miscompiled since r15-7597.
The left comparison is unsigned (x & 0x8000U) != 0) while the
right one is signed (x >> 16) >= 0 and is actually a signbit test,
so rsignbit is 64.
After debugging this and reading the r15-7597 change, I believe there
is just a pasto, the if (lsignbit) and if (rsignbit) blocks are pretty
much identical with just the first l on all variables starting with l
replaced with r (the only difference is that if (lsignbit) has a comment
explaining the sign <<= 1; stuff, while it isn't repeated in the second one.
Except the second one was using ll_unsignedp instead of rl_unsignedp
in one spot.  I think it should use the latter, the signedness of the left
comparison doesn't affect the other one, they are basically independent
with the exception that we check that after transformations they are both
EQ or both NE and later on we try to merge them together.

2025-02-27  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/119030
* gimple-fold.cc (fold_truth_andor_for_ifcombine): Fix a pasto,
ll_unsignedp -> rl_unsignedp.

* gcc.c-torture/execute/pr119030.c: New test.

5 months agoinput: Fix up ICEs with --param=file-cache-files=N for N > 16 [PR118860]
Jakub Jelinek [Thu, 27 Feb 2025 21:10:46 +0000 (22:10 +0100)] 
input: Fix up ICEs with --param=file-cache-files=N for N > 16 [PR118860]

The following testcase ICEs, because we first construct file_cache object
inside of *global_dc, then process options and then call file_cache::tune.
The earlier construction allocates the m_file_slots array (using new)
based on the static data member file_cache::num_file_slots, but then tune
changes it, without actually reallocating all m_file_slots arrays in already
constructed file_cache objects.

I think it is just weird to have the count be a static data member and
the pointer be non-static data member, that is just asking for issues like
this.

So, this patch changes num_file_slots into m_num_file_slots and turns tune
into a non-static member function and changes toplev.cc to call it on the
global_gc->get_file_cache () object.  And let's the tune just delete the
array and allocate it freshly if there is a change in the number of slots
or lines.

Note, file_cache_slot has similar problem, but because there are many, I
haven't moved the count into those objects; I just hope that when tune
is called there is exactly one file_cache constructed and all the
file_cache_slot objects constructed are pointed by its m_file_slots member,
so also on lines change it just deletes it and allocates again.  I think
it should be unlikely that the cache actually has any used slots by the time
it is called.

2025-02-27  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/118860
* input.h (file_cache::tune): No longer static.  Rename argument
from num_file_slots_ to num_file_slots.  Formatting fix.
(file_cache::num_file_slots): Renamed to ...
(file_cache::m_num_file_slots): ... this.  No longer static.
* input.cc (file_cache_slot::tune): Change return type from void to
size_t, return previous file_cache_slot::line_record_size value.
Formatting fixes.
(file_cache::tune): Rename argument from num_file_slots_ to
num_file_slots.  Set m_num_file_slots rather than num_file_slots.
If m_num_file_slots or file_cache_slot::line_record_size changes,
delete[] m_file_slots and new it again.
(file_cache::num_file_slots): Remove definition.
(file_cache::lookup_file): Use m_num_file_slots rather than
num_file_slots.
(file_cache::evicted_cache_tab_entry): Likewise.
(file_cache::file_cache): Likewise.  Initialize m_num_file_slots
to 16.
(file_cache::dump): Use m_num_file_slots rather than num_file_slots.
(file_cache_slot::get_next_line): Formatting fixes.
(file_cache_slot::read_line_num): Likewise.
(get_source_text_between): Likewise.
* toplev.cc (toplev::main): Call global_dc->get_file_cache ().tune
rather than file_cache::tune.

* gcc.dg/pr118860.c: New test.

5 months agonvptx: '#define MAX_FIXED_MODE_SIZE 128'
Thomas Schwinge [Wed, 26 Feb 2025 14:39:37 +0000 (15:39 +0100)] 
nvptx: '#define MAX_FIXED_MODE_SIZE 128'

... instead of 64 via 'gcc/defaults.h':

    MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)

This fixes ICEs:

    [-FAIL: c-c++-common/pr111309-1.c  -Wc++-compat  (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -Wc++-compat  (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -Wc++-compat  [-compilation failed to produce executable-]{+execution test+}

    [-FAIL: c-c++-common/pr111309-1.c  -std=gnu++17 (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++17 (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
    [-FAIL: c-c++-common/pr111309-1.c  -std=gnu++26 (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++26 (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++26 [-compilation failed to produce executable-]{+execution test+}
    [-FAIL: c-c++-common/pr111309-1.c  -std=gnu++98 (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++98 (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++98 [-compilation failed to produce executable-]{+execution test+}

    [-FAIL: gcc.dg/torture/pr116480-1.c   -O0  (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} gcc.dg/torture/pr116480-1.c   -O0  (test for excess errors)
    [-FAIL: gcc.dg/torture/pr116480-1.c   -O1  (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} gcc.dg/torture/pr116480-1.c   -O1  (test for excess errors)
    PASS: gcc.dg/torture/pr116480-1.c   -O2  (test for excess errors)
    PASS: gcc.dg/torture/pr116480-1.c   -O3 -g  (test for excess errors)
    PASS: gcc.dg/torture/pr116480-1.c   -Os  (test for excess errors)

..., where we ran into 'gcc_assert (icode != CODE_FOR_nothing);' in
'gcc/internal-fn.cc:expand_fn_using_insn' for '__int128' '__builtin_clzg' etc.:

    during RTL pass: expand
    [...]/c-c++-common/pr111309-1.c: In function 'clzI':
    [...]/c-c++-common/pr111309-1.c:69:10: internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268
    0x120ec2cf internal_error(char const*, ...)
            [...]/gcc/diagnostic-global-context.cc:517
    0x102c7c5b fancy_abort(char const*, int, char const*)
            [...]/gcc/diagnostic.cc:1722
    0x109708eb expand_fn_using_insn
            [...]/gcc/internal-fn.cc:268
    0x1098114f expand_internal_call(internal_fn, gcall*)
            [...]/gcc/internal-fn.cc:5273
    0x1098114f expand_internal_call(gcall*)
            [...]/gcc/internal-fn.cc:5281
    0x10594fc7 expand_call_stmt
            [...]/gcc/cfgexpand.cc:3049
    [...]

Likewise, as of commit e8ad697a75b0870a833366daf687668a57cabb6e
"libstdc++: Use new type-generic built-ins in <bit> [PR118855]",
the libstdc++ target library build ICEd in the same way.

Additionally, this change fixes:

    [-FAIL:-]{+PASS:+} gcc.dg/pr105094.c (test for excess errors)

..., which was:

    [...]/gcc.dg/pr105094.c: In function 'foo':
    [...]/gcc.dg/pr105094.c:11:12: error: size of variable 's' is too large

And, finally, regarding 'gcc.target/nvptx/stack_frame-1.c'.  Before, in
'gcc/cfgexpand.cc': 'expand_used_vars' -> 'expand_used_vars_for_block' ->
'expand_one_var' for 'ww' -> 'gcc/function.cc:use_register_for_decl' due to
'DECL_MODE (decl) == BLKmode' did 'return false;', thus -> 'add_stack_var'
(even if 'ww' wasn't then actually living on the stack).  Now, 'ww' has
'TImode' and 'use_register_for_decl' does 'return true;', thus ->
'expand_one_register_var', and therefore no unused stack frame emitted.

gcc/
* config/nvptx/nvptx.h (MAX_FIXED_MODE_SIZE): '#define'.
gcc/testsuite/
* gcc.target/nvptx/stack_frame-1.c: Adjust.

5 months agoAdd 'gcc.target/nvptx/stack_frame-1.c'
Thomas Schwinge [Wed, 26 Feb 2025 16:17:44 +0000 (17:17 +0100)] 
Add 'gcc.target/nvptx/stack_frame-1.c'

gcc/testsuite/
* gcc.target/nvptx/stack_frame-1.c: New.

5 months agonvptx: Build libgfortran with '-mfake-ptx-alloca' [PR107635]
Thomas Schwinge [Tue, 25 Feb 2025 21:31:25 +0000 (22:31 +0100)] 
nvptx: Build libgfortran with '-mfake-ptx-alloca' [PR107635]

As of recent commit 8bf0ee8d62b8a08e808344d31354ab713157e15d
"Fortran: Add transfer_between_remotes [PR107635]", we've got 'alloca' usage
in 'libgfortran/caf/single.c:_gfortran_caf_transfer_between_remotes', and
the libgfortran target library fails to build for legacy configurations where
PTX 'alloca' is not available:

    ../../../../source-gcc/libgfortran/caf/single.c: In function ‘_gfortran_caf_transfer_between_remotes’:
    ../../../../source-gcc/libgfortran/caf/single.c:675:23: sorry, unimplemented: dynamic stack allocation not supported
      675 |       transfer_desc = __builtin_alloca (desc_size);
          |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../../../../source-gcc/libgfortran/caf/single.c:680:20: sorry, unimplemented: dynamic stack allocation not supported
      680 |     transfer_ptr = __builtin_alloca (*opt_dst_charlen * src_size);
          |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    make[6]: *** [Makefile:4675: caf/single.lo] Error 1

With '-mfake-ptx-alloca', libgfortran again succeeds to build, and compared
to before, we've got only a small number of regressions due to nvptx 'ld'
complaining about 'unresolved symbol __GCC_nvptx__PTX_alloca_not_supported':

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/codimension_2.f90 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/event_4.f08 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)
    [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/event_4.f08 -fcoarray=lib  -O2  -lcaf_single [-execution test-]{+compilation failed to produce executable+}

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)
    [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib  -O2  -lcaf_single [-execution test-]{+compilation failed to produce executable+}

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)
    [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 -fcoarray=lib  -O2  -lcaf_single [-execution test-]{+compilation failed to produce executable+}

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray_43.f90   -O  (test for excess errors)

That's acceptable for such legacy PTX configurations.

PR target/107635
libgfortran/
* config/t-nvptx: New.
* configure.host [nvptx] (tmake_file): Add it.

5 months agonvptx: Support '-mfake-ptx-alloca'
Thomas Schwinge [Mon, 24 Feb 2025 15:13:11 +0000 (16:13 +0100)] 
nvptx: Support '-mfake-ptx-alloca'

With '-mfake-ptx-alloca' enabled, the user-visible behavior changes only
for configurations where PTX 'alloca' is not available.  Rather than a
compile-time 'sorry, unimplemented: dynamic stack allocation not supported'
in presence of dynamic stack allocation, compilation and assembly then
succeeds.  However, attempting to link in such '*.o' files then fails due
to unresolved symbol '__GCC_nvptx__PTX_alloca_not_supported'.

This is meant to be used in scenarios where large volumes of code are
compiled, a small fraction of which runs into dynamic stack allocation, but
these parts are not important for specific use cases, and we'd thus like the
build to succeed, and error out just upon actual, very rare use of the
offending '*.o' files.

gcc/
* config/nvptx/nvptx.opt (-mfake-ptx-alloca): New.
* config/nvptx/nvptx-protos.h (nvptx_output_fake_ptx_alloca):
Declare.
* config/nvptx/nvptx.cc (nvptx_output_fake_ptx_alloca): New.
* config/nvptx/nvptx.md (define_insn "@nvptx_alloca_<mode>")
[!(TARGET_PTX_7_3 && TARGET_SM52)]: Use it for
'-mfake-ptx-alloca'.
gcc/testsuite/
* gcc.target/nvptx/alloca-1-O0_-mfake-ptx-alloca.c: New.
* gcc.target/nvptx/alloca-2-O0_-mfake-ptx-alloca.c: Likewise.
* gcc.target/nvptx/alloca-4-O3_-mfake-ptx-alloca.c: Likewise.
* gcc.target/nvptx/vla-1-O0_-mfake-ptx-alloca.c: Likewise.
* gcc.target/nvptx/alloca-4-O3.c:
'dg-additional-options -mfake-ptx-alloca'.

5 months agonvptx: Delay 'sorry, unimplemented: dynamic stack allocation not supported' from...
Thomas Schwinge [Mon, 24 Feb 2025 09:09:11 +0000 (10:09 +0100)] 
nvptx: Delay 'sorry, unimplemented: dynamic stack allocation not supported' from expansion time to code generation

This gives the back end a chance to clean out a few more unnecessary instances
of dynamic stack allocation.  This progresses:

    PASS: gcc.dg/pr78902.c  (test for warnings, line 7)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 8)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 9)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 10)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 11)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 12)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 13)
    PASS: gcc.dg/pr78902.c strndup excessive bound at line 14 (test for warnings, line 13)
    [-UNSUPPORTED: gcc.dg/pr78902.c: dynamic stack allocation not supported-]
    {+PASS: gcc.dg/pr78902.c (test for excess errors)+}

    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O0 : dynamic stack allocation not supported
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr71901.c   -O1  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O2 : dynamic stack allocation not supported
    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions : dynamic stack allocation not supported
    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O3 -g : dynamic stack allocation not supported
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr71901.c   -Os  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}

    UNSUPPORTED: gcc.dg/torture/pr78742.c   -O0 : dynamic stack allocation not supported
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O1  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O2  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O3 -g  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    UNSUPPORTED: gcc.dg/torture/pr78742.c   -Os : dynamic stack allocation not supported

    [-UNSUPPORTED:-]{+PASS:+} gfortran.dg/pr101267.f90   -O  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}

    [-UNSUPPORTED:-]{+PASS:+} gfortran.dg/pr112404.f90   -O  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}

gcc/
* config/nvptx/nvptx.md (define_expand "allocate_stack")
[!TARGET_SOFT_STACK]: Move
'sorry ("dynamic stack allocation not supported");'...
(define_insn "@nvptx_alloca_<mode>"): ... here.
gcc/testsuite/
* gcc.target/nvptx/alloca-1-unused-O0-sm_30.c: Adjust.

5 months agonvptx: Add test cases for dead/unused 'alloca'/VLA
Thomas Schwinge [Mon, 24 Feb 2025 21:03:47 +0000 (22:03 +0100)] 
nvptx: Add test cases for dead/unused 'alloca'/VLA

gcc/testsuite/
* gcc.target/nvptx/alloca-1-dead-O0-sm_30.c: New.
* gcc.target/nvptx/alloca-1-dead-O0.c: Likewise.
* gcc.target/nvptx/alloca-1-dead-O1-sm_30.c: Likewise.
* gcc.target/nvptx/alloca-1-dead-O1.c: Likewise.
* gcc.target/nvptx/alloca-1-unused-O0-sm_30.c: Likewise.
* gcc.target/nvptx/alloca-1-unused-O0.c: Likewise.
* gcc.target/nvptx/alloca-1-unused-O1-sm_30.c: Likewise.
* gcc.target/nvptx/alloca-1-unused-O1.c: Likewise.
* gcc.target/nvptx/vla-1-dead-O0-sm_30.c: Likewise.
* gcc.target/nvptx/vla-1-dead-O0.c: Likewise.
* gcc.target/nvptx/vla-1-dead-O1-sm_30.c: Likewise.
* gcc.target/nvptx/vla-1-dead-O1.c: Likewise.
* gcc.target/nvptx/vla-1-unused-O0-sm_30.c: Likewise.
* gcc.target/nvptx/vla-1-unused-O0.c: Likewise.
* gcc.target/nvptx/vla-1-unused-O1-sm_30.c: Likewise.
* gcc.target/nvptx/vla-1-unused-O1.c: Likewise.

5 months agoGCC: Documentation of -x option
Jerry DeLisle [Thu, 27 Feb 2025 01:26:26 +0000 (17:26 -0800)] 
GCC: Documentation of -x option

This change updates information about the -x option to clarify
that it does not ensure standards compliance. Sparked by
discussions in the following PR.

PR fortran/108369

gcc/ChangeLog:

* doc/invoke.texi: Add a note to clarify. Adjust some wording.

5 months agoc++: ICE with GOTO_EXPR [PR118928]
Marek Polacek [Wed, 19 Feb 2025 19:06:33 +0000 (14:06 -0500)] 
c++: ICE with GOTO_EXPR [PR118928]

In this PR we crash in cxx_eval_constant_expression/GOTO_EXPR on:

  gcc_assert (cxx_dialect >= cxx23);

The code obviously doesn't expect to see a goto pre-C++23.  But we can
get here with the new prvalue optimization.  In this test we found
ourselves in synthesize_method for X::X().  This function calls:

 a) finish_function, which does cp_genericize -> ... -> genericize_c_loops,
    which creates the GOTO_EXPR;
 b) expand_or_defer_fn -> maybe_clone_body -> ... -> cp_fold_function
    where we reach the new maybe_constant_init call and crash on the
    goto.

Since we can validly get to that assert, I think we should just remove
it.  I don't see other similar asserts like this one.

PR c++/118928

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_constant_expression) <case GOTO_EXPR>: Remove
an assert.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-prvalue5.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>
5 months ago[PR118940][LRA]: Add a test
Vladimir N. Makarov [Thu, 27 Feb 2025 18:39:04 +0000 (13:39 -0500)] 
[PR118940][LRA]: Add a test

PR115458 also solves given PR.  So the patch adds only a
test case which can be used for testing LRA work aspects different from
PR115458 test case.

gcc/testsuite/ChangeLog:

PR target/118940
* gcc.target/i386/pr118940.c: New test.

5 months ago[PR116336][LRA]: Add a test
Vladimir N. Makarov [Thu, 27 Feb 2025 18:05:44 +0000 (13:05 -0500)] 
[PR116336][LRA]: Add a test

  Patch for PR116234 solves given PR116366.  So the patch adds only the test
case which is very different from PR116234 one.

gcc/testsuite/ChangeLog:

PR rtl-optimization/116336
* gcc.dg/pr116336.c: New test.

5 months agoc++: too many errors with sneaky template [PR118516]
Marek Polacek [Thu, 20 Feb 2025 19:35:25 +0000 (14:35 -0500)] 
c++: too many errors with sneaky template [PR118516]

Since C++20 P0846, a name followed by a < can be treated as a template-name
even though name lookup did not find a template-name.  That happens
in this test with "i < foo ()":

  for (int id = 0; i < foo(); ++id);

and results in a raft of errors about non-constant foo().  The problem
is that the require_potential_constant_expression call in
cp_parser_template_argument emits errors even when we're parsing
tentatively.  So we repeat the error when we're trying to parse
as a nested-name-specifier, type-name, etc.

Guarding the call with !cp_parser_uncommitted_to_tentative_parse_p would
mean that require_potential_constant_expression never gets called.  But
we don't need the call at all as far as I can tell.  Stuff like

  template<int N> struct S { };
  int foo () { return 4; }
  void
  g ()
  {
    S<foo()> s;
  }

gets diagnosed in convert_nontype_argument.  In fact, with this patch,
we only emit "call to non-constexpr function" once.  (That is, in C++17
only; C++14 uses a different path.)

PR c++/118516

gcc/cp/ChangeLog:

* parser.cc (cp_parser_template_argument): Don't call
require_potential_constant_expression.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/fn-template11.C:
* g++.dg/template/fn-template1.C: New test.
* g++.dg/template/fn-template2.C: New test.

5 months agotestsuite: arm: Avoid incremental link warnings in pr61123-enum-size
Richard Earnshaw [Thu, 27 Feb 2025 15:11:47 +0000 (15:11 +0000)] 
testsuite: arm: Avoid incremental link warnings in pr61123-enum-size

This test uses incremental linking, but that can generate warnings if
the LTO step contains a mix of LTO and non-LTO object files (this can
happen when there's a testglue file that is normally included during
linking).

We don't care about the testglue, though, so just tell the LTO
optimizer to generate nolto-rel output, which is what it is falling
back to anyway.

gcc/testsuite:
* gcc.target/arm/lto/pr61123-enum-size_0.c: (dg-lto-options) Move
linker related options to ...
(dg-extra-ld-options): ... here.  Add -flinker-output=nolto-rel.

5 months agoFortran: Fix ICE on associate of pointer [PR118789]
Andre Vehreschild [Tue, 25 Feb 2025 16:15:47 +0000 (17:15 +0100)] 
Fortran: Fix ICE on associate of pointer [PR118789]

Fix ICE when associating a pointer to void (c_ptr) by looking at the
compatibility of the type hierarchy.

PR fortran/118789

gcc/fortran/ChangeLog:

* trans-stmt.cc (trans_associate_var): Compare pointed to types when
expr to associate is already a pointer.

gcc/testsuite/ChangeLog:

* gfortran.dg/associate_73.f90: New test.

5 months agoi386: Treat Granite Rapids/Granite Rapids-D/Diamond Rapids similar as Sapphire Rapids...
Haochen Jiang [Wed, 26 Feb 2025 03:28:45 +0000 (11:28 +0800)] 
i386: Treat Granite Rapids/Granite Rapids-D/Diamond Rapids similar as Sapphire Rapids in x86-tune.def

Since GNR, GNR-D, DMR are both P-core based, we should treat them
just like SPR for now.

gcc/ChangeLog:

* config/i386/x86-tune.def
(X86_TUNE_DEST_FALSE_DEP_FOR_GLC): Add GNR, GNR-D, DMR.
(X86_TUNE_AVOID_256FMA_CHAINS): Ditto.
(X86_TUNE_AVX512_MOVE_BY_PIECES): Ditto.
(X86_TUNE_AVX512_STORE_BY_PIECES): Ditto.

5 months agogimple-range-phi: Fix comment typo
Jakub Jelinek [Thu, 27 Feb 2025 07:56:29 +0000 (08:56 +0100)] 
gimple-range-phi: Fix comment typo

During reading of this file I've noticed a typo in the comment, which
this patch fixes.

2025-02-27  Jakub Jelinek  <jakub@redhat.com>

* gimple-range-phi.cc (phi_analyzer::process_phi): Fix comment typo,
dpoesn;t -> doesn't.

5 months agoMakefile: Link in {simple,lazy}-diagnostic-path.o [PR116143]
Jakub Jelinek [Thu, 27 Feb 2025 07:50:47 +0000 (08:50 +0100)] 
Makefile: Link in {simple,lazy}-diagnostic-path.o [PR116143]

Some of the plugin.exp tests FAIL in --enable-checking=release builds while
they succeed in --enable-checking=yes builds.
Initially I've changed some small simple out of line methods into inline ones
in the header, but the tests kept failing, just with different symbols.

The _ZN22simple_diagnostic_path9add_eventEmP9tree_nodeiPKcz symbol (and the
others too) are normally emitted in simple-diagnostic-path.o, it isn't some
fancy C++ optimization of classes with final method or LTO optimization.

The problem is that simple-diagnostic-path.o is like most objects added into
libbackend.a and we then link libbackend.a without -Wl,--whole-archive ...
-Wl,--no-whole-archive around it (and can't easily, not all system compilers
and linkers will support that).
With --enable-checking=yes simple-diagnostic-path.o is pulled in, because
selftest-run-tests.o calls simple_diagnostic_path_cc_tests and so
simple-diagnostic-path.o is linked in.
With --enable-checking=release self-tests aren't done and nothing links in
simple-diagnostic-path.o, because nothing in the compiler proper needs
anything from it, only the plugin tests.

Using -Wl,-M on cc1 linking, I see that in --enable-checking=release
build
analyzer/analyzer-selftests.o
digraph.o
dwarf2codeview.o
fibonacci_heap.o
function-tests.o
hash-map-tests.o
hash-set-tests.o
hw-doloop.o
insn-peep.o
lazy-diagnostic-path.o
options-urls.o
ordered-hash-map-tests.o
pair-fusion.o
print-rtl-function.o
resource.o
rtl-tests.o
selftest-rtl.o
selftest-run-tests.o
simple-diagnostic-path.o
splay-tree-utils.o
typed-splay-tree.o
vmsdbgout.o
aren't linked into cc1 (the *test* for obvious reasons of not doing
selftests, pair-fusion.o because it is aarch64 specific, hw-doloop.o because
x86 doesn't have doloop opts, vmsdbgout.o because not on VMS).

So, the question is if and what from digraph.o, fibinacci_heap.o,
hw-doloop.o, insn-peep.o, lazy-diagnostic-path.o, options-urls.o,
pair-fusion.o, print-rtl-function.o, resource.o, simple-diagnostic-path.o,
splay-tree-utils.o, typed-splay-tree.o are supposed to be part of the
plugin API if anything and how we arrange for those to be linked in when
plugins are enabled.

The following patch just adds unconditionally the
{simple,lazy}-diagnostic-path.o objects to the link lines before libbackend.a
so that their content is available to plugin users.

2025-02-27  Jakub Jelinek  <jakub@redhat.com>

PR testsuite/116143
* Makefile.in (EXTRA_BACKEND_OBJS): New variable.
(BACKEND): Use it before libbackend.a.

5 months agoalias: Perform offset arithmetics in poly_offset_int rather than poly_int64 [PR118819]
Jakub Jelinek [Thu, 27 Feb 2025 07:48:18 +0000 (08:48 +0100)] 
alias: Perform offset arithmetics in poly_offset_int rather than poly_int64 [PR118819]

This PR is about ubsan error on the c - cx1 + cy1 evaluation in the first
hunk.

The following patch hopefully fixes that by doing the additions/subtractions
in poly_offset_int rather than poly_int64 and then converting back to poly_int64.
If it doesn't fit, -1 is returned (which means it is unknown if there is a conflict
or not).

2025-02-27  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/118819
* alias.cc (memrefs_conflict_p): Perform arithmetics on c, xsize and
ysize in poly_offset_int and return -1 if it is not representable in
poly_int64.

5 months agoDaily bump.
GCC Administrator [Thu, 27 Feb 2025 00:17:51 +0000 (00:17 +0000)] 
Daily bump.

5 months agolibstdc++: Add code comment documenting LWG 4027 change [PR118083]
Patrick Palka [Wed, 26 Feb 2025 19:51:38 +0000 (14:51 -0500)] 
libstdc++: Add code comment documenting LWG 4027 change [PR118083]

PR libstdc++/118083

libstdc++-v3/ChangeLog:

* include/bits/ranges_base.h
(ranges::__access::__possibly_const_range): Mention LWG 4027.

5 months agoc: Assorted fixes for flexible array members in unions [PR119001]
Jakub Jelinek [Wed, 26 Feb 2025 18:31:08 +0000 (19:31 +0100)] 
c: Assorted fixes for flexible array members in unions [PR119001]

r15-209 allowed flexible array members inside of unions, but as the
following testcase shows, not everything has been adjusted for that.
Unlike structures, in unions flexible array member (as an extension)
can be any of the members, not just the last one, as in union all
members are effectively last.
The first hunk is about an ICE on the initialization of the FAM
in union which is not the last FIELD_DECL with a string literal,
the second hunk just formatting fix, third hunk fixes a bug in which
we were just throwing away the initializers (except for with string literal)
of FAMs in unions which aren't the last FIELD_DECL, and the last hunk
is to diagnose FAM errors in unions the same as for structures, in
particular trying to initialize a FAM with non-constant or initialization
in nested context.

2025-02-26  Jakub Jelinek  <jakub@redhat.com>

PR c/119001
gcc/
* varasm.cc (output_constructor_regular_field): Don't fail
assertion if next is non-NULL and FIELD_DECL if
TREE_CODE (local->type) is UNION_TYPE.
gcc/c/
* c-typeck.cc (pop_init_level): Don't clear constructor_type
if DECL_CHAIN of constructor_fields is NULL but p->type is UNION_TYPE.
Formatting fix.
(process_init_element): Diagnose non-static initialization of flexible
array member in union or FAM in union initialization in nested context.
gcc/testsuite/
* gcc.dg/pr119001-1.c: New test.
* gcc.dg/pr119001-2.c: New test.

5 months agoc: stddef.h C23 fixes [PR114870]
Jakub Jelinek [Wed, 26 Feb 2025 18:29:12 +0000 (19:29 +0100)] 
c: stddef.h C23 fixes [PR114870]

The stddef.h header for C23 defines __STDC_VERSION_STDDEF_H__ and
unreachable macros multiple times in some cases.
The header doesn't have normal multiple inclusion guard, because it supports
for glibc inclusion with __need_{size_t,wchar_t,ptrdiff_t,wint_t,NULL}.
While the definition of __STDC_VERSION_STDDEF_H__ and unreachable is done
solely in the #ifdef _STDDEF_H part, so they are defined only if stddef.h
is included without those __need_* macros defined.  But actually once
stddef.h is included without the __need_* macros, _STDDEF_H is then defined
and while further stddef.h includes without __need_* macros don't do
anything:
 #if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
      && !defined(__STDDEF_H__)) \
     || defined(__need_wchar_t) || defined(__need_size_t) \
     || defined(__need_ptrdiff_t) || defined(__need_NULL) \
     || defined(__need_wint_t)
if one includes whole stddef.h first and then stddef.h with some of the
__need_* macros defined, the #ifdef _STDDEF_H part is used again.
It isn't that big deal for most cases, as it uses extra guarding macros
like:
 #ifndef _GCC_MAX_ALIGN_T
 #define _GCC_MAX_ALIGN_T
 ...
 #endif
etc., but for __STDC_VERSION_STDDEF_H__/unreachable nothing like that is
used.

So, either we do what the following patch does and just don't define
__STDC_VERSION_STDDEF_H__/unreachable second time, or use #ifndef
unreachable separately for the #define unreachable() case, or use
new _GCC_STDC_VERSION_STDDEF_H macro to guard this (or two, one for
__STDC_VERSION_STDDEF_H__ and one for unreachable), or rework the initial
condition to be just
 #if !defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
     && !defined(__STDDEF_H__)
- I really don't understand why the header should do anything at all after
it has been included once without __need_* macros.  But changing how this
behaves after 35 years might be risky for various OS/libc combinations.

2025-02-26  Jakub Jelinek  <jakub@redhat.com>

PR c/114870
* ginclude/stddef.h (__STDC_VERSION_STDDEF_H__, unreachable): Don't
redefine multiple times if stddef.h is first included without __need_*
defines and later with them.  Move nullptr_t and unreachable and
__STDC_VERSION_STDDEF_H__ definitions into the same
defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L #if block.

* gcc.dg/c23-stddef-2.c: New test.

5 months agoarm: Fix up REVERSE_CONDITION macro [PR119002]
Jakub Jelinek [Wed, 26 Feb 2025 18:28:09 +0000 (19:28 +0100)] 
arm: Fix up REVERSE_CONDITION macro [PR119002]

The linaro CI found my PR119002 patch broke bootstrap on arm.
Seems the problem is that it has incorrect REVERSE_CONDITION macro
definition.
All other target's REVERSE_CONDITION definitions and the default one
just use the macro's arguments, while arm.h definition uses the MODE
argument but uses code instead of CODE (the first argument).
This happens to work because before my patch the only use of the
macro was in jump.cc with
  /* First see if machine description supplies us way to reverse the
     comparison.  Give it priority over everything else to allow
     machine description to do tricks.  */
  if (GET_MODE_CLASS (mode) == MODE_CC
      && REVERSIBLE_CC_MODE (mode))
    return REVERSE_CONDITION (code, mode);
but in my patch it is used with GT rather than code.

2025-02-26  Jakub Jelinek  <jakub@redhat.com>

PR rtl-optimization/119002
* config/arm/arm.h (REVERSE_CONDITION): Use CODE - the macro
argument - in the macro rather than code.

5 months ago[PR119021][LRA]: Fix rtl correctness check failure in LRA.
Vladimir N. Makarov [Wed, 26 Feb 2025 16:28:08 +0000 (11:28 -0500)] 
[PR119021][LRA]: Fix rtl correctness check failure in LRA.

  Patch to fix PR115458 contained a code change in dealing with asm
errors to avoid cycling in reporting the error for asm gotos.  This
code was wrong and resulted in checking RTL correctness failure.  This
patch reverts the code change and solves cycling in asm error
reporting in a different way.

gcc/ChangeLog:

PR middle-end/119021
* lra.cc (lra_asm_insn_error): Use lra_invalidate_insn_data
instead of lra_update_insn_regno_info.
* lra-assigns.cc (lra_split_hard_reg_for): Restore old code.

5 months ago[testsuite] add x86 effective target
Alexandre Oliva [Wed, 26 Feb 2025 10:39:25 +0000 (07:39 -0300)] 
[testsuite] add x86 effective target

I got tired of repeating the conditional that recognizes ia32 or
x86_64, and introduced 'x86' as a shorthand for that, adjusting all
occurrences in target-supports.exp, to set an example.  I found some
patterns that recognized i?86* and x86_64*, but I took those as likely
cut&pastos instead of trying to preserve those weirdnesses.

for  gcc/ChangeLog

* doc/sourcebuild.texi: Add x86 effective target.

for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (check_effective_target_x86): New.
Replace all uses of i?86-*-* and x86_64-*-* in this file.

5 months ago[testsuite] adjust expectations of x86 vect-simd-clone tests
Alexandre Oliva [Wed, 26 Feb 2025 10:39:18 +0000 (07:39 -0300)] 
[testsuite] adjust expectations of x86 vect-simd-clone tests

Some vect-simd-clone tests fail when targeting ancient x86 variants,
because the expected transformations only take place with -msse4 or
higher.

So arrange for these tests to take an -msse4 option on x86, so that
the expected vectorization takes place, but decay to a compile test if
vect.exp would enable execution but the target doesn't have an sse4
runtime.  This requires the new dg-do-if to override the action on a
target while retaining the default action on others, instead of
disabling the test.

We can count on avx512f compile-time support for these tests, because
vect_simd_clones requires that on x86, and that implies sse4 support,
so we need not complicate the scan conditionals with tests for sse4,
except on the last test.

for  gcc/ChangeLog

* doc/sourcebuild.texi (dg-do-if): Document.

for  gcc/testsuite/ChangeLog

* lib/target-supports-dg.exp (dg-do-if): New.
* gcc.dg/vect/vect-simd-clone-16f.c: Use -msse4 on x86, and
skip in case execution is enabled but the runtime isn't.
* gcc.dg/vect/vect-simd-clone-17f.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18f.c: Likewise.
* gcc.dg/vect/vect-simd-clone-20.c: Likewise, but only skip
the scan test.

5 months agosimple-diagnostic-path: Inline two trivial methods [PR116143]
Jakub Jelinek [Wed, 26 Feb 2025 09:50:51 +0000 (10:50 +0100)] 
simple-diagnostic-path: Inline two trivial methods [PR116143]

Various plugin tests fail with --enable-checking=release, because the
num_events and num_threads methods of simple_diagnostic_path are only used
inside of #if CHECKING_P code inside of GCC proper and then tested inside of
some plugin tests.  So, with --enable-checking=yes they are compiled into
cc1/cc1plus etc. binaries and plugins can call those, but with
--enable-checking=release they are optimized away (at least for LTO builds).

As they are trivial, the following patch just defines them inline, so that
the plugin tests get their definitions directly and don't have to rely
on cc1/cc1plus etc. exporting those.

2025-02-26  Jakub Jelinek  <jakub@redhat.com>

PR testsuite/116143
* simple-diagnostic-path.h (simple_diagnostic_path::num_events): Define
inline.
(simple_diagnostic_path::num_threads): Likewise.
* simple-diagnostic-path.cc (simple_diagnostic_path::num_events):
Remove out of line definition.
(simple_diagnostic_path::num_threads): Likewise.

5 months agoFortran: Remove SAVE_EXPR on lhs in assign [PR108233]
Andre Vehreschild [Tue, 25 Feb 2025 13:17:16 +0000 (14:17 +0100)] 
Fortran: Remove SAVE_EXPR on lhs in assign [PR108233]

With vectorial shaped datatypes like e.g. complex numbers, fold_convert
inserts a SAVE_EXPR.  Using that on the lhs in an assignment prevented
the update of the variable, when in a coarray.

PR fortran/108233

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_trans_assignment_1): Remove SAVE_EXPR on lhs.

gcc/testsuite/ChangeLog:

* gfortran.dg/coarray/complex_1.f90: New test.

5 months agotestsuite: Add pragma novector to more tests [PR118464]
Tamar Christina [Wed, 26 Feb 2025 07:31:28 +0000 (07:31 +0000)] 
testsuite: Add pragma novector to more tests [PR118464]

These loops will now vectorize the entry finding
loops.  As such we get more failures because they
were not expecting to be vectorized.

Fixed by adding #pragma GCC novector.

gcc/testsuite/ChangeLog:

PR tree-optimization/118464
PR tree-optimization/116855
* g++.dg/ext/pragma-unroll-lambda-lto.C: Add pragma novector.
* gcc.dg/tree-ssa/gen-vect-2.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-25.c: Likewise.
* gcc.dg/tree-ssa/gen-vect-32.c: Likewise.
* gcc.dg/tree-ssa/ivopt_mult_2g.c: Likewise.
* gcc.dg/tree-ssa/ivopts-5.c: Likewise.
* gcc.dg/tree-ssa/ivopts-6.c: Likewise.
* gcc.dg/tree-ssa/ivopts-7.c: Likewise.
* gcc.dg/tree-ssa/ivopts-8.c: Likewise.
* gcc.dg/tree-ssa/ivopts-9.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-1.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-10.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-11.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-12.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-2.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-3.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-4.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-5.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-6.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-7.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-8.c: Likewise.
* gcc.dg/tree-ssa/predcom-dse-9.c: Likewise.
* gcc.target/i386/pr90178.c: Likewise.

5 months agoDaily bump.
GCC Administrator [Wed, 26 Feb 2025 00:17:49 +0000 (00:17 +0000)] 
Daily bump.

5 months agolibphobos: Generate test files for phobos testsuite
Iain Buclaw [Tue, 25 Feb 2025 20:01:23 +0000 (21:01 +0100)] 
libphobos: Generate test files for phobos testsuite

Extracts all public unittests from libphobos/src and emits them as
standalone tests in the testsuite using the tests_extractor script.

Compiling every module in the Phobos library with unittests included is
computationally expensive, and these tests are now only ran when
GCC_TEST_RUN_EXPENSIVE is not empty.

When instead just compiling the unittests and linking in the module
under test, this has been observed to reduce the time spent running the
testsuite by more than half.

libphobos/ChangeLog:

* testsuite/libphobos.phobos/shared/phobos-shared.exp: Require
is-effective-target run_expensive_tests.
* testsuite/libphobos.phobos/static/phobos-static.exp: Likewise.
* testsuite/libphobos.phobos/phobos.exp: New test.
* testsuite/libphobos.phobos/std_algorithm_comparison.d: New test.
* testsuite/libphobos.phobos/std_algorithm_iteration.d: New test.
* testsuite/libphobos.phobos/std_algorithm_mutation.d: New test.
* testsuite/libphobos.phobos/std_algorithm_searching.d: New test.
* testsuite/libphobos.phobos/std_algorithm_setops.d: New test.
* testsuite/libphobos.phobos/std_algorithm_sorting.d: New test.
* testsuite/libphobos.phobos/std_array.d: New test.
* testsuite/libphobos.phobos/std_ascii.d: New test.
* testsuite/libphobos.phobos/std_base64.d: New test.
* testsuite/libphobos.phobos/std_bigint.d: New test.
* testsuite/libphobos.phobos/std_bitmanip.d: New test.
* testsuite/libphobos.phobos/std_checkedint.d: New test.
* testsuite/libphobos.phobos/std_complex.d: New test.
* testsuite/libphobos.phobos/std_concurrency.d: New test.
* testsuite/libphobos.phobos/std_container_array.d: New test.
* testsuite/libphobos.phobos/std_container_binaryheap.d: New test.
* testsuite/libphobos.phobos/std_container_dlist.d: New test.
* testsuite/libphobos.phobos/std_container_rbtree.d: New test.
* testsuite/libphobos.phobos/std_container_slist.d: New test.
* testsuite/libphobos.phobos/std_container_util.d: New test.
* testsuite/libphobos.phobos/std_conv.d: New test.
* testsuite/libphobos.phobos/std_csv.d: New test.
* testsuite/libphobos.phobos/std_datetime_date.d: New test.
* testsuite/libphobos.phobos/std_datetime_interval.d: New test.
* testsuite/libphobos.phobos/std_datetime_package.d: New test.
* testsuite/libphobos.phobos/std_datetime_stopwatch.d: New test.
* testsuite/libphobos.phobos/std_datetime_systime.d: New test.
* testsuite/libphobos.phobos/std_datetime_timezone.d: New test.
* testsuite/libphobos.phobos/std_demangle.d: New test.
* testsuite/libphobos.phobos/std_digest_crc.d: New test.
* testsuite/libphobos.phobos/std_digest_hmac.d: New test.
* testsuite/libphobos.phobos/std_digest_md.d: New test.
* testsuite/libphobos.phobos/std_digest_murmurhash.d: New test.
* testsuite/libphobos.phobos/std_digest_package.d: New test.
* testsuite/libphobos.phobos/std_digest_ripemd.d: New test.
* testsuite/libphobos.phobos/std_digest_sha.d: New test.
* testsuite/libphobos.phobos/std_encoding.d: New test.
* testsuite/libphobos.phobos/std_exception.d: New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_affix_allocator.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_aligned_block_list.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_allocator_list.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_ascending_page_allocator.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_bitmapped_block.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_bucketizer.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_fallback_allocator.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_free_list.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_kernighan_ritchie.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_quantizer.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_region.d: New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_scoped_allocator.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_segregator.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_building_blocks_stats_collector.d:
New test.
* testsuite/libphobos.phobos/std_experimental_allocator_common.d: New test.
* testsuite/libphobos.phobos/std_experimental_allocator_gc_allocator.d: New test.
* testsuite/libphobos.phobos/std_experimental_allocator_mallocator.d: New test.
* testsuite/libphobos.phobos/std_experimental_allocator_package.d: New test.
* testsuite/libphobos.phobos/std_experimental_allocator_showcase.d: New test.
* testsuite/libphobos.phobos/std_experimental_allocator_typed.d: New test.
* testsuite/libphobos.phobos/std_file.d: New test.
* testsuite/libphobos.phobos/std_format_package.d: New test.
* testsuite/libphobos.phobos/std_format_read.d: New test.
* testsuite/libphobos.phobos/std_format_spec.d: New test.
* testsuite/libphobos.phobos/std_format_write.d: New test.
* testsuite/libphobos.phobos/std_functional.d: New test.
* testsuite/libphobos.phobos/std_getopt.d: New test.
* testsuite/libphobos.phobos/std_int128.d: New test.
* testsuite/libphobos.phobos/std_internal_cstring.d: New test.
* testsuite/libphobos.phobos/std_internal_scopebuffer.d: New test.
* testsuite/libphobos.phobos/std_json.d: New test.
* testsuite/libphobos.phobos/std_logger_core.d: New test.
* testsuite/libphobos.phobos/std_logger_nulllogger.d: New test.
* testsuite/libphobos.phobos/std_math_algebraic.d: New test.
* testsuite/libphobos.phobos/std_math_exponential.d: New test.
* testsuite/libphobos.phobos/std_math_hardware.d: New test.
* testsuite/libphobos.phobos/std_math_operations.d: New test.
* testsuite/libphobos.phobos/std_math_remainder.d: New test.
* testsuite/libphobos.phobos/std_math_rounding.d: New test.
* testsuite/libphobos.phobos/std_math_traits.d: New test.
* testsuite/libphobos.phobos/std_math_trigonometry.d: New test.
* testsuite/libphobos.phobos/std_meta.d: New test.
* testsuite/libphobos.phobos/std_mmfile.d: New test.
* testsuite/libphobos.phobos/std_numeric.d: New test.
* testsuite/libphobos.phobos/std_outbuffer.d: New test.
* testsuite/libphobos.phobos/std_package.d: New test.
* testsuite/libphobos.phobos/std_parallelism.d: New test.
* testsuite/libphobos.phobos/std_path.d: New test.
* testsuite/libphobos.phobos/std_random.d: New test.
* testsuite/libphobos.phobos/std_range_interfaces.d: New test.
* testsuite/libphobos.phobos/std_range_package.d: New test.
* testsuite/libphobos.phobos/std_range_primitives.d: New test.
* testsuite/libphobos.phobos/std_regex_package.d: New test.
* testsuite/libphobos.phobos/std_signals.d: New test.
* testsuite/libphobos.phobos/std_socket.d: New test.
* testsuite/libphobos.phobos/std_stdio.d: New test.
* testsuite/libphobos.phobos/std_string.d: New test.
* testsuite/libphobos.phobos/std_sumtype.d: New test.
* testsuite/libphobos.phobos/std_traits.d: New test.
* testsuite/libphobos.phobos/std_typecons.d: New test.
* testsuite/libphobos.phobos/std_typetuple.d: New test.
* testsuite/libphobos.phobos/std_uni_package.d: New test.
* testsuite/libphobos.phobos/std_uri.d: New test.
* testsuite/libphobos.phobos/std_utf.d: New test.
* testsuite/libphobos.phobos/std_uuid.d: New test.
* testsuite/libphobos.phobos/std_variant.d: New test.
* testsuite/libphobos.phobos/std_zlib.d: New test.

5 months agolibstdc++: add support for constexpr stable_sort (P2562R1)
Giuseppe D'Angelo [Tue, 25 Feb 2025 18:23:55 +0000 (18:23 +0000)] 
libstdc++: add support for constexpr stable_sort (P2562R1)

stable_sort has been made constexpr in C++26. Apart from plastering a
few functions with constexpr, there's an implementation challenge, that
is: stable_sort takes different codepaths in case extra memory can be
allocated. Rather than doing some major refactorings, simply use the
non-allocating path during constant evaluation. That's the same codepath
used when extra memory could not be allocated, as well as by
freestanding.

libstdc++-v3/ChangeLog:

* include/bits/algorithmfwd.h (stable_sort): Add constexpr.
* include/bits/ranges_algo.h (__stable_sort_fn): Add constexpr
to the function call operators.
* include/bits/stl_algo.h (__stable_sort): Add constexpr.
During constant evaluation, always use the non-allocating path.
(stable_sort): Add constexpr.
(__inplace_stable_sort): Likewise.
(__merge_without_buffer): Likewise.
* include/bits/version.def (constexpr_algorithms): Bump value
for C++26.
* include/bits/version.h: Regnerate.
* testsuite/25_algorithms/cpp_lib_constexpr.cc: Test the bumped
feature-testing macro.
* testsuite/25_algorithms/headers/algorithm/synopsis.cc: Adapt
the test to constexpr stable_sort.
* testsuite/25_algorithms/stable_sort/constexpr.cc: New test.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
5 months agolibstdc++: add a constexpr macro for C++26
Giuseppe D'Angelo [Tue, 25 Feb 2025 18:07:46 +0000 (18:07 +0000)] 
libstdc++: add a constexpr macro for C++26

Following the precedent of _GLIBCXX20_CONSTEXPR.

It will be used to decorate some functions which have been made
constexpr in C++26 (for instance P2562R1, and maybe P3508R0, P3369R0,
...).

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX26_CONSTEXPR): New macro.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
5 months agolibstdc++: Fix typo in std::fill SFINAE constraint [PR93059]
Jonathan Wakely [Tue, 25 Feb 2025 18:06:46 +0000 (18:06 +0000)] 
libstdc++: Fix typo in std::fill SFINAE constraint [PR93059]

The r15-4321-gd8ef4471cb9c9f change incorrectly used __value as the
member of the __memcpyable_integer trait, but it should have been
__width. That meant this overload was not being used for _Tp != _Up.

Also return after doing the loop for the consteval case. The missing
return wasn't causing incorrect behaviour because the consteval loop
increments the iterator until it equals the end of the range, so the
memset isn't done.  But it's still better to return and not even try
to do the memset.

libstdc++-v3/ChangeLog:

PR libstdc++/93059
* include/bits/stl_algobase.h (__fill_a1): Fix typo in SFINAE
constraint.

5 months agoi386: Fix pr101950-2.c [PR115028]
Andrew Pinski [Thu, 20 Feb 2025 21:03:51 +0000 (13:03 -0800)] 
i386: Fix pr101950-2.c [PR115028]

So what is happening here is that after r15-268-g9dbff9c05520a7,
a move instruction still exists after combine and the register
allocator choses different register allocation order for the xor
and because the input operand of lzcntq is not the same as output
operand, there is an extra xor that happens (due to an errata).

This fixes the testcase by using loading from a pointer instead
of a function argument directly. The register allocator has more
freedom since the load has no hard register associated with it (rdi)
so it can be in eax register right away.

Tested for both -m32 and -m64 on x86_64-linux-gnu.

gcc/testsuite/ChangeLog:

PR testsuite/115028
* gcc.target/i386/pr101950-2.c: Use a pointer argument instead
of the argument directly.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
5 months agolibphobos: Add script for extracting unittests from phobos
Iain Buclaw [Tue, 25 Feb 2025 18:47:06 +0000 (19:47 +0100)] 
libphobos: Add script for extracting unittests from phobos

This script parses all unittests annotated with three slashes (`///')
and extracts them into a standalone test case.  The intended use is for
generating inexpensive tests to be ran for the phobos testsuite.

libphobos/ChangeLog:

* scripts/.gitignore: Add tests_extractor.
* scripts/README: Document tests_extractor.d.
* scripts/tests_extractor.d: New file.

5 months agolibphobos: Organize druntime and phobos tests under common directory
Iain Buclaw [Tue, 25 Feb 2025 19:08:14 +0000 (20:08 +0100)] 
libphobos: Organize druntime and phobos tests under common directory

The druntime and druntime_shared tests are identical, save for one
compiled with `-static-libphobos' and the other `-shared-libphobos'.
Move them to libphobos.druntime/static and libphobos.druntime/shared
respectively.  This has also been done for libphobos.phobos.

libphobos/ChangeLog:

* testsuite/libphobos.druntime_shared/druntime_shared.exp: Move to...
* testsuite/libphobos.druntime/shared/druntime-shared.exp: ...here.
* testsuite/libphobos.druntime/druntime.exp: Move to...
* testsuite/libphobos.druntime/static/druntime-static.exp: ...here.
* testsuite/libphobos.phobos_shared/phobos_shared.exp: Move to...
* testsuite/libphobos.phobos/shared/phobos-shared.exp: ...here.
* testsuite/libphobos.phobos/phobos.exp: Move to...
* testsuite/libphobos.phobos/static/phobos-static.exp: ...here.

5 months agolibstdc++: [_Hashtable] Fix hash code cache usage when stateful hash functor
François Dumont [Sun, 16 Feb 2025 18:27:49 +0000 (19:27 +0100)] 
libstdc++: [_Hashtable] Fix hash code cache usage when stateful hash functor

It is wrong to reuse a cached hash code from another container when this code depends
on the state of the container's Hash functor.

Add checks that Hash functor is stateless before reusing the cached hash code.

libstdc++-v3/ChangeLog:

* include/bits/hashtable_policy.h
(_Hash_code_base::_M_copy_code, _Hash_code_base::_M_store_code): Remove.
* include/bits/hashtable.h (_M_hash_code_ext): New.
(_M_merge_multi(_Hashtable&)): Use latter.
(_M_copy_code): New.
(_M_assign): Use latter.
(_M_bucket_index_ex): New.
(_M_equals): Use latter.
(_M_store_code): New.
(_M_src_hash_code): Remove key_type parameter.
* testsuite/23_containers/unordered_map/modifiers/merge.cc (test10): New
test case.

5 months agodoc: update C++98 bootstrap note
Jason Merrill [Tue, 25 Feb 2025 20:13:34 +0000 (15:13 -0500)] 
doc: update C++98 bootstrap note

r10-11132 uses C++11 default member initializers, which breaks bootstrapping
with a C++98 compiler.

gcc/ChangeLog:

* doc/install.texi: 10.5 won't bootstrap with C++98.

5 months ago[PR115458][LRA]: Run split sub-pass more times
Vladimir N. Makarov [Tue, 25 Feb 2025 20:01:15 +0000 (15:01 -0500)] 
[PR115458][LRA]: Run split sub-pass more times

  In this PR case LRA needs to provide too many hard regs for insn
reloads, where some reload pseudos require 8 aligned regs for
themselves.  As the last attempt, LRA tries to split live ranges of
hard regs for insn reload pseudos.  It is a very rare case.  An
inheritance pseudo involving a reload pseudo of the insn can be
spilled in the assignment sub-pass run right after splitting and we need
to run split sub-pass for the inheritance pseudo now.

gcc/ChangeLog:

PR target/115458
* lra-int.h (LRA_MAX_FAILED_SPLITS): Define and check its value.
(lra_split_hard_reg_for): Change prototype.
* lra.cc (lra): Try to split hard reg range several times after a
failure.
* lra-assigns.cc (lra_split_hard_reg_for): Add an arg, a flag of
giving up.  Report asm error and nullify the asm insn depending on
the arg value.

gcc/testsuite/ChangeLog:

PR target/115458
* g++.target/riscv/pr115458.C: New.

5 months agopru: Fix pru_pragma_ctable_entry diagnostics [PR118991]
Jakub Jelinek [Tue, 25 Feb 2025 19:03:38 +0000 (20:03 +0100)] 
pru: Fix pru_pragma_ctable_entry diagnostics [PR118991]

HOST_WIDE_INT_PRINT* macros aren't supposed to be used in
gcc-internal-format format strings, we have the w modifier for HOST_WIDE_INT
in that case, the HOST_WIDE_INT_PRINT* macros might not work properly on
some hosts (e.g. mingw32 has HOST_LONG_LONG_FORMAT "I64" and that is
something pretty-print doesn't handle, while it handles "ll" for long long)
and also the use of macros in the middle of format strings breaks
translations (both that exgettext can't retrieve the string from there
and we get
 #: config/pru/pru-pragma.cc:61
 msgid "%<CTABLE_ENTRY%> index %"
 msgstr ""

 #: config/pru/pru-pragma.cc:64
 msgid "redefinition of %<CTABLE_ENTRY %"
 msgstr ""
in po/gcc.pot and also the macros are different on different hosts,
so even if exgettext extracted say "%<CTABLE_ENTRY%> index %lld is not valid"
it could be translated on some hosts but not e.g. mingw32).

So, the following patch just uses %wd instead.

Tested it before/after the
patch on
 #pragma ctable_entry 12 0x48040000
 #pragma ctable_entry 1024 0x48040000
 #pragma ctable_entry 12 0x48040001
and the result is the same.

2025-02-25  Jakub Jelinek  <jakub@redhat.com>

PR translation/118991
* config/pru/pru-pragma.cc (pru_pragma_ctable_entry): Use %wd
instead of %" HOST_WIDE_INT_PRINT "d to print a hwi in error.

5 months agolibstdc++: Implement LWG 4027 change to possibly-const-range [PR118083]
Patrick Palka [Tue, 25 Feb 2025 18:35:04 +0000 (13:35 -0500)] 
libstdc++: Implement LWG 4027 change to possibly-const-range [PR118083]

LWG 4027 effectively makes the const range access CPOs ranges::cfoo behave
more consistently across C++23 and C++20 (pre-P2278R4) and also more
consistently with the std::cfoo range accessors, as the below testcase
adjustments demonstrate (which mostly consist of reverting workarounds
added by r14-3771-gf12e26f3496275 and r13-7186-g0d94c6df183375).

In passing fix PR118083 which reports that the input_range constraint on
possibly-const-range is missing in our implementation.  A consequence of
this is that the const range access CPOs now consistently reject a non-range
argument, and so in some our of tests we need to introduce otherwise
unused begin/end members.

PR libstdc++/118083

libstdc++-v3/ChangeLog:

* include/bits/ranges_base.h
(ranges::__access::__possibly_const_range): Adjust logic as per
LWG 4027.  Add missing input_range constraint.
* testsuite/std/ranges/access/cbegin.cc (test05): Verify LWG
4027 testcases.
* testsuite/std/ranges/access/cdata.cc: Adjust, simplify and
consolidate some tests after the above.
* testsuite/std/ranges/access/cend.cc: Likewise.
* testsuite/std/ranges/access/crbegin.cc: Likewise.
* testsuite/std/ranges/access/crend.cc: Likewise.
* testsuite/std/ranges/adaptors/join.cc: Likewise.
* testsuite/std/ranges/adaptors/take_while.cc: Likewise.
* testsuite/std/ranges/adaptors/transform.cc: Likewise.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
5 months agolibphobos: Add scripts to update Makefile.am after an upstream merge
Iain Buclaw [Tue, 25 Feb 2025 17:58:27 +0000 (18:58 +0100)] 
libphobos: Add scripts to update Makefile.am after an upstream merge

These two scripts have been used for updating Makefile.am whenever
there's been a file added/removed from either Druntime or Phobos since
the start, but never included in the source tree.

libphobos/ChangeLog:

* libdruntime/Makefile.am: Update comment.
* libdruntime/Makefile.in: Regenerate.
* src/Makefile.am: Update comment.
* src/Makefile.in: Regenerate.
* scripts/.gitignore: New file.
* scripts/README: New file.
* scripts/gen_druntime_sources.d: New file.
* scripts/gen_phobos_sources.d: New file.

5 months agod/i386: Add CET TargetInfo key and predefined version [PR118654]
Iain Buclaw [Tue, 25 Feb 2025 17:01:09 +0000 (18:01 +0100)] 
d/i386: Add CET TargetInfo key and predefined version [PR118654]

Adds a new i386 d_target_info_spec entry to handle requests for
`__traits(getTargetInfo, "CET")', and add predefined target version
`GNU_CET' when the option `-fcf-protecton' is used.

Both TargetInfo key and predefined version have been added to the D
front-end documentation.

In the library, `GNU_CET' replaces the existing use of the user-defined
version flag `CET' when building libphobos.

PR d/118654

gcc/ChangeLog:

* config/i386/i386-d.cc (ix86_d_target_versions): Predefine GNU_CET.
(ix86_d_handle_target_cf_protection): New.
(ix86_d_register_target_info): Add 'CET' TargetInfo key.

gcc/d/ChangeLog:

* implement-d.texi: Document CET version and traits key.

libphobos/ChangeLog:

* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove CET_DFLAGS.
* libdruntime/Makefile.am: Replace CET_DFLAGS with CET_FLAGS.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/core/thread/fiber/package.d: Replace CET with GNU_CET.
* src/Makefile.am: Replace CET_DFLAGS with CET_FLAGS.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
* testsuite/testsuite_flags.in: Replace CET_DFLAGS with CET_FLAGS.

gcc/testsuite/ChangeLog:

* gdc.dg/target/i386/i386.exp: New test.
* gdc.dg/target/i386/targetinfo_CET.d: New test.

5 months agod: Increase max parallelism of the D testsuite
Iain Buclaw [Mon, 24 Feb 2025 18:57:15 +0000 (19:57 +0100)] 
d: Increase max parallelism of the D testsuite

It was noticed that when running the testsuite for gdc and libphobos in
parallel, this was capped at 10 simultaneous jobs each.  Increase this
limit to 128, which enables running for example `make check-d -j48` to
complete in half the time.

gcc/d/ChangeLog:

* Make-lang.in (check_gdc_parallelize): Increase to 128.

libphobos/ChangeLog:

* testsuite/Makefile.am (check_p_subno): Remove variable.
(check_p_subdirs): Increase default parallel slots to 128.
* testsuite/Makefile.in: Regenerate.

5 months agoFortran: Fix detection of descriptor arrays in coarray [PR107635]
Andre Vehreschild [Fri, 21 Feb 2025 13:06:28 +0000 (14:06 +0100)] 
Fortran: Fix detection of descriptor arrays in coarray [PR107635]

Look at the formal arguments generated type in the function declaration
to figure if an argument is a descriptor arrays.  Fix handling of class
types while splitting coarray expressions.

PR fortran/107635

gcc/fortran/ChangeLog:

* coarray.cc (fixup_comp_refs): For class types set correct
component (class) type.
(split_expr_at_caf_ref): Provide location.
* trans-intrinsic.cc (conv_caf_send_to_remote): Look at
generated formal argument and not declared one to detect
descriptor arrays.
(conv_caf_sendget): Same.

5 months agoFortran: Use correct size when transferring between images [PR107635]
Andre Vehreschild [Wed, 19 Feb 2025 08:04:47 +0000 (09:04 +0100)] 
Fortran: Use correct size when transferring between images [PR107635]

gcc/fortran/ChangeLog:

PR fortran/107635

* trans-intrinsic.cc (conv_caf_sendget): Use the size of data
transferred between the two images and not the descritor's size.

5 months agoopenmp: Mark OpenMP atomic write expression as read [PR119000]
Jakub Jelinek [Tue, 25 Feb 2025 08:33:21 +0000 (09:33 +0100)] 
openmp: Mark OpenMP atomic write expression as read [PR119000]

The following testcase was emitting false positive warning that
the rhs of #pragma omp atomic write was stored but not read,
when the atomic actually does read it.  The following patch
fixes that by calling default_function_array_read_conversion
on it, so that it is marked as read as well as converted from
lvalue to rvalue.
Furthermore, the code had
if (code == NOP_EXPR) ... else ... if (code == NOP_EXPR) ...
with none of ... parts changing code, so I've merged the two ifs.

2025-02-25  Jakub Jelinek  <jakub@redhat.com>

PR c/119000
* c-parser.cc (c_parser_omp_atomic): For omp write call
default_function_array_read_conversion on the rhs expression.
Merge the two adjacent if (code == NOP_EXPR) blocks.

* c-c++-common/gomp/pr119000.c: New test.

5 months agoopenmp: Fix handling of declare target statics with array type which need destruction...
Jakub Jelinek [Tue, 25 Feb 2025 08:29:39 +0000 (09:29 +0100)] 
openmp: Fix handling of declare target statics with array type which need destruction [PR118876]

The following testcase ICEs because it attempts to emit the __tcfa function twice,
once when handling the host destruction and once when handling nohost destruction.

This patch fixes it by using __omp_tcfa function for the nohost case and marks it
with the needed "omp declare target" and "omp declare target nohost" attributes.

2025-02-25  Jakub Jelinek  <jakub@redhat.com>

PR c++/118876
* cp-tree.h (register_dtor_fn): Add a bool argument defaulted to false.
* decl.cc (start_cleanup_fn): Add OMP_TARGET argument, use
"__omp_tcf" prefix rather than "__tcf" in that case.  Add
"omp declare target" and "omp declare target nohost" attributes
to the fndecl.
(register_dtor_fn): Add OMP_TARGET argument, pass it down to
start_cleanup_fn.
* decl2.cc (one_static_initialization_or_destruction): Add OMP_TARGET
argument, pass it down to register_dtor_fn.
(emit_partial_init_fini_fn): Pass omp_target to
one_static_initialization_or_destruction.
(handle_tls_init): Pass false to
one_static_initialization_or_destruction.

* g++.dg/gomp/pr118876.C: New test.

5 months agoc++: Fix range for with PMFs [PR118923]
Jakub Jelinek [Tue, 25 Feb 2025 08:26:46 +0000 (09:26 +0100)] 
c++: Fix range for with PMFs [PR118923]

The following testcases segfault because the new range for -frange-for-ext-temps
temporary extension extends even the internal TARGET_EXPRs created by
get_member_function_from_ptrfunc.

The following patch fixes that by using get_internal_target_expr for those
instead of force_target_expr (similarly in cp_finish_decl and
build_comparison_op) and using force_target_expr inside of
get_internal_target_expr.

2025-02-25  Jakub Jelinek  <jakub@redhat.com>

PR c++/118923
* tree.cc (get_internal_target_expr): Use force_target_expr
instead of build_target_expr_with_type.
* typeck.cc (get_member_function_from_ptrfunc): Use
get_internal_target_expr instead of force_target_expr.
* decl.cc (cp_finish_decl): Likewise.
* method.cc (build_comparison_op): Likewise.

* g++.dg/cpp0x/pr118923.C: New test.
* g++.dg/cpp1y/pr118923.C: New test.

5 months agoDaily bump.
GCC Administrator [Tue, 25 Feb 2025 00:17:52 +0000 (00:17 +0000)] 
Daily bump.

5 months agoRISC-V: Include pattern stmts for dynamic LMUL computation [PR114516].
Robin Dapp [Fri, 21 Feb 2025 16:08:16 +0000 (17:08 +0100)] 
RISC-V: Include pattern stmts for dynamic LMUL computation [PR114516].

When scanning for program points, i.e. vector statements, we're missing
pattern statements.  In PR114516 this becomes obvious as we choose
LMUL=8 assuming there are only three statements but the divmod pattern
adds another three.  Those push us beyond four registers so we need to
switch to LMUL=4.

This patch adds pattern statements to the program points which helps
calculate a better register pressure estimate.

PR target/114516

gcc/ChangeLog:

* config/riscv/riscv-vector-costs.cc (compute_estimated_lmul):
Add pattern statements to program points.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/pr114516.c: New test.

5 months agovect: Use original LHS type for gather pattern [PR118950].
Robin Dapp [Fri, 21 Feb 2025 06:19:40 +0000 (07:19 +0100)] 
vect: Use original LHS type for gather pattern [PR118950].

In PR118950 we do not zero masked elements in a gather load.
While recognizing a gather/scatter pattern we do not use the original
type of the LHS.  This matters because the type can differ with bool
patterns (e.g. _Bool vs unsigned char) and we don't notice the need
for zeroing out the padding bytes.

This patch just uses the original LHS's type.

PR middle-end/118950

gcc/ChangeLog:

* tree-vect-patterns.cc (vect_recog_gather_scatter_pattern): Use
original LHS's type.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr118950.c: New test.

5 months agoreassoc: Fix up optimize_range_tests_to_bit_test [PR118915]
Jakub Jelinek [Mon, 24 Feb 2025 11:19:16 +0000 (12:19 +0100)] 
reassoc: Fix up optimize_range_tests_to_bit_test [PR118915]

The following testcase is miscompiled due to a bug in
optimize_range_tests_to_bit_test.  It is trying to optimize
check for a in [-34,-34] or [-26,-26] or [-6,-6] or [-4,inf] ranges.
Another reassoc optimization folds the the test for the first
two ranges into (a + 34U) & ~8U in [0U,0U] range, and extract_bit_test_mask
actually has code to virtually undo it and treat that again as test
for a being -34 or -26.  The problem is that optimize_range_tests_to_bit_test
remembers in the type variable TREE_TYPE (ranges[i].exp); from the first
range.  If extract_bit_test_mask doesn't do that virtual undoing of the
BIT_AND_EXPR handling, that is just fine, the returned exp is ranges[i].exp.
But if the first range is BIT_AND_EXPR, the type could be different, the
BIT_AND_EXPR form has the optional cast to corresponding unsigned type
in order to avoid introducing UB.  Now, type was used to fill in the
max value if ranges[j].high was missing in subsequently tested range,
and so in this particular testcase the [-4,inf] range which was
signed int and so [-4,INT_MAX] was treated as [-4,UINT_MAX] instead.
And we were subtracting values of 2 different types and trying to make
sense out of that.

The following patch fixes this by using the type of the low bound
(which is always non-NULL) for the max value of the high bound instead.

2025-02-24  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/118915
* tree-ssa-reassoc.cc (optimize_range_tests_to_bit_test): For
highj == NULL_TREE use TYPE_MAX_VALUE (TREE_TYPE (lowj)) rather
than TYPE_MAX_VALUE (type).

* gcc.c-torture/execute/pr118915.c: New test.

5 months agotree-optimization/118973 - stray abnormal edge after DCE
Richard Biener [Mon, 24 Feb 2025 08:45:28 +0000 (09:45 +0100)] 
tree-optimization/118973 - stray abnormal edge after DCE

DCE preserves stmts performing abnormal control flow transfer but
currently has an exception for replaceable allocations and cxa_atexit
calls.  That results in a broken CFG since DCE isn't set up to prune
abnormal edges possibly hanging off those.

While we could try to add this handling, the following is the safe
fix at this point and more suitable for backporting.

PR tree-optimization/118973
* tree-ssa-dce.cc (mark_stmt_if_obviously_necessary): Calls
that alter control flow in unpredictable ways need to be
preserved.

* g++.dg/torture/pr118973.C: New testcase.

5 months agoopenmp: Fix diagnostics typo [PR118993]
Jakub Jelinek [Mon, 24 Feb 2025 08:25:34 +0000 (09:25 +0100)] 
openmp: Fix diagnostics typo [PR118993]

There is a typo in one of the OpenMP gimplification diagnostics messages.
The following patch fixes that and adjusts tests which just copied that
message including typo to dg-warning regexps in 2 tests.

2025-02-24  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/118993
* gimplify.cc (gimplify_scan_omp_clauses): Fix diagnostics typo,
undfined -> undefined.

* c-c++-common/gomp/allocate-18.c: Adjust dg-warning regex for
diagnostics typo fix.
* gfortran.dg/gomp/allocate-clause.f90: Likewise.

5 months agoUse nonnull_if_nonzero attribute rather than nonnull on various builtins [PR117023]
Jakub Jelinek [Mon, 24 Feb 2025 08:20:47 +0000 (09:20 +0100)] 
Use nonnull_if_nonzero attribute rather than nonnull on various builtins [PR117023]

On top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668699.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668700.html
patches the following patch adds nonnull_if_nonzero attribute(s) to
various builtins instead of or in addition to nonnull attribute.

The patch adjusts builtins (when we have them) corresponding to the APIs
mentioned in the C2Y N3322 paper:
1) strndup and memset get one nonnull_if_nonzero attribute instead of
   nonnull
2) memcpy, memmove, strncpy, memcmp, strncmp get two nonnull_if_nonzero
   attributes instead of nonnull
3) strncat has nonnull without argument changed to nonnull (1) and
   gets one nonnull_if_nonzero for the src argument (maybe it needs
   to be clarified in C2Y, but I really think first argument to strncat
   and wcsncat shouldn't be NULL even for n == 0, because NULL doesn't
   point to NULL terminated string and one can't append anything to it;
   and various implementations in the wild including glibc will crash
   with NULL first argument (x86_64 avx+ doesn't though)

Such changes are done also to the _chk suffixed counterparts of the
builtins.

Furthermore I've changed a couple of builtins for POSIX functions which
aren't covered by ISO C, but I'd expect if/when POSIX incorporates C2Y
it would do the same changes.  In particular

4) strnlen gets one nonnull_if_nonzero instead of nonnull
5) mempcpy and stpncpy get two nonnull_if_nonzero instead of nonnull
   and lose returns_nonnull attribute; this is kind of unfortunate
   but I think in the spirit of N3322 mempcpy (NULL, src, 0) should
   return NULL (i.e. dest + n aka NULL + 0, now valid) and it is hard to
   express returns non-NULL if first argument is non-NULL or third argument
   is non-zero

I'm not really sure about fread/fwrite, N3322 doesn't mention those,
can the first argument be NULL if third argument is 0?  What about
if second argument is 0?  Can the fourth argument be NULL in such cases?

And of course, when not using builtins the glibc headers will affect stuff
too, so we'll need to wait for N3322 implementation there too (possibly
by dropping the nonnull attributes and perhaps conditionally replacing them
with this new one if the compiler supports them).

2025-02-24  Jakub Jelinek  <jakub@redhat.com>

PR c/117023
gcc/
* builtin-attrs.def (ATTR_NONNULL_IF_NONZERO): New DEF_ATTR_IDENT.
(ATTR_NOTHROW_NONNULL_IF12_LEAF, ATTR_NOTHROW_NONNULL_IF13_LEAF,
ATTR_NOTHROW_NONNULL_IF123_LEAF, ATTR_NOTHROW_NONNULL_IF23_LEAF,
ATTR_NOTHROW_NONNULL_1_IF23_LEAF, ATTR_PURE_NOTHROW_NONNULL_IF12_LEAF,
ATTR_PURE_NOTHROW_NONNULL_IF13_LEAF,
ATTR_PURE_NOTHROW_NONNULL_IF123_LEAF,
ATTR_WARN_UNUSED_RESULT_NOTHROW_NONNULL_IF12_LEAF,
ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL_IF12_LEAF): New
DEF_ATTR_TREE_LIST.
* builtins.def (BUILT_IN_STRNDUP): Use
ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL_IF12_LEAF instead of
ATTR_MALLOC_WARN_UNUSED_RESULT_NOTHROW_NONNULL_LEAF.
(BUILT_IN_STRNCAT, BUILT_IN_STRNCAT_CHK): Use
ATTR_NOTHROW_NONNULL_1_IF23_LEAF instead of ATTR_NOTHROW_NONNULL_LEAF.
(BUILT_IN_BCOPY, BUILT_IN_MEMCPY, BUILT_IN_MEMCPY_CHK,
BUILT_IN_MEMMOVE, BUILT_IN_MEMMOVE_CHK,  BUILT_IN_STRNCPY,
BUILT_IN_STRNCPY_CHK): Use ATTR_NOTHROW_NONNULL_IF123_LEAF instead of
ATTR_NOTHROW_NONNULL_LEAF.
(BUILT_IN_MEMPCPY, BUILT_IN_MEMPCPY_CHK, BUILT_IN_STPNCPY,
BUILT_IN_STPNCPY_CHK): Use ATTR_NOTHROW_NONNULL_IF123_LEAF instead of
ATTR_RETNONNULL_NOTHROW_LEAF.
(BUILT_IN_BZERO, BUILT_IN_MEMSET, BUILT_IN_MEMSET_CHK): Use
ATTR_NOTHROW_NONNULL_IF13_LEAF instead of ATTR_NOTHROW_NONNULL_LEAF.
(BUILT_IN_BCMP, BUILT_IN_MEMCMP, BUILT_IN_STRNCASECMP,
BUILT_IN_STRNCMP): Use ATTR_PURE_NOTHROW_NONNULL_IF123_LEAF instead of
ATTR_PURE_NOTHROW_NONNULL_LEAF.
(BUILT_IN_STRNLEN): Use ATTR_PURE_NOTHROW_NONNULL_IF12_LEAF instead of
ATTR_PURE_NOTHROW_NONNULL_LEAF.
(BUILT_IN_MEMCHR): Use ATTR_PURE_NOTHROW_NONNULL_IF13_LEAF instead of
ATTR_PURE_NOTHROW_NONNULL_LEAF.
gcc/testsuite/
* gcc.dg/builtins-nonnull.c (test_memfuncs, test_memfuncs_chk,
test_strfuncs, test_strfuncs_chk): Add if (n == 0) return; at the
start of the functions.
* gcc.dg/Wnonnull-2.c: Copy __builtin_* call statements where
appropriate 3 times, once with 0 length, once with n and once with
non-zero constant and expect warning only in the third case.
Formatting fixes.
* gcc.dg/Wnonnull-3.c: Copy __builtin_* call statements where
appropriate 3 times, once with 0 length, once with n and once with
n guarded with n != 0 and expect warning only in the third case.
Formatting fixes.
* gcc.dg/nonnull-3.c (foo): Use 16 instead of 0 in the calls added
for PR80936.
* gcc.dg/nonnull-11.c: New test.
* c-c++-common/ubsan/nonnull-1.c: Don't expect runtime diagnostics
for the __builtin_memcpy call.
* gcc.dg/tree-ssa/pr78154.c (f): Add dn argument and return early
if it is NULL.  Duplicate cases of builtins which have the first
argument changed from nonnull to nonnull_if_nonzero except stpncpy,
once with dn as first argument instead of d and once with constant
non-zero count rather than n.  Disable the stpncpy non-null check.
* gcc.dg/Wbuiltin-declaration-mismatch-14.c (test_builtin_calls):
Triplicate the strncmp calls, once with 1 last argument and expect
warning, once with n last argument and don't expect warning and
once with 0 last argument and don't expect warning.
* gcc.dg/Wbuiltin-declaration-mismatch-15.c (test_builtin_calls_fe):
Likewise.

5 months agoanalyzer: Handle nonnull_if_nonzero attribute [PR117023]
Jakub Jelinek [Mon, 24 Feb 2025 08:18:27 +0000 (09:18 +0100)] 
analyzer: Handle nonnull_if_nonzero attribute [PR117023]

On top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html
patch which introduces the nonnull_if_nonzero attribute (because
C2Y is allowing NULL arguments on various calls like memcpy, memset,
strncpy etc. as long as the count is 0) the following patch adds just
limited handling of the attribute in the analyzer.

For nonnull attribute(s) we have the get_nonnull_args helper which
returns a bitmap, for nonnull_if_nonzero a function would need to
return a hash_map or something similar, I think it is better to
handle the attributes one by one.  This patch just handles the
non-zero INTEGER_CST (integer_nonzerop) count arguments, in other places
the above patch uses ranger to some extent, but I'm not familiar enough
with the analyzer to know if one can use the ranger, or should somehow
explain in data structures the conditional nature of the nonnull property,
the argument is nonnull only if some other argument is nonzero.

Also, analyzer uses get_nonnull_args in another spot when entering a frame,
not sure if anything can be done there (note the conditional nonnull
somehow, pass from callers if the argument is nonzero, ...).

Note, the testsuite changes aren't strictly necessary with just
the above and this patch, but will be with a patch I'm going to post
soon.

2025-02-24  Jakub Jelinek  <jakub@redhat.com>

PR c/117023
gcc/analyzer/
* sm-malloc.cc (malloc_state_machine::handle_nonnull): New private
method.
(malloc_state_machine::on_stmt): Use it for nonnull attribute arguments.
Handle also nonnull_if_nonzero attributes.
gcc/testsuite/
* c-c++-common/analyzer/call-summaries-malloc.c
(test_use_without_check): Pass 4 rather than sz to memset.
* c-c++-common/analyzer/strncpy-1.c (test_null_dst,
test_null_src): Pass 42 rather than count to strncpy.

5 months agoRISC-V: Fix .cfi_offset directive when push/pop in zcmp
Lino Hsing-Yu Peng [Thu, 20 Feb 2025 09:09:22 +0000 (17:09 +0800)] 
RISC-V: Fix .cfi_offset directive when push/pop in zcmp

The incorrect cfi directive info breaks stack unwind in try/catch/cxa.

Before patch:
  cm.push {ra, s0-s2}, -16
  .cfi_offset 1, -12
  .cfi_offset 8, -8
  .cfi_offset 18, -4

After patch:
  cm.push {ra, s0-s2}, -16
  .cfi_offset 1, -16
  .cfi_offset 8, -12
  .cfi_offset 9, -8
  .cfi_offset 18, -4

gcc/ChangeLog:

* config/riscv/riscv.cc: Set multi push regs bits.

gcc/testsuite/ChangeLog:
* gcc.target/riscv/zcmp_push_gpr.c: New test.

5 months agoDaily bump.
GCC Administrator [Mon, 24 Feb 2025 00:17:12 +0000 (00:17 +0000)] 
Daily bump.

5 months agox86: Add tests for PR tree-optimization/82142
H.J. Lu [Sun, 23 Feb 2025 21:44:40 +0000 (05:44 +0800)] 
x86: Add tests for PR tree-optimization/82142

Verify that PR tree-optimization/82142 testcase is properly optimized.

PR tree-optimization/82142
* gcc.target/i386/pr82142a.c: New file.
* gcc.target/i386/pr82142b.c: Likewise.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
5 months agoDaily bump.
GCC Administrator [Sun, 23 Feb 2025 00:17:00 +0000 (00:17 +0000)] 
Daily bump.

5 months agolibstdc++: Fix bootstrap failure with --enable-vtable-verify [PR118981]
Jonathan Wakely [Sat, 22 Feb 2025 21:02:29 +0000 (21:02 +0000)] 
libstdc++: Fix bootstrap failure with --enable-vtable-verify [PR118981]

The compiler emits code with init_priority(99) for -fvtable-verify=std
and that creates a section conflict with the uses of init_priority(99)
that I recently added to src/c++20/tzdb.cc.

Change tzdb.cc to use a different priority to avoid the conflict.

libstdc++-v3/ChangeLog:

PR c++/118981
* src/c++20/tzdb.cc: Use init_priority(98) instead of
init_priority(99).

5 months agoTurn test cases into UNSUPPORTED if running into 'sorry, unimplemented: dynamic stack...
Thomas Schwinge [Fri, 21 Feb 2025 10:21:08 +0000 (11:21 +0100)] 
Turn test cases into UNSUPPORTED if running into 'sorry, unimplemented: dynamic stack allocation not supported'

In Subversion r217296 (Git commit e2acc079ff125a869159be45371dc0a29b230e92)
"Testsuite alloca fixes for ptx", effective-target 'alloca' was added to mark
up test cases that run into the nvptx back end's non-support of dynamic stack
allocation.  (Later, nvptx gained conditional support for that in
commit 3861d362ec7e3c50742fc43833fe9d8674f4070e
"nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181]", but on the
other hand, in commit f93a612fc4567652b75ffc916d31a446378e6613
"bpf: liberate R9 for general register allocation", the BPF back end joined
"the list of targets that do not support alloca in target-support.exp".

Manually maintaining the list of test cases requiring effective-target 'alloca'
is notoriously hard, gets out of date quickly: new test cases added to the test
suite may need to be analyzed and annotated, and over time annotations also may
need to be removed, in cases where the compiler learns to optimize out
'alloca'/VLA usage, for example.  This commit replaces (99 % of) the manual
annotations with an automatic scheme: turn test cases into UNSUPPORTED if
running into 'sorry, unimplemented: dynamic stack allocation not supported'.

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_alloca):
Gracefully handle the case that we've not be called (indirectly)
from 'dg-test'.
* lib/gcc-dg.exp (proc gcc-dg-prune): Turn
'sorry, unimplemented: dynamic stack allocation not supported' into
UNSUPPORTED.
* c-c++-common/Walloca-larger-than.c: Don't
'dg-require-effective-target alloca'.
* c-c++-common/Warray-bounds-9.c: Likewise.
* c-c++-common/Warray-bounds.c: Likewise.
* c-c++-common/Wdangling-pointer-2.c: Likewise.
* c-c++-common/Wdangling-pointer-4.c: Likewise.
* c-c++-common/Wdangling-pointer-5.c: Likewise.
* c-c++-common/Wdangling-pointer.c: Likewise.
* c-c++-common/Wimplicit-fallthrough-7.c: Likewise.
* c-c++-common/Wsizeof-pointer-memaccess1.c: Likewise.
* c-c++-common/Wsizeof-pointer-memaccess2.c: Likewise.
* c-c++-common/Wstringop-truncation.c: Likewise.
* c-c++-common/Wunused-var-6.c: Likewise.
* c-c++-common/Wunused-var-8.c: Likewise.
* c-c++-common/analyzer/alloca-leak.c: Likewise.
* c-c++-common/analyzer/allocation-size-multiline-2.c: Likewise.
* c-c++-common/analyzer/allocation-size-multiline-3.c: Likewise.
* c-c++-common/analyzer/capacity-1.c: Likewise.
* c-c++-common/analyzer/capacity-3.c: Likewise.
* c-c++-common/analyzer/imprecise-floating-point-1.c: Likewise.
* c-c++-common/analyzer/infinite-recursion-alloca.c: Likewise.
* c-c++-common/analyzer/malloc-callbacks.c: Likewise.
* c-c++-common/analyzer/malloc-paths-8.c: Likewise.
* c-c++-common/analyzer/out-of-bounds-5.c: Likewise.
* c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise.
* c-c++-common/analyzer/uninit-alloca.c: Likewise.
* c-c++-common/analyzer/write-to-string-literal-5.c: Likewise.
* c-c++-common/asan/alloca_loop_unpoisoning.c: Likewise.
* c-c++-common/auto-init-11.c: Likewise.
* c-c++-common/auto-init-12.c: Likewise.
* c-c++-common/auto-init-15.c: Likewise.
* c-c++-common/auto-init-16.c: Likewise.
* c-c++-common/builtins.c: Likewise.
* c-c++-common/dwarf2/vla1.c: Likewise.
* c-c++-common/gomp/pr61486-2.c: Likewise.
* c-c++-common/torture/builtin-clear-padding-4.c: Likewise.
* c-c++-common/torture/strub-run3.c: Likewise.
* c-c++-common/torture/strub-run4.c: Likewise.
* c-c++-common/torture/strub-run4c.c: Likewise.
* c-c++-common/torture/strub-run4d.c: Likewise.
* c-c++-common/torture/strub-run4i.c: Likewise.
* g++.dg/Walloca1.C: Likewise.
* g++.dg/Walloca2.C: Likewise.
* g++.dg/cpp0x/pr70338.C: Likewise.
* g++.dg/cpp1y/lambda-generic-vla1.C: Likewise.
* g++.dg/cpp1y/vla10.C: Likewise.
* g++.dg/cpp1y/vla2.C: Likewise.
* g++.dg/cpp1y/vla6.C: Likewise.
* g++.dg/cpp1y/vla8.C: Likewise.
* g++.dg/debug/debug5.C: Likewise.
* g++.dg/debug/debug6.C: Likewise.
* g++.dg/debug/pr54828.C: Likewise.
* g++.dg/diagnostic/pr70105.C: Likewise.
* g++.dg/eh/cleanup5.C: Likewise.
* g++.dg/eh/spbp.C: Likewise.
* g++.dg/ext/builtin_alloca.C: Likewise.
* g++.dg/ext/tmplattr9.C: Likewise.
* g++.dg/ext/vla10.C: Likewise.
* g++.dg/ext/vla11.C: Likewise.
* g++.dg/ext/vla12.C: Likewise.
* g++.dg/ext/vla15.C: Likewise.
* g++.dg/ext/vla16.C: Likewise.
* g++.dg/ext/vla17.C: Likewise.
* g++.dg/ext/vla23.C: Likewise.
* g++.dg/ext/vla3.C: Likewise.
* g++.dg/ext/vla6.C: Likewise.
* g++.dg/ext/vla7.C: Likewise.
* g++.dg/init/array24.C: Likewise.
* g++.dg/init/new47.C: Likewise.
* g++.dg/init/pr55497.C: Likewise.
* g++.dg/opt/pr78201.C: Likewise.
* g++.dg/template/vla2.C: Likewise.
* g++.dg/torture/Wsizeof-pointer-memaccess1.C: Likewise.
* g++.dg/torture/Wsizeof-pointer-memaccess2.C: Likewise.
* g++.dg/torture/pr62127.C: Likewise.
* g++.dg/torture/pr67055.C: Likewise.
* g++.dg/torture/stackalign/eh-alloca-1.C: Likewise.
* g++.dg/torture/stackalign/eh-inline-2.C: Likewise.
* g++.dg/torture/stackalign/eh-vararg-1.C: Likewise.
* g++.dg/torture/stackalign/eh-vararg-2.C: Likewise.
* g++.dg/warn/Wplacement-new-size-5.C: Likewise.
* g++.dg/warn/Wsizeof-pointer-memaccess-1.C: Likewise.
* g++.dg/warn/Wvla-1.C: Likewise.
* g++.dg/warn/Wvla-3.C: Likewise.
* g++.old-deja/g++.ext/array2.C: Likewise.
* g++.old-deja/g++.ext/constructor.C: Likewise.
* g++.old-deja/g++.law/builtin1.C: Likewise.
* g++.old-deja/g++.other/crash12.C: Likewise.
* g++.old-deja/g++.other/eh3.C: Likewise.
* g++.old-deja/g++.pt/array6.C: Likewise.
* g++.old-deja/g++.pt/dynarray.C: Likewise.
* gcc.c-torture/compile/20000923-1.c: Likewise.
* gcc.c-torture/compile/20030224-1.c: Likewise.
* gcc.c-torture/compile/20071108-1.c: Likewise.
* gcc.c-torture/compile/20071117-1.c: Likewise.
* gcc.c-torture/compile/900313-1.c: Likewise.
* gcc.c-torture/compile/parms.c: Likewise.
* gcc.c-torture/compile/pr17397.c: Likewise.
* gcc.c-torture/compile/pr35006.c: Likewise.
* gcc.c-torture/compile/pr42956.c: Likewise.
* gcc.c-torture/compile/pr51354.c: Likewise.
* gcc.c-torture/compile/pr52714.c: Likewise.
* gcc.c-torture/compile/pr55851.c: Likewise.
* gcc.c-torture/compile/pr77754-1.c: Likewise.
* gcc.c-torture/compile/pr77754-2.c: Likewise.
* gcc.c-torture/compile/pr77754-3.c: Likewise.
* gcc.c-torture/compile/pr77754-4.c: Likewise.
* gcc.c-torture/compile/pr77754-5.c: Likewise.
* gcc.c-torture/compile/pr77754-6.c: Likewise.
* gcc.c-torture/compile/pr78439.c: Likewise.
* gcc.c-torture/compile/pr79413.c: Likewise.
* gcc.c-torture/compile/pr82564.c: Likewise.
* gcc.c-torture/compile/pr87110.c: Likewise.
* gcc.c-torture/compile/pr99787-1.c: Likewise.
* gcc.c-torture/compile/vla-const-1.c: Likewise.
* gcc.c-torture/compile/vla-const-2.c: Likewise.
* gcc.c-torture/execute/20010209-1.c: Likewise.
* gcc.c-torture/execute/20020314-1.c: Likewise.
* gcc.c-torture/execute/20020412-1.c: Likewise.
* gcc.c-torture/execute/20021113-1.c: Likewise.
* gcc.c-torture/execute/20040223-1.c: Likewise.
* gcc.c-torture/execute/20040308-1.c: Likewise.
* gcc.c-torture/execute/20040811-1.c: Likewise.
* gcc.c-torture/execute/20070824-1.c: Likewise.
* gcc.c-torture/execute/20070919-1.c: Likewise.
* gcc.c-torture/execute/built-in-setjmp.c: Likewise.
* gcc.c-torture/execute/pr22061-1.c: Likewise.
* gcc.c-torture/execute/pr43220.c: Likewise.
* gcc.c-torture/execute/pr82210.c: Likewise.
* gcc.c-torture/execute/pr86528.c: Likewise.
* gcc.c-torture/execute/vla-dealloc-1.c: Likewise.
* gcc.dg/20001012-2.c: Likewise.
* gcc.dg/20020415-1.c: Likewise.
* gcc.dg/20030331-2.c: Likewise.
* gcc.dg/20101010-1.c: Likewise.
* gcc.dg/Walloca-1.c: Likewise.
* gcc.dg/Walloca-10.c: Likewise.
* gcc.dg/Walloca-11.c: Likewise.
* gcc.dg/Walloca-12.c: Likewise.
* gcc.dg/Walloca-13.c: Likewise.
* gcc.dg/Walloca-14.c: Likewise.
* gcc.dg/Walloca-15.c: Likewise.
* gcc.dg/Walloca-2.c: Likewise.
* gcc.dg/Walloca-3.c: Likewise.
* gcc.dg/Walloca-4.c: Likewise.
* gcc.dg/Walloca-5.c: Likewise.
* gcc.dg/Walloca-6.c: Likewise.
* gcc.dg/Walloca-7.c: Likewise.
* gcc.dg/Walloca-8.c: Likewise.
* gcc.dg/Walloca-9.c: Likewise.
* gcc.dg/Walloca-larger-than-2.c: Likewise.
* gcc.dg/Walloca-larger-than-3.c: Likewise.
* gcc.dg/Walloca-larger-than-4.c: Likewise.
* gcc.dg/Walloca-larger-than.c: Likewise.
* gcc.dg/Warray-bounds-22.c: Likewise.
* gcc.dg/Warray-bounds-41.c: Likewise.
* gcc.dg/Warray-bounds-46.c: Likewise.
* gcc.dg/Warray-bounds-48-novec.c: Likewise.
* gcc.dg/Warray-bounds-48.c: Likewise.
* gcc.dg/Warray-bounds-50.c: Likewise.
* gcc.dg/Warray-bounds-63.c: Likewise.
* gcc.dg/Warray-bounds-66.c: Likewise.
* gcc.dg/Wdangling-pointer.c: Likewise.
* gcc.dg/Wfree-nonheap-object-2.c: Likewise.
* gcc.dg/Wfree-nonheap-object.c: Likewise.
* gcc.dg/Wrestrict-17.c: Likewise.
* gcc.dg/Wrestrict.c: Likewise.
* gcc.dg/Wreturn-local-addr-2.c: Likewise.
* gcc.dg/Wreturn-local-addr-3.c: Likewise.
* gcc.dg/Wreturn-local-addr-4.c: Likewise.
* gcc.dg/Wreturn-local-addr-6.c: Likewise.
* gcc.dg/Wsizeof-pointer-memaccess1.c: Likewise.
* gcc.dg/Wstack-usage.c: Likewise.
* gcc.dg/Wstrict-aliasing-bogus-vla-1.c: Likewise.
* gcc.dg/Wstrict-overflow-27.c: Likewise.
* gcc.dg/Wstringop-overflow-15.c: Likewise.
* gcc.dg/Wstringop-overflow-23.c: Likewise.
* gcc.dg/Wstringop-overflow-25.c: Likewise.
* gcc.dg/Wstringop-overflow-27.c: Likewise.
* gcc.dg/Wstringop-overflow-3.c: Likewise.
* gcc.dg/Wstringop-overflow-39.c: Likewise.
* gcc.dg/Wstringop-overflow-56.c: Likewise.
* gcc.dg/Wstringop-overflow-57.c: Likewise.
* gcc.dg/Wstringop-overflow-67.c: Likewise.
* gcc.dg/Wstringop-overflow-71.c: Likewise.
* gcc.dg/Wstringop-truncation-3.c: Likewise.
* gcc.dg/Wvla-larger-than-1.c: Likewise.
* gcc.dg/Wvla-larger-than-2.c: Likewise.
* gcc.dg/Wvla-larger-than-3.c: Likewise.
* gcc.dg/Wvla-larger-than-4.c: Likewise.
* gcc.dg/Wvla-larger-than-5.c: Likewise.
* gcc.dg/analyzer/boxed-malloc-1.c: Likewise.
* gcc.dg/analyzer/call-summaries-2.c: Likewise.
* gcc.dg/analyzer/malloc-1.c: Likewise.
* gcc.dg/analyzer/malloc-reuse.c: Likewise.
* gcc.dg/analyzer/out-of-bounds-diagram-12.c: Likewise.
* gcc.dg/analyzer/pr93355-localealias.c: Likewise.
* gcc.dg/analyzer/putenv-1.c: Likewise.
* gcc.dg/analyzer/taint-alloc-1.c: Likewise.
* gcc.dg/analyzer/torture/pr93373.c: Likewise.
* gcc.dg/analyzer/torture/ubsan-1.c: Likewise.
* gcc.dg/analyzer/vla-1.c: Likewise.
* gcc.dg/atomic/stdatomic-vm.c: Likewise.
* gcc.dg/attr-alloc_size-6.c: Likewise.
* gcc.dg/attr-alloc_size-7.c: Likewise.
* gcc.dg/attr-alloc_size-8.c: Likewise.
* gcc.dg/attr-alloc_size-9.c: Likewise.
* gcc.dg/attr-noipa.c: Likewise.
* gcc.dg/auto-init-uninit-36.c: Likewise.
* gcc.dg/auto-init-uninit-9.c: Likewise.
* gcc.dg/auto-type-1.c: Likewise.
* gcc.dg/builtin-alloc-size.c: Likewise.
* gcc.dg/builtin-dynamic-alloc-size.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-1.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-2.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-3.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-4.c: Likewise.
* gcc.dg/builtin-object-size-1.c: Likewise.
* gcc.dg/builtin-object-size-2.c: Likewise.
* gcc.dg/builtin-object-size-3.c: Likewise.
* gcc.dg/builtin-object-size-4.c: Likewise.
* gcc.dg/builtins-64.c: Likewise.
* gcc.dg/builtins-68.c: Likewise.
* gcc.dg/c23-auto-2.c: Likewise.
* gcc.dg/c99-const-expr-13.c: Likewise.
* gcc.dg/c99-vla-1.c: Likewise.
* gcc.dg/fold-alloca-1.c: Likewise.
* gcc.dg/gomp/pr30494.c: Likewise.
* gcc.dg/gomp/vla-2.c: Likewise.
* gcc.dg/gomp/vla-3.c: Likewise.
* gcc.dg/gomp/vla-4.c: Likewise.
* gcc.dg/gomp/vla-5.c: Likewise.
* gcc.dg/graphite/pr99085.c: Likewise.
* gcc.dg/guality/guality.c: Likewise.
* gcc.dg/lto/pr80778_0.c: Likewise.
* gcc.dg/nested-func-10.c: Likewise.
* gcc.dg/nested-func-12.c: Likewise.
* gcc.dg/nested-func-13.c: Likewise.
* gcc.dg/nested-func-14.c: Likewise.
* gcc.dg/nested-func-15.c: Likewise.
* gcc.dg/nested-func-16.c: Likewise.
* gcc.dg/nested-func-17.c: Likewise.
* gcc.dg/nested-func-9.c: Likewise.
* gcc.dg/packed-vla.c: Likewise.
* gcc.dg/pr100225.c: Likewise.
* gcc.dg/pr25682.c: Likewise.
* gcc.dg/pr27301.c: Likewise.
* gcc.dg/pr31507-1.c: Likewise.
* gcc.dg/pr33238.c: Likewise.
* gcc.dg/pr41470.c: Likewise.
* gcc.dg/pr49120.c: Likewise.
* gcc.dg/pr50764.c: Likewise.
* gcc.dg/pr51491-2.c: Likewise.
* gcc.dg/pr51990-2.c: Likewise.
* gcc.dg/pr51990.c: Likewise.
* gcc.dg/pr59011.c: Likewise.
* gcc.dg/pr59523.c: Likewise.
* gcc.dg/pr61561.c: Likewise.
* gcc.dg/pr78468.c: Likewise.
* gcc.dg/pr78902.c: Likewise.
* gcc.dg/pr79972.c: Likewise.
* gcc.dg/pr82875.c: Likewise.
* gcc.dg/pr83844.c: Likewise.
* gcc.dg/pr84131.c: Likewise.
* gcc.dg/pr87099.c: Likewise.
* gcc.dg/pr87320.c: Likewise.
* gcc.dg/pr89045.c: Likewise.
* gcc.dg/pr91014.c: Likewise.
* gcc.dg/pr93986.c: Likewise.
* gcc.dg/pr98721-1.c: Likewise.
* gcc.dg/pr99122-2.c: Likewise.
* gcc.dg/shrink-wrap-alloca.c: Likewise.
* gcc.dg/sso-14.c: Likewise.
* gcc.dg/strlenopt-62.c: Likewise.
* gcc.dg/strlenopt-83.c: Likewise.
* gcc.dg/strlenopt-84.c: Likewise.
* gcc.dg/strlenopt-91.c: Likewise.
* gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Likewise.
* gcc.dg/torture/calleesave-sse.c: Likewise.
* gcc.dg/torture/pr48953.c: Likewise.
* gcc.dg/torture/pr71881.c: Likewise.
* gcc.dg/torture/pr71901.c: Likewise.
* gcc.dg/torture/pr78742.c: Likewise.
* gcc.dg/torture/pr92088-1.c: Likewise.
* gcc.dg/torture/pr92088-2.c: Likewise.
* gcc.dg/torture/pr93124.c: Likewise.
* gcc.dg/torture/pr94479.c: Likewise.
* gcc.dg/torture/stackalign/alloca-1.c: Likewise.
* gcc.dg/torture/stackalign/inline-2.c: Likewise.
* gcc.dg/torture/stackalign/nested-3.c: Likewise.
* gcc.dg/torture/stackalign/vararg-1.c: Likewise.
* gcc.dg/torture/stackalign/vararg-2.c: Likewise.
* gcc.dg/tree-ssa/20030807-2.c: Likewise.
* gcc.dg/tree-ssa/20080530.c: Likewise.
* gcc.dg/tree-ssa/alias-37.c: Likewise.
* gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: Likewise.
* gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: Likewise.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Likewise.
* gcc.dg/tree-ssa/loop-interchange-15.c: Likewise.
* gcc.dg/tree-ssa/pr23848-1.c: Likewise.
* gcc.dg/tree-ssa/pr23848-2.c: Likewise.
* gcc.dg/tree-ssa/pr23848-3.c: Likewise.
* gcc.dg/tree-ssa/pr23848-4.c: Likewise.
* gcc.dg/uninit-32.c: Likewise.
* gcc.dg/uninit-36.c: Likewise.
* gcc.dg/uninit-39.c: Likewise.
* gcc.dg/uninit-41.c: Likewise.
* gcc.dg/uninit-9-O0.c: Likewise.
* gcc.dg/uninit-9.c: Likewise.
* gcc.dg/uninit-pr100250.c: Likewise.
* gcc.dg/uninit-pr101300.c: Likewise.
* gcc.dg/uninit-pr101494.c: Likewise.
* gcc.dg/uninit-pr98583.c: Likewise.
* gcc.dg/vla-2.c: Likewise.
* gcc.dg/vla-22.c: Likewise.
* gcc.dg/vla-24.c: Likewise.
* gcc.dg/vla-3.c: Likewise.
* gcc.dg/vla-4.c: Likewise.
* gcc.dg/vla-stexp-1.c: Likewise.
* gcc.dg/vla-stexp-2.c: Likewise.
* gcc.dg/vla-stexp-4.c: Likewise.
* gcc.dg/vla-stexp-5.c: Likewise.
* gcc.dg/winline-7.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-1.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-10.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-2.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-3.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-4.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-5.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-6.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-7.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-8.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-9.c: Likewise.
* gcc.target/arc/interrupt-6.c: Likewise.
* gcc.target/i386/pr80969-3.c: Likewise.
* gcc.target/loongarch/stack-check-alloca-1.c: Likewise.
* gcc.target/loongarch/stack-check-alloca-2.c: Likewise.
* gcc.target/loongarch/stack-check-alloca-3.c: Likewise.
* gcc.target/loongarch/stack-check-alloca-4.c: Likewise.
* gcc.target/loongarch/stack-check-alloca-5.c: Likewise.
* gcc.target/loongarch/stack-check-alloca-6.c: Likewise.
* gcc.target/riscv/stack-check-alloca-1.c: Likewise.
* gcc.target/riscv/stack-check-alloca-10.c: Likewise.
* gcc.target/riscv/stack-check-alloca-2.c: Likewise.
* gcc.target/riscv/stack-check-alloca-3.c: Likewise.
* gcc.target/riscv/stack-check-alloca-4.c: Likewise.
* gcc.target/riscv/stack-check-alloca-5.c: Likewise.
* gcc.target/riscv/stack-check-alloca-6.c: Likewise.
* gcc.target/riscv/stack-check-alloca-7.c: Likewise.
* gcc.target/riscv/stack-check-alloca-8.c: Likewise.
* gcc.target/riscv/stack-check-alloca-9.c: Likewise.
* gcc.target/sparc/setjmp-1.c: Likewise.
* gcc.target/x86_64/abi/ms-sysv/ms-sysv.c: Likewise.
* gcc.c-torture/compile/20001221-1.c: Don't 'dg-skip-if'
for '! alloca'.
* gcc.c-torture/compile/20020807-1.c: Likewise.
* gcc.c-torture/compile/20050801-2.c: Likewise.
* gcc.c-torture/compile/920428-4.c: Likewise.
* gcc.c-torture/compile/debugvlafunction-1.c: Likewise.
* gcc.c-torture/compile/pr41469.c: Likewise.
* gcc.c-torture/execute/920721-2.c: Likewise.
* gcc.c-torture/execute/920929-1.c: Likewise.
* gcc.c-torture/execute/921017-1.c: Likewise.
* gcc.c-torture/execute/941202-1.c: Likewise.
* gcc.c-torture/execute/align-nest.c: Likewise.
* gcc.c-torture/execute/alloca-1.c: Likewise.
* gcc.c-torture/execute/pr22061-4.c: Likewise.
* gcc.c-torture/execute/pr36321.c: Likewise.
* gcc.dg/torture/pr8081.c: Likewise.
* gcc.dg/analyzer/data-model-1.c: Don't
'dg-require-effective-target alloca'.  XFAIL relevant
'dg-warning's for '! alloca'.
* gcc.dg/uninit-38.c: Likewise.
* gcc.dg/uninit-pr98578.c: Likewise.
* gcc.dg/compat/struct-by-value-22_main.c: Comment on
'dg-require-effective-target alloca'.
libstdc++-v3/
* testsuite/lib/prune.exp (proc libstdc++-dg-prune): Turn
'sorry, unimplemented: dynamic stack allocation not supported' into
UNSUPPORTED.

5 months agoGracefully handle the case that 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what' has...
Thomas Schwinge [Fri, 21 Feb 2025 20:54:59 +0000 (21:54 +0100)] 
Gracefully handle the case that 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what' has not been called (indirectly) from 'dg-test'

No change in behavior intended.

gcc/testsuite/
* lib/gcc-dg.exp (find-dg-do-what): Gracefully handle the case
that we've not be called (indirectly) from 'dg-test'.
* lib/target-supports.exp (check_effective_target_stack_size)
(check_effective_target_alloca): Catch this.

5 months agoRefactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'
Thomas Schwinge [Fri, 21 Feb 2025 18:42:28 +0000 (19:42 +0100)] 
Refactor duplicated code into 'gcc/testsuite/lib/gcc-dg.exp:find-dg-do-what'

No change in behavior intended.

gcc/testsuite/
* lib/gcc-dg.exp (proc find-dg-do-what): New.
* lib/target-supports.exp (check_effective_target_stack_size)
(check_effective_target_alloca): Use it.

5 months agoBPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation not supported'
Thomas Schwinge [Fri, 21 Feb 2025 10:21:08 +0000 (11:21 +0100)] 
BPF, nvptx: Standardize on 'sorry, unimplemented: dynamic stack allocation not supported'

... instead of BPF: 'error: BPF does not support dynamic stack allocation', and
nvptx: 'sorry, unimplemented: target cannot support alloca'.

gcc/
* config/bpf/bpf.md (define_expand "allocate_stack"): Emit
'sorry, unimplemented: dynamic stack allocation not supported'.
* config/nvptx/nvptx.md (define_expand "allocate_stack")
[!TARGET_SOFT_STACK && !(TARGET_PTX_7_3 && TARGET_SM52)]: Likewise.
gcc/testsuite/
* gcc.target/bpf/diag-alloca-1.c: Adjust 'dg-message'.
* gcc.target/bpf/diag-alloca-2.c: Likewise.
* gcc.target/nvptx/alloca-1-sm_30.c: Likewise.
* gcc.target/nvptx/vla-1-sm_30.c: Likewise.
* lib/target-supports.exp (proc check_effective_target_alloca):
Adjust comment.

5 months agolibgomp: Add '__attribute__((unused))' to variables used only in 'assert(...)'
shynur [Mon, 17 Feb 2025 15:06:58 +0000 (23:06 +0800)] 
libgomp: Add '__attribute__((unused))' to variables used only in 'assert(...)'

Without this attribute, the building process will fail if GCC is configured
with 'CFLAGS=-DNDEBUG'.

libgomp/ChangeLog:

* oacc-mem.c (acc_unmap_data, goacc_exit_datum_1, find_group_last,
goacc_enter_data_internal): Add '__attribute__((unused))'.
* target.c (gomp_unmap_vars_internal): Likewise.

5 months agolibstdc++: Remove misleading comment in __atomic_base<Int>
Jonathan Wakely [Tue, 15 Apr 2014 19:13:41 +0000 (20:13 +0100)] 
libstdc++: Remove misleading comment in __atomic_base<Int>

No conversion is needed because the type of _M_i is __int_type anyway.

libstdc++-v3/ChangeLog:

* include/bits/atomic_base.h (__atomic_base<_ITp>): Remove
misleading comment.

5 months agolibstdc++: Remove redundant cast in floating_from_chars.cc
Jonathan Wakely [Thu, 20 Feb 2025 15:16:11 +0000 (15:16 +0000)] 
libstdc++: Remove redundant cast in floating_from_chars.cc

In r15-7647-g32457bc25fea80 I added a cast and also changed the type of
the variable, making the cast redundant. This removes the cast.

libstdc++-v3/ChangeLog:

* src/c++17/floating_from_chars.cc (__floating_from_chars_hex):
Remove redundant cast.

5 months agoOpenMP: Silence uninitialized variable warning in C++ front end.
Sandra Loosemore [Sat, 22 Feb 2025 16:54:50 +0000 (16:54 +0000)] 
OpenMP: Silence uninitialized variable warning in C++ front end.

There's no actual problem with the code here, just a false-positive
warning emitted by some older GCC versions.

gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Initialize
append_args_last.

5 months agoPR modula2/118978 ICE when attempting to pass an incompatible parameter
Gaius Mulley [Sat, 22 Feb 2025 16:47:21 +0000 (16:47 +0000)] 
PR modula2/118978 ICE when attempting to pass an incompatible parameter

This bugfix is for a an ICE which occurs if an incompatible parameter
is passed to a procedure.  In particular if a REAL constant actual
parameter is passed to INTEGER formal parameter then M2Range is invoked
to check the type and then M2Range is called to check the value range.

The value range check causes an ICE.  The bug fix introduces range
dependencies on type checks.  If the type check fails an
error message is generated and any future range check cancelled.
These range and type checks are tightly coupled when generating
parameter quad intermediate code.

gcc/m2/ChangeLog:

PR modula2/118978
* gm2-compiler/M2Check.mod (checkConstMeta): Add check for
typed constants.
* gm2-compiler/M2Quads.mod (BoolFrame): New field RangeDep.
(CheckProcedureParameters): Call PutRangeDep to associate the
range dependency with the parameter on the quad stack.
Pass ParamCheckId to CheckParameter.
(CheckProcTypeAndProcedure): Add ParamCheckId parameter.
Pass ParamCheckId to BuildRange.
(CheckParameter): New parameter ParamCheckId.
Pass ParamCheckId to CheckProcTypeAndProcedure.
(CheckParameterOrdinals): Add extra range dep parameter to the
call of InitParameterRangeCheck.
(ConvertBooleanToVariable): Initialize RangeDep field.
(PushBacktok): Ditto.
(OperandRangeDep): New procedure.
(PutRangeDep): Ditto.
* gm2-compiler/M2Range.def (InitTypesParameterCheck): Add new
parameter depRangeId.
(InitParameterRangeCheck): Add new parameter parentRangeId.
(FoldRangeCheck): Add new parameter range.
* gm2-compiler/M2Range.mod (InitTypesParameterCheck): Add new
parameter depRangeId.
(InitParameterRangeCheck): Add new parameter parentRangeId.
(FoldRangeCheck): Add new parameter range and rewrite.
(FoldRangeCheckLower): New procedure.
(Range): New field cancelled.
New field dependantid.
(PutRangeParam): Initialize dependantid.
(PutRangeParamAssign): Ditto.
(CheckCancelled): New procedure.
(Cancel): Ditto.
(IsCancelled): New procedure function.
(FoldTypeParam): Add depRangeId parameter.
(WriteRangeCheck): Add dependent debugging.

gcc/testsuite/ChangeLog:

PR modula2/118978
* gm2/pim/fail/badparamtype.mod: New test.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
5 months agoDaily bump.
GCC Administrator [Sat, 22 Feb 2025 00:17:38 +0000 (00:17 +0000)] 
Daily bump.