Fortran: fix FE memleak with BOZ expressions.

gcc/fortran/ChangeLog:

* expr.cc (free_expr0): Free also BOZ strings as part of an expression.

c++: outer 'this' leaking into local class [PR106969]

Here when resolving the implicit object for '&wrapped' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context.  And yet at this point
current_class_ref still corresponds to the outer class Context (and is
const), which confuses maybe_dummy_object into propagating the cv-quals
of current_class_ref and returning an object of type const Foo&.  Thus
decltype(&wrapped) wrongly yields const int* instead of int*.

The problem ultimately seems to be that the 'this' from the enclosing
class appears available for use when parsing the local class, but 'this'
shouldn't persist across classes like that.  This patch fixes this by
clearing current_class_ptr/ref before parsing a class definition.

After this change, for the test name-clash11.C in C++98 mode we would
now complain about an invalid use of 'this' in e.g.

  ASSERT (sizeof (this->A) == 16);

due to the way the test defines the ASSERT macro via a local class.
This patch redefines the macro using a local typedef instead.

PR c++/106969

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier): Clear current_class_ptr
and current_class_ref sooner, before parsing a class definition.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/name-clash11.C: Fix ASSERT macro definition in
C++98 mode.
* g++.dg/lookup/this2.C: New test.

libatomic: Fix SEQ_CST 128-bit atomic load [PR108891]

The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP -
without it, it effectively has Load-AcquirePC semantics similar to LDAPR,
which is less restrictive than what __ATOMIC_SEQ_CST requires.  This patch
fixes this and adds comments to make it easier to see which sequence is
used for each case.  Use a load/store exclusive loop for store to simplify
testing memory ordering is correct (it is slightly faster too).

libatomic/
PR libgcc/108891
* config/linux/aarch64/atomic_16.S: Fix libat_load_16_i1.
Add comments describing the memory order.

libgomp.texi: Fix wording in GCN offload specifics

libgomp/
* libgomp.texi (Offload-Target Specifics): Grammar fix.

c++: default template arg, partial ordering [PR105481]

The default argument code in type_unification_real was assuming that all
targs we've deduced by that point are non-dependent, but that's not the case
for partial ordering.

PR c++/105481

gcc/cp/ChangeLog:

* pt.cc (type_unification_real): Adjust for partial ordering.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.

Add caveat/safeguard to OpenMP: Handle descriptors in target's firstprivate [PR104949]

Follow-up to commit 49d1a2f91325fa8cc011149e27e5093a988b3a49
"OpenMP: Handle descriptors in target's firstprivate [PR104949]".

PR fortran/104949
libgomp/
* target.c (gomp_map_vars_internal) <GOMP_MAP_FIRSTPRIVATE>: Add
caveat/safeguard.

json: preserve key-insertion order [PR109163]

PR other/109163 notes that when we write out JSON files, we traverse
the keys within each object via hash_map iteration, and thus the
ordering is non-deterministic - it can arbitrarily vary from run to
run and from different machines, making it harder for users to compare
results and determine if anything has "really" changed.

I'm running into this issue with SARIF output, but there are several
places where we're currently emitting JSON:

  * -fsave-optimization-record emits SRCFILE.opt-record.json.gz
"This option is experimental and the format of the data within
the compressed JSON file is subject to change."; see
optinfo-emit-json.{h,cc}, dumpfile.cc, etc
  * -fdiagnostics-format= with the various "sarif" and "json" options
  * -fdump-analyzer-json is a developer option in the analyzer
  * gcov has:
     "-j, --json-format: Output JSON intermediate format into
     .gcov.json.gz file"

This patch adds an auto_vec to class json::object to preserve
key-insertion order, and use it when writing out objects.  Potentially
this slightly slows down JSON output, but I believe that this isn't
normally a bottleneck, and that the benefits to the user of
deterministic output are worth it.

I had first attempted to use ordered_hash_map.h for this, but ran into
impenetrable template errors, so this patch uses a simpler approach of
just adding an auto_vec to json::object.

Testing showed a failure of diagnostic-format-json-5.c, which was using
a convoluted set of regexps to consume the output; I believe that this
was brittle, and was intermittently failing for some of the random
orderings of output.  I rewrote these regexps to work with the expected
output order.  The other such tests seem to pass with the
now-deterministic orderings.

gcc/ChangeLog:
PR other/109163
* json.cc: Update comments to indicate that we now preserve
insertion order of keys within objects.
(object::print): Traverse keys in insertion order.
(object::set): Preserve insertion order of keys.
(selftest::test_writing_objects): Add an additional key to verify
that we preserve insertion order.
* json.h (object::m_keys): New field.

gcc/testsuite/ChangeLog:
PR other/109163
* c-c++-common/diagnostic-format-json-1.c: Update comment.
* c-c++-common/diagnostic-format-json-2.c: Likewise.
* c-c++-common/diagnostic-format-json-3.c: Likewise.
* c-c++-common/diagnostic-format-json-4.c: Likewise.
* c-c++-common/diagnostic-format-json-5.c: Rewrite regexps.
* c-c++-common/diagnostic-format-json-stderr-1.c: Update comment.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

Ranger cache dominator queries should ignore backedges.

When querying dominators for cache values, ignore back edges in
read-only mode.

PR tree-optimization/109238
gcc/
* gimple-range-cache.cc (ranger_cache::resolve_dom): Ignore
predecessors which this block dominates.

gcc/testsuite/
* gcc.dg/pr109238.c: New.

tree-optimization/106912 - clear const attribute from fntype

The following makes sure that after clearing pure/const from
instrumented function declarations we are adjusting call statements
fntype as well to handle indirect calls and because gimple_call_flags
looks at both decl and fntype.

Like the pure/const flag clearing on decls we refrain from touching
calls to known functions that do not have a body in the current TU.

PR tree-optimization/106912
* tree-profile.cc (tree_profiling): Update stmts only when
profiling or testing coverage.  Make sure to update calls
fntype, stripping 'const' there.

* gcc.dg/profile-generate-4.c: New testcase.

modula2: Enable iso-extended-opaque-run-pass.exp to build library tests

This patch fixes the tcl test script iso-extended-opaque-run-pass.exp so
that the test library modules are built and included with the link command.

gcc/testsuite/ChangeLog:

* gm2/projects/iso/small/run/pass/iso-extended-opaque-run-pass.exp:
Compile object for stressset.mod and testlib.mod.  Add test so
that we only link these objects with test application objects.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

builtins: Fix up ICE in inline_string_cmp [PR109258]

The PR109086 r13-6690 inline_string_cmp change to
      if (diff != result)
        emit_move_insn (result, diff);
regressed
FAIL: go.test/test/fixedbugs/bug207.go,  -O2 -g  (internal compiler error: in emit_move_insn, at expr.cc:4224)
The problem is the Go FE doesn't mark __builtin_memcmp as pure (I'll also
send patch for that) and so result is const0_rtx when the call lost its lhs
and the above move ICEs because moving something into const0_rtx is obviously
invalid.
I think it is better not to rely on all FEs having these *cmp functions
pure anD DCE being performed.  The following patch just punts from the
inline expansion in that case, so we just emit normal library call.

2023-03-24  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/109258
* builtins.cc (inline_expand_builtin_bytecmp): Return NULL_RTX early
if target == const0_rtx.

testsuite: Fix up gcc.target/i386/pr109137.c testcase [PR109137]

The testcase has a couple of small problems:
1) had -m32 in dg-options, that should never be done, instead the test
   should be guarded on ia32
2) adds -fPIC unconditionally (that should be guarded on fpic effective
   target)
3) using #include <string.h> for a RA test seems unnecessary, __builtin_memset
   handles it without the header

2023-03-24  Jakub Jelinek  <jakub@redhat.com>

PR target/109137
* gcc.target/i386/pr109137.c: Remove -m32 from dg-options, instead
require ia32 effective target.  Only add -fPIC for fpic effective
target.  Remove #include <string.h>, use __builtin_memset instead of
memset.

testsuite: Add testcase for already fixed PR [PR99739]

This PR was fixed by r13-1268-g8c99e307b20, I'm adding testcase
to make sure we don't regress on it in the future.

2023-03-24  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/99739
* gcc.dg/tree-ssa/pr99739.c: New test.

[testsuite] test for weak_undefined support and add options

A number of tests that depend on weak undefined symbols fail to
require that support, and arrange to skip some targets and add special
options to others on a test-by-test basis.  Fix this by stating the
requirement explicitly, and adding a proc to return any required
options.

Others rely on weak undefined symbols only to test for the
availability of posix_memalign.  Drop that in favor of dg effective
target support for posix_memalign.

for  gcc/ChangeLog

* doc/sourcebuild.texi (weak_undefined, posix_memalign):
Document options and effective targets.

for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (add_options_for_weak_undefined):
New.
(check_effective_target_weak_undefined): Use it.
(check_effective_target_posix_memalign): New.
* gcc.dg/torture/pr53922.c: Drop skips and custom options in
favor of effective target requirement and added options for
weak_undefined symbols.
* gcc.dg/torture/pr90020.c: Likewise.
* gcc.dg/addr_equal-1.c: Likewise.
* gcc.target/aarch64/aapcs64/aapcs64.exp: Likewise, for
abitest.S-using tests.
* gcc.dg/torture/pr60092.c: Likewise, but in favor of
posix_memalign tests.
* gcc.dg/vect/vect-tail-nomask-1.c: Likewise.

Fortran: Escalate failure when Hollerith constant to real conversion fails

gcc/fortran/
PR target/103628
* target-memory.cc (gfc_interpret_float): Return FAIL when
native_interpret_expr gets a NULL tree.
* arith.cc (gfc_hollerith2real): Return NULL when
gfc_interpret_float fails.
* error.cc (gfc_buffered_p): Define.
* gfortran.h (gfc_buffered_p): Declare.
* intrinsic.cc: Add diagnostic.h to include list.
(do_simplify): Save errorcount and check it at finish.  Report a
"Cannot simplify expression" error on a bad result if error count
doesn't change and no other errors buffered.

gcc/testsuite/
PR target/103628
* gfortran.dg/assumed_size_refs_2.f90: Check "Cannot simplify
expression" error.
* gfortran.dg/unpack_field_1.f90: Likewise.
* gfortran.dg/pr103628.f90: New.

Co-Authored-By: Tobias Burnus <tobias@codesourcery.com>

Fix native MSYS2 build failure [PR108865, PR109188]

Don't cause an error if the symbol is not found.

When building natively as an MSYS2 package, some
executables are borrowing the $(COMPILERS) flags
and --require-defined=HOST_EXTRA_OBJS_SYMBOL is
causing them to fail.

These executables don't need that symbol, so make
it optional such that they don't error out.

The compilers will still look for it (and find it)
with the desired effect of getting UTF-8 support.

PR/PR108865

gcc/ChangeLog:

* config/i386/x-mingw32-utf8: Make HOST_EXTRA_OBJS_SYMBOL
optional.

Signed-off-by: Jonathan Yong <10walls@gmail.com>

Daily bump.

c++: constexpr PMF conversion [PR105996]

Here, we were calling build_reinterpret_cast regardless of whether there was
actually a cast, and that now sets REINTERPRET_CAST_P.  But that
optimization seems dodgy anyway, as it involves NOP_EXPR from one
RECORD_TYPE to another and we try to reserve NOP_EXPR for fundamental types.
And the generated code seems the same, so let's drop it.  And also strip
location wrappers.

PR c++/105996

gcc/cp/ChangeLog:

* typeck.cc (build_ptrmemfunc): Drop 0-offset optimization
and location wrappers.

gcc/testsuite/ChangeLog:

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

testsuite: Xfail gcc.dg/tree-ssa/ssa-fre-100.c for ! natural_alignment_32

The test gcc.dg/tree-ssa/ssa-fre-100.c fails the
scan-tree-dump-not fre1 "baz" for at least m68k-linux,
pru-elf, and cris-elf according to posts on gcc-testresults.

GCC requires int-size-alignment for a target to see through
the "int *" dereference and perform value-numbering.  See
comments in PR91419 and also the recent patch to
gcc.dg/tree-ssa/pr100359.c.  This is a flaw in gcc rather
than the target, so prefer an xfail rather than skipping
the test.

* gcc.dg/tree-ssa/ssa-fre-100.c: XFAIL for ! natural_alignment_32.

testsuite: Compile-only gcc.dg/tree-ssa/pr100359.c if ! natural_alignment_32

The test gcc.dg/tree-ssa/pr100359.c fails the "test for
excess errors" for at least m68k-linux, pru-elf, and
cris-elf according to posts on gcc-testresults.  For
cris-elf, the "excess errors" is a failure to link; an
undefined reference to foo, because the code has a call to
an extern function foo, which is not optimized away, and
which is not defined.  I guess it's the same for those other
targets.

From comparative gdb sessions for native x86_64-linux and
cris-elf, I see tree-ssa-sccvn.cc:vn_reference_lookup_3
(called from the "pre" pass) requires int-size-alignment for
a target to see through the "int *" dereference, that the
expression is constant false and subsequently optimize away
the call to foo.  The conclusion is with substantially less
effort available from comments in PR91419.

The point of the test seems only incidental to
optimizing-out the call to foo, judging from the comments in
PR100359, so an alternative is compile it (not link it) for
all targets.  However, I chose to not change the nature of
the test where it passes.

* gcc.dg/tree-ssa/pr100359.c: Compile-only for ! natural_alignment_32.

Don't force target of modulo into a distinct register.

The define_insns for the modulo operation currently force the target register
to a distinct reg in preparation for a possible future peephole combining
div/mod. But this can lead to cases of a needless copy being inserted. Fixed
with the following patch.

gcc/
* config/rs6000/rs6000.md (*mod<mode>3, umod<mode>3): Add
non-earlyclobber alternative.

gcc/testsuite/
* gcc.target/powerpc/mod-no_copy.c: New.
* gcc.target/powerpc/mod-peephole.c: New.

c: [PR84900] cast of compound literal does not cause the code to become a non-lvalue

The problem here is after r0-92187-g2ec5deb5c3146c, maybe_lvalue_p would
return false for compound literals which causes non_lvalue_loc not
to wrap the expression with a NON_LVALUE_EXPR unlike before when it
return true as it returns true for all language specific tree codes.

This fixes that oversight and fixes the testcase to have the cast as
a non-lvalue.

Committed to the trunk as obvious after a bootstrap/test on x86_64-linux-gnu.

PR c/84900

gcc/ChangeLog:

* fold-const.cc (maybe_lvalue_p): Treat COMPOUND_LITERAL_EXPR
as a lvalue.

gcc/testsuite/ChangeLog:

* gcc.dg/compound-literal-cast-lvalue-1.c: New test.

PR modula2/109264 Bugfix resolve opaque types containing sets

Resolve opaque type handling.  The bug is caused by the compiler
attempting to resolve the meta types of a constant constructor.
It incorrectly attempts to get the type on an enumeration type
(resulting in NulSym) which causes the meta resolver to spin.
Some PHBuild rules (building records need to be copied from P3Build
so that hidden types are resolved in order across the compile.

gcc/m2/ChangeLog:

PR modula2/109264
* gm2-compiler/M2Quads.mod (BuildConstFunctionCall): Comment
out ErrorString in debugging block.
(BuildConstructorStart): Replace Assert with a call to
MetaErrorT3.  Import MetaErrorT3.
* gm2-compiler/PCSymBuild.mod (buildConstFunction): Rename
local variables.
(WalkFunctionParam): Remove test for IsEnumeration when
resolving MIN or MAX parameters.
* gm2-compiler/PHBuild.bnf (BlockAssert): New procedure.
(ErrorArrayat): New procedure.
(Expect): Renamed parameter t to tok.
(PushQualident): New rule.
(ConstSetOrQualidentOrFunction): Force AutoOn.
(TypeDeclaration): Add debugging assert.
(SimpleType): Add debugging assert.
(DefaultRecordAttributes): New rule (and bugfix).
(FieldPragmaExpression): New rule (and bugfix).
(PragmaConstExpression): New rule (and bugfix).
(SetOrDesignatorOrFunction): Add debugging assert.
(Block): Add debugging assert.
* gm2-gcc/m2expr.cc (m2expr_ConstantExpressionWarning): int
to bool.
* gm2-gcc/m2expr.h (m2expr_TreeOverflow): int to bool.
(m2expr_GetBooleanTrue): Remove.
(m2expr_GetBooleanFalse): Remove.
* gm2-gcc/m2options.h (M2Options_SetStatistics): Replace
int with bool.

gcc/testsuite/ChangeLog:

PR modula2/109264
* gm2/iso/extended-opaque/pass/iso-extended-opaque-pass.exp:
New test.
* gm2/iso/extended-opaque/pass/stressset.def: New test.
* gm2/iso/extended-opaque/pass/stressset.mod: New test.
* gm2/iso/extended-opaque/pass/testset.mod: New test.
* gm2/projects/iso/small/run/pass/iso-extended-opaque-run-pass.exp:
New test.
* gm2/projects/iso/small/run/pass/stressset.def: New test.
* gm2/projects/iso/small/run/pass/stressset.mod: New test.
* gm2/projects/iso/small/run/pass/test1.mod: New test.
* gm2/projects/iso/small/run/pass/testlib.def: New test.
* gm2/projects/iso/small/run/pass/testlib.mod: New test.
* gm2/projects/iso/small/run/pass/testset.mod: New test.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

tree-optimization/107569 - avoid wrecking earlier folding in FRE/PRE

The following avoids picking up dead code left over from folding
during FRE/PRE, effectively undoing propagations.

PR tree-optimization/107569
* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt):
Do not push SSA names with zero uses as available leader.
(process_bb): Likewise.

* g++.dg/opt/pr107569.C: New testcase.

tree-optimization/109262 - ICE with non-call EH and forwprop

The recent combining of complex part loads to a complex load missed
to account for non-call EH.

PR tree-optimization/109262
* tree-ssa-forwprop.cc (pass_forwprop::execute): When
combining a piecewise complex load avoid touching loads
that throw internally.  Use fun, not cfun throughout.

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

ranger: Ranger meets aspell

I've noticed a comment typo in tree-vrp.cc and decided to quickly
skim aspell -c on the ranger sources (with quick I on everything that
looked ok or roughly ok).
But not being a native English speaker, I could get stuff wrong.

2023-03-23  Jakub Jelinek  <jakub@redhat.com>

* value-range.cc (irange::irange_union, irange::intersect): Fix
comment spelling bugs.
* gimple-range-trace.cc (range_tracer::do_header): Likewise.
* gimple-range-trace.h: Likewise.
* gimple-range-edge.cc: Likewise.
(gimple_outgoing_range_stmt_p,
gimple_outgoing_range::switch_edge_range,
gimple_outgoing_range::edge_range_p): Likewise.
* gimple-range.cc (gimple_ranger::prefill_stmt_dependencies,
gimple_ranger::fold_stmt, gimple_ranger::register_transitive_infer,
assume_query::assume_query, assume_query::calculate_phi): Likewise.
* gimple-range-edge.h: Likewise.
* value-range.h (Value_Range::set, Value_Range::lower_bound,
Value_Range::upper_bound, frange::set_undefined): Likewise.
* gimple-range-gori.h (range_def_chain::depend, gori_map::m_outgoing,
gori_compute): Likewise.
* gimple-range-fold.h (fold_using_range): Likewise.
* gimple-range-path.cc (path_range_query::compute_ranges_in_phis):
Likewise.
* gimple-range-gori.cc (range_def_chain::in_chain_p,
range_def_chain::dump, gori_map::calculate_gori,
gori_compute::compute_operand_range_switch,
gori_compute::logical_combine, gori_compute::refine_using_relation,
gori_compute::compute_operand1_range, gori_compute::may_recompute_p):
Likewise.
* gimple-range.h: Likewise.
(enable_ranger): Likewise.
* range-op.h (empty_range_varying): Likewise.
* value-query.h (value_query): Likewise.
* gimple-range-cache.cc (block_range_cache::set_bb_range,
block_range_cache::dump, ssa_global_cache::clear_global_range,
temporal_cache::temporal_value, temporal_cache::current_p,
ranger_cache::range_of_def, ranger_cache::propagate_updated_value,
ranger_cache::range_from_dom, ranger_cache::register_inferred_value):
Likewise.
* gimple-range-fold.cc (fur_edge::get_phi_operand,
fur_stmt::get_operand, gimple_range_adjustment,
fold_using_range::range_of_phi,
fold_using_range::relation_fold_and_or): Likewise.
* value-range-storage.h (irange_storage_slot::MAX_INTS): Likewise.
* value-query.cc (range_query::value_of_expr,
range_query::value_on_edge, range_query::query_relation): Likewise.
* tree-vrp.cc (remove_unreachable::remove_and_update_globals,
intersect_range_with_nonzero_bits): Likewise.
* gimple-range-infer.cc (gimple_infer_range::check_assume_func,
exit_range): Likewise.
* value-relation.h: Likewise.
(equiv_oracle, relation_trio::relation_trio, value_relation,
value_relation::value_relation, pe_min): Likewise.
* range-op-float.cc (range_operator_float::rv_fold,
frange_arithmetic, foperator_unordered_equal::op1_range,
foperator_div::rv_fold): Likewise.
* gimple-range-op.cc (cfn_clz::fold_range): Likewise.
* value-relation.cc (equiv_oracle::query_relation,
equiv_oracle::register_equiv, equiv_oracle::add_equiv_to_block,
value_relation::apply_transitive, relation_chain_head::find_relation,
dom_oracle::query_relation, dom_oracle::find_relation_block,
dom_oracle::find_relation_dom, path_oracle::register_equiv): Likewise.
* range-op.cc (range_operator::wi_fold_in_parts_equiv,
create_possibly_reversed_range, adjust_op1_for_overflow,
operator_mult::wi_fold, operator_exact_divide::op1_range,
operator_cast::lhs_op1_relation, operator_cast::fold_pair,
operator_cast::fold_range, operator_abs::wi_fold, range_op_cast_tests,
range_op_lshift_tests): Likewise.

Skip gnat.dg/div_zero.adb on Aarch64

gcc/testsuite/
* gnat.dg/div_zero.adb: Skip for aarch64*-*-* targets.

c++: further -Wdangling-reference refinement [PR107532]

Based on <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532#c24>,
it seems like we should treat *any* class with a reference member
as a reference wrapper.  To suppress the warning in

  int i = 42;
  auto const& v = std::get<0>(std::tuple<int&>(i));

we have to look into base classes as well.  For std::tuple, this means
that we have to check the _Head_base subobject, which is a non-direct
base class of std::tuple.  So I've employed a DFS walk.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (class_has_reference_member_p): New.
(class_has_reference_member_p_r): New.
(reference_like_class_p): Don't look for a specific constructor.
Use a DFS walk with class_has_reference_member_p_r.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference11.C: New test.
* g++.dg/warn/Wdangling-reference12.C: New test.

amdgcn: Fix register size bug

Fix an issue in which "vectors" of duplicate entries placed in scalar
registers caused the following 63 registers to be marked live, for the
purpose of prologue generation, which resulted in stack corruption.

gcc/ChangeLog:

* config/gcn/gcn.cc (gcn_class_max_nregs): Handle vectors in SGPRs.
(move_callee_saved_registers): Detect the bug condition early.

amdgcn: vec_extract no-op insns

Just using move insn for no-op conversions triggers special move handling in
IRA which declares that subreg of vectors aren't valid and routes everything
through memory.  These patterns make the vec_select explicit and all is well.

gcc/ChangeLog:

* config/gcn/gcn-protos.h (gcn_stepped_zero_int_parallel_p): New.
* config/gcn/gcn-valu.md (V_1REG_ALT): New.
(V_2REG_ALT): New.
(vec_extract<V_1REG:mode><V_1REG_ALT:mode>_nop): New.
(vec_extract<V_2REG:mode><V_2REG_ALT:mode>_nop): New.
(vec_extract<V_ALL:mode><V_ALL_ALT:mode>): Use new patterns.
* config/gcn/gcn.cc (gcn_stepped_zero_int_parallel_p): New.
* config/gcn/predicates.md (ascending_zero_int_parallel): New.

tree-vect-generic: Fix up expand_vector_condition [PR109176]

The following testcase ICEs on aarch64-linux, because
expand_vector_condition attempts to piecewise lower SVE
  d_3 = a_1(D) < b_2(D);
  _5 = VEC_COND_EXPR <d_3, c_4(D), d_3>;
which isn't possible - nunits_for_known_piecewise_op ICEs but
the rest of the code assumes constant number of elements too.

expand_vector_condition attempts to find if a (rhs1) is a SSA_NAME
for comparison and calls expand_vec_cond_expr_p (type, TREE_TYPE (a1), code)
where a1 is one of the operands of the comparison and code is the comparison
code.  That one indeed isn't supported here, but what aarch64 SVE supports
are the individual statements, comparison (expand_vec_cmp_expr_p) and
expand_vec_cond_expr_p (type, TREE_TYPE (a), SSA_NAME), the latter because
that function starts with
  if (VECTOR_BOOLEAN_TYPE_P (cmp_op_type)
      && get_vcond_mask_icode (TYPE_MODE (value_type),
                               TYPE_MODE (cmp_op_type)) != CODE_FOR_nothing)
    return true;

In an earlier version of the patch (in the PR), we did this
  if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a))
      && expand_vec_cond_expr_p (type, TREE_TYPE (a), ERROR_MARK))
    return true;
before the code == SSA_NAME handling plus some further tweaks later.
While that fixed the ICE, it broke quite a few tests on x86 and some on
aarch64 too.  The problem is that expand_vector_comparison doesn't lower
comparisons which aren't supported and only feed VEC_COND_EXPR first operand
and expand_vector_condition succeeds for those, so with the above mentioned
change we'd verify the VEC_COND_EXPR is implementable using optab alone,
but nothing would verify the tcc_comparison which relied on
expand_vector_condition to verify.

So, the following patch instead queries whether optabs can handle the
comparison and VEC_COND_EXPR together (if a (rhs1) is a comparison;
otherwise as before it checks only the VEC_COND_EXPR) and if that fails,
also checks whether the two operations could be supported individually
and only if even that fails does the piecewise lowering.

2023-03-23  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/109176
* tree-vect-generic.cc (expand_vector_condition): If a has
vector boolean type and is a comparison, also check if both
the comparison and VEC_COND_EXPR could be successfully expanded
individually.

* gcc.target/aarch64/sve/pr109176.c: New test.

RISC-V: Bugfix for rvv bool mode size adjustment

Fix the bug of the rvv bool mode size by the adjustment.
Besides the mode precision (aka bit size [1, 2, 4, 8, 16, 32, 64])
of the vbool*_t, the mode size (aka byte size) will be adjusted to
[1, 1, 1, 1, 2, 4, 8] according to the rvv spec 1.0 isa. The
adjustment will provide correct information for the underlying
redundant instruction elimiation.

Given the below sample code:
{
  vbool1_t v1 = *(vbool1_t*)in;
  vbool64_t v2 = *(vbool64_t*)in;

  *(vbool1_t*)(out + 100) = v1;
  *(vbool64_t*)(out + 200) = v2;
}

Before the size adjustment:
csrr    t0,vlenb
slli    t1,t0,1
csrr    a3,vlenb
sub     sp,sp,t1
slli    a4,a3,1
add     a4,a4,sp
addi    a2,a1,100
vsetvli a5,zero,e8,m8,ta,ma
sub     a3,a4,a3
vlm.v   v24,0(a0)
vsm.v   v24,0(a2)
vsm.v   v24,0(a3)
addi    a1,a1,200
csrr    t0,vlenb
vsetvli a4,zero,e8,mf8,ta,ma
slli    t1,t0,1
vlm.v   v24,0(a3)
vsm.v   v24,0(a1)
add     sp,sp,t1
jr      ra

After the size adjustment:
addi    a3,a1,100
vsetvli a4,zero,e8,m8,ta,ma
addi    a1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a3)
vsetvli a5,zero,e8,mf8,ta,ma
vlm.v   v24,0(a0)
vsm.v   v24,0(a1)
ret

Additionally, the size adjust cannot cover all possible combinations
of the vbool*_t code pattern like above. We will take a look into it
in another patches.

PR 108185
PR 108654

gcc/ChangeLog:

PR target/108654
PR target/108185
* config/riscv/riscv-modes.def (ADJUST_BYTESIZE): Adjust size
for vector mask modes.
* config/riscv/riscv.cc (riscv_v_adjust_bytesize): New.
* config/riscv/riscv.h (riscv_v_adjust_bytesize): New.

gcc/testsuite/ChangeLog:

PR target/108654
PR target/108185
* gcc.target/riscv/rvv/base/pr108185-1.c: Update.
* gcc.target/riscv/rvv/base/pr108185-2.c: Ditto.
* gcc.target/riscv/rvv/base/pr108185-3.c: Ditto.

Signed-off-by: Pan Li <pan2.li@intel.com>
Co-authored-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>

RISC-V: Fix loss of function to script 'multilib-generator'

The arch 'rv32imac' will not be created when excuting
'./multilib-generator rv32imc-ilp32--a'

The output is:
MULTILIB_OPTIONS = march=rv32imc mabi=ilp32
MULTILIB_DIRNAMES = rv32imc ilp32
MULTILIB_REQUIRED = march=rv32imc/mabi=ilp32
MULTILIB_REUSE =

Analysis : The alts:['rv32imc', 'rv32imac'] will change
to ['rv32imac', 'rv32imc'] through function:unique(alts) processing,
This is the wrong alts should not be changed.
This patch fix it.

gcc/ChangLog:
* config/riscv/multilib-generator: Adjusting the loop of 'alt' in 'alts'.

Signed-off-by: Songhe Zhu <zhusonghe@eswincomputing.com>

c++: local class in nested generic lambda [PR109241]

In this testcase, the tree walk to look for bare parameter packs was
confused by finding a type with no TREE_BINFO.  But it should be fine that
it's unset; we already checked for unexpanded packs at parse time.

I also tried doing the partial instantiation of the local class, which is
probably the long-term direction we want to go, but for stage 4 let's go
with this safer change.

PR c++/109241

gcc/cp/ChangeLog:

* pt.cc (find_parameter_packs_r): Handle null TREE_BINFO.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-local-class2.C: New test.

RISC-V: Fix LRA issue for LMUL < 1 vector spillings [PR109244]

In order to decrease the memory traffic, we don't use whole register
load/store for the LMUL less than 1 and mask mode, so those case will
require one extra general purpose register for setting up VL register,
but it's not allowed during LRA process, so we defined few special move patterns
used for LRA, which will defer the expansion after LRA.

gcc/ChangeLog:

PR target/109244
* config/riscv/riscv-protos.h (emit_vlmax_vsetvl): Define as global.
(emit_vlmax_op): Ditto.
* config/riscv/riscv-v.cc (get_sew): New function.
(emit_vlmax_vsetvl): Adapt function.
(emit_pred_op): Ditto.
(emit_vlmax_op): Ditto.
(emit_nonvlmax_op): Ditto.
(legitimize_move): Fix LRA ICE.
(gen_no_side_effects_vsetvl_rtx): Adapt function.
* config/riscv/vector.md (@mov<V_FRACT:mode><P:mode>_lra): New pattern.
(@mov<VB:mode><P:mode>_lra): Ditto.
(*mov<V_FRACT:mode><P:mode>_lra): Ditto.
(*mov<VB:mode><P:mode>_lra): Ditto.

gcc/testsuite/ChangeLog:

PR target/109244
* g++.target/riscv/rvv/base/pr109244.C: New test.
* gcc.target/riscv/rvv/base/binop_vv_constraint-4.c: Adapt testcase.
* gcc.target/riscv/rvv/base/binop_vv_constraint-6.c: Ditto.
* gcc.target/riscv/rvv/base/binop_vx_constraint-127.c: Ditto.
* gcc.target/riscv/rvv/base/spill-1.c: Ditto.
* gcc.target/riscv/rvv/base/spill-2.c: Ditto.
* gcc.target/riscv/rvv/base/spill-3.c: Ditto.
* gcc.target/riscv/rvv/base/spill-5.c: Ditto.
* gcc.target/riscv/rvv/base/spill-7.c: Ditto.
* g++.target/riscv/rvv/base/bug-18.C: New test.
* gcc.target/riscv/rvv/base/merge_constraint-3.c: New test.
* gcc.target/riscv/rvv/base/merge_constraint-4.c: New test.

RISC-V: Implement __riscv_vlenb PR109228

__riscv_vlenb is defined in RVV intrinsic spec 0.11 and used in some project
like google/highway.

gcc/ChangeLog:

PR target/109228
* config/riscv/riscv-vector-builtins-bases.cc (class vlenb): Add
__riscv_vlenb support.
(BASE): Ditto.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
* config/riscv/riscv-vector-builtins-functions.def (vlenb): Ditto.
* config/riscv/riscv-vector-builtins-shapes.cc (struct vlenb_def): Ditto.
(SHAPE): Ditto.
* config/riscv/riscv-vector-builtins-shapes.h: Ditto.
* config/riscv/riscv-vector-builtins.cc: Ditto.

gcc/testsuite/ChangeLog:

PR target/109228
* gcc.target/riscv/rvv/base/vlenb-1.c: New test.

RISC-V: Fix wrong vsetvli fusion for vmv.s.x

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (reg_available_p): Fix bugs.
(pass_vsetvl::compute_local_backward_infos): Fix bugs.
(pass_vsetvl::need_vsetvl): Fix bugs.
(pass_vsetvl::backward_demand_fusion): Fix bugs.
(pass_vsetvl::demand_fusion): Fix bugs.
(eliminate_insn): Fix bugs.
(insert_vsetvl): Ditto.
(pass_vsetvl::emit_local_forward_vsetvls): Ditto.
* config/riscv/riscv-vsetvl.h (enum vsetvl_type): Ditto.
* config/riscv/vector.md: Ditto.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/bug-10.C: New test.
* g++.target/riscv/rvv/base/bug-11.C: New test.
* g++.target/riscv/rvv/base/bug-12.C: New test.
* g++.target/riscv/rvv/base/bug-13.C: New test.
* g++.target/riscv/rvv/base/bug-14.C: New test.
* g++.target/riscv/rvv/base/bug-15.C: New test.
* g++.target/riscv/rvv/base/bug-16.C: New test.
* g++.target/riscv/rvv/base/bug-17.C: New test.
* g++.target/riscv/rvv/base/bug-2.C: New test.
* g++.target/riscv/rvv/base/bug-3.C: New test.
* g++.target/riscv/rvv/base/bug-4.C: New test.
* g++.target/riscv/rvv/base/bug-5.C: New test.
* g++.target/riscv/rvv/base/bug-6.C: New test.
* g++.target/riscv/rvv/base/bug-7.C: New test.
* g++.target/riscv/rvv/base/bug-8.C: New test.
* g++.target/riscv/rvv/base/bug-9.C: New test.

Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
Co-authored-by: kito-cheng <kito.cheng@sifive.com>

RISC-V: Fix wrong RTL pattern for ternary instructions.

We've wrong RTL pattern cause unexpected optimizaion result.

Give a example is vnmsub.vx pattern, the operation of vnmsub.vx
list below:

  vnmsub.vx vd, rs1, vs2, vm    # vd[i] = -(x[rs1] * vd[i]) + vs2[i]

But our RTL pattern write as (x[rs1] * vd[i]) - vs2[i], and the GCC try to
simplify when x[rs1] is constant 1, and then become a vd[i] - vs[i]
instruction.

We also revise all ternary instructions to make sure the RTL has right
semantic:

And it's the mapping list between instruction and RTL pattern:

interger:
vnmsac.vv vd, vs1, vs2, vm    # vd[i] = -(vs1[i] * vs2[i]) + vd[i]  (minus op3 (mult op1 op2))
vnmsac.vx vd, rs1, vs2, vm    # vd[i] = -(x[rs1] * vs2[i]) + vd[i]   (minus op3 (mult op1 op2))

floating-point:
vfmacc.vv vd, vs1, vs2, vm    # vd[i] = +(vs1[i] * vs2[i]) + vd[i] (plus (mult (op1 op2)) op3)
vfmacc.vf vd, rs1, vs2, vm    # vd[i] = +(f[rs1] * vs2[i]) + vd[i] (plus (mult (op1 op2)) op3)

vfnmacc.vv vd, vs1, vs2, vm   # vd[i] = -(vs1[i] * vs2[i]) - vd[i] (minus (neg (mult (op1 op2))) op3))
vfnmacc.vf vd, rs1, vs2, vm   # vd[i] = -(f[rs1] * vs2[i]) - vd[i] (minus (neg (mult (op1 op2)) op3))
vfmsac.vv vd, vs1, vs2, vm    # vd[i] = +(vs1[i] * vs2[i]) - vd[i] (minus (mult (op1 op2)) op3)
vfmsac.vf vd, rs1, vs2, vm    # vd[i] = +(f[rs1] * vs2[i]) - vd[i] (minus (mult (op1 op2)) op3)

vfnmsac.vv vd, vs1, vs2, vm   # vd[i] = -(vs1[i] * vs2[i]) + vd[i] (plus (neg:(mult (op1 op2))) op3)
vfnmsac.vf vd, rs1, vs2, vm   # vd[i] = -(f[rs1] * vs2[i]) + vd[i] (plus (neg:(mult (op1 op2))) op3)

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc: Fix ternary bug.
* config/riscv/vector-iterators.md (nmsac): Ditto.
(nmsub): Ditto.
(msac): Ditto.
(msub): Ditto.
(nmadd): Ditto.
(nmacc): Ditto.
* config/riscv/vector.md (@pred_mul_<optab><mode>): Ditto.
(@pred_mul_plus<mode>): Ditto.
(*pred_madd<mode>): Ditto.
(*pred_macc<mode>): Ditto.
(*pred_mul_plus<mode>): Ditto.
(@pred_mul_plus<mode>_scalar): Ditto.
(*pred_madd<mode>_scalar): Ditto.
(*pred_macc<mode>_scalar): Ditto.
(*pred_mul_plus<mode>_scalar): Ditto.
(*pred_madd<mode>_extended_scalar): Ditto.
(*pred_macc<mode>_extended_scalar): Ditto.
(*pred_mul_plus<mode>_extended_scalar): Ditto.
(@pred_minus_mul<mode>): Ditto.
(*pred_<madd_nmsub><mode>): Ditto.
(*pred_nmsub<mode>): Ditto.
(*pred_<macc_nmsac><mode>): Ditto.
(*pred_nmsac<mode>): Ditto.
(*pred_mul_<optab><mode>): Ditto.
(*pred_minus_mul<mode>): Ditto.
(@pred_mul_<optab><mode>_scalar): Ditto.
(@pred_minus_mul<mode>_scalar): Ditto.
(*pred_<madd_nmsub><mode>_scalar): Ditto.
(*pred_nmsub<mode>_scalar): Ditto.
(*pred_<macc_nmsac><mode>_scalar): Ditto.
(*pred_nmsac<mode>_scalar): Ditto.
(*pred_mul_<optab><mode>_scalar): Ditto.
(*pred_minus_mul<mode>_scalar): Ditto.
(*pred_<madd_nmsub><mode>_extended_scalar): Ditto.
(*pred_nmsub<mode>_extended_scalar): Ditto.
(*pred_<macc_nmsac><mode>_extended_scalar): Ditto.
(*pred_nmsac<mode>_extended_scalar): Ditto.
(*pred_mul_<optab><mode>_extended_scalar): Ditto.
(*pred_minus_mul<mode>_extended_scalar): Ditto.
(*pred_<madd_msub><mode>): Ditto.
(*pred_<macc_msac><mode>): Ditto.
(*pred_<madd_msub><mode>_scalar): Ditto.
(*pred_<macc_msac><mode>_scalar): Ditto.
(@pred_neg_mul_<optab><mode>): Ditto.
(@pred_mul_neg_<optab><mode>): Ditto.
(*pred_<nmadd_msub><mode>): Ditto.
(*pred_<nmsub_nmadd><mode>): Ditto.
(*pred_<nmacc_msac><mode>): Ditto.
(*pred_<nmsac_nmacc><mode>): Ditto.
(*pred_neg_mul_<optab><mode>): Ditto.
(*pred_mul_neg_<optab><mode>): Ditto.
(@pred_neg_mul_<optab><mode>_scalar): Ditto.
(@pred_mul_neg_<optab><mode>_scalar): Ditto.
(*pred_<nmadd_msub><mode>_scalar): Ditto.
(*pred_<nmsub_nmadd><mode>_scalar): Ditto.
(*pred_<nmacc_msac><mode>_scalar): Ditto.
(*pred_<nmsac_nmacc><mode>_scalar): Ditto.
(*pred_neg_mul_<optab><mode>_scalar): Ditto.
(*pred_mul_neg_<optab><mode>_scalar): Ditto.
(@pred_widen_neg_mul_<optab><mode>): Ditto.
(@pred_widen_mul_neg_<optab><mode>): Ditto.
(@pred_widen_neg_mul_<optab><mode>_scalar): Ditto.
(@pred_widen_mul_neg_<optab><mode>_scalar): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/bug-3.c: New test.
* gcc.target/riscv/rvv/base/bug-4.c: New test.
* gcc.target/riscv/rvv/base/bug-5.c: New test.

Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
Co-authored-by: kito-cheng <kito.cheng@sifive.com>

RISC-V: Add riscv_vector target check

Add target check funciton to ensure vector extension can be used.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_riscv_vector):
New.

Remove TARGET_GEN_MEMSET_SCRATCH_RTX since it's not used anymore.

The target hook is only used by i386, and the current definition is
same as default gen_reg_rtx.

gcc/ChangeLog:

* builtins.cc (builtin_memset_read_str): Replace
targetm.gen_memset_scratch_rtx with gen_reg_rtx.
(builtin_memset_gen_str): Ditto.
* config/i386/i386-expand.cc
(ix86_convert_const_wide_int_to_broadcast): Replace
ix86_gen_scratch_sse_rtx with gen_reg_rtx.
(ix86_expand_vector_move): Ditto.
* config/i386/i386-protos.h (ix86_gen_scratch_sse_rtx):
Removed.
* config/i386/i386.cc (ix86_gen_scratch_sse_rtx): Removed.
(TARGET_GEN_MEMSET_SCRATCH_RTX): Removed.
* doc/tm.texi: Remove TARGET_GEN_MEMSET_SCRATCH_RTX.
* doc/tm.texi.in: Ditto.
* target.def: Ditto.

Daily bump.

libstdc++: Fix assigning nullptr to std::atomic<shared_ptr<T>> (LWG 3893)

LWG voted this to Tentatively Ready recently.

libstdc++-v3/ChangeLog:

* include/bits/shared_ptr_atomic.h (atomic::operator=(nullptr_t)):
Add overload, as per LWG 3893.
* testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc:
Check assignment from nullptr.

testsuite: always use UTF-8 in scan-sarif-file[-not] [PR105959]

c-c++-common/diagnostic-format-sarif-file-4.c is a test case for
quoting non-ASCII source code in a SARIF diagnostic log.

The SARIF standard mandates that .sarif files are UTF-8 encoded.

PR testsuite/105959 notes that the test case fails when the system
encoding is not UTF-8, such as when the "make" invocation is prefixed
with LC_ALL=C, whereas it works with in a UTF-8-locale.

The root cause is that dg-scan opens the file for reading using the
"system" encoding; I believe it is falling back to treating all files as
effectively ISO 8859-1 in a non-UTF-8 locale.

This patch fixes things by adding a mechanism to dg-scan to allow
callers to (optionally) specify an encoding to use when reading the
file, and updating scan-sarif-file (and the -not variant) to always
use UTF-8 when calling dg-scan, fixing the test case with LC_ALL=C.

gcc/testsuite/ChangeLog:
PR testsuite/105959
* gcc.dg-selftests/dg-final.exp
(dg_final_directive_check_num_args): Update expected maximum
number of args for the various directives using dg-scan.
* lib/scanasm.exp (append_encoding_arg): New procedure.
(dg-scan): Add optional 3rd argument: the encoding to use when
reading from the file.
* lib/scansarif.exp (scan-sarif-file): Treat the file as UTF-8
encoded when reading it.
(scan-sarif-file-not): Likewise.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

compiler: add missing Slice_info_expression::do_traverse

Fixes golang/go#59169

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/478176

c++: array bound partial ordering [PR108390]

fold_convert doesn't work with a dependent argument, and problematically
differed from the corresponding fold+build_nop further down in the
function.  So change it to match.

PR c++/108390

gcc/cp/ChangeLog:

* pt.cc (unify): Use fold of build_nop instead of fold_convert.

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-order3.C: New test.

Fortran: improve checking of FINAL subroutine arguments [PR104572]

gcc/fortran/ChangeLog:

PR fortran/104572
* resolve.cc (gfc_resolve_finalizers): Argument of a FINAL subroutine
cannot be an alternate return.

gcc/testsuite/ChangeLog:

PR fortran/104572
* gfortran.dg/pr104572.f90: New test.

Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>

libstdc++: Remove std::formatter<const charT[N], charT> specialization

This was approved in Issaquah as LWG 3833.

libstdc++-v3/ChangeLog:

* include/std/format (formatter<const charT[N], charT>): Do not
define partial speclialization, as per LWG 3833.
* testsuite/std/format/formatter/requirements.cc: Check it.

libstdc++: Define __cpp_lib_constexpr_algorithms in <utility> (LWG 3792)

We actually defined this macro in <utility> at one point, but I removed
it in r10-7901-g2025db692e9ed1.

libstdc++-v3/ChangeLog:

* include/std/utility (__cpp_lib_constexpr_algorithms): Define,
as per LWG 3792.
* testsuite/20_util/exchange/constexpr.cc: Check for it.

libstdc++: Add missing __cpp_lib_format macro to <version>

libstdc++-v3/ChangeLog:

* include/std/version (__cpp_lib_format): Define.
* testsuite/std/format/functions/format.cc: Check it.

libstdc++: Use rvalues in std::string::resize_and_overwrite (LWG 3645)

Previously the C++23 draft required that the callback arguments were
lvalues, which was overvable by the callback. LWG 3645 removes that
overspecification, so we can pass rvalues and the user can't modify
our local variables. I've used auto(p) to produce rvalues, which is only
supported since Clang 15, but I think that's OK for a C++23 feature.

While making this change I noticed that we weren't correctly enforcing
the requirement that the callback returns an integer-like type. Add
better assertions for the type and value.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.tcc (basic_string::resize_and_overwrite):
Pass rvalues to the callback, as now allowed by LWG 3645.
Enforce preconditions on the return value.
* testsuite/21_strings/basic_string/capacity/char/resize_and_overwrite.cc:
Adjust.

libstdc++: Add comment to <format> (LWG 3720)

libstdc++-v3/ChangeLog:

* include/std/format: Add a comment noting that the resolution
of LWG 3720 has been applied..

libstdc++: Add allocator-extended constructors to std::match_results (LWG 2195)

This was approved in Issaquah last month.

libstdc++-v3/ChangeLog:

* include/bits/regex.h (match_results): Add allocator-extended
copy and move constructors, as per LWG 2195.
* testsuite/28_regex/match_results/ctors/char/alloc.cc: New test.

libstdc++: Make std::istream_iterator copy ctor constexpr (LWG 3600)

As explained in LWG 3600, we never implemented a C++0x change that made
the copy constructor of std::istream_iterator defined as defaulted. That
would be an ABI break, so the resolution of LWG 3600 is to not require
it to be trivial, but just constexpr and conditionally noexcept. This
applies that resolution.

libstdc++-v3/ChangeLog:

* include/bits/stream_iterator.h (istream_iterator): Add
constexpr to copy constructor, as per LWG 3600.
* testsuite/24_iterators/istream_iterator/cons/constexpr.cc:
Check copy construction.

LRA: Do not repeat inheritance and live range splitting in case of asm error

LRA was trying to do live range splitting again and again as there were
no enough regs for asm.  This patch solves the problem.

        PR target/109137

gcc/ChangeLog:

* lra.cc (lra): Do not repeat inheritance and live range splitting
when asm error is found.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr109137.c: New.

modula2: Add cwd to include path.  Include m2cor before m2pim.

The driver should default to include the current working directory in the
module search path.  This patch adds . to the search path provided
-fm2-pathname has not been specified.  The patch also reorders the pim
libraries so that the m2cor directory is searched before m2pim.
Coroutine support is visible by default for both -fpim and -fiso
(from their respective SYSTEM modules).

gcc/m2/ChangeLog:

PR modula2/109248
* Make-lang.in (m2/pge-boot/%.o): Add CFLAGS and CXXFLAGS for C
and C++ compiles.
* gm2spec.cc (add_m2_I_path): Indentation.
(lang_specific_driver): New variable seen_pathname.
Detect -fm2-pathname.  If not seen then push_back_Ipath (".").
Change non iso library path to "m2cor,m2log,m2pim,m2iso".

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

c++: attribute on dtor in template [PR108795]

Since r7-2549 we were throwing away the explicit C:: when we found that ~C
has an attribute that we treat as making its type dependent.

PR c++/108795

gcc/cp/ChangeLog:

* semantics.cc (finish_id_expression_1): Check scope before
returning id_expression.

gcc/testsuite/ChangeLog:

* g++.dg/ext/attr-tsafe1.C: New test.

c++: Avoid duplicate diagnostic calling unavailable function [PR109177]

As the PR shows, we currently emit duplicate diagnostics for calls to
functions marked with __attribute__((unavailable)). This patch fixes
that.

gcc/cp/ChangeLog:

PR c++/109177
* call.cc (build_over_call): Use make_temp_override to suppress
both unavailable and deprecated warnings when calling
build_addr_func.

gcc/testsuite/ChangeLog:

PR c++/109177
* g++.dg/ext/pr109177.C: New test.

analyzer: fix false +ves from -Wanalyzer-deref-before-check due to inlining [PR109239]

The patch has this effect on my integration tests of -fanalyzer:

  Comparison:
    GOOD: 129        (17.70% -> 17.92%)
     BAD: 600 -> 591 (-9)

which is purely due to improvements to -Wanalyzer-deref-before-check
on the Linux kernel:

  -Wanalyzer-deref-before-check:
    GOOD: 1        (4.55% -> 7.69%)
     BAD: 21 -> 12 (-9)
     Known false positives: 16 -> 10 (-6)
       linux-5.10.162: 7 -> 1 (-6)
     Suspected false positives: 3 -> 0 (-3)
       linux-5.10.162: 3 -> 0 (-3)

gcc/analyzer/ChangeLog:
PR analyzer/109239
* program-point.cc: Include "analyzer/inlining-iterator.h".
(program_point::effectively_intraprocedural_p): New function.
* program-point.h (program_point::effectively_intraprocedural_p):
New decl.
* sm-malloc.cc (deref_before_check::emit): Use it when rejecting
interprocedural cases, so that we reject interprocedural cases
that have become intraprocedural due to inlining.

gcc/testsuite/ChangeLog:
PR analyzer/109239
* gcc.dg/analyzer/deref-before-check-pr109239-linux-bus.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

amdgcn: Add instruction patterns for complex number operations.

gcc/ChangeLog:

* config/gcn/gcn-protos.h (gcn_expand_dpp_swap_pairs_insn)
(gcn_expand_dpp_distribute_even_insn)
(gcn_expand_dpp_distribute_odd_insn): Declare.
* config/gcn/gcn-valu.md (@dpp_swap_pairs<mode>)
(@dpp_distribute_even<mode>, @dpp_distribute_odd<mode>)
(cmul<conj_op><mode>3, cml<addsub_as><mode>4, vec_addsub<mode>3)
(cadd<rot><mode>3, vec_fmaddsub<mode>4, vec_fmsubadd<mode>4)
(fms<mode>4<exec>, fms<mode>4_negop2<exec>, fms<mode>4)
(fms<mode>4_negop2): New patterns.
* config/gcn/gcn.cc (gcn_expand_dpp_swap_pairs_insn)
(gcn_expand_dpp_distribute_even_insn)
(gcn_expand_dpp_distribute_odd_insn): New functions.
* config/gcn/gcn.md: Add entries to unspec enum.

gcc/testsuite/ChangeLog:

* gcc.target/gcn/complex.c: New test.

MAINTAINERS: Add myself as OpenMP and libgomp maintainer

ChangeLog:
* MAINTAINERS: Add myself as OpenMP and libgomp maintainer.

frange: Implement nan_state class [PR109008]

This patch implements a nan_state class, that allows us to query or
pass around the NANness of an frange.  We can store +NAN, -NAN, +-NAN,
or not-a-NAN with it.

I tried to touch as little as possible, leaving other cleanups to the
next release.  For example, we should replace the m_*_nan fields in
frange with nan_state, and provide relevant accessors to nan_state
(isnan, etc).

PR tree-optimization/109008

gcc/ChangeLog:

* value-range.cc (frange::set): Add nan_state argument.
* value-range.h (class nan_state): New.
(frange::get_nan_state): New.

configure: regenerate

gcc/ChangeLog:

* configure: Regenerate.

PR modula2/107630 Remove M2LINK and remove some cross linking

Remove M2LINK.def.  Pass the user forced module initialization string as
a parameter to M2RTS.ConstructModules.  This patch allows
-fm2-whole-program to link successfully using dynamic libraries.

gcc/m2/ChangeLog:

PR modula2/107630
* Make-lang.in (m2/stage2/cc1gm2$(exeext)): Remove
m2/gm2-libs-boot/M2LINK.o.
(m2/stage1/cc1gm2$(exeext)): Ditto.
(GM2-LIBS-BOOT-DEFS): Remove M2LINK.def.
(GM2-LIBS-DEFS): Ditto.
(m2/mc-boot/$(SRC_PREFIX)%.o): Replace CXX_FLAGS with CXXFLAGS.
(m2/mc-boot-ch/$(SRC_PREFIX)%.o): Ditto.
(m2/mc-boot/main.o): Ditto.
(mcflex.o): Add $(CFLAGS).
(m2/gm2-libs-boot/M2LINK.o): Remove rule.
* gm2-compiler/M2GCCDeclare.def (DeclareM2linkGlobals): Remove.
* gm2-compiler/M2GCCDeclare.mod: (M2LinkEntry): Remove.
(M2LinkIndex): Remove.
(DoVariableDeclaration): Remove initial and call to
AddEntryM2Link.
(AddEntryM2Link): Remove.
(GetEntryM2Link): Remove.
(DeclareM2linkGlobals): Remove.
(DetectM2LinkInitial): Remove.
(InitM2LinkModule): Remove.
* gm2-compiler/M2GenGCC.mod (CodeFinallyEnd): Remove call to
DeclareM2linkGlobals.
* gm2-compiler/M2Quads.mod (BuildM2InitFunction): Add extra
parameter containing runtime module override to ConstructModules.
* gm2-compiler/M2Scaffold.mod: Update comment describing
ConstructModules.
* gm2-gcc/m2decl.cc (m2decl_DeclareM2linkForcedModuleInitOrder):
Remove.
* gm2-libs-iso/M2RTS.def (ConstructModules): Add overrideliborder
parameter.
* gm2-libs-iso/M2RTS.mod: Add overrideliborder parameter.
* gm2-libs/M2Dependent.def (ConstructModules): Add overrideliborder
parameter.
* gm2-libs/M2Dependent.mod (ConstructModules): Add overrideliborder
parameter.
* gm2-libs/M2RTS.def (ConstructModules): Add overrideliborder parameter.
* gm2-libs/M2RTS.mod (ConstructModules): Add overrideliborder
parameter.
* gm2-libs/M2LINK.def: Removed.

libgm2/ChangeLog:

* libm2pim/Makefile.am (M2DEFS): Remove M2LINK.def.
* libm2pim/Makefile.in: Rebuild.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

Daily bump.

stor-layout: Set TYPE_TYPELESS_STORAGE consistently for type variants

I've observed an LTO wrong-code bug with a large testcase in GCC 12,
that results from TYPE_TYPELESS_STORAGE not being set consistently on
type variants.

Specifically, in the LTO stage of compilation, there is an aggregate
type passed to get_alias_set, whose TYPE_MAIN_VARIANT does not have
TYPE_TYPELESS_STORAGE set.  However, the TYPE_CANONICAL of that main
variant *does* have have TYPE_TYPELESS_STORAGE set; note that the use
of TYPE_CANONICAL in get_alias_set comes after the check of
TYPE_TYPELESS_STORAGE.  The effect is that when (one-argument)
record_component_aliases is called, the recursive call to
get_alias_set gives alias set 0, and the aggregate type ends up not
being considered to alias its members, with wrong-code consequences.

I haven't managed to produce a self-contained executable testcase to
demonstrate this, but it clearly seems appropriate for
TYPE_TYPELESS_STORAGE to be consistent on type variants, so this patch
makes it so, which appears to be sufficient to resolve the bug.  I've
attached a reduced test to
<https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614278.html>
that does at least demonstrate main-variant versions of a type (SB in
this test) being written out to LTO IR both with and without
TYPE_TYPELESS_STORAGE, although not the subsequent consequences of a
type without TYPE_TYPELESS_STORAGE with a TYPE_CANONICAL (as
constructed after LTO type merging) with TYPE_TYPELESS_STORAGE and
following wrong-code.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

* stor-layout.cc (finalize_type_size): Copy TYPE_TYPELESS_STORAGE
to variants.

libstdc++: Use more precise __RECIPROCAL_MATH__ macro

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:

* include/experimental/bits/simd_x86.h
(_SimdImplX86::_S_divides): Replace test for __GCC_IEC_559 == 0
with __RECIPROCAL_MATH__.

libstdc++: Skip integer division optimization for Clang

Clang ICEs on _SimdImplX86::_S_divides. The function is only working
around a missed optimization and not necessary for correctness.
Therefore, don't use it for Clang.

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:

* include/experimental/bits/simd_detail.h: Don't define
_GLIBCXX_SIMD_WORKAROUND_PR90993 for Clang.
* include/experimental/bits/simd_x86.h (_S_divides): Remove
check for __clang__.

Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

gcc/fortran/ChangeLog:

PR fortran/99036
* decl.cc (gfc_match_modproc): Reject MODULE PROCEDURE if not in a
generic module interface.

gcc/testsuite/ChangeLog:

PR fortran/99036
* gfortran.dg/pr99036.f90: New test.

libstdc++: Fix simd compilation with Clang

Clang fails to compile some constant expressions involving simd.
Therefore, just disable this non-conforming extension for clang.

Fix AVX512 blend implementation for Clang. It was converting the bitmask
to bool before, which is obviously wrong. Instead use a Clang builtin to
convert the bitmask to vector-mask before using a vector blend ?:. A
similar change is required for the masked unary implementation, because
the GCC builtins do not exist on Clang.

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:

* include/experimental/bits/simd_detail.h: Don't declare the
simd API as constexpr with Clang.
* include/experimental/bits/simd_x86.h (__movm): New.
(_S_blend_avx512): Resolve FIXME. Implement blend using __movm
and ?:.
(_SimdImplX86::_S_masked_unary): Clang does not implement the
same builtins. Implement the function using __movm, ?:, and -
operators on vector_size types instead.

c++: DMI in template with virtual base [PR106890]

When parsing a default member init we just build a CONVERT_EXPR for
converting to a virtual base, and then expand that into the more complex
form when we actually use the DMI in a constructor.  But that wasn't working
for the template case where we are considering the conversion at the point
that the constructor needs the DMI instantiation, so it seemed like we were
in a constructor already.  And then when the other constructor tries to
reuse the instantiation, it sees uses of the first constructor's parameters,
and dies.  So ensure that we get the CONVERT_EXPR in this case, too.

PR c++/106890

gcc/cp/ChangeLog:

* init.cc (maybe_instantiate_nsdmi_init): Don't leave
current_function_decl set to a constructor.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template25.C: New test.

Terminate GORI calculations if a relation is not relevant.

We currently allow VARYING lhs GORI calculations to continue if there is
a relation present in the hope it will eventually better refine a result.
This adds a check that the relation is relevant to the outgoing range
calculation first.  If it is not relevant, stop calculating.

PR tree-optimization/109192
* gimple-range-gori.cc (gori_compute::compute_operand_range):
Terminate gori calculations if a relation is not relevant.
* value-relation.h (value_relation::set_relation): Allow
equality between op1 and op2 if they are the same.

tree-optimization/109219 - avoid looking at STMT_SLP_TYPE

The following avoids looking at STMT_SLP_TYPE apart from the only
place needing it - transform and analysis of non-SLP loop stmts.
In particular it doesn't have a reliable meaning on SLP representatives
which are also passed as stmt_vinfo to vectorizable_* routines.  The
proper way to check in those is to look for the slp_node argument
instead.

PR tree-optimization/109219
* tree-vect-loop.cc (vectorizable_reduction): Check
slp_node, not STMT_SLP_TYPE.
* tree-vect-stmts.cc (vectorizable_condition): Likewise.
* tree-vect-slp.cc (vect_slp_analyze_node_operations_1):
Remove assertion on STMT_SLP_TYPE.

* gcc.dg/torture/pr109219.c: New testcase.

testsuite: Remove obsolete comments [PR108898]

On Tue, Mar 21, 2023 at 12:35:19PM +0000, Andrew Stubbs wrote:
> >   /* Ensure the the in-branch simd clones are used on targets that support them.
> >      Some targets use another call for the epilogue loops.  */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 2 "vect" { target { ! aarch64*-*-* } } } } */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 3 "vect" { target aarch64*-*-* } } } */
> > +/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 2 "vect" } } */
>
> I suppose those comments are now obsolete.

Oops, fixed thusly.

2023-03-21  Jakub Jelinek  <jakub@redhat.com>

PR testsuite/108898
* gcc.dg/vect/vect-simd-clone-16.c: Remove parts of comment mentioning
epilogue loops.
* gcc.dg/vect/vect-simd-clone-17.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18.c: Likewise.

testsuite: Fix up vect-simd-clone1[678]*.c tests [PR108898]

As mentioned in the PR, vect-simd-clone-1[678]{,f}.c tests FAIL on
x86_64-linux with -m64/-march=cascadelake or -m32/-march=cascadelake,
there are 3 matches for the calls rather than expected two.
As suggested by Richi, this patch changes those tests to use
--param vect-epilogues-nomask=0 such that it is more predictable on how
many calls will show up.  In the non-[a-f] suffixed tests, the
scan-tree-dump-times patterns were expecting 2 for non-aarch64 and 3 for
aarch64, which is a puzzle for me, because vect_simd_clones effective
target is apparently never true on aarch64 (just on x86 in some cases and
on amdgcn; perhaps something to change for GCC14, but I guess too late
for stage4).  That said, I have looked at aarch64 dumps and see only 2
calls with --param vect-epilogues-nomask=0 and 3 with --param
vect-epilogues-nomask=1 or without it, so I have tweaked those to always
expect the same thing.  Another thing is some tests uselessly had
-fdump-tree-optimized in dg-options even when they don't scan anything
there.

Tested on x86_64-linux with
make -j32 -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-*.c \
--target_board='unix{-m64/-march=x86-64,-m64/-march=cascadelake,-m32/-march=i686,-m32/-march=cascadelake}'"
and aarch64-linux (where all tests are UNSUPPORTED before/after).

2023-03-21  Jakub Jelinek  <jakub@redhat.com>

PR testsuite/108898
* gcc.dg/vect/vect-simd-clone-16.c: Add --param vect-epilogues-nomask=0
to dg-additional-options.  Always expect just 2 foo.simdclone calls.
* gcc.dg/vect/vect-simd-clone-16f.c: Add
--param vect-epilogues-nomask=0 to dg-additional-options.
* gcc.dg/vect/vect-simd-clone-17.c: Likewise.  Always expect just 2
foo.simdclone calls.
* gcc.dg/vect/vect-simd-clone-17d.c: Remove -fdump-tree-optimized from
dg-additional-options.
* gcc.dg/vect/vect-simd-clone-17e.c: Likewise.
* gcc.dg/vect/vect-simd-clone-17f.c: Likewise.  Add
--param vect-epilogues-nomask=0 to dg-additional-options.
* gcc.dg/vect/vect-simd-clone-18.c: Add --param vect-epilogues-nomask=0
to dg-additional-options.  Always expect just 2 foo.simdclone calls.
* gcc.dg/vect/vect-simd-clone-18f.c: Add
--param vect-epilogues-nomask=0 to dg-additional-options.

libstdc++: Fix simd test compilation with Clang

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:

* testsuite/experimental/simd/tests/operators.cc: Clang doesn't
define __GCC_IEC_559. Use __STDC_IEC_559__ instead.

tree: Fix up component_ref_sam_type handling of arrays of 0 sized elements [PR109215]

Our documentation sadly talks about elt_type arr[0]; as zero-length arrays,
not arrays with zero elements.  Unfortunately, those aren't the only arrays
which can have zero size, the same size can be also result of zero-length
element, like in GNU C struct whatever {} or in GNU C/C++ if the element
type is [0] array or combination thereof (dunno if Ada doesn't allow
something similar too).  One can't do much with them, taking address of
their elements, (no-op) copying of the elements in and out.  But they
behave differently from arr[0] arrays e.g. in that using non-zero indexes
in them (as long as they are within bounds as for normal arrays) is valid.

I think this naming inaccuracy resulted in Martin designing
special_array_member in an inconsistent way, mixing size zero array members
with array members of one or two or more elements and then using the
size zero interchangeably with zero elements.

The following patch changes that (but doesn't do any
documentation/diagnostics renaming, as this is really a corner case),
such that int_0/trail_0 for consistency is just about [0] arrays
plus [] for the latter, not one or more zero sized elements case.

The testcase has one xfailed case for where perhaps in later GCC versions
we could add extra code to handle it, for some reason we don't diagnose
out of bounds accesses for the zero sized elements cases.  It will be
harder because e.g. FRE will canonicalize &var.fld[0] and &var.fld[10]
to just one of them because they are provably the same address.
But the important thing is to fix this regression (where we warn on
completely valid code in the Linux kernel).  Anyway, for further work
on this we don't really need any extra help from special_array_member,
all code can just check integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (type))),
it doesn't depend on the position of the members etc.

2023-03-21  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/109215
* tree.h (enum special_array_member): Adjust comments for int_0
and trail_0.
* tree.cc (component_ref_sam_type): Clear zero_elts if memtype
has zero sized element type and the array has variable number of
elements or constant one or more elements.
(component_ref_size): Adjust comments, formatting fix.

* gcc.dg/Wzero-length-array-bounds-3.c: New test.

html: Set CONTENTS_OUTPUT_LOCATION=inline if makeinfo supports it

This flag allows us to restore old (pre-6.8) behavior of the
@{summary,}content commands, so that texi2any continues to emit
summarycontents first.

maintainer-scripts/ChangeLog:

* update_web_docs_git: Set CONTENTS_OUTPUT_LOCATION=inline in
order to put @shortcontents above contents.

gcc/ChangeLog:

* configure.ac: Add check for the Texinfo 6.8
CONTENTS_OUTPUT_LOCATION customization variable and set it if
supported.
* configure: Regenerate.
* Makefile.in (MAKEINFO_TOC_INLINE_FLAG): New variable.  Set by
configure.ac to -c CONTENTS_OUTPUT_LOCATION=inline if
CONTENTS_OUTPUT_LOCATION support is detected, empty otherwise.
($(build_htmldir)/%/index.html): Pass MAKEINFO_TOC_INLINE_FLAG.

docs: Fix up new instances of index reordering

This commit fixes up an instance of the index entry mis-ordering that
occurred between the formulation and application of commit
r13-6310-gf33d7a88d069d1.

gcc/ChangeLog:

* doc/extend.texi: Associate use_hazard_barrier_return index
entry with its attribute.
* doc/invoke.texi: Associate -fcanon-prefix-map index entry with
its attribute

update_web_docs_git: Update CSS reference to new manual CSS

maintainer-scripts/ChangeLog:

* update_web_docs_git (CSS): Update CSS reference to point to
/texinfo-manuals.css.

doc: Remove the @gol macro/alias

The @gol macro appears to have existed as a workaround for a bug in old
versions of makeinfo and/or texinfo.tex, where they would, in some types
of output, fail to emit line breaks in @gccoptlists.  After updating
texinfo.tex, I noticed that this behavior appears to no longer be
exhibited, instead, both acted correctly and inserted newlines.  The
(groff) manual output also appears unaffected.

gcc/ChangeLog:

* doc/implement-c.texi: Remove usage of @gol.
* doc/invoke.texi: Ditto.
* doc/sourcebuild.texi: Ditto.
* doc/include/gcc-common.texi: Remove @gol.  In new Makeinfo and
texinfo.tex versions, the bug it was working around appears to
be gone.

gcc/fortran/ChangeLog:

* invoke.texi: Remove usages of @gol.
* intrinsic.texi: Ditto.

doc: Update texinfo.tex

gcc/ChangeLog:

* doc/include/texinfo.tex: Update to 2023-01-17.19.

docs: Add @defbuiltin family of helpers

The @defbuiltin{,x} macros are convenience macros for the often-repeated
task of defining a built-in function in extend.texi.  Usage of this
macro should lead to a higher degree of consistency across pieces of
text written by different people, and provide a better reading
experience, as they prevent easy-to-make errors, like forgetting index
entries for these functions.

gcc/ChangeLog:

* doc/include/gcc-common.texi: Add @defbuiltin{,x} and
@enddefbuiltin for defining built-in functions.
* doc/extend.texi: Apply @defbuiltin{,x} to many, but not all,
places where it should be used.

doc: Fix a few minor errors spotted by testers

This commit addresses a few minor errors that were spotted while testing
the GCC manual with a few people, and while working on wider changes.

gcc/ChangeLog:

* doc/extend.texi (Formatted Output Function Checking): New
subsection for  grouping together printf et al.
(Exception handling) Fix missing @ sign before copyright
header, which lead to the copyright line leaking into
'(gcc)Exception handling'.
* doc/gcc.texi: Set document language to en_US.
(@copying): Wrap front cover texts in quotations, move in manual
description text.

docs: Create Indices appendix

The GCC manual has multiple indices.  By creating an appendix which
lists them, we help makeinfo present a more accessible way for the
reader to see all the indices.

gcc/ChangeLog:

* doc/gcc.texi: Add the Indices appendix, to make texinfo
generate nice indices overview page.

tree-optimization/109170 - bogus use-after-free with __builtin_expect

The following adds a missing range-op for __builtin_expect which
helps -Wuse-after-free to detect the case a realloc original
pointer is used when the result was NULL.  The implementation
should handle all argument one pass-through builtins we handle
in the fnspec machinery, but that's defered to GCC 14.

The gcc.dg/tree-ssa/ssa-lim-21.c testcase needs adjustment because

   for (int j = 0; j < m; j++)
     if (__builtin_expect (m, 0))
       for (int i = 0; i < m; i++)

is now correctly optimized to a unconditional jump by EVRP - m
cannot be zero when the outer loop is entered.  I've adjusted
the outer loop to iterate 'n' times which makes us apply store-motion
to 'count' and 'q->data1' but only out of the inner loop and
as expected not apply store motion to 'q->data' at all.

The gcc.dg/predict-20.c testcase relies on broken behavior of
profile estimation when trying to handle __builtin_expect values
flowing into PHI nodes.  I have opened PR109210 and removed
the expected matching from the testcase.

PR tree-optimization/109170
* gimple-range-op.cc (cfn_pass_through_arg1): New.
(gimple_range_op_handler::maybe_builtin_call): Handle
__builtin_expect via cfn_pass_through_arg1.

* gcc.dg/Wuse-after-free-pr109170.c: New testcase.
* gcc.dg/tree-ssa/ssa-lim-21.c: Adjust.
* gcc.dg/predict-20.c: Likewise.

Fortran: Fix regression caused by PR37336 patch [PR109206]

2023-03-21  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
PR fortran/109206
* trans-array.cc (gfc_trans_array_constructor_value): Correct
incorrect setting of typespec.

Fortran: Fix regression caused by PR37336 patch [PR109209]

2023-03-21  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
PR fortran/109209
* resolve.cc (generate_component_assignments): Restore the
exclusion of allocatable components from the loop.

gcc/testsuite/
PR fortran/109209
* gfortran.dg/pr109209.f90: New test.

[modula2] Add $(CXX_FLAGS) to the bootstrap tool rules.

The bootstrap tool mc is built using $(CXX) and it is missing
$(CXXFLAGS).

gcc/m2/ChangeLog:

* Make-lang.in (m2/mc-boot/$(SRC_PREFIX)%.o): Add $(CXXFLAGS).
(m2/mc-boot-ch/$(SRC_PREFIX)%.o): Add $(CXXFLAGS).
(m2/mc-boot-ch/$(SRC_PREFIX)%.o): Add $(CXXFLAGS).
(m2/mc-boot/main.o): Add $(CXXFLAGS).

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

Daily bump.

libstdc++: Fix formatting in std::filesystem helper function

libstdc++-v3/ChangeLog:

* src/filesystem/ops-common.h (get_temp_directory_from_env): Fix
formatting.

Update gcc sv.po

* sv.po: Update.

Fortran: fix documentation of -fno-underscoring [PR109216]

gcc/fortran/ChangeLog:

PR fortran/109216
* invoke.texi: Correct documentation of how underscores are appended
to external names.

c++: explicit ctor and list-initialization [PR109159]

When I implemented explicit(bool) in r9-3735, I added this code to
add_template_candidate_real:
+  /* Now the explicit specifier might have been deduced; check if this
+     declaration is explicit.  If it is and we're ignoring non-converting
+     constructors, don't add this function to the set of candidates.  */
+  if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn))
+    return NULL;
but as this test demonstrates, that's incorrect when we're initializing
from a {}: for list-initialization we consider explicit constructors and
complain if one is chosen.

PR c++/109159

gcc/cp/ChangeLog:

* call.cc (add_template_candidate_real): Add explicit decls to the
set of candidates when the initializer is a braced-init-list.

libstdc++-v3/ChangeLog:

* testsuite/20_util/pair/cons/explicit_construct.cc: Adjust dg-error.
* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
* testsuite/23_containers/span/explicit.cc: Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/explicit16.C: New test.

c++: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

The following two testcases are miscompiled, because we keep TREE_READONLY
on the vars even when they are (possibly) dynamically initialized by a TLS
wrapper function.  Normally cp_finish_decl drops TREE_READONLY from vars
which need dynamic initialization, but for TLS we do this kind of
initialization upon every access to those variables.  Keeping them
TREE_READONLY means e.g. PRE can hoist loads from those before loops
which contain the TLS wrapper calls, so we can access the TLS variables
before they are initialized.

2023-03-20  Jakub Jelinek  <jakub@redhat.com>

PR c++/109164
* cp-tree.h (var_needs_tls_wrapper): Declare.
* decl2.cc (var_needs_tls_wrapper): No longer static.
* decl.cc (cp_finish_decl): Clear TREE_READONLY on TLS variables
for which a TLS wrapper will be needed.

* g++.dg/tls/thread_local13.C: New test.
* g++.dg/tls/thread_local13-aux.cc: New file.
* g++.dg/tls/thread_local14.C: New test.
* g++.dg/tls/thread_local14-aux.cc: New file.

Rework 128-bit complex multiply and divide.

This patch reworks how the complex multiply and divide built-in functions are
done.  Previously GCC created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit.  However, it did not
support __ibm128 complex multiply and divide if long double is IEEE 128-bit.

This code does not create the built-in declaration with the changed name.
Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name
before it is written out to the assembler file like it now does for all of the
other long double built-in functions.

2023-03-20   Michael Meissner  <meissner@linux.ibm.com>

gcc/

PR target/109067
* config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
(init_float128_ieee): Delete code to switch complex multiply and divide
for long double.
(complex_multiply_builtin_code): New helper function.
(complex_divide_builtin_code): Likewise.
(rs6000_mangle_decl_assembler_name): Add support for mangling the name
of complex 128-bit multiply and divide built-in functions.

gcc/testsuite/

PR target/109067
* gcc.target/powerpc/divic3-1.c: New test.
* gcc.target/powerpc/divic3-2.c: Likewise.
* gcc.target/powerpc/mulic3-1.c: Likewise.
* gcc.target/powerpc/mulic3-2.c: Likewise.

Fortran: simplification of NEAREST for large argument [PR109186]

gcc/fortran/ChangeLog:

PR fortran/109186
* simplify.cc (gfc_simplify_nearest): Fix off-by-one error in setting
up real kind-specific maximum exponent for mpfr.

gcc/testsuite/ChangeLog:

PR fortran/109186
* gfortran.dg/nearest_6.f90: New test.

rs6000: Don't ICE when compiling the __builtin_vec_xst_trunc built-in [PR109178]

When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
for the MEM operand which causes an unrecognizable insn ICE.  The solution
is to use the correct TMODE mode.

2023-03-20  Peter Bergner  <bergner@linux.ibm.com>

gcc/
PR target/109178
* config/rs6000/rs6000-builtin.cc (stv_expand_builtin): Use tmode.

gcc/testsuite/
PR target/109178
* gcc.target/powerpc/pr109178.c: New test.

testsuite: Fix up 20230313.C test

I've noticed this testcase FAILs on i686-linux with
-fstack-protector-strong.

sizeof (auto_vec<int, 8>) == 16, which in this case contains
4-byte m_vec (which points to to m_auto), then 8-byte m_auto
which contains just 8-byte m_vecpfx and finally 1 byte m_data,
rest is padding.  We then try to push 2 ints to it, so 8 bytes,
starting at the end of m_vecpfx aka address of m_data, but there
is just 1 byte + 3 bytes of padding.
In the lp64 case, I think sizeof (auto_vec<int, 8>) == 24,
because there is 8-byte m_vec, 8-byte m_vecpfx and 1-byte m_char
all with 8-byte alignment.

2023-03-20  Jakub Jelinek  <jakub@redhat.com>

* g++.dg/torture/20230313.C (auto_vec): Change m_data type
from char to char [2 * sizeof (int)].

libstdc++: Remove template-head from std::expected<void> ctor [PR109182]

The presence of a template-head on this constructor is a copy & paste
error from the primary template.

libstdc++-v3/ChangeLog:

PR libstdc++/109182
* include/std/expected (expected<void>::expected(in_place_t)):
Remove template-head.

Fortran: Allow external function from in an associate block [PR87127]

2023-03-20  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
PR fortran/87127
* resolve.cc (check_host_association): If an external function
is typed but not declared explicitly to be external, change the
old symbol from a variable to an external function.

gcc/testsuite/
PR fortran/87127
* gfortran.dg/external_procedures_4.f90: New test.