There's heuristic to detect ptr[1].a[...] out of bound accesses
reasoning that if ptr points to an array of aggregates a trailing
incomplete array has to have size zero. The following more
thoroughly constrains the cases this applies to avoid false
positive diagnostics.
2022-05-25 Richard Biener <rguenther@suse.de>
PR tree-optimization/105726
* gimple-ssa-warn-restrict.cc (builtin_memref::set_base_and_offset):
Constrain array-of-flexarray case more.
* g++.dg/warn/Warray-bounds-27.C: New testcase.
The following testcase triggers a false positive UBSan binding a reference
to null diagnostics.
In the FE we instrument conversions from pointer to reference type
to diagnose at runtime if the operand of such a conversion is 0.
The problem is that a GENERIC folding folds
((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) range_check (x)
conversion to const struct Bar & by converting to that the first
operand of the POINTER_PLUS_EXPR. But that changes when the -fsanitize=null
binding to reference runtime check occurs. Without the optimization,
it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check
call throws, that means it never triggers in the testcase.
With the optimization, it checks whether this->data is NULL and it is.
The following patch avoids that optimization during GENERIC folding when
-fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to
REFERENCE_TYPE.
2022-05-27 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105729
* fold-const.cc (fold_unary_loc): Don't optimize (X &) ((Y *) z + w)
to (X &) z + w if -fsanitize=null during GENERIC folding.
* g++.dg/ubsan/pr105729.C: New test.
"For every pessimization, there's an equal and opposite optimization".
In the review of my original patch for PR middle-end/98865, Richard
Biener pointed out that match.pd shouldn't be transforming X*Y into
X&-Y as the former is considered cheaper by tree-ssa's cost model
(operator count). A corollary of this is that we should instead be
transforming X&-Y into the cheaper X*Y as a preferred canonical form
(especially as RTL expansion now intelligently selects the appropriate
implementation based on the target's costs).
With this patch we now generate identical code for:
int foo(int x, int y) { return -(x&1) & y; }
int bar(int x, int y) { return (x&1) * y; }
specifically on x86_64-pc-linux-gnu both use and/neg/and with -O2,
but both use and/mul with -Os.
One minor wrinkle/improvement is that this patch includes three
additional optimizations (that account for the change in canonical
form) to continue to optimize PR92834 and PR94786.
2022-05-27 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* match.pd (match_zero_one_valued_p): New predicate.
(mult @0 @1): Use zero_one_valued_p for optimization to the
expression "bit_and @0 @1".
(bit_and (negate zero_one_valued_p@0) @1): Optimize to MULT_EXPR.
(plus @0 (mult (minus @1 @0) zero_one_valued_p@2)): New transform.
(minus @0 (mult (minus @0 @1) zero_one_valued_p@2)): Likewise.
(bit_xor @0 (mult (bit_xor @0 @1) zero_one_valued_p@2)): Likewise.
Remove three redundant transforms obsoleted by the three above.
gcc/testsuite/ChangeLog
* gcc.dg/pr98865.c: New test case.
A common idiom for testing if a specific set of bits is set in a value
is to use "(X & Y) == Y", which on x86 results in an AND followed by a
CMP. A slightly improved implementation is to instead use (~X & Y)==0,
that uses a NOT and a TEST (or ANDN where available); still two "fast"
instructions, but typically shorter especially if Y is an immediate
constant. Because the above transformation would require more gimple
statements in SSA, and may only be a win on targets with flags registers,
it isn't performed by the middle-end, instead leaving this choice to
the backend.
As an example, here's the change in code generation for pr91400-1.c
[which now requires a tweak to its dg-final clauses].
Before:
movl __cpu_model+12(%rip), %eax
andl $68, %eax // 3 bytes
cmpl $68, %eax // 3 bytes
sete %al
ret
After:
movl __cpu_model+12(%rip), %eax
notl %eax // 2 bytes
testb $68, %al // 2 bytes
sete %al
ret
2022-05-27 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/i386/i386.md (*test<mode>_not): New define_insn_and_split
to split a combined "and;cmp" sequence into "not;test".
gcc/testsuite/ChangeLog
* gcc.target/i386/pr91400-1.c: Update for improved code generation.
* gcc.target/i386/pr91400-2.c: Likewise.
* gcc.target/i386/testnot-1.c: New test case.
* gcc.target/i386/testnot-2.c: Likewise.
This patch makes bswap[sd]i2 better register allocation, and reconstructs
bswapsi2 in order to take advantage of GIMPLE manual byte-swapping
recognition.
gcc/ChangeLog:
* config/xtensa/xtensa.md (bswapsi2): New expansion pattern.
(bswapsi2_internal): Revise the template and condition, and add
detection code for preceding the same insn in order to omit a
"SSAI 8" instruction of the latter.
(bswapdi2): Suppress built-in insn expansion with the corresponding
library call when optimizing for size.
gcc/testsuite/ChangeLog:
* gcc.target/xtensa/bswap.c: Remove test.
* gcc.target/xtensa/bswap-O1.c: New.
* gcc.target/xtensa/bswap-O2.c: Ditto.
* gcc.target/xtensa/bswap-Os.c: Ditto.
This patch introduces setmemsi insn pattern of two kinds, unrolled loop and
small loop, for fixed small length and constant initialization value.
gcc/ChangeLog:
* config/xtensa/xtensa-protos.h
(xtensa_expand_block_set_unrolled_loop,
xtensa_expand_block_set_small_loop): New prototypes.
* config/xtensa/xtensa.cc (xtensa_sizeof_MOVI,
xtensa_expand_block_set_unrolled_loop,
xtensa_expand_block_set_small_loop): New functions.
* config/xtensa/xtensa.md (setmemsi): New expansion pattern.
* config/xtensa/xtensa.opt (mlongcalls): Add target mask.
On a 16-bit target such as msp430 we get errors about narrowing long
values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is
used the <bits/extc++.h> header breaks the build because of these
narrowing errors.
libstdc++-v3/ChangeLog:
PR libstdc++/105681
* include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:
Limit ga_sizes array to values that fit in size_t.
* include/ext/random [__SIZE_WIDTH < 32] (sfmt86243)
(sfmt86243_64, sfmt132049, sfmt132049_64, sfmt216091)
(sfmt216091_64): Do not declare.
This fixes the printers to work with std::__8::atomic and
std::__v8::ios_errc and std::__v8::future_errc.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdErrorCodePrinter): Make
lookup for ios_errc and future_errc check versioned namespace.
(StdAtomicPrinter): Strip versioned namespace from typename.
This fixes a missing symbol when the dual ABI is disabled, e.g. for the
versioned namespace build.
libstdc++-v3/ChangeLog:
* src/c++11/Makefile.am: Add new source file.
* src/c++11/Makefile.in: Regenerate.
* src/c++11/cxx11-ios_failure.cc (iostream_category):
Move to ...
* src/c++11/ios_errcat.cc: New file.
* testsuite/27_io/ios_base/failure/error_code.cc: Check that
std::iostream_category() is defined and used for std::io_errc.
This patch improves the diagnostic for -Waddress when it warns for
if (dynamic_cast<A*>(&ref))
// ...
where 'ref' is a reference, which cannot be null. In particular, it
changes
warning: comparing the result of pointer addition '(((A*)ref) + ((sizetype)(*(long int*)((& ref)->B::_vptr.B + -24))))' and NULL
to
warning: the compiler can assume that the address of 'ref' will never be NULL
PR c++/105569
gcc/cp/ChangeLog:
* typeck.cc (warn_for_null_address): Improve the warning when
the POINTER_PLUS_EXPR's base is of reference type.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Waddress-9.C: New test.
This patch makes counting the number of instructions of the remainder
(modulo 4) part more accurate.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_expand_block_move):
Make instruction counting more accurate, and simplify emitting insns.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (counted_iterator::operator++(int)):
Add 'constexpr' as per LWG 3643.
* testsuite/24_iterators/counted_iterator/lwg3643.cc: New test.
Here during cp_parser_single_declaration for #2, we were calling
associate_classtype_constraints for TPL<T> (the primary template type)
before maybe_process_partial_specialization could get a chance to
notice that we're in fact declaring a distinct constrained partial
spec and not redeclaring the primary template. This caused us to
emit a bogus error about differing constraints b/t the primary template
and #2's constraints. This patch fixes this by moving the call to
associate_classtype_constraints after the call to shadow_tag (which
calls maybe_process_partial_specialization) and adjusting shadow_tag to
use the return value of m_p_p_s.
Moreover, if we later try to define a constrained partial specialization
that's been declared earlier (as in the third testcase), then
maybe_new_partial_specialization correctly notices it's a redeclaration
and returns NULL_TREE. But in this case we also need to update TYPE to
point to the redeclared partial spec (it'll otherwise continue pointing
to the primary template type, eventually leading to a bogus error).
PR c++/96363
gcc/cp/ChangeLog:
* decl.cc (shadow_tag): Use the return value of
maybe_process_partial_specialization.
* parser.cc (cp_parser_single_declaration): Call shadow_tag
before associate_classtype_constraints.
* pt.cc (maybe_new_partial_specialization): Change return type
to bool. Take 'type' argument by mutable reference. Set 'type'
to point to the correct constrained specialization when
appropriate.
(maybe_process_partial_specialization): Adjust accordingly.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-partial-spec12.C: New test.
* g++.dg/cpp2a/concepts-partial-spec12a.C: New test.
* g++.dg/cpp2a/concepts-partial-spec13.C: New test.
This moves some #include directives to the relevant place. For example,
<bits/hashtable_policy.h> needs <bits/stl_pair.h> so should include it
directly instead of relying on <unordered_map> and <unordered_set> to do
so first.
libstdc++-v3/ChangeLog:
* include/bits/functional_hash.h (__is_fast_hash): Add doxygen
comment.
* include/bits/hashtable.h: Do not include <bits/stl_function.h>
here.
* include/bits/hashtable_policy.h: Include <bits/stl_pair.h> and
<bits/functional_hash.h>.
* include/bits/unordered_map.h: Include required headers.
* include/bits/unordered_set.h: Likewise.
* include/std/unordered_map: Do not include headers for indirect
dependencies.
* include/std/unordered_set: Likewise.
These headers do not use anything in <bits/stl_iterator_base_types.h>
directly, and it's included by <bits/stl_iterator_base_funcs.h> and
<bits/stl_iterator.h> anyway, because they do need it.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algobase.h: Do not include
<bits/stl_iterator_base_types.h>.
* include/std/string: Likewise.
* include/std/variant: Likewise.
These headers were relying on their includers having already included
some prerequisites. That makes them unsuitable to be header-units.
So directly include the needed headers.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h: Include required headers.
* include/bits/hashtable_policy.h: Likewise.
* include/bits/stl_heap.h: Likewise.
* include/bits/stl_iterator_base_funcs.h: Likewise.
Repeating "explicit_instantiation" in these long pathnames is not
necessary.
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/requirements/explicit_instantiation/explicit_instantiation.cc:
Moved to...
* testsuite/20_util/duration/requirements/explicit_instantiation.cc: ...here.
* testsuite/20_util/time_point/requirements/explicit_instantiation/explicit_instantiation.cc:
Moved to...
* testsuite/20_util/time_point/requirements/explicit_instantiation.cc: ...here.
* testsuite/20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc:
Moved to...
* testsuite/20_util/unique_ptr/requirements/explicit_instantiation.cc: ...here.
When chaining attributes, attr_chainon should be used rather than plain
chainon, so that we don't end up with a TREE_LIST where one of the elements
is error_mark_node, which causes problems. parser.cc has already been
fixed to use attr_chainon, but decl.cc has not. Until now.
PR c++/96637
gcc/cp/ChangeLog:
* cp-tree.h (attr_chainon): Declare.
* decl.cc (start_decl): Use attr_chainon.
(grokdeclarator): Likewise.
* parser.cc (cp_parser_statement): No longer static.
gcc/testsuite/ChangeLog:
* g++.dg/parse/error64.C: New test.
Here, alias_ctad_tweaks expect tsubst_decl of a FUNCTION_DECL to return a
FUNCTION_DECL. A reasonable expectation, but in this case we were replacing
the template args of the class-scope deduction guide with equivalent args,
so looking in the hash table we found the partial instantiation stored when
instantiating A<int>, which is a TEMPLATE_DECL. It's fine for that to be
what is stored, but tsubst_function_decl should never return it.
PR c++/105655
gcc/cp/ChangeLog:
* pt.cc (build_template_decl): Add assert.
(tsubst_function_decl): Don't return a template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias13.C: New test.
Since my patch for PR90451, we defer mark_used of single functions as late
as possible. And since my r12-1273, we keep BASELINK from lookup around
rather than reconstruct it later. These both made us try to instantiate g
with a function type that still had 'auto' as its return type.
PR c++/105623
gcc/cp/ChangeLog:
* decl2.cc (mark_used): Copy type from fn to BASELINK.
* pt.cc (unify_one_argument): Call mark_single_function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn62.C: New test.
In constexpr-new3.C, the f7 function returns a deleted pointer, which we
were happily caching because the new and delete are balanced. Don't.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Check for
heap vars in the result.
A change I was working on made constexpr_searcher.cc start to fail, and when
I looked at it I wondered why it had been accepted before. This turned out
to be because we try to be more flexible about constant-evaluation of static
initializers, as allowed, but we were wrongly doing the same for non-static
initializers as well.
gcc/cp/ChangeLog:
* constexpr.cc (maybe_constant_init_1): Only pass false for
strict when initializing a variable of static duration.
libstdc++-v3/ChangeLog:
* testsuite/20_util/function_objects/constexpr_searcher.cc: Add
constexpr.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-local4.C: New test.
Consider
struct A {
int x;
int y = x;
};
struct B {
int x = 0;
int y = A{x}.y; // #1
};
where for #1 we end up with
{.x=(&<PLACEHOLDER_EXPR struct B>)->x, .y=(&<PLACEHOLDER_EXPR struct A>)->x}
that is, two PLACEHOLDER_EXPRs for different types on the same level in
a {}. This crashes because our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism to
avoid replacing unrelated PLACEHOLDER_EXPRs cannot deal with it.
Here's why we wound up with those PLACEHOLDER_EXPRs: When we're performing
cp_parser_late_parsing_nsdmi for "int y = A{x}.y;" we use finish_compound_literal
on type=A, compound_literal={((struct B *) this)->x}. When digesting this
initializer, we call get_nsdmi which creates a PLACEHOLDER_EXPR for A -- we don't
have any object to refer to yet. After digesting, we have
{.x=((struct B *) this)->x, .y=(&<PLACEHOLDER_EXPR struct A>)->x}
and since we've created a PLACEHOLDER_EXPR inside it, we marked the whole ctor
CONSTRUCTOR_PLACEHOLDER_BOUNDARY. f_c_l creates a TARGET_EXPR and returns
TARGET_EXPR <D.2384, {.x=((struct B *) this)->x, .y=(&<PLACEHOLDER_EXPR struct A>)->x}>
Then we get to
B b = {};
and call store_init_value, which digests the {}, which produces
{.x=NON_LVALUE_EXPR <0>, .y=(TARGET_EXPR <D.2395, {.x=(&<PLACEHOLDER_EXPR struct B>)->x, .y=(&<PLACEHOLDER_EXPR struct A>)->x}>).y}
lookup_placeholder in constexpr won't find an object to replace the
PLACEHOLDER_EXPR for B, because ctx->object will be D.2395 of type A, and we
cannot search outward from D.2395 to find 'b'.
The call to replace_placeholders in store_init_value will not do anything:
we've marked the inner { } CONSTRUCTOR_PLACEHOLDER_BOUNDARY, and it's only
a sub-expression, so replace_placeholders does nothing, so the <P_E struct B>
stays even though now is the perfect time to replace it because we have an
object for it: 'b'.
Later, in cp_gimplify_init_expr the *expr_p is
D.2395 = {.x=(&<PLACEHOLDER_EXPR struct B>)->x, .y=(&<PLACEHOLDER_EXPR struct A>)->x}
where D.2395 is of type A, but we crash because we hit <P_E struct B>, which
has a different type.
My idea was to replace <P_E struct A> with D.2384 after creating the
TARGET_EXPR because that means we have an object we can refer to.
Then clear CONSTRUCTOR_PLACEHOLDER_BOUNDARY because we no longer have
a PLACEHOLDER_EXPR in the {}. Then store_init_value will be able to
replace <P_E struct B> with 'b', and we should be good to go. We must
be careful not to break guaranteed copy elision, so this replacement
happens in digest_nsdmi_init where we can see the whole initializer,
and avoid replacing any placeholders in TARGET_EXPRs used in the context
of initialization/copy elision. This is achieved via the new function
called potential_prvalue_result_of.
While fixing this problem, I found PR105550, thus the FIXMEs in the
tests.
PR c++/100252
gcc/cp/ChangeLog:
* typeck2.cc (potential_prvalue_result_of): New.
(replace_placeholders_for_class_temp_r): New.
(digest_nsdmi_init): Call it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/nsdmi-aggr14.C: New test.
* g++.dg/cpp1y/nsdmi-aggr15.C: New test.
* g++.dg/cpp1y/nsdmi-aggr16.C: New test.
* g++.dg/cpp1y/nsdmi-aggr17.C: New test.
* g++.dg/cpp1y/nsdmi-aggr18.C: New test.
* g++.dg/cpp1y/nsdmi-aggr19.C: New test.
Increase the priority of the init_have_lse_atomics constructor so it runs
before other constructors. This improves chances that rr works when LSE
atomics are supported.
libgcc/
PR libgcc/105708
* config/aarch64/lse-init.c: Increase constructor priority.
Rename the files and classes to reflect the term infer rather than side-effect.
* Makefile.in (OBJS): Use gimple-range-infer.o.
* gimple-range-cache.cc (ranger_cache::fill_block_cache): Change msg.
(ranger_cache::range_from_dom): Rename var side_effect to infer.
(ranger_cache::apply_inferred_ranges): Rename from apply_side_effects.
* gimple-range-cache.h: Include gimple-range-infer.h.
(class ranger_cache): Adjust prototypes, use infer_range_manager.
* gimple-range-infer.cc: Rename from gimple-range-side-effects.cc.
(gimple_infer_range::*): Rename from stmt_side_effects.
(infer_range_manager::*): Rename from side_effect_manager.
* gimple-range-side-effect.cc: Rename.
* gimple-range-side-effect.h: Rename.
* gimple-range-infer.h: Rename from gimple-range-side-effects.h.
(class gimple_infer_range): Rename from stmt_side_effects.
(class infer_range_manager): Rename from side_effect_manager.
* gimple-range.cc (gimple_ranger::register_inferred_ranges): Rename
from register_side_effects.
* gimple-range.h (register_inferred_ranges): Adjust prototype.
* range-op.h: Adjust comment.
* tree-vrp.cc (rvrp_folder::pre_fold_bb): Use register_inferred_ranges.
(rvrp_folder::post_fold_bb): Use register_inferred_ranges.
This solves an issue where rv32i, etc. are canonicalized to rv32imafd
since the g->i addition of 'm', 'a', 'f', 'd' is not actually gated by
whether the input was rv32g/rv64g.
gcc/ChangeLog:
* config/riscv/arch-canonicalize: Only add mafd extension if
base was rv32/rv64g.
On the following testcase (the first dg-error line) we emit a weird
diagnostics and even fixit on pointerpointer->member
where pointerpointer is pointer to pointer to struct and we say
'pointerpointer' is a pointer; did you mean to use '->'?
The first part is indeed true, but suggesting -> when the code already
does use -> is confusing.
The following patch adjusts callers so that they tell it if it is from
. parsing or from -> parsing and in the latter case suggests to dereference
the left operand instead by adding (* before it and ) after it (before ->).
Or would a suggestion to add [0] before -> be better?
2022-05-25 Jakub Jelinek <jakub@redhat.com>
PR c/91134
gcc/c/
* c-tree.h (build_component_ref): Add ARROW_LOC location_t argument.
* c-typeck.cc (build_component_ref): Likewise. If DATUM is
INDIRECT_REF and ARROW_LOC isn't UNKNOWN_LOCATION, print a different
diagnostic and fixit hint if DATUM has pointer type.
* c-parser.cc (c_parser_postfix_expression,
c_parser_omp_variable_list): Adjust build_component_ref callers.
* gimple-parser.cc (c_parser_gimple_postfix_expression_after_primary):
Likewise.
gcc/objc/
* objc-act.cc (objc_build_component_ref): Adjust build_component_ref
caller.
gcc/testsuite/
* gcc.dg/pr91134.c: New test.
The first round of adding these missed several more cases in other
files where the Visitor pattern is used in the D front-end.
gcc/d/ChangeLog:
* expr.cc: Add "final" and "override" to all "visit" vfunc decls
as appropriate.
* imports.cc: Likewise.
* typeinfo.cc: Likewise.
Signed-off-by: Iain Buclaw <ibuclaw@gdcproject.org>
This fixes misspelled defaut: in switch statements in three
new testcases.
2022-05-25 Richard Biener <rguenther@suse.de>
* gcc.dg/loop-unswitch-10.c: Fix misspelled defaut:
* gcc.dg/loop-unswitch-11.c: Likewise.
* gcc.dg/loop-unswitch-14.c: Likewise.
On the following testcase with -Os asan pass sees:
<bb 6> [local count: 354334800]:
# h_21 = PHI <h_15(6), 0(5)>
*c.3_5 = *d.2_4;
h_15 = h_21 + 1;
if (h_15 != 3)
goto <bb 6>; [75.00%]
else
goto <bb 7>; [25.00%]
<bb 7> [local count: 118111600]:
*c.3_5 = MEM[(struct a *)&b + 12B];
_13 = c.3_5->x;
return _13;
It instruments the
*c.3_5 = *d.2_4;
assignment by adding
.ASAN_CHECK (7, c.3_5, 4, 4);
.ASAN_CHECK (6, d.2_4, 4, 4);
before it (which later lowers to checking the corresponding shadow
memory). But when considering instrumentation of
*c.3_5 = MEM[(struct a *)&b + 12B];
it doesn't instrument anything, because it sees that *c.3_5 store is
already instrumented in a dominating block and so there is no need
to instrument *c.3_5 store again (i.e. add another
.ASAN_CHECK (7, c.3_5, 4, 4);
). That is true, but misses the fact that we still want to
instrument the MEM[(struct a *)&b + 12B] load.
The following patch fixes that by changing has_stmt_been_instrumented_p
to consider both store and load in the assignment if it does both
(returning true iff both have been instrumented).
That matches how we handle e.g. builtin calls, where we also perform AND
of all the memory locs involved in the call.
I've verified that we still don't add the redundant
.ASAN_CHECK (7, c.3_5, 4, 4);
call but just add
_18 = &MEM[(struct a *)&b + 12B];
.ASAN_CHECK (6, _18, 4, 4);
to instrument the load.
2022-05-25 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105714
* asan.cc (has_stmt_been_instrumented_p): For assignments which
are both stores and loads, return true only if both destination
and source have been instrumented.
* gcc.dg/asan/pr105714.c: New test.
Richi reported occassional hangs with taskwait-depend-nowait-1.*
tests and I've finally manged to reproduce. The problem is if
taskwait depend without nowait is encountered soon after
taskwait depend nowait and the former depends on the latter and there
is no other work to do, the taskwait depend without nowait is put
to sleep, but the empty_task optimization in
gomp_task_run_post_handle_dependers wouldn't wake it up in that
case. gomp_task_run_post_handle_dependers normally does some wakeups
because it schedules more work (another task), which is not the
case of empty_task, but we need to do the wakeups that would be done
upon task completion so that we awake sleeping threads when the
last child is done.
So, the taskwait-depend-nowait-1.* testcase is fixed with the
else if (__builtin_expect (task->parent_depends_on, 0) part of
the patch.
The new testcase can hang on another problem, if the empty task
is the last task of a taskgroup, we need to use atomic store
like elsewhere to decrease the counter to 0, and wake up taskgroup
end if needed.
Yet another spot which can sleep is normal taskwait (without depend),
but I believe nothing needs to be done for that - in that case we
await solely until the children's queue has no tasks, tasks still
waiting for dependencies aren't accounted in that, but the reason
is that if taskwait should wait for something, there needs to be at least
one active child doing something (in the children queue), which then
possibly awakes some of its siblings when the dependencies are met,
or in the empty task case awakes further dependencies, but in any
case the child that finished is still handled as active child and
will awake taskwait at the end if there is nothing further to
do.
Last sleeping case are barriers, but that is handled by ++ret and
awaking the barrier.
2022-05-25 Jakub Jelinek <jakub@redhat.com>
* task.c (gomp_task_run_post_handle_dependers): If empty_task
is the last task taskwait depend depends on, wake it up.
Similarly if it is the last child of a taskgroup, use atomic
store instead of decrement and awak taskgroup wait if any.
* testsuite/libgomp.c-c++-common/taskwait-depend-nowait-2.c: New test.
This patch adds support to unswitch loops with switch statements
based on invariant index. It furthermore reworks the cost model
to allow an overall budget of statements to be created per original
loop by all unswitching opportunities in the loop. Compared to
the original all unswitching opportunities in a loop are
pre-evaluated before the first transform which will allow future
changes to select the most profitable candidates first.
To efficiently support switch statements the pass now uses
ranger to simplify switch statements and conditions in loop
copies based on ranges extracted from the recorded set of
predicates unswitched.
gcc/ChangeLog:
* dbgcnt.def (DEBUG_COUNTER): Add loop_unswitch counter.
* params.opt (max-unswitch-level): Remove.
* doc/invoke.texi (max-unswitch-level): Likewise.
* tree-cfg.cc (gimple_lv_add_condition_to_bb): Support not
gimplified expressions.
* tree-ssa-loop-unswitch.cc (struct unswitch_predicate): New.
(tree_may_unswitch_on): Rename to ...
(find_unswitching_predicates_for_bb): ... this and handle
switch statements.
(get_predicates_for_bb): Likewise.
(set_predicates_for_bb): Likewise.
(init_loop_unswitch_info): Likewise.
(tree_ssa_unswitch_loops): Prepare stuff before calling
tree_unswitch_single_loop.
(tree_unswitch_single_loop): Rework the function using
pre-computed predicates and with a per original loop cost model.
(merge_last): New.
(add_predicate_to_path): Likewise.
(find_range_for_lhs): Likewise.
(simplify_using_entry_checks): Rename to ...
(evaluate_control_stmt_using_entry_checks): ... this, handle
switch statements and improve simplifications using ranger.
(simplify_loop_version): Rework using
evaluate_control_stmt_using_entry_checks.
(evaluate_bbs): New.
(evaluate_loop_insns_for_predicate): Likewise.
(tree_unswitch_loop): Adjust to allow switch statements and
pass in the edge to unswitch.
(clean_up_after_unswitching): New.
(pass_tree_unswitch::execute): Pass down fun.
gcc/testsuite/ChangeLog:
* gcc.dg/loop-unswitch-7.c: New test.
* gcc.dg/loop-unswitch-8.c: New test.
* gcc.dg/loop-unswitch-9.c: New test.
* gcc.dg/loop-unswitch-10.c: New test.
* gcc.dg/loop-unswitch-11.c: New test.
* gcc.dg/loop-unswitch-12.c: New test.
* gcc.dg/loop-unswitch-13.c: New test.
* gcc.dg/loop-unswitch-14.c: New test.
* gcc.dg/loop-unswitch-15.c: New test.
* gcc.dg/loop-unswitch-16.c: New test.
* gcc.dg/loop-unswitch-17.c: New test.
* gcc.dg/torture/20220518-1.c: New test.
* gcc.dg/torture/20220518-2.c: New test.
* gcc.dg/torture/20220525-1.c: New test.
* gcc.dg/alias-10.c: Adjust.
* gcc.dg/tree-ssa/loop-6.c: Likewise.
* gcc.dg/loop-unswitch-1.c: Likewise.
Co-authored-by: Richard Biener <rguenther@suse.de>
The RA_SIGN_STATE dwarf pseudo-register is normally only set using the
DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which
toggles the return address signedness state (the default state is 0).
(It may be set by remember/restore_state CFI too, those save/restore
the state of all registers.)
However RA_SIGN_STATE can be set directly via DW_CFA_val_expression too.
GCC does not generate such CFI but some other compilers reportedly do.
Note: the toggle operation must not be mixed with other dwarf register
rule CFI within the same CIE and FDE.
In libgcc we assume REG_UNSAVED means the RA_STATE is set using toggle
operations, otherwise we assume its value is set by other CFI.
libgcc/ChangeLog:
PR target/104689
* config/aarch64/aarch64-unwind.h (aarch64_frob_update_context):
Handle the !REG_UNSAVED case.
* unwind-dw2.c (execute_cfa_program): Fail toggle if !REG_UNSAVED.
gcc/testsuite/ChangeLog:
PR target/104689
* gcc.target/aarch64/pr104689.c: New test.
This patch changes the code to save/restore profile counts for
the epliog loop (when not using scalar loop in the epilog)
instead of scaling them down and then back up, which may lead
to problems if we scale down to 0.
Tested on x86_64-pc-linux-gnu.
gcc/ChangeLog:
* tree-vect-loop-manip.cc (vect_do_peeling): Save/restore profile
counts for the epilog loop.
The code in cxx_eval_call_expression to fold *this was doing the wrong thing
for array decay; we can use cxx_fold_indirect_ref instead.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_fold_indirect_ref): Add default arg.
(cxx_eval_call_expression): Call it.
(cxx_fold_indirect_ref_1): Handle null empty_base.
We have noticed that, when running the GCC testsuite on AArch64
RTEMS 6, we have about 150 tests failing due to a link failure.
When investigating, we found that all the tests were failing
due to the use of -gsplit-dwarf.
On this platform, using -gsplit-dwarf currently causes an error
during the link:
| /[...]/ld: a.out section `.unexpected_sections' will not fit
| in region `UNEXPECTED_SECTIONS'
| /[...]/ld: region `UNEXPECTED_SECTIONS' overflowed by 56 bytes
The error is a bit cryptic, but the source of the issue is that
the linker does not currently support the sections generated
by -gsplit-dwarf (.debug_gnu_pubnames, .debug_gnu_pubtypes).
This means that the -gsplit-dwarf feature itself really isn't
supported on this platform, at least for the moment.
This commit enhances the -gsplit-dwarf support check to be
a compile-and-link check, rather than just a compile check.
This allows it to properly detect that this feature isn't
supported on platforms such as AArch64 RTEMS where the compilation
works, but not the link.
Tested on aarch64-rtems, where a little over 150 tests are now
passing, instead of failing, as well as on x86_64-linux, where
the results are identical, and where the .log file was also manually
inspected to make sure that the use of the -gsplit-dwarf option
was preserved.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/outputs.exp: Make the -gsplit-dwarf test
a compile-and-link test rather than a compile-only test.
I've been thinking for a while that the 'lval' parameter needed a third
value for discarded-value expressions; most importantly,
cxx_eval_store_expression does extra work for an lvalue result, and we also
don't want to do the l->r conversion.
Mostly this is pretty mechanical. Apart from the _store_ fix, I also use
vc_discard for substatements of a STATEMENT_LIST other than a stmt-expr
result, and avoid building _REFs to be ignored in a few other places.
gcc/cp/ChangeLog:
* constexpr.cc (enum value_cat): New. Change all 'lval' parameters
from int to value_cat. Change most false to vc_prvalue, most true
to vc_glvalue, cases where the return value is ignored to
vc_discard.
(cxx_eval_statement_list): Only vc_prvalue for stmt-expr result.
(cxx_eval_store_expression): Only build _REF for vc_glvalue.
(cxx_eval_array_reference, cxx_eval_component_reference)
(cxx_eval_indirect_ref, cxx_eval_constant_expression): Likewise.
Richard Biener
Jakub Jelinek
Tobias Burnus
Roger Sayle
Takayuki 'January June' Suwa
GCC Administrator
Jonathan Wakely
Marek Polacek
Patrick Palka
Nathan Sidwell
François Dumont
Jason Merrill
Wilco Dijkstra
Andrew MacLeod
Simon Cook
Iain Buclaw
Martin Liska
Szabolcs Nagy
Eugene Rozenfeld
Martin Sebor
Joel Brobecker