Martin Uecker [Wed, 21 Dec 2022 09:52:34 +0000 (10:52 +0100)]
c: reorganize recursive type checking
Reorganize recursive type checking to use a structure to
store information collected during the recursion and
returned to the caller (warning_needed, enum_and_init_p,
different_types_p).
gcc/c:
* c-typeck.cc (struct comptypes_data): Add structure.
(tagged_types_tu_compatible_p,
function_types_compatible_p, type_lists_compatible_p,
comptypes_internal): Add structure to interface, change
return type to bool, and adapt calls.
(comptarget_types): Change return type too bool.
(comptypes, comptypes_check_enum_int,
comptypes_check_different_types): Adapt calls.
RISC-V: enable muti push and pop for Zcmp when shrink-wrap-separate is ineffective
So that zcmp can be enabled in -Os where
shrink-wrap-separate is not effective.
To force enabling zcmp multi push/pop in speed perfered case,
fno-shrink-wrap-separate has to be explictly given.
gcc/ChangeLog:
* config/riscv/riscv.cc
(riscv_avoid_shrink_wrapping_separate): wrap the condition check in
riscv_avoid_shrink_wrapping_separate.
(riscv_avoid_multi_push):avoid multi push if shrink_wrapping_separate
is active.
(riscv_get_separate_components):call riscv_avoid_shrink_wrapping_separate
Gaius Mulley [Mon, 11 Sep 2023 21:28:01 +0000 (22:28 +0100)]
PR modula2/111330 Bootstrap failure building SeqFile.lo
cc1gm2 issues a runtime case statement error and terminates
when building SeqFile.lo on Fedora mock. There are four
missing labels from the largest case statement in M2SymInit.mod.
This patch adds the case labels and appropriate actions.
gcc/m2/ChangeLog:
PR modula2/111330
* gm2-compiler/M2SymInit.mod (CheckReadBeforeInitQuad): Add
case labels LogicalDiffOp, DummyOp, OptParamOp and
InitAddressOp.
Andrew Pinski [Mon, 11 Sep 2023 15:05:10 +0000 (08:05 -0700)]
MATCH: [PR111348] add missing :c to cmp in the `(a CMP b) ? minmax<a, c> : minmax<b, c>` pattern
When I added this pattern in r14-337-gc43819a9b4cd, I had missed the :c on the cmp
part of the pattern meaning there might be some missing optimizations happening.
The testcase shows an example of the missed optmization.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/111348
gcc/ChangeLog:
* match.pd (`(a CMP b) ? minmax<a, c> : minmax<b, c>`): Add :c on
the cmp part of the pattern.
Edwin Lu [Mon, 11 Sep 2023 16:57:37 +0000 (09:57 -0700)]
RISC-V: Update Types for RISC-V Instructions
Adds types to riscv instructions that were added or were
missed by the original patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html
Edwin Lu [Mon, 11 Sep 2023 16:47:02 +0000 (09:47 -0700)]
RISC-V: Update Types for Vector Instructions
Adds types to vector instructions that were added after or were
missed by the original patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html
The second argument of these builtins is an unsigned immediate. For
vec_rli the API allows immediates up to 64 bits whereas the instruction
verll only allows immediates up to 32 bits. Since the shift count
equals the immediate modulo vector element size, truncating those
immediates is fine.
Passing a non-immediate argument to vec_rli already results in an error
message without this patch:
t.c: In function ‘foo’:
t.c:7:10: error: invalid argument 2 for builtin ‘__builtin_s390_verllf’
7 | return __builtin_s390_vec_rli (v, x);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whereas with this patch
t.c: In function 'foo':
t.c:7:10: error: constant value required for builtin '__builtin_s390_verllf' argument 2
7 | return __builtin_s390_vec_rli (v, x);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the error message, generated by s390_const_operand_ok, clearly speaks
about a constant argument value.
Jonathan Wakely [Mon, 11 Sep 2023 15:42:54 +0000 (16:42 +0100)]
libstdc++: Remove unconditional use of atomics in Debug Mode
The fix for PR 91910 (r10-3426-gf7a3a382279585) introduced unconditional
uses of atomics into src/c++11/debug.cc, which causes linker errors for
arm4t where GCC emits an unresolved reference to __sync_synchronize.
By making the uses of atomics depend on _GLIBCXX_HAS_GTHREADS we can
avoid those unconditional references to __sync_synchronize for targets
where the atomics are unnecessary. As a minor performance optimization
we can also check the __gnu_cxx::__is_single_threaded function to avoid
atomics for single-threaded programs even where they don't cause linker
errors.
libstdc++-v3/ChangeLog:
* src/c++11/debug.cc (acquire_sequence_ptr_for_lock): New
function.
(reset_sequence_ptr): New function.
(_Safe_iterator_base::_M_detach)
(_Safe_local_iterator_base::_M_detach): Replace bare atomic_load
with acquire_sequence_ptr_for_lock.
(_Safe_iterator_base::_M_reset): Replace bare atomic_store with
reset_sequence_ptr.
Ken Matsui [Tue, 18 Jul 2023 22:24:50 +0000 (15:24 -0700)]
libstdc++: Define _GLIBCXX_USE_BUILTIN_TRAIT
This patch defines _GLIBCXX_USE_BUILTIN_TRAIT macro, which will be used
as a flag to toggle the use of built-in traits in the type_traits header
through _GLIBCXX_DO_NOT_USE_BUILTIN_TRAITS macro, without needing to modify
the source code.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Do not undef.
(_GLIBCXX_USE_BUILTIN_TRAIT): Define.
Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Andrew Pinski [Mon, 11 Sep 2023 04:58:12 +0000 (21:58 -0700)]
MATCH: [PR111349] add missing :c to cmp in the `(a CMP CST1) ? max<a,CST2> : a` pattern
When I added this pattern in r14-1411-g17cca3c43e2f49, I had missed the :c on the cmp
part of the pattern meaning there might be some missing optimizations happening.
The testcase shows an example of the missed optmization.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/111349
gcc/ChangeLog:
* match.pd (`(a CMP CST1) ? max<a,CST2> : a`): Add :c on
the cmp part of the pattern.
Jakub Jelinek [Mon, 11 Sep 2023 09:08:41 +0000 (11:08 +0200)]
pretty-print: Fix up pp_wide_int [PR111329]
The recent pp_wide_int changes for _BitInt support (because not all
wide_ints fit into the small fixed size digit_buffer anymore) apparently
broke
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c (test for excess errors)
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c 2 blank line(s) in output
+FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c expected multiline pattern lines 17-39
(and I couldn't reproduce that in bisect seed (which is -O0 compiled) and
thought it would be some analyzer diagnostic bug).
The problem is that analyzer uses pp_wide_int with a function call in the
second argument. Previously, when pp_wide_int macro just did
print_dec (W, pp_buffer (PP)->digit_buffer, SGN);
pp_string (PP, pp_buffer (PP)->digit_buffer);
it worked, because the const wide_int_ref & first argument to print_dec
bound to a temporary, which was only destructed at the end of the full
statement after print_dec was called.
But with my changes where I need to first compare the precision of the
const wide_int_ref & to decide whether to use digit_buffer or XALLOCAVEC
something larger, this means that pp_wide_int_ref binds to a temporary
which is destroyed at the end of full statement which is the
const wide_int_ref &pp_wide_int_ref = (W);
declaration, so then invokes UB accessing a destructed temporary.
The following patch fixes it by rewriting pp_wide_int into an inline
function, so that the end of the full statement is the end of the inline
function call. As functions using alloca aren't normally inlined, I've
also split that part into a separate out of line function. Putting that
into pretty-print.cc didn't work, e.g. the gm2 binary doesn't link,
because pretty-print.o is in libcommon.a, but wide-print-print.o which
defines print_dec is not. So I've put that out of line function into
wide-int-print.cc instead.
2023-09-11 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111329
* pretty-print.h (pp_wide_int): Rewrite from macro into inline
function. For printing values which don't fit into digit_buffer
use out-of-line function.
* wide-int-print.h (pp_wide_int_large): Declare.
* wide-int-print.cc: Include pretty-print.h.
(pp_wide_int_large): Define.
* gcc.target/riscv/rvv/autovec/partial/slp-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/partial/slp-16.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-17.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/compress-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-7.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-7.c: New test.
Andrew Pinski [Sun, 10 Sep 2023 22:59:41 +0000 (15:59 -0700)]
MATCH: [PR111346] `X CMP MINMAX` pattern missing :c on CMP
I noticed this while working on other MINMAX optimizations. It was
hard to find a simplified testcase though because it was dependent on
the ssa name versions. Adding the `:c` to cmp allows the pattern to
be match for the case where minmax as the first operand of the comparison
rather than the second.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/111346
gcc/ChangeLog:
* match.pd (`X CMP MINMAX`): Add `:c` on the cmp part
of the pattern
RISC-V: Expand fixed-vlmax/vls vector permutation in targethook
When debugging FAIL: gcc.dg/pr92301.c execution test.
Realize a vls vector permutation situation failed to vectorize since early return false:
- /* For constant size indices, we dont't need to handle it here.
- Just leave it to vec_perm<mode>. */
- if (d->perm.length ().is_constant ())
- return false;
To avoid more potential failed vectorization case. Now expand it in targethook.
The problem here is after r6-7425-ga9fee7cdc3c62d0e51730,
the comparison to see if the transformation could be done was using the
wrong value. Instead of see if the inner was LE (for MIN and GE for MAX)
the outer value, it was comparing the inner to the value used in the comparison
which was wrong.
The match pattern copied the same logic mistake when they were added in r14-1411-g17cca3c43e2f49 .
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR tree-optimization/111331
* match.pd (`(a CMP CST1) ? max<a,CST2> : a`):
Fix the LE/GE comparison to the correct value.
* tree-ssa-phiopt.cc (minmax_replacement):
Fix the LE/GE comparison for the
`(a CMP CST1) ? max<a,CST2> : a` optimization.
gcc/testsuite/ChangeLog:
PR tree-optimization/111331
* gcc.c-torture/execute/pr111331-1.c: New test.
* gcc.c-torture/execute/pr111331-2.c: New test.
* gcc.c-torture/execute/pr111331-3.c: New test.
Darwin: Partial reversion of r14-3648 (Inits Section).
Although the Darwin ABI places both hot and cold partitions in the same
section (the linker can partition by name), this does not work with the
current dwarf2out implementation.
Since we do see global initialization code getting hot/cold splits, this
patch places the cold parts into text_cold, and keeps the hot part in
the correct Init section per ABI.
TODO: figure out a way to allow us to match the ABI fully.
gcc/ChangeLog:
* config/darwin.cc (darwin_function_section): Place unlikely
executed global init code into the standard cold section.
benjamin priour [Sat, 9 Sep 2023 16:03:56 +0000 (18:03 +0200)]
analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]
Second batch of moving tests from under gcc.dg/analyzer into
c-c++-common/analyzer.
Prior to this patch the analyzer was not unwrapping ordering
binop_svalue, such as LT_EXPR, when evaluating conditions.
Therefore when an ordering conditional was stored, the analyzer
was missing out on some constraints, which led to false positives.
gcc/analyzer/ChangeLog:
PR analyzer/96395
* region-model.cc
(region_model::add_constraints_from_binop): binop_svalues around
LT_EXPR, LE_EXPR, GT_EXPR, GE_EXPR are now unwrapped.
gcc/testsuite/ChangeLog:
PR analyzer/96395
* gcc.dg/analyzer/allocation-size-1.c: Moved to...
* c-c++-common/analyzer/allocation-size-1.c: ...here.
* gcc.dg/analyzer/allocation-size-2.c: Moved to...
* c-c++-common/analyzer/allocation-size-2.c: ...here.
* gcc.dg/analyzer/allocation-size-3.c: Moved to...
* c-c++-common/analyzer/allocation-size-3.c: ...here.
* gcc.dg/analyzer/allocation-size-4.c: Moved to...
* c-c++-common/analyzer/allocation-size-4.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-0.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-0.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-1.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-1.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-2.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-2.c: ...here.
* gcc.dg/analyzer/analyzer-verbosity-3.c: Moved to...
* c-c++-common/analyzer/analyzer-verbosity-3.c: ...here.
* gcc.dg/analyzer/attr-alloc_size-1.c: Moved to...
* c-c++-common/analyzer/attr-alloc_size-1.c: ...here.
* gcc.dg/analyzer/attr-alloc_size-2.c: Moved to...
* c-c++-common/analyzer/attr-alloc_size-2.c: ...here.
* gcc.dg/analyzer/call-summaries-malloc.c: Moved to...
* c-c++-common/analyzer/call-summaries-malloc.c: ...here.
* gcc.dg/analyzer/call-summaries-pr107158-2.c: Moved to...
* c-c++-common/analyzer/call-summaries-pr107158-2.c: ...here.
* gcc.dg/analyzer/capacity-1.c: Moved to...
* c-c++-common/analyzer/capacity-1.c: ...here.
* gcc.dg/analyzer/dot-output.c: Moved to...
* c-c++-common/analyzer/dot-output.c: ...here.
* gcc.dg/analyzer/escaping-1.c: Moved to...
* c-c++-common/analyzer/escaping-1.c: ...here.
* gcc.dg/analyzer/expect-1.c: Moved to...
* c-c++-common/analyzer/expect-1.c: ...here.
* gcc.dg/analyzer/fgets-1.c: Moved to...
* c-c++-common/analyzer/fgets-1.c: ...here.
* gcc.dg/analyzer/file-uninit-1.c: Moved to...
* c-c++-common/analyzer/file-uninit-1.c: ...here.
* gcc.dg/analyzer/fileno-1.c: Moved to...
* c-c++-common/analyzer/fileno-1.c: ...here.
* gcc.dg/analyzer/first-field-1.c: Moved to...
* c-c++-common/analyzer/first-field-1.c: ...here.
* gcc.dg/analyzer/first-field-2.c: Moved to...
* c-c++-common/analyzer/first-field-2.c: ...here.
* gcc.dg/analyzer/flex-with-call-summaries.c: Moved to...
* c-c++-common/analyzer/flex-with-call-summaries.c: ...here.
* gcc.dg/analyzer/flex-without-call-summaries.c: Moved to...
* c-c++-common/analyzer/flex-without-call-summaries.c: ...here.
* gcc.dg/analyzer/flexible-array-member-1.c: Moved to...
* c-c++-common/analyzer/flexible-array-member-1.c: ...here.
* gcc.dg/analyzer/fold-string-to-char.c: Moved to...
* c-c++-common/analyzer/fold-string-to-char.c: ...here.
* gcc.dg/analyzer/fread-1.c: Moved to...
* c-c++-common/analyzer/fread-1.c: ...here.
* gcc.dg/analyzer/fread-2.c: Moved to...
* c-c++-common/analyzer/fread-2.c: ...here.
* gcc.dg/analyzer/fread-pr108661.c: Moved to...
* c-c++-common/analyzer/fread-pr108661.c: ...here.
* gcc.dg/analyzer/function-ptr-1.c: Moved to...
* c-c++-common/analyzer/function-ptr-1.c: ...here.
* gcc.dg/analyzer/function-ptr-2.c: Moved to...
* c-c++-common/analyzer/function-ptr-2.c: ...here.
* gcc.dg/analyzer/function-ptr-3.c: Moved to...
* c-c++-common/analyzer/function-ptr-3.c: ...here.
* gcc.dg/analyzer/function-ptr-4.c: Moved to...
* c-c++-common/analyzer/function-ptr-4.c: ...here.
* gcc.dg/analyzer/getc-1.c: Moved to...
* c-c++-common/analyzer/getc-1.c: ...here.
* gcc.dg/analyzer/getchar-1.c: Moved to...
* c-c++-common/analyzer/getchar-1.c: ...here.
* gcc.dg/analyzer/gzio-2.c: Moved to...
* c-c++-common/analyzer/gzio-2.c: ...here.
* gcc.dg/analyzer/gzio-3.c: Moved to...
* c-c++-common/analyzer/gzio-3.c: ...here.
* gcc.dg/analyzer/gzio-3a.c: Moved to...
* c-c++-common/analyzer/gzio-3a.c: ...here.
* gcc.dg/analyzer/gzio.c: Moved to...
* c-c++-common/analyzer/gzio.c: ...here.
* gcc.dg/analyzer/imprecise-floating-point-1.c: Moved to...
* c-c++-common/analyzer/imprecise-floating-point-1.c: ...here.
* gcc.dg/analyzer/infinite-recursion-2.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-2.c: ...here.
* gcc.dg/analyzer/infinite-recursion-3.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-3.c: ...here.
* gcc.dg/analyzer/infinite-recursion-4-limited-buggy.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-4-limited-buggy.c: ...here.
* gcc.dg/analyzer/infinite-recursion-4-limited.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-4-limited.c: ...here.
* gcc.dg/analyzer/infinite-recursion-4-unlimited-buggy.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-4-unlimited-buggy.c: ...here.
* gcc.dg/analyzer/infinite-recursion-4-unlimited.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-4-unlimited.c: ...here.
* gcc.dg/analyzer/infinite-recursion-5.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-5.c: ...here.
* gcc.dg/analyzer/infinite-recursion-alloca.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-alloca.c: ...here.
* gcc.dg/analyzer/infinite-recursion-inlining.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-inlining.c: ...here.
* gcc.dg/analyzer/infinite-recursion-multiline-1.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-multiline-1.c: ...here.
* gcc.dg/analyzer/infinite-recursion-multiline-2.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-multiline-2.c: ...here.
* gcc.dg/analyzer/infinite-recursion-pr108935-1.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-pr108935-1.c: ...here.
* gcc.dg/analyzer/infinite-recursion-pr108935-1a.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-pr108935-1a.c: ...here.
* gcc.dg/analyzer/infinite-recursion-pr108935-2.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-pr108935-2.c: ...here.
* gcc.dg/analyzer/infinite-recursion-variadic.c: Moved to...
* c-c++-common/analyzer/infinite-recursion-variadic.c: ...here.
* gcc.dg/analyzer/infinite-recursion.c: Moved to...
* c-c++-common/analyzer/infinite-recursion.c: ...here.
* gcc.dg/analyzer/inlining-1-multiline.c: Moved to...
* c-c++-common/analyzer/inlining-1-multiline.c: ...here.
* gcc.dg/analyzer/inlining-1-no-undo.c: Moved to...
* c-c++-common/analyzer/inlining-1-no-undo.c: ...here.
* gcc.dg/analyzer/inlining-2-multiline.c: Moved to...
* c-c++-common/analyzer/inlining-2-multiline.c: ...here.
* gcc.dg/analyzer/inlining-5-multiline.c: Moved to...
* c-c++-common/analyzer/inlining-5-multiline.c: ...here.
* gcc.dg/analyzer/inlining-6-multiline.c: Moved to...
* c-c++-common/analyzer/inlining-6-multiline.c: ...here.
* gcc.dg/analyzer/inlining-6.c: Moved to...
* c-c++-common/analyzer/inlining-6.c: ...here.
* gcc.dg/analyzer/inlining-7-multiline.c: Moved to...
* c-c++-common/analyzer/inlining-7-multiline.c: ...here.
* gcc.dg/analyzer/invalid-shift-1.c: Moved to...
* c-c++-common/analyzer/invalid-shift-1.c: ...here.
* gcc.dg/analyzer/isatty-1.c: Moved to...
* c-c++-common/analyzer/isatty-1.c: ...here.
* gcc.dg/analyzer/leak-2.c: Moved to...
* c-c++-common/analyzer/leak-2.c: ...here.
* gcc.dg/analyzer/leak-3.c: Moved to...
* c-c++-common/analyzer/leak-3.c: ...here.
* gcc.dg/analyzer/leak-4.c: Moved to...
* c-c++-common/analyzer/leak-4.c: ...here.
* gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c: Moved to...
* c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c: ...here.
* gcc.dg/analyzer/loop-0-up-to-n-by-1.c: Moved to...
* c-c++-common/analyzer/loop-0-up-to-n-by-1.c: ...here.
* gcc.dg/analyzer/loop-2.c: Moved to...
* c-c++-common/analyzer/loop-2.c: ...here.
* gcc.dg/analyzer/loop-2a.c: Moved to...
* c-c++-common/analyzer/loop-2a.c: ...here.
* gcc.dg/analyzer/loop-3.c: Moved to...
* c-c++-common/analyzer/loop-3.c: ...here.
* gcc.dg/analyzer/loop-4.c: Moved to...
* c-c++-common/analyzer/loop-4.c: ...here.
* gcc.dg/analyzer/loop-n-down-to-1-by-1.c: Moved to...
* c-c++-common/analyzer/loop-n-down-to-1-by-1.c: ...here.
* gcc.dg/analyzer/loop-start-down-to-end-by-1.c: Moved to...
* c-c++-common/analyzer/loop-start-down-to-end-by-1.c: ...here.
* gcc.dg/analyzer/loop-start-down-to-end-by-step.c: Moved to...
* c-c++-common/analyzer/loop-start-down-to-end-by-step.c: ...here.
* gcc.dg/analyzer/loop-start-to-end-by-step.c: Moved to...
* c-c++-common/analyzer/loop-start-to-end-by-step.c: ...here.
* gcc.dg/analyzer/loop-start-up-to-end-by-1.c: Moved to...
* c-c++-common/analyzer/loop-start-up-to-end-by-1.c: ...here.
* gcc.dg/analyzer/loop.c: Moved to...
* c-c++-common/analyzer/loop.c: ...here.
* gcc.dg/analyzer/malloc-3.c: Moved to...
* c-c++-common/analyzer/malloc-3.c: ...here.
* gcc.dg/analyzer/malloc-5.c: Moved to...
* c-c++-common/analyzer/malloc-5.c: ...here.
* gcc.dg/analyzer/malloc-CWE-401-example.c: Moved to...
* c-c++-common/analyzer/malloc-CWE-401-example.c: ...here.
* gcc.dg/analyzer/malloc-CWE-415-examples.c: Moved to...
* c-c++-common/analyzer/malloc-CWE-415-examples.c: ...here.
* gcc.dg/analyzer/malloc-CWE-416-examples.c: Moved to...
* c-c++-common/analyzer/malloc-CWE-416-examples.c: ...here.
* gcc.dg/analyzer/malloc-CWE-590-examples.c: Moved to...
* c-c++-common/analyzer/malloc-CWE-590-examples.c: ...here.
* gcc.dg/analyzer/malloc-callbacks.c: Moved to...
* c-c++-common/analyzer/malloc-callbacks.c: ...here.
* gcc.dg/analyzer/malloc-dce.c: Moved to...
* c-c++-common/analyzer/malloc-dce.c: ...here.
* gcc.dg/analyzer/malloc-dedupe-1.c: Moved to...
* c-c++-common/analyzer/malloc-dedupe-1.c: ...here.
* gcc.dg/analyzer/malloc-in-loop.c: Moved to...
* c-c++-common/analyzer/malloc-in-loop.c: ...here.
* gcc.dg/analyzer/malloc-ipa-1.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-1.c: ...here.
* gcc.dg/analyzer/malloc-ipa-11.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-11.c: ...here.
* gcc.dg/analyzer/malloc-ipa-2.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-2.c: ...here.
* gcc.dg/analyzer/malloc-ipa-3.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-3.c: ...here.
* gcc.dg/analyzer/malloc-ipa-4.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-4.c: ...here.
* gcc.dg/analyzer/malloc-ipa-5.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-5.c: ...here.
* gcc.dg/analyzer/malloc-ipa-6.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-6.c: ...here.
* gcc.dg/analyzer/malloc-ipa-7.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-7.c: ...here.
* gcc.dg/analyzer/malloc-ipa-8-unchecked.c: Moved to...
* c-c++-common/analyzer/malloc-ipa-8-unchecked.c: ...here.
* gcc.dg/analyzer/malloc-macro-inline-events.c: Moved to...
* c-c++-common/analyzer/malloc-macro-inline-events.c: ...here.
* gcc.dg/analyzer/malloc-macro-separate-events.c: Moved to...
* c-c++-common/analyzer/malloc-macro-separate-events.c: ...here.
* gcc.dg/analyzer/malloc-macro.h: Moved to...
* c-c++-common/analyzer/malloc-macro.h: ...here.
* gcc.dg/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c: Moved to...
* c-c++-common/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c: ...here.
* gcc.dg/analyzer/out-of-bounds-1.c: Moved to...
* c-c++-common/analyzer/out-of-bounds-1.c: ...here.
* gcc.dg/analyzer/out-of-bounds-2.c: Moved to...
* c-c++-common/analyzer/out-of-bounds-2.c: ...here.
* gcc.dg/analyzer/out-of-bounds-5.c: Moved to...
* c-c++-common/analyzer/out-of-bounds-5.c: ...here.
* gcc.dg/analyzer/out-of-bounds-diagram-11.c: Moved to...
* c-c++-common/analyzer/out-of-bounds-diagram-11.c: ...here.
* gcc.dg/analyzer/out-of-bounds-diagram-3.c: Moved to...
* c-c++-common/analyzer/out-of-bounds-diagram-3.c: ...here.
* gcc.dg/analyzer/out-of-bounds-diagram-8.c: Moved to...
* c-c++-common/analyzer/out-of-bounds-diagram-8.c: ...here.
* gcc.dg/analyzer/phi-1.c: Moved to...
* c-c++-common/analyzer/phi-1.c: ...here.
* gcc.dg/analyzer/pr100615.c: Moved to...
* c-c++-common/analyzer/pr100615.c: ...here.
* gcc.dg/analyzer/pr103526.c: Moved to...
* c-c++-common/analyzer/pr103526.c: ...here.
* gcc.dg/analyzer/pr94362-1.c: Moved to...
* c-c++-common/analyzer/pr94362-1.c: ...here.
* gcc.dg/analyzer/pr97074.c: Moved to...
* c-c++-common/analyzer/pr97074.c: ...here.
* c-c++-common/analyzer/pr99193-2.c: Added include.
* c-c++-common/analyzer/realloc-1.c: Added include.
* gcc.dg/analyzer/scope-1.c: Moved to...
* c-c++-common/analyzer/scope-1.c: ...here.
* gcc.dg/analyzer/setjmp-2.c: Moved to...
* c-c++-common/analyzer/setjmp-2.c: ...here.
* gcc.dg/analyzer/setjmp-5.c: Moved to...
* c-c++-common/analyzer/setjmp-5.c: ...here.
* gcc.dg/analyzer/setjmp-9.c: Moved to...
* c-c++-common/analyzer/setjmp-9.c: ...here.
* gcc.dg/analyzer/signal-4a.c: Moved to...
* c-c++-common/analyzer/signal-4a.c: ...here.
* gcc.dg/analyzer/signal-4b.c: Moved to...
* c-c++-common/analyzer/signal-4b.c: ...here.
* gcc.dg/analyzer/file-pr58237.c: C only.
* gcc.dg/analyzer/fopen-1.c: C only.
* gcc.dg/analyzer/malloc-4.c: C only.
* gcc.dg/analyzer/malloc-paths-9.c: C only.
* gcc.dg/analyzer/pr103892.c: C only.
* gcc.dg/analyzer/pr109577.c: C only.
* gcc.dg/analyzer/pr93355-localealias-feasibility.c: C only.
* gcc.dg/analyzer/pr99193-1.c: C only.
* gcc.dg/analyzer/compound-assignment-1.c: Removed.
* gcc.dg/analyzer/inlining-1.c: Removed.
* gcc.dg/analyzer/inlining-2.c: Removed.
* gcc.dg/analyzer/inlining-5.c: Removed.
* gcc.dg/analyzer/inlining-7.c: Removed.
* c-c++-common/analyzer/compound-assignment-1.c: New test.
* c-c++-common/analyzer/file-pr58237-noexcept.c: Duplicate of
gcc.dg/analyzer/file-pr58237.c with exceptions disabled.
* c-c++-common/analyzer/fopen-2.c: C++ compatible parts from
gcc.dg/analyzer/fopen-1.c.
* c-c++-common/analyzer/inlining-1.c: New test.
* c-c++-common/analyzer/inlining-2.c: New test.
* c-c++-common/analyzer/inlining-5.c: New test.
* c-c++-common/analyzer/inlining-7.c: New test.
* c-c++-common/analyzer/malloc-paths-9-noexcept.c: Duplicate of
gcc.dg/analyzer/malloc-paths-9.c with exceptions disabled.
* c-c++-common/analyzer/pr109577-noexcept.c: Duplicate of
gcc.dg/analyzer/pr109577.c with exceptions disabled.
* c-c++-common/analyzer/pr93355-localealias-feasibility-noexcept.c:
Duplicate of gcc.dg/analyzer/pr93355-localealias-feasibility.c with
exceptions disabled.
* c-c++-common/analyzer/pr99193-1-noexcept.c: Duplicate of
gcc.dg/analyzer/pr99193-1.c with exceptions disabled.
Signed-off-by: benjamin priour <vultkayn@gcc.gnu.org>
Mikael Morin [Sat, 9 Sep 2023 09:45:11 +0000 (11:45 +0200)]
fortran: Remove redundant tree walk to delete element
Remove preliminary walk of the symbol tree when we are about to remove an
element. This preliminary walk was necessary because the deletion function
updated the tree without reporting back to the caller the element it had
removed. But knowing that element is necessary to free its memory, so one
had to first get that element before it was removed from the tree.
This change updates the main deletion function delete_treap and its public
wrapper gfc_delete_bbt so that the removed element can be known by the
caller. This makes the preliminary walk in gfc_delete_symtree redundant,
permitting its removal.
gcc/fortran/ChangeLog:
* bbt.cc (delete_treap): Add argument REMOVED, set it to the removed
element from the tree. Change NULL to nullptr.
(gfc_delete_bbt): Return the removed element from the tree.
* gfortran.h (gfc_delete_symtree): Remove prototype.
(gfc_delete_bbt): Set return type to pointer.
* symbol.cc (gfc_delete_symtree): Make static. Get the element to be
freed from the result of gfc_delete_bbt. Remove the preliminary walk to
get it.
Xi Ruoyao [Sat, 9 Sep 2023 08:18:06 +0000 (16:18 +0800)]
LoongArch: Fix up memcpy-vec-3.c test case
The generic code will split 16-byte copy into two 8-byte copies, so the
vector code wouldn't be used even if -mno-strict-align. This
contradicted with the purpose of this test case.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/memcpy-vec-3.c: Increase the amount of
copied bytes to 32.
1. Can generate mulh.w[u] instruction.
2. Can generate mulw.d.wu instruction.
gcc/ChangeLog:
* config/loongarch/loongarch.md (mulsidi3_64bit):
Field unsigned extension support.
(<u>muldi3_highpart): Modify template name.
(<u>mulsi3_highpart): Likewise.
(<u>mulsidi3_64bit): Field unsigned extension support.
(<su>muldi3_highpart): Modify muldi3_highpart to
smuldi3_highpart.
(<su>mulsi3_highpart): Modify mulsi3_highpart to
smulsi3_highpart.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/mulw_d_wu.c: New test.
* gcc.target/loongarch/smuldi3_highpart.c: New test.
* gcc.target/loongarch/smulsi3_highpart.c: New test.
* gcc.target/loongarch/umulsi3_highpart.c: New test.
* config/loongarch/loongarch.cc (loongarch_block_move_straight):
Check precondition (delta must be a power of 2) and use
popcount_hwi instead of a homebrew loop.
Xi Ruoyao [Tue, 5 Sep 2023 13:02:38 +0000 (21:02 +0800)]
LoongArch: Use LSX and LASX for block move
gcc/ChangeLog:
* config/loongarch/loongarch.h (LARCH_MAX_MOVE_PER_INSN):
Define to the maximum amount of bytes able to be loaded or
stored with one machine instruction.
* config/loongarch/loongarch.cc (loongarch_mode_for_move_size):
New static function.
(loongarch_block_move_straight): Call
loongarch_mode_for_move_size for machine_mode to be moved.
(loongarch_expand_block_move): Use LARCH_MAX_MOVE_PER_INSN
instead of UNITS_PER_WORD.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/memcpy-vec-1.c: New test.
* gcc.target/loongarch/memcpy-vec-2.c: New test.
* gcc.target/loongarch/memcpy-vec-3.c: New test.
This patch adds support that tries to fold `MIN (poly, poly)` to
a constant. Consider the following C Code:
```
void foo2 (int* restrict a, int* restrict b, int n)
{
for (int i = 0; i < 3; i += 1)
a[i] += b[i];
}
```
Before this patch:
```
void foo2 (int * restrict a, int * restrict b, int n)
{
vector([4,4]) int vect__7.27;
vector([4,4]) int vect__6.26;
vector([4,4]) int vect__4.23;
unsigned long _32;
In trying to come up with a missing testcase for commit 979e0fbf53cd,
I've realized the patch doesn't catch anything.
A relation of VREL_EQ in foperator_ltgt::fold_range() is either both
arguments the same (x LTGT_EXPR x), which we should never emit, or two
arguments that are actually the same, in which case !NAN applies, and the
whole thing can be handled as NE_EXPR further down.
gcc/ChangeLog:
* range-op-float.cc (foperator_ltgt::fold_range): Do not special
case VREL_EQ nor call frelop_early_resolve.
Jonathan Wakely [Thu, 7 Sep 2023 09:24:56 +0000 (10:24 +0100)]
libstdc++: Add Filesystem TS and std::stacktrace symbols to libstdc++exp.a
This consolidates the three static archives for extensions into one, so
that -lstdc++exp can be used to provide the definitions of all unstable
library features.
The libstdc++_libbacktrace.a archive is now just a "noinst" convenience
library that is only used during the build, not installed. Its contents
are added to libstdc++exp.a, along with the new non-inline definitions
of std::stacktrace symbols.
The libstdc++fs.a archive is still installed, but its contents are
duplicated in libstdc++exp.a now. This means -lstdc++exp can be used
instead of -lstdc++fs. For targets using the GNU linker we should
consider replacing libstdc++fs.a with a linker script that does
INPUT(libstdc++exp.a).
The tests for <experimental/filesystem> could be changed to use
-lstdc++exp instead of -lstdc++fs, which would allow removing
src/filesystem/.libs from the LDFLAGS in scripts/testsuite_flags.in,
but that can be done at a later date.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CONFIGURE): Add c++23 directory.
* configure: Regenerate.
* doc/html/manual/*: Regenerate.
* doc/xml/manual/using.xml: Update documentation on linking.
* include/std/stacktrace: Remove declarations of libbacktrace
APIs.
(stacktrace_entry::_S_err_handler, stacktrace_entry::_S_init):
Remove.
(stacktrace_entry::_Info): New class.
(stacktrace_entry::_M_get_info): Use _Info.
(__stacktrace_impl): New class.
(basic_stacktrace): Derive from __stacktrace_impl.
(basic_stacktrace::current): Use __stacktrace_impl::_S_current.
* scripts/testsuite_flags.in: Adjust LDFLAGS to find
libstdc++exp instead of libstdc++_libbacktrace.
* src/Makefile.am (SUBDIRS): Add c++23 directory.
* src/Makefile.in: Regenerate.
* src/c++20/Makefile.am: Fix comment.
* src/c++20/Makefile.in: Regenerate.
* src/c++23/Makefile.am: New file.
* src/c++23/Makefile.in: New file.
* src/c++23/stacktrace.cc: New file with definitions of
stacktrace_entry::_Info and __stacktrace_impl members.
* src/experimental/Makefile.am: Use LIBADD to include other
libraries.
* src/experimental/Makefile.in: Regenerate.
* src/libbacktrace/Makefile.am: Use noinst_LTLIBRARIES.
* src/libbacktrace/Makefile.in: Regenerate.
* testsuite/19_diagnostics/stacktrace/current.cc: Adjust
dg-options to use -lstdc++exp.
* testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
* testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
Likewise.
Jonathan Wakely [Thu, 7 Sep 2023 13:26:38 +0000 (14:26 +0100)]
libstdc++: Reduce output of 'make check'
This removes the 39 lines of shell commands that get echoed when
starting the testsuite. The fact that near the end of that output it
prints `echo "WARNING: could not find \`runtest'" 1>&2; :;` makes it
look like that warning is actually being shown to the user.
Suppress echoing the recipe, so that users only see the actual output
from the testsuite, not the makefile recipe as well.
libstdc++-v3/ChangeLog:
* testsuite/Makefile.am (check-DEJAGNU): Use @ in recipe.
* testsuite/Makefile.in: Regenerate.
Patrick Palka [Fri, 8 Sep 2023 16:02:20 +0000 (12:02 -0400)]
c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]
As described in detail in the PR, the CWG 2369 resolution has the
surprising consequence of introducing constraint recursion in seemingly
valid and innocent code.
This patch attempts to fix this surpising behavior for the majority of
problematic cases. Rather than checking satisfaction before _all_
non-dependent conversions, as specified by the CWG resolution, this patch
makes us first check "safe" non-dependent conversions, then satisfaction,
then followed by other non-dependent conversions. A conversion is
considered "safe" if computing it is guaranteed to not induce template
instantiation, and we conservatively determine this by checking for
user-declared constructors (resp. conversion functions) in the parm
(resp. arg) class type, roughly.
PR c++/99599
gcc/cp/ChangeLog:
* pt.cc (check_non_deducible_conversions): Add bool parameter
passed down to check_non_deducible_conversion.
(fn_type_unification): Call check_non_deducible_conversions
an extra time before satisfaction with noninst_only_p=true.
(conversion_may_instantiate_p): Define.
(check_non_deducible_conversion): Add bool parameter controlling
whether to compute only conversions that are guaranteed to
not induce template instantiation.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-recursive-sat4.C: Make 'Int' non-aggregate
in order to preserve intent of the testcase.
* g++.dg/cpp2a/concepts-nondep4.C: New test.
Recently three SPEC CPU 2017 benchmarks broke when using xtheadbb:
* 500.perlbench_r
* 525.x264_r
* 557.xz_r
Tracing the issue down revealed, that we emit a 'th.ext xN,xN,15,0'
for a extendqi<SUPERQI> insn, which is obviously wrong.
This patch splits the common 'extend<SHORT:mode><SUPERQI:mode>2_th_ext'
insn into two 'extendqi<SUPERQI>' and 'extendhi<SUPERQI>' insns,
which emit the right extension instruction.
Additionally, this patch adds test cases for these insns.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
gcc/ChangeLog:
* config/riscv/thead.md (*extend<SHORT:mode><SUPERQI:mode>2_th_ext):
Remove broken INSN.
(*extendhi<SUPERQI:mode>2_th_ext): New INSN.
(*extendqi<SUPERQI:mode>2_th_ext): New INSN.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadbb-ext-2.c: New test.
* gcc.target/riscv/xtheadbb-ext-3.c: New test.
Update contrib + libgomp ChangeLogs for failed reject-commit testing
The following commit should have enabled checking for invalid revert hashes;
it worked locally - but did work as pre-commit hook on sourceware
as it wasn't copied to the hook directory: r14-3777-gff20bce9f58 contrib/gcc-changelog: Check whether revert-commit exists
Hence, the following revert commit was wrongly applied: r14-3778-gfbbd9001e9b Revert "contrib/gcc-changelog: Check whether revert-commit exists"
(In this commit: contrib/ChangeLog update for the revert.)
r14-3779-g69e83181ebc contrib/gcc-changelog: Check whether revert-commit exists
Re-applied the commit with a commit-log typo fixed but missing a late commit.
r14-3780-g1b0934b7276 Revert "contrib/gcc-changelog: Check whether revert-commit exists"
This commit still came through but re-instated the late wording fix in
contrib/gcc-changelog/git_commit.py.
(In this commit: contrib/ChangeLog update for the wording change.)
r14-3781-gd22cd7745ff Revert: "Another revert test with a bogus hash"
Another attempt to get a reject, but it still came through.
It removed tailing whitespace in libgomp/target.c
(In this commit: libgomp/ChangeLog was for the whitespace removal.)
Yang Yujie [Thu, 7 Sep 2023 06:50:10 +0000 (14:50 +0800)]
LoongArch: Adjust C++ multilib header layout.
For LoongArch, the toplevel library build is always aliased to
one of the multilib variants. This patch installs it with the
actual MULTISUBDIR (instead of ".") so that the headers can be
reached by the compiler.
This patch is an update of
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629435.html
libstdc++-v3/ChangeLog:
* configure.host: Register t-loongarch in tmake_file.
* config/cpu/loongarch/t-loongarch: New file. Manually refresh
MULTISUBDIR with $(shell $(CXX) --print-multi-directory).
Support vpermw/vpermi2w/vpermt2w instructions for vector HF/BFmodes.
gcc/ChangeLog:
* config/i386/sse.md
(<avx512>_vpermt2var<mode>3<sd_maskz_name>): New define_insn.
(VHFBF_AVX512VL): New mode iterator.
(VI2HFBF_AVX512VL): New mode iterator.
David Malcolm [Thu, 7 Sep 2023 22:43:05 +0000 (18:43 -0400)]
analyzer: basic support for computed gotos (PR analyzer/110529)
PR analyzer/110529 notes that -fanalyzer was giving up on execution
paths that follow a computed goto, due to ignoring CFG edges with the
flag EDGE_ABNORMAL set.
This patch implements enough handling for them to allow analysis of
such execution paths to continue.
In the conversion of iranges to wide_int (commit cb779afeff204f), I
mistakenly made contains_zero_p() return TRUE for undefined ranges.
This means the rest of the patch was adjusted for this stupidity.
For example, we ended up doing the following, to make up for the fact
that contains_zero_p was broken:
- if (!lhs.contains_p (build_zero_cst (lhs.type ())))
+ if (lhs.undefined_p () || !contains_zero_p (lhs))
This patch fixes the thinko and adjusts all callers.
In places where a caller is not checking undefined_p(), it is because
either the caller has already handled undefined ranges in the
preceeding code, or the check is superfluous.
benjamin priour [Fri, 1 Sep 2023 18:21:41 +0000 (20:21 +0200)]
analyzer: Call off a superseding when diagnostics are unrelated [PR110830]
Before this patch, a saved_diagnostic would supersede another at
the same statement if and only its vfunc supercedes_p returned true
for the other diagnostic's kind.
That both warning were unrelated - i.e. resolving one would not fix
the other - was not considered in making the above choice.
This patch makes it so that two saved_diagnostics taking a different
outcome of at least one common conditional branching cannot supersede
each other.
Signed-off-by: Benjamin Priour <vultkayn@gcc.gnu.org> Co-authored-by: David Malcolm <dmalcolm@redhat.com> Signed-off-by: David Malcolm <dmalcolm@redhat.com>
gcc/analyzer/ChangeLog:
PR analyzer/110830
* diagnostic-manager.cc
(compatible_epaths_p): New function.
(saved_diagnostic::supercedes_p): Now calls the above
to determine if the diagnostics do overlap and the superseding
may proceed.
gcc/testsuite/ChangeLog:
PR analyzer/110830
* c-c++-common/analyzer/pr110830.c: New test.
Andrew MacLeod [Thu, 7 Sep 2023 15:15:50 +0000 (11:15 -0400)]
Some ssa-names get incorrectly marked as always_current.
When range_of_stmt invokes prefill_name to evaluate unvisited dependencies
it should not mark already visited names as always_current.
PR tree-optimization/110875
gcc/
* gimple-range.cc (gimple_ranger::prefill_name): Only invoke
cache-prefilling routine when the ssa-name has no global value.
This ICE was caused by an invalid assumption that all BIND_EXPRs have
a non-null BIND_EXPR_BLOCK. In C++ these do exist and are used for
temporaries introduced in expressions that are not full-expressions.
Since they have no block to fix up, the traversal can just ignore
these tree nodes.
gcc/cp/ChangeLog
PR c++/111274
* parser.cc (fixup_blocks_walker): Check for null BIND_EXPR_BLOCK.
gcc/testsuite/ChangeLog
PR c++/111274
* g++.dg/gomp/pr111274.C: New test case.
Jonathan Wakely [Thu, 7 Sep 2023 16:03:40 +0000 (17:03 +0100)]
libstdc++: Add autoconf checks for mkdir, chmod, chdir, and getcwd
The filesystem code was using these functions without checking for their
existence, assuming that any UNIX-like libc with <unistd.h> would always
provide them. That's not true for some newlib targets like arm-eabi.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for mkdir,
chmod, chdir, and getcwd.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/c++17/fs_ops.cc (create_dir): Use USE_MKDIR macro.
(fs::current_path): Use USE_GETCWD and USE_CHDIR macros.
(fs::permissions): Use USE_CHMOD macro.
* src/filesystem/ops-common.h [FILESYSTEM_IS_WINDOWS]
(chmod, mkdir, getcwd, chdir): Define new macros.
[FILESYSTEM_IS_WINDOWS] (chmod, mkdir, getcwd, chdir): Use
new macros.
* src/filesystem/ops.cc (create_dir): Use USE_MKDIR macro.
(fs::current_path): Use USE_GETCWD and USE_CHDIR macros.
(fs::permissions): Use USE_CHMOD macro.
[LRA]: Don't reuse chosen insn alternative with special memory constraint
To speed up GCC, LRA reuses chosen alternative from previous
constraint subpass. A spilled pseudo is considered ok for any memory
constraint although stack slot assigned to the pseudo later might not
satisfy the chosen alternative constraint. As we don't consider all insn
alternatives on the subsequent LRA sub-passes, it might result in LRA failure
to generate the correct insn. This patch solves the problem.
gcc/ChangeLog:
PR target/111225
* lra-constraints.cc (goal_reuse_alt_p): New global flag.
(process_alt_operands): Set up the flag. Clear flag for chosen
alternative with special memory constraints.
(process_alt_operands): Set up used insn alternative depending on the flag.
gcc/testsuite/ChangeLog:
PR target/111225
* gcc.target/i386/pr111225.c: New test.
This should get rejected because of the invalid hash.
If it still is accepted, it does something sensible:
It removes tailing white space from a line in libgomp/target.c.
It reverts the test revert in commit r14-3778-gfbbd9001e9b6f2c59b542cc53a8f9183514091ce
which has a bogus commit hash and should have been rejected,
but we missed that - before testing - the script had to be
manually copied to the right place on sourceware to be
affective as pre-commit hook.
Thus, the r14-3777 commit had to be reinstate by this commit ...
contrib/ChangeLog:
* gcc-changelog/git_commit.py (GitCommit.__init__):
Handle commit_to_info_hook = None; otherwise, if None,
regard it as error.
(to_changelog_entries): Handle commit_to_info_hook = None;
if info is None, create a warning for it.
* gcc-changelog/git_email.py (GitEmail.__init__):
call super() with commit_to_info_hook=None instead
of a lambda function.
* gcc-changelog/git_commit.py (GitCommit.__init__):
Handle commit_to_info_hook = None; otherwise, if None,
regard it as error.
(to_changelog_entries): Handle commit_to_info_hook = None;
if info is None, create a warning for it.
* gcc-changelog/git_email.py (GitEmail.__init__):
call super() with commit_to_info_hook=None instead
of a lamda function.
Jakub Jelinek [Thu, 7 Sep 2023 09:17:04 +0000 (11:17 +0200)]
middle-end: Avoid calling targetm.c.bitint_type_info inside of gcc_assert [PR102989]
On Thu, Sep 07, 2023 at 10:36:02AM +0200, Thomas Schwinge wrote:
> Minor comment/question: are we doing away with the property that
> 'assert'-like "calls" must not have side effects? Per 'gcc/system.h',
> this is "OK" for 'gcc_assert' for '#if ENABLE_ASSERT_CHECKING' or
> '#elif (GCC_VERSION >= 4005)' -- that is, GCC 4.5, which is always-true,
> thus the "offending" '#else' is never active. However, it's different
> for standard 'assert' and 'gcc_checking_assert', so I'm not sure if
> that's a good property for 'gcc_assert' only? For example, see also
> <https://gcc.gnu.org/PR6906> "warn about asserts with side effects", or
> recent <https://gcc.gnu.org/PR111144>
> "RFE: could -fanalyzer warn about assertions that have side effects?".
You're right, the
#define gcc_assert(EXPR) ((void)(0 && (EXPR)))
fallback definition is incompatible with the way I've used it, so for
--disable-checking built by non-GCC it would not work properly.
2023-09-07 Jakub Jelinek <jakub@redhat.com>
PR c/102989
* expr.cc (expand_expr_real_1): Don't call targetm.c.bitint_type_info
inside gcc_assert, as later code relies on it filling info variable.
* gimple-fold.cc (clear_padding_bitint_needs_padding_p,
clear_padding_type): Likewise.
* varasm.cc (output_constant): Likewise.
* fold-const.cc (native_encode_int, native_interpret_int): Likewise.
* stor-layout.cc (finish_bitfield_representative, layout_type):
Likewise.
* gimple-lower-bitint.cc (bitint_precision_kind): Likewise.
Jonathan Wakely [Wed, 6 Sep 2023 13:13:18 +0000 (14:13 +0100)]
libstdc++: Fix <ranges> tests that fail in C++23
The tests for the std::ranges access CPOs (ranges::begin etc) use
pathological types with ridiculous overload sets for begin/end/data
members, to exercise all the corner cases in the specification.
Since P2278R4 "cbegin should always return a constant iterator" was
implemented for C++23 mode, some of the range access CPOs now require
the argument to satisfy the range concept, which was not previously
required. The behaviour of the CPO also changes for corner cases where
the type is a range R for which constant_range<R> is satisfied in
addition to constant_range<const R> (meaning there's no need to wrap its
iterators in const_iterator). Adjust the expected results for those
pathological types that changed meaning in C++23, and add some new types
to verify other corner cases.
Some other range adaptor tests fail for C++20 because they assert that
ranges::end and ranges::cend return different types, which is not true
when the type satisfies constant_range.
This fixes the tests to PASS for both C++20 and C++23 (and later).
This implements the C++23 change "Poison Pills are Too Toxic". This
makes sense to do unconditionally for C++20, as the corner cases that it
fixes are considered to be defects in the C++20 design (e.g. LWG3480 was
needed to fix directory iterators because of these pills being too
toxic).
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (__imove::iter_move): Define
poison pill as deleted for consistency.
(__access::begin): Replace with a single declaration.
* include/bits/ranges_base.h (__access::end, __access::rbegin)
(__access::rend, __access::size): Likewise.
* include/bits/version.def (ranges): Update value for C++23.
* include/bits/version.h: Regenerate.
* libsupc++/compare (__compare): Add missing poison pill
overloads.
* testsuite/std/ranges/version_c++23.cc: Adjust expected value
of __cpp_lib_ranges.
* testsuite/std/ranges/access/p2602.cc: New test.
Jonathan Wakely [Wed, 6 Sep 2023 12:21:57 +0000 (13:21 +0100)]
libstdc++: Rename C++20 Customization Point Objects
This makes the naming of the CPO types and namespaces simpler and more
consistent. With this change the string "cust" won't appear in
diagnostics related to these CPOs, which avoids confusion about what it
means (customization? customer?). Users don't really need to care that
these are called "customization point objects", so don't show them the
string "cust". Names like "__imove::_IterMove" are preferable to names
like "__cust_imove::_IMove" as the former is more obviously related to
the public API "ranges::iter_move".
Instead of a plethora of inline namespaces for all the different CPO
objects, define them all in an inline namespace called _Cpo (which isn't
shown to users anyway, unlike the types of those objects).
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h (ranges::__cust_imove):
Rename to ranges::__imove.
(_IMove): Rename to _IterMove.
(ranges::__cust_iswap): Rename to ranges::__iswap.
(ranges::__cust): Rename to ranges::_Cpo.
(ranges::__cust_access): Rename to ranges::__access.
* include/bits/ranges_base.h (ranges::__cust_access): Rename to
ranges::__access.
(ranges::__cust): Rename to ranges::_Cpo.
* include/std/concepts (ranges::__cust_swap): Rename to
ranges::__swap.
(ranges::__cust): Rename to ranges::_Cpo.
* libsupc++/compare (__cmp_cust): Rename to __compare.
(__cmp_algo): Rename to _Cpo.
Jonathan Wakely [Tue, 5 Sep 2023 21:07:22 +0000 (22:07 +0100)]
libstdc++: Relax range adaptors for move-only types (P2494R2)
This is a C++23 feature that relaxes the constraints on some range
adaptors, to support move-only types.
libstdc++-v3/ChangeLog:
* include/bits/version.def (ranges): Update value.
* include/bits/version.h: Regenerate.
* include/std/ranges (__detail::__boxable): Use
move_constructible instead of copy_constructible for C++23.
(__detail::__box<T>): Adjust constraints for partial
specialization.
(single_view, transform_view): Use __box_constructible instead
of copy_constructible in constraints.
(zip_transform_view, adjacent_transform_view, repeat_view): Use
move_constructible instead of copy_constructible in constraints.
* testsuite/std/ranges/adaptors/adjacent_transform/1.cc: Check
construction from move-only argument.
* testsuite/std/ranges/adaptors/transform.cc: Likewise.
* testsuite/std/ranges/repeat/1.cc: Likewise.
* testsuite/std/ranges/single_view.cc: Likewise.
* testsuite/std/ranges/zip_transform/1.cc: Likewise.
* testsuite/std/ranges/version_c++23.cc: Adjust expected value
of __cpp_lib_ranges.
While backporting another patch to an earlier release, I hit a
situation in which lra_eliminate_regs_1 would eliminate an address to:
(plus (reg:P R) (const_int 0))
This address compared not-equal to plain:
(reg:P R)
which caused an ICE in a later peephole2. (The ICE showed up in
gfortran.fortran-torture/compile/pr80464.f90 on the branch but seems
to be latent on trunk.)
These unfolded PLUSes shouldn't occur in the insn stream, and later code
in the same function tried to avoid them.
gcc/
* lra-eliminations.cc (lra_eliminate_regs_1): Use simplify_gen_binary
rather than gen_rtx_PLUS.
RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313]
This patch removes the incorrect earliest poset vsetvl optimization,
such bug was found in vect-double-reduc-5.c which is runtime(execution fail) and also in PR111313.
For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl (see vector.md) to
occupy a scalar register which is used by the following RVV instruction which is VLMAX AVL.
Then for O2, O3, Ofast, earliest LCM works so well.
However, for O1, the vlmax_avl is not well optimized in the before pass which confused LCM earliest
so that we will end up with some redundant vsetvli zero,zero instructions in O1. (Note that O2 O3 Ofast are all good).
To elide those redundant vsetvli zero,zero, I added cleanup_earliest_vsetvls to elide those redundant vsetvls.
Now, after I review the implementation of this post optimizaiton again, I found it is incorrect and it is hard to
do the post optimizations for vsetvls that earliest LCM failed to eliminate.
Besides, such performance issues only happen in O1 or O0, such issues may not be serious.
So remove it and we may will find another way (E.g. adjust vlmax_avl pattern COST)
to optimize it if we really need to care about performance for O1.
Tsukasa OI [Wed, 30 Aug 2023 02:34:35 +0000 (02:34 +0000)]
RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support
'XVentanaCondOps' is a vendor extension from Ventana Micro Systems
containing two instructions for conditional move and will be supported on
their Veyron V1 CPU.
And most notably (for historical reasons), 'XVentanaCondOps' and the
standard 'Zicond' extension are functionally equivalent (only encodings and
instruction names are different).
* czero.eqz == vt.maskc
* czero.nez == vt.maskcn
This commit adds support for the 'XVentanaCondOps' extension by extending
'Zicond' extension support. With this, we can now reuse the optimization
using the 'Zicond' extension for the 'XVentanaCondOps' extension.
The specification for the 'XVentanaCondOps' extension is based on:
<https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.1/ventana-custom-extensions-v1.0.1.pdf>
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Parse 'XVentanaCondOps' extension.
* config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS): New.
(TARGET_XVENTANACONDOPS): Ditto.
(TARGET_ZICOND_LIKE): New to represent targets with conditional
moves like 'Zicond'. It includes RV64 + 'XVentanaCondOps'.
* config/riscv/riscv.cc (riscv_rtx_costs): Replace TARGET_ZICOND
with TARGET_ZICOND_LIKE.
(riscv_expand_conditional_move): Ditto.
* config/riscv/riscv.md (mov<mode>cc): Replace TARGET_ZICOND with
TARGET_ZICOND_LIKE.
* config/riscv/riscv.opt: Add new riscv_xventana_subext.
* config/riscv/zicond.md: Modify description.
(eqz_ventana): New to match corresponding czero instructions.
(nez_ventana): Ditto.
(*czero.<eqz>.<GPR><X>): Emit a 'XVentanaCondOps' instruction if
'Zicond' is not available but 'XVentanaCondOps' + RV64 is.
(*czero.<eqz>.<GPR><X>): Ditto.
(*czero.eqz.<GPR><X>.opt1): Ditto.
(*czero.nez.<GPR><X>.opt2): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xventanacondops-primitiveSemantics.c: New test,
* gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c: New
test to make sure that XVentanaCondOps instructions are disabled
on RV32.
* gcc.target/riscv/xventanacondops-xor-01.c: New test,