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,
Jakub Jelinek [Wed, 6 Sep 2023 15:52:24 +0000 (17:52 +0200)]
Additional _BitInt test coverage [PR102989]
On Tue, Sep 05, 2023 at 10:40:26PM +0000, Joseph Myers wrote:
> Additional tests I think should be added (for things I expect should
> already work):
>
> * Tests for BITINT_MAXWIDTH in <limits.h>. Test that it's defined for
> C2x, but not defined for C11/C17 (the latter independent of whether the
> target has _BitInt support). Test the value as well: _BitInt
> (BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt
> (BITINT_MAXWIDTH + 1) should not be OK. Also test that BITINT_MAXWIDTH >=
> ULLONG_MAX.
>
> * Test _BitInt (N) where N is a constexpr variable or enum constant (I
> expect these should work - the required call to convert_lvalue_to_rvalue
> for constexpr to work is present - but I don't see such tests in the
> testsuite).
>
> * Test that -funsigned-bitfields does not affect the signedness of _BitInt
> (N) bit-fields (the standard wording isn't entirely clear, but that's
> what's implemented in the patches).
>
> * Test the errors for _Sat used with _BitInt (though such a test might not
> actually run at present because no target supports both features).
The following patch does that plus for most of the new changes in the
C _BitInt support patch requested in patch review it also does testsuite
coverage.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
* gcc.dg/bitint-2.c (foo): Add tests for constexpr var or enumerator
arguments of _BitInt.
* gcc.dg/bitint-31.c: Remove forgotten 0 &&.
* gcc.dg/bitint-32.c: New test.
* gcc.dg/bitint-33.c: New test.
* gcc.dg/bitint-34.c: New test.
* gcc.dg/bitint-35.c: New test.
* gcc.dg/bitint-36.c: New test.
* gcc.dg/fixed-point/bitint-1.c: New test.
Jakub Jelinek [Wed, 6 Sep 2023 15:50:49 +0000 (17:50 +0200)]
Handle BITINT_TYPE in build_{,minus_}one_cst [PR102989]
Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
I forgot to handle BITINT_TYPE in these (while I've handled it in
build_zero_cst).
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
* tree.cc (build_one_cst, build_minus_one_cst): Handle BITINT_TYPE
like INTEGER_TYPE.
Jakub Jelinek [Wed, 6 Sep 2023 15:49:44 +0000 (17:49 +0200)]
_BitInt profile fixes [PR102989]
On Thu, Aug 24, 2023 at 03:14:32PM +0200, Jan Hubicka via Gcc-patches wrote:
> this patch extends verifier to check that all probabilities and counts are
> initialized if profile is supposed to be present. This is a bit complicated
> by the posibility that we inline !flag_guess_branch_probability function
> into function with profile defined and in this case we need to stop
> verification. For this reason I added flag to cfg structure tracking this.
This patch broke a couple of _BitInt tests (in the admittedly still
uncommitted series - still waiting for review of the C FE bits).
Here is a minimal patch to make it work again, though I'm not sure
if in the if_then_else and if_then_if_then_else cases I shouldn't scale
count of the other bbs as well. if_then method creates
if (COND) new_bb1;
in a middle of some pre-existing bb (with PROB that COND is true), if_then_else
if (COND) new_bb1; else new_bb2;
and if_then_if_then_else
if (COND1) { if (COND2) new_bb2; else new_bb1; }
with PROB1 and PROB2 probabilities that COND1 and COND2 are true.
The lowering happens shortly after IPA.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
* gimple-lower-bitint.cc (bitint_large_huge::if_then_else,
bitint_large_huge::if_then_if_then_else): Use make_single_succ_edge
rather than make_edge, initialize bb->count.
Jakub Jelinek [Wed, 6 Sep 2023 15:47:49 +0000 (17:47 +0200)]
Add further _BitInt <-> floating point tests [PR102989]
Here are just the testsuite additions from libgcc _BitInt patch review.
On Fri, Sep 01, 2023 at 09:48:22PM +0000, Joseph Myers wrote:
> 1. Test overflowing conversions to integers (including from inf or NaN)
> raise FE_INVALID. (Note: it's not specified in the standard whether
> inexact conversions to integers raise FE_INEXACT or not, so testing that
> seems less important.)
This is in gcc.dg/bitint-28.c (FE_INVALID) and gcc.dg/bitint-29.c
(FE_INEXACT) for binary and dfp/bitint-8.c new tests.
> 2. Test conversions from integers to floating point raise FE_INEXACT when
> inexact, together with FE_OVERFLOW when overflowing (while exact
> conversions don't raise exceptions).
This is in gcc.dg/bitint-30.c new test.
> 3. Test conversions from integers to floating point respect the rounding
> mode.
This is in gcc.dg/bitint-31.c new test.
> 4. Test converting floating-point values in the range (-1.0, 0.0] to both
> unsigned and signed _BitInt; I didn't see such tests for binary floating
> types, only for decimal types, and the decimal tests didn't include tests
> of negative zero itself as the value converted to _BitInt.
This is done as incremental changes to existing tests.
> 5. Test conversions of noncanonical BID zero to integers (these tests
> would be specific to BID). See below for a bug in this area.
This is done in dfp/bitint-7.c test.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
* gcc.dg/torture/bitint-21.c (main): Add tests for -1 for signed only,
-1 + epsilon, another (-1, 0) range value and -0.
* gcc.dg/torture/bitint-22.c (main): Likewise.
* gcc.dg/bitint-28.c: New test.
* gcc.dg/bitint-29.c: New test.
* gcc.dg/bitint-30.c: New test.
* gcc.dg/bitint-31.c: New test.
* gcc.dg/dfp/bitint-1.c (main): Add tests for -1 for signed only,
-1 + epsilon and -0.
* gcc.dg/dfp/bitint-2.c (main): Likewise.
* gcc.dg/dfp/bitint-3.c (main): Likewise.
* gcc.dg/dfp/bitint-7.c: New test.
* gcc.dg/dfp/bitint-8.c: New test.
Jakub Jelinek [Wed, 6 Sep 2023 15:42:37 +0000 (17:42 +0200)]
libgcc _BitInt helper documentation [PR102989]
On Mon, Aug 21, 2023 at 05:32:04PM +0000, Joseph Myers wrote:
> I think the libgcc functions (i.e. those exported by libgcc, to which
> references are generated by the compiler) need documenting in libgcc.texi.
> Internal functions or macros in the libgcc patch need appropriate comments
> specifying their semantics; especially FP_TO_BITINT and FP_FROM_BITINT
> which have a lot of arguments and no comments saying what the semantics of
> the macros and their arguments are supposed to me.
Here is an incremental patch which does that.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
gcc/
* doc/libgcc.texi (Bit-precise integer arithmetic functions):
Document general rules for _BitInt support library functions
and document __mulbitint3 and __divmodbitint4.
(Conversion functions): Document __fix{s,d,x,t}fbitint,
__floatbitint{s,d,x,t,h,b}f, __bid_fix{s,d,t}dbitint and
__bid_floatbitint{s,d,t}d.
libgcc/
* libgcc2.c (bitint_negate): Add function comment.
* soft-fp/bitint.h (bitint_negate): Add function comment.
(FP_TO_BITINT, FP_FROM_BITINT): Add comment explaining the macros.
Jakub Jelinek [Wed, 6 Sep 2023 15:39:15 +0000 (17:39 +0200)]
C _BitInt incremental fixes [PR102989]
On Wed, Aug 09, 2023 at 09:17:57PM +0000, Joseph Myers wrote:
> > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs
> > mention how those should be passed/returned; in a limited way they are
> > supported internally because the internal functions into which
> > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a
> > hack to return 2 values without using references/pointers
>
> What happens when the usual arithmetic conversions are applied to
> operands, one of which is a complex integer type and the other of which is
> a wider _BitInt type? I don't see anything in the code to disallow this
> case (which would produce an expression with a _Complex _BitInt type), or
> any testcases for it.
I've added a sorry for that case (+ return the narrower COMPLEX_TYPE).
Also added testcase to verify we don't create VECTOR_TYPEs of BITINT_TYPE
even if they have mode precision and suitable size (others were rejected
already before).
> Other testcases I think should be present (along with any corresponding
> changes needed to the code itself):
>
> * Verifying that the new integer constant suffix is rejected for C++.
Done.
> * Verifying appropriate pedwarn-if-pedantic for the new constant suffix
> for versions of C before C2x (and probably for use of _BitInt type
> specifiers before C2x as well) - along with the expected -Wc11-c2x-compat
> handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes.
Done.
Here is an incremental patch which does that.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
gcc/c/
* c-decl.cc (finish_declspecs): Emit pedwarn_c11 on _BitInt.
* c-typeck.cc (c_common_type): Emit sorry for common type between
_Complex integer and larger _BitInt and return the _Complex integer.
gcc/c-family/
* c-attribs.cc (type_valid_for_vector_size): Reject vector types
with BITINT_TYPE elements even if they have mode precision and
suitable size.
gcc/testsuite/
* gcc.dg/bitint-19.c: New test.
* gcc.dg/bitint-20.c: New test.
* gcc.dg/bitint-21.c: New test.
* gcc.dg/bitint-22.c: New test.
* gcc.dg/bitint-23.c: New test.
* gcc.dg/bitint-24.c: New test.
* gcc.dg/bitint-25.c: New test.
* gcc.dg/bitint-26.c: New test.
* gcc.dg/bitint-27.c: New test.
* g++.dg/ext/bitint1.C: New test.
* g++.dg/ext/bitint2.C: New test.
* g++.dg/ext/bitint3.C: New test.
* g++.dg/ext/bitint4.C: New test.
libcpp/
* expr.cc (cpp_classify_number): Diagnose wb literal suffixes
for -pedantic* before C2X or -Wc11-c2x-compat.
Jakub Jelinek [Wed, 6 Sep 2023 15:37:53 +0000 (17:37 +0200)]
testsuite part 2 for _BitInt support [PR102989]
This is second part of the testcase additions in order to fit into
mailing lists limits. Most of these tests are for the floating
point conversions, atomics, __builtin_*_overflow and -fsanitize=undefined.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
gcc/testsuite/
* gcc.dg/torture/bitint-20.c: New test.
* gcc.dg/torture/bitint-21.c: New test.
* gcc.dg/torture/bitint-22.c: New test.
* gcc.dg/torture/bitint-23.c: New test.
* gcc.dg/torture/bitint-24.c: New test.
* gcc.dg/torture/bitint-25.c: New test.
* gcc.dg/torture/bitint-26.c: New test.
* gcc.dg/torture/bitint-27.c: New test.
* gcc.dg/torture/bitint-28.c: New test.
* gcc.dg/torture/bitint-29.c: New test.
* gcc.dg/torture/bitint-30.c: New test.
* gcc.dg/torture/bitint-31.c: New test.
* gcc.dg/torture/bitint-32.c: New test.
* gcc.dg/torture/bitint-33.c: New test.
* gcc.dg/torture/bitint-34.c: New test.
* gcc.dg/torture/bitint-35.c: New test.
* gcc.dg/torture/bitint-36.c: New test.
* gcc.dg/torture/bitint-37.c: New test.
* gcc.dg/torture/bitint-38.c: New test.
* gcc.dg/torture/bitint-39.c: New test.
* gcc.dg/torture/bitint-40.c: New test.
* gcc.dg/torture/bitint-41.c: New test.
* gcc.dg/torture/bitint-42.c: New test.
* gcc.dg/atomic/stdatomic-bitint-1.c: New test.
* gcc.dg/atomic/stdatomic-bitint-2.c: New test.
* gcc.dg/dfp/bitint-1.c: New test.
* gcc.dg/dfp/bitint-2.c: New test.
* gcc.dg/dfp/bitint-3.c: New test.
* gcc.dg/dfp/bitint-4.c: New test.
* gcc.dg/dfp/bitint-5.c: New test.
* gcc.dg/dfp/bitint-6.c: New test.
* gcc.dg/ubsan/bitint-1.c: New test.
* gcc.dg/ubsan/bitint-2.c: New test.
* gcc.dg/ubsan/bitint-3.c: New test.
Jakub Jelinek [Wed, 6 Sep 2023 15:36:41 +0000 (17:36 +0200)]
testsuite part 1 for _BitInt support [PR102989]
This patch adds first part of the testsuite support. When creating the
testcases, I've been using
https://defuse.ca/big-number-calculator.htm
tool, a randombitint tool I wrote (posted as a reply to the first series) plus
LLVM trunk on godbolt and the WIP GCC support checking if both compilers
agree on stuff (and in case of differences tried constant evaluation etc.).
The whole testsuite has been also tested with
make -j32 -k check-gcc GCC_TEST_RUN_EXPENSIVE=1 \
RUNTESTFLAGS='GCC_TEST_RUN_EXPENSIVE=1 --target_board=unix\{-m32,-m64\} ubsan.exp=bitint*.c dg.exp=bitint* dg-torture.exp=bitint*'
to verify it in all modes, normally I'm limitting the torture tests to just
-O0 and -O2 because they are quite large and expensive.
Generally it is needed to test different _BitInt precisions because they
are lowered differently (the small vs. medium vs. large vs. huge, precision
of multiples of limb precision or some other etc.).
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_bitint,
check_effective_target_bitint128, check_effective_target_bitint575):
New effective targets.
* gcc.dg/bitint-1.c: New test.
* gcc.dg/bitint-2.c: New test.
* gcc.dg/bitint-3.c: New test.
* gcc.dg/bitint-4.c: New test.
* gcc.dg/bitint-5.c: New test.
* gcc.dg/bitint-6.c: New test.
* gcc.dg/bitint-7.c: New test.
* gcc.dg/bitint-8.c: New test.
* gcc.dg/bitint-9.c: New test.
* gcc.dg/bitint-10.c: New test.
* gcc.dg/bitint-11.c: New test.
* gcc.dg/bitint-12.c: New test.
* gcc.dg/bitint-13.c: New test.
* gcc.dg/bitint-14.c: New test.
* gcc.dg/bitint-15.c: New test.
* gcc.dg/bitint-16.c: New test.
* gcc.dg/bitint-17.c: New test.
* gcc.dg/bitint-18.c: New test.
* gcc.dg/torture/bitint-1.c: New test.
* gcc.dg/torture/bitint-2.c: New test.
* gcc.dg/torture/bitint-3.c: New test.
* gcc.dg/torture/bitint-4.c: New test.
* gcc.dg/torture/bitint-5.c: New test.
* gcc.dg/torture/bitint-6.c: New test.
* gcc.dg/torture/bitint-7.c: New test.
* gcc.dg/torture/bitint-8.c: New test.
* gcc.dg/torture/bitint-9.c: New test.
* gcc.dg/torture/bitint-10.c: New test.
* gcc.dg/torture/bitint-11.c: New test.
* gcc.dg/torture/bitint-12.c: New test.
* gcc.dg/torture/bitint-13.c: New test.
* gcc.dg/torture/bitint-14.c: New test.
* gcc.dg/torture/bitint-15.c: New test.
* gcc.dg/torture/bitint-16.c: New test.
* gcc.dg/torture/bitint-17.c: New test.
* gcc.dg/torture/bitint-18.c: New test.
* gcc.dg/torture/bitint-19.c: New test.
Jakub Jelinek [Wed, 6 Sep 2023 15:34:49 +0000 (17:34 +0200)]
C _BitInt support [PR102989]
This patch adds the C FE support, c-family support, small libcpp change
so that 123wb and 42uwb suffixes are handled plus glimits.h change
to define BITINT_MAXWIDTH macro.
The previous patches really do nothing without this, which enables
all the support.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
gcc/
* glimits.h (BITINT_MAXWIDTH): Define if __BITINT_MAXWIDTH__ is
predefined.
gcc/c-family/
* c-common.cc (c_common_reswords): Add _BitInt as keyword.
(unsafe_conversion_p): Handle BITINT_TYPE like INTEGER_TYPE.
(c_common_signed_or_unsigned_type): Handle BITINT_TYPE.
(c_common_truthvalue_conversion, c_common_get_alias_set,
check_builtin_function_arguments): Handle BITINT_TYPE like
INTEGER_TYPE.
(sync_resolve_size): Add ORIG_FORMAT argument. If
FETCH && !ORIG_FORMAT, type is BITINT_TYPE, return -1 if size isn't
one of 1, 2, 4, 8 or 16 or if it is 16 but TImode is not supported.
(atomic_bitint_fetch_using_cas_loop): New function.
(resolve_overloaded_builtin): Adjust sync_resolve_size caller. If
-1 is returned, use atomic_bitint_fetch_using_cas_loop to lower it.
Formatting fix.
(keyword_begins_type_specifier): Handle RID_BITINT.
* c-common.h (enum rid): Add RID_BITINT enumerator.
* c-cppbuiltin.cc (c_cpp_builtins): For C call
targetm.c.bitint_type_info and predefine __BITINT_MAXWIDTH__
and for -fbuilding-libgcc also __LIBGCC_BITINT_LIMB_WIDTH__ and
__LIBGCC_BITINT_ORDER__ macros if _BitInt is supported.
* c-lex.cc (interpret_integer): Handle CPP_N_BITINT.
* c-pretty-print.cc (c_pretty_printer::simple_type_specifier,
c_pretty_printer::direct_abstract_declarator,
c_pretty_printer::direct_declarator, c_pretty_printer::declarator):
Handle BITINT_TYPE.
(pp_c_integer_constant): Handle printing of large precision wide_ints
which would buffer overflow digit_buffer.
* c-warn.cc (conversion_warning, warnings_for_convert_and_check,
warnings_for_convert_and_check): Handle BITINT_TYPE like
INTEGER_TYPE.
gcc/c/
* c-convert.cc (c_convert): Handle BITINT_TYPE like INTEGER_TYPE.
* c-decl.cc (check_bitfield_type_and_width): Allow BITINT_TYPE
bit-fields.
(finish_struct): Prefer to use BITINT_TYPE for BITINT_TYPE bit-fields
if possible.
(declspecs_add_type): Formatting fixes. Handle cts_bitint. Adjust
for added union in *specs. Handle RID_BITINT.
(finish_declspecs): Handle cts_bitint. Adjust for added union
in *specs.
* c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs,
c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle
RID_BITINT.
(c_parser_omp_clause_schedule): Handle BITINT_TYPE like INTEGER_TYPE.
* c-tree.h (enum c_typespec_keyword): Mention _BitInt in comment.
Add cts_bitint enumerator.
(struct c_declspecs): Move int_n_idx and floatn_nx_idx into a union
and add bitint_prec there as well.
* c-typeck.cc (c_common_type, comptypes_internal):
Handle BITINT_TYPE.
(perform_integral_promotions): Promote BITINT_TYPE bit-fields to
their declared type.
(build_array_ref, build_unary_op, build_conditional_expr,
build_c_cast, convert_for_assignment, digest_init, build_binary_op):
Handle BITINT_TYPE.
* c-fold.cc (c_fully_fold_internal): Handle BITINT_TYPE like
INTEGER_TYPE.
* c-aux-info.cc (gen_type): Handle BITINT_TYPE.
libcpp/
* expr.cc (interpret_int_suffix): Handle wb and WB suffixes.
* include/cpplib.h (CPP_N_BITINT): Define.
Jakub Jelinek [Wed, 6 Sep 2023 15:33:05 +0000 (17:33 +0200)]
libgcc _BitInt support [PR102989]
This patch adds the library helpers for multiplication, division + modulo
and casts from and to floating point (both binary and decimal).
As described in the intro, the first step is try to reduce further the
passed in precision by skipping over most significant limbs with just zeros
or sign bit copies. For multiplication and division I've implemented
a simple algorithm, using something smarter like Karatsuba or Toom N-Way
might be faster for very large _BitInts (which we don't support right now
anyway), but could mean more code in libgcc, which maybe isn't what people
are willing to accept.
For the to/from floating point conversions the patch uses soft-fp, because
it already has tons of handy macros which can be used for that. In theory
it could be implemented using {,unsigned} long long or {,unsigned} __int128
to/from floating point conversions with some frexp before/after, but at that
point we already need to force it into integer registers and analyze it
anyway. Plus, for 32-bit arches there is no __int128 that could be used
for XF/TF mode stuff.
I know that soft-fp is owned by glibc and I think the op-common.h change
should be propagated there, but the bitint stuff is really GCC specific
and IMHO doesn't belong into the glibc copy.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
libgcc/
* config/aarch64/t-softfp (softfp_extras): Use += rather than :=.
* config/i386/64/t-softfp (softfp_extras): Likewise.
* config/i386/libgcc-glibc.ver (GCC_14.0.0): Export _BitInt support
routines.
* config/i386/t-softfp (softfp_extras): Add fixxfbitint and
bf, hf and xf mode floatbitint.
(CFLAGS-floatbitintbf.c, CFLAGS-floatbitinthf.c): Add -msse2.
* config/riscv/t-softfp32 (softfp_extras): Use += rather than :=.
* config/rs6000/t-e500v1-fp (softfp_extras): Likewise.
* config/rs6000/t-e500v2-fp (softfp_extras): Likewise.
* config/t-softfp (softfp_floatbitint_funcs): New.
(softfp_bid_list): New.
(softfp_func_list): Add sf and df mode from and to _BitInt libcalls.
(softfp_bid_file_list): New.
(LIB2ADD_ST): Add $(softfp_bid_file_list).
* config/t-softfp-sfdftf (softfp_extras): Add fixtfbitint and
floatbitinttf.
* config/t-softfp-tf (softfp_extras): Likewise.
* libgcc2.c (bitint_reduce_prec): New inline function.
(BITINT_INC, BITINT_END): Define.
(bitint_mul_1, bitint_addmul_1): New helper functions.
(__mulbitint3): New function.
(bitint_negate, bitint_submul_1): New helper functions.
(__divmodbitint4): New function.
* libgcc2.h (LIBGCC2_UNITS_PER_WORD): When building _BitInt support
libcalls, redefine depending on __LIBGCC_BITINT_LIMB_WIDTH__.
(__mulbitint3, __divmodbitint4): Declare.
* libgcc-std.ver.in (GCC_14.0.0): Export _BitInt support routines.
* Makefile.in (lib2funcs): Add _mulbitint3.
(LIB2_DIVMOD_FUNCS): Add _divmodbitint4.
* soft-fp/bitint.h: New file.
* soft-fp/fixdfbitint.c: New file.
* soft-fp/fixsfbitint.c: New file.
* soft-fp/fixtfbitint.c: New file.
* soft-fp/fixxfbitint.c: New file.
* soft-fp/floatbitintbf.c: New file.
* soft-fp/floatbitintdf.c: New file.
* soft-fp/floatbitinthf.c: New file.
* soft-fp/floatbitintsf.c: New file.
* soft-fp/floatbitinttf.c: New file.
* soft-fp/floatbitintxf.c: New file.
* soft-fp/op-common.h (_FP_FROM_INT): Add support for rsize up to
4 * _FP_W_TYPE_SIZE rather than just 2 * _FP_W_TYPE_SIZE.
* soft-fp/bitintpow10.c: New file.
* soft-fp/fixsdbitint.c: New file.
* soft-fp/fixddbitint.c: New file.
* soft-fp/fixtdbitint.c: New file.
* soft-fp/floatbitintsd.c: New file.
* soft-fp/floatbitintdd.c: New file.
* soft-fp/floatbitinttd.c: New file.
Jakub Jelinek [Wed, 6 Sep 2023 15:31:23 +0000 (17:31 +0200)]
libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989]
The following patch adds a header with generated helper tables to support
computation of powers of 10 from 10^0 to 10^6111 inclusive into a
sufficiently large array of _BitInt limbs. This is split from the rest
of the libgcc _BitInt support because it is quite large and together it
would run into gcc-patches mail length limits.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
libgcc/
* soft-fp/bitintpow10.h: New file.
Jakub Jelinek [Wed, 6 Sep 2023 15:30:07 +0000 (17:30 +0200)]
ubsan: _BitInt -fsanitize=undefined support [PR102989]
The following patch introduces some -fsanitize=undefined support for _BitInt,
but some of the diagnostics is limited by lack of proper support in the
library.
I've filed https://github.com/llvm/llvm-project/issues/64100 to request
proper support, for now some of the diagnostics might have less or more
confusing or inaccurate wording but UB should still be diagnosed when it
happens.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
gcc/
* internal-fn.cc (expand_ubsan_result_store): Add LHS, MODE and
DO_ERROR arguments. For non-mode precision BITINT_TYPE results
check if all padding bits up to mode precision are zeros or sign
bit copies and if not, jump to DO_ERROR.
(expand_addsub_overflow, expand_neg_overflow, expand_mul_overflow):
Adjust expand_ubsan_result_store callers.
* ubsan.cc: Include target.h and langhooks.h.
(ubsan_encode_value): Pass BITINT_TYPE values which fit into pointer
size converted to pointer sized integer, pass BITINT_TYPE values
which fit into TImode (if supported) or DImode as those integer types
or otherwise for now punt (pass 0).
(ubsan_type_descriptor): Handle BITINT_TYPE. For pstyle of
UBSAN_PRINT_FORCE_INT use TK_Integer (0x0000) mode with a
TImode/DImode precision rather than TK_Unknown used otherwise for
large/huge BITINT_TYPEs.
(instrument_si_overflow): Instrument BITINT_TYPE operations even when
they don't have mode precision.
* ubsan.h (enum ubsan_print_style): New enumerator.
gcc/c-family/
* c-ubsan.cc (ubsan_instrument_shift): Use UBSAN_PRINT_FORCE_INT
for type0 type descriptor.
Jakub Jelinek [Wed, 6 Sep 2023 15:27:41 +0000 (17:27 +0200)]
_BitInt lowering support [PR102989]
The following patch adds a new bitintlower lowering pass which lowers most
operations on medium _BitInt into operations on corresponding integer types,
large _BitInt into straight line code operating on 2 or more limbs and
finally huge _BitInt into a loop plus optional straight line code.
As the only supported architecture is little-endian, the lowering only
supports little-endian for now, because it would be impossible to test it
all for big-endian. Rest is written with any endian support in mind, but
of course only little-endian has been actually tested.
I hope it is ok to add big-endian support to the lowering pass incrementally
later when first big-endian target shows with the backend support.
There are 2 possibilities of adding such support, one would be minimal one,
just tweak limb_access function and perhaps one or two other spots and
transform there the indexes from little endian (index 0 is least significant)
to big endian for just the memory access. Advantage is I think maintainance
costs, disadvantage is that the loops will still iterate from 0 to some number
of limbs and we'd rely on IVOPTs or something similar changing it later if
needed. Or we could make those indexes endian related everywhere, though
I'm afraid that would be several hundreds of changes.
For switches indexed by large/huge _BitInt the patch invokes what the switch
lowering pass does (but only on those specific switches, not all of them);
the switch lowering breaks the switches into clusters and none of the clusters
can have a range which doesn't fit into 64-bit UWHI, everything else will be
turned into a tree of comparisons. For clusters normally emitted as smaller
switches, because we already have a guarantee that the low .. high range is
at most 64 bits, the patch forces subtraction of the low and turns it into
a 64-bit switch. This is done before the actual pass starts.
Similarly, we cancel lowering of certain constructs like ABS_EXPR, ABSU_EXPR,
MIN_EXPR, MAX_EXPR and COND_EXPR and turn those back to simpler comparisons
etc., so that fewer operations need to be lowered later.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
* Makefile.in (OBJS): Add gimple-lower-bitint.o.
* passes.def: Add pass_lower_bitint after pass_lower_complex and
pass_lower_bitint_O0 after pass_lower_complex_O0.
* tree-pass.h (PROP_gimple_lbitint): Define.
(make_pass_lower_bitint_O0, make_pass_lower_bitint): Declare.
* gimple-lower-bitint.h: New file.
* tree-ssa-live.h (struct _var_map): Add bitint member.
(init_var_map): Adjust declaration.
(region_contains_p): Handle map->bitint like map->outofssa_p.
* tree-ssa-live.cc (init_var_map): Add BITINT argument, initialize
map->bitint and set map->outofssa_p to false if it is non-NULL.
* tree-ssa-coalesce.cc: Include gimple-lower-bitint.h.
(build_ssa_conflict_graph): Call build_bitint_stmt_ssa_conflicts if
map->bitint.
(create_coalesce_list_for_region): For map->bitint ignore SSA_NAMEs
not in that bitmap, and allow res without default def.
(compute_optimized_partition_bases): In map->bitint mode try hard to
coalesce any SSA_NAMEs with the same size.
(coalesce_bitint): New function.
(coalesce_ssa_name): In map->bitint mode, or map->bitmap into
used_in_copies and call coalesce_bitint.
* gimple-lower-bitint.cc: New file.
Jakub Jelinek [Wed, 6 Sep 2023 15:25:49 +0000 (17:25 +0200)]
Middle-end _BitInt support [PR102989]
The following patch introduces the middle-end part of the _BitInt
support, a new BITINT_TYPE, handling it where needed, except the lowering
pass and sanitizer support.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
PR c/102989
* tree.def (BITINT_TYPE): New type.
* tree.h (TREE_CHECK6, TREE_NOT_CHECK6): Define.
(NUMERICAL_TYPE_CHECK, INTEGRAL_TYPE_P): Include
BITINT_TYPE.
(BITINT_TYPE_P): Define.
(CONSTRUCTOR_BITFIELD_P): Return true even for BLKmode bit-fields if
they have BITINT_TYPE type.
(tree_check6, tree_not_check6): New inline functions.
(any_integral_type_check): Include BITINT_TYPE.
(build_bitint_type): Declare.
* tree.cc (tree_code_size, wide_int_to_tree_1, cache_integer_cst,
build_zero_cst, type_hash_canon_hash, type_cache_hasher::equal,
type_hash_canon): Handle BITINT_TYPE.
(bitint_type_cache): New variable.
(build_bitint_type): New function.
(signed_or_unsigned_type_for, verify_type_variant, verify_type):
Handle BITINT_TYPE.
(tree_cc_finalize): Free bitint_type_cache.
* builtins.cc (type_to_class): Handle BITINT_TYPE.
(fold_builtin_unordered_cmp): Handle BITINT_TYPE like INTEGER_TYPE.
* cfgexpand.cc (expand_debug_expr): Punt on BLKmode BITINT_TYPE
INTEGER_CSTs.
* convert.cc (convert_to_pointer_1, convert_to_real_1,
convert_to_complex_1): Handle BITINT_TYPE like INTEGER_TYPE.
(convert_to_integer_1): Likewise. For BITINT_TYPE don't check
GET_MODE_PRECISION (TYPE_MODE (type)).
* doc/generic.texi (BITINT_TYPE): Document.
* doc/tm.texi.in (TARGET_C_BITINT_TYPE_INFO): New.
* doc/tm.texi: Regenerated.
* dwarf2out.cc (base_type_die, is_base_type, modified_type_die,
gen_type_die_with_usage): Handle BITINT_TYPE.
(rtl_for_decl_init): Punt on BLKmode BITINT_TYPE INTEGER_CSTs or
handle those which fit into shwi.
* expr.cc (expand_expr_real_1): Define EXTEND_BITINT macro, reduce
to bitfield precision reads from BITINT_TYPE vars, parameters or
memory locations. Expand large/huge BITINT_TYPE INTEGER_CSTs into
memory.
* fold-const.cc (fold_convert_loc, make_range_step): Handle
BITINT_TYPE.
(extract_muldiv_1): For BITINT_TYPE use TYPE_PRECISION rather than
GET_MODE_SIZE (SCALAR_INT_TYPE_MODE).
(native_encode_int, native_interpret_int, native_interpret_expr):
Handle BITINT_TYPE.
* gimple-expr.cc (useless_type_conversion_p): Make BITINT_TYPE
to some other integral type or vice versa conversions non-useless.
* gimple-fold.cc (gimple_fold_builtin_memset): Punt for BITINT_TYPE.
(clear_padding_unit): Mention in comment that _BitInt types don't need
to fit either.
(clear_padding_bitint_needs_padding_p): New function.
(clear_padding_type_may_have_padding_p): Handle BITINT_TYPE.
(clear_padding_type): Likewise.
* internal-fn.cc (expand_mul_overflow): For unsigned non-mode
precision operands force pos_neg? to 1.
(expand_MULBITINT, expand_DIVMODBITINT, expand_FLOATTOBITINT,
expand_BITINTTOFLOAT): New functions.
* internal-fn.def (MULBITINT, DIVMODBITINT, FLOATTOBITINT,
BITINTTOFLOAT): New internal functions.
* internal-fn.h (expand_MULBITINT, expand_DIVMODBITINT,
expand_FLOATTOBITINT, expand_BITINTTOFLOAT): Declare.
* match.pd (non-equality compare simplifications from fold_binary):
Punt if TYPE_MODE (arg1_type) is BLKmode.
* pretty-print.h (pp_wide_int): Handle printing of large precision
wide_ints which would buffer overflow digit_buffer.
* stor-layout.cc (finish_bitfield_representative): For bit-fields
with BITINT_TYPE, prefer representatives with precisions in
multiple of limb precision.
(layout_type): Handle BITINT_TYPE. Handle COMPLEX_TYPE with BLKmode
element type and assert it is BITINT_TYPE.
* target.def (bitint_type_info): New C target hook.
* target.h (struct bitint_info): New type.
* targhooks.cc (default_bitint_type_info): New function.
* targhooks.h (default_bitint_type_info): Declare.
* tree-pretty-print.cc (dump_generic_node): Handle BITINT_TYPE.
Handle printing large wide_ints which would buffer overflow
digit_buffer.
* tree-ssa-sccvn.cc: Include target.h.
(eliminate_dom_walker::eliminate_stmt): Punt for large/huge
BITINT_TYPE.
* tree-switch-conversion.cc (jump_table_cluster::emit): For more than
64-bit BITINT_TYPE subtract low bound from expression and cast to
64-bit integer type both the controlling expression and case labels.
* typeclass.h (enum type_class): Add bitint_type_class enumerator.
* varasm.cc (output_constant): Handle BITINT_TYPE INTEGER_CSTs.
* vr-values.cc (check_for_binary_op_overflow): Use widest2_int rather
than widest_int.
(simplify_using_ranges::simplify_internal_call_using_ranges): Use
unsigned_type_for rather than build_nonstandard_integer_type.
RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit
Previously, I add TARGET_64BIT condtion to block VLS modes with size = 64bit in RV32 system
E.g. V8QI
Since I realized such modes may cause inferior codegen for some situations in RV32 system.
However, this is really quite ugly and it cause ICE for some cases in RV32:
FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (internal compiler error: in require, at machmode.h:313)
3937FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (test for excess errors)
For inferior codegen in RV32 system, we should try another reasonable approach to fix it.
David Malcolm [Wed, 6 Sep 2023 13:32:01 +0000 (09:32 -0400)]
analyzer: implement kf_strncpy [PR105899]
gcc/analyzer/ChangeLog:
PR analyzer/105899
* kf.cc (class kf_strncpy): New.
(kf_strncpy::impl_call_post): New.
(register_known_functions): Register it.
* region-model.cc (region_model::read_bytes): Handle unknown
number of bytes.
gcc/testsuite/ChangeLog:
PR analyzer/105899
* c-c++-common/analyzer/null-terminated-strings-2.c: New test.
* c-c++-common/analyzer/overlapping-buffers.c: Update dg-bogus
directives to avoid clashing with note from <string.h> that might
happen to have the same line number. Add strpncpy test coverage.
* c-c++-common/analyzer/strncpy-1.c: New test.
* gcc.dg/analyzer/null-terminated-strings-1.c
(test_filled_nonzero): New.
(void test_filled_zero): New.
(test_filled_symbolic): New.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX
This patch optimizes the boolean evaluation for equality to 0 in SImode
using the MINU (Minimum Value Unsigned) machine instruction available
when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x, 1)
and (x == 0) to (MINU(x, 1) ^ 1).
/* example */
int test0(int x) {
return x == 0;
}
int test1(int x) {
return x != 0;
}
;; after (prereq. TARGET_MINMAX)
test0:
movi.n a9, 1
minu a2, a2, a9
xor a2, a2, a9
ret.n
test1:
movi.n a9, 1
minu a2, a2, a9
ret.n
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_expand_scc):
Add code for particular constants (only 0 and INT_MIN for now)
for EQ/NE boolean evaluation in SImode.
* config/xtensa/xtensa.md (*eqne_INT_MIN): Remove because its
implementation has been integrated into the above.
riscv: xtheadbb: Fix xtheadbb-li-rotr test for rv32
The test was introduced recently and tests a RV64-only feature.
However, when testing an RV32 compiler, the test gets executed as well
and fails with "cc1: error: ABI requires '-march=rv32'".
This patch fixes this by adding '-mabi=lp64' (like it is done for
other RV64-only tests as well).
Retested with RV32 and RV64 to ensure this won't pop up again.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadbb-li-rotr.c: Don't run for RV32.
RISC-V: Keep vlmax vector operators in simple form until split1 pass
This patch keep vlmax vector pattern in simple before split1 pass which
will allow more optimization (e.g. combine) before split1 pass.
This patch changes the vlmax pattern in autovec.md to define_insn_and_split
as much as possible and clean up some combine patterns that are no longer needed.
This patch also fixed PR111232 bug which was caused by a combined failed.
RISC-V: Part-3: Output .variant_cc directive for vector function
Functions which follow vector calling convention variant need be annotated by
.variant_cc directive according the RISC-V Assembly Programmer's Manual[1] and
RISC-V ELF Specification[2].
RISC-V: Part-2: Save/Restore vector registers which need to be preversed
Because functions which follow vector calling convention variant has
callee-saved vector reigsters but functions which follow standard calling
convention don't have. We need to distinguish which function callee is so that
we can tell GCC exactly which vector registers callee will clobber. So I encode
the callee's calling convention information into the calls rtx pattern like
AArch64. The old operand 2 and 3 of call pattern which copy from MIPS target are
useless and removed according to my analysis.
gcc/ChangeLog:
* config/riscv/riscv-sr.cc (riscv_remove_unneeded_save_restore_calls): Pass riscv_cc.
* config/riscv/riscv.cc (struct riscv_frame_info): Add new fileds.
(riscv_frame_info::reset): Reset new fileds.
(riscv_call_tls_get_addr): Pass riscv_cc.
(riscv_function_arg): Return riscv_cc for call patterm.
(get_riscv_cc): New function return riscv_cc from rtl call_insn.
(riscv_insn_callee_abi): Implement TARGET_INSN_CALLEE_ABI.
(riscv_save_reg_p): Add vector callee-saved check.
(riscv_stack_align): Add vector save area comment.
(riscv_compute_frame_info): Ditto.
(riscv_restore_reg): Update for type change.
(riscv_for_each_saved_v_reg): New function save vector registers.
(riscv_first_stack_step): Handle funciton with vector callee-saved registers.
(riscv_expand_prologue): Ditto.
(riscv_expand_epilogue): Ditto.
(riscv_output_mi_thunk): Pass riscv_cc.
(TARGET_INSN_CALLEE_ABI): Implement TARGET_INSN_CALLEE_ABI.
* config/riscv/riscv.h (get_riscv_cc): Export get_riscv_cc function.
* config/riscv/riscv.md: Add CALLEE_CC operand for call pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-1.c: New test.
* gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-2.c: New test.
* gcc.target/riscv/rvv/base/abi-callee-saved-1-save-restore.c: New test.
* gcc.target/riscv/rvv/base/abi-callee-saved-1-zcmp.c: New test.
* gcc.target/riscv/rvv/base/abi-callee-saved-1.c: New test.
* gcc.target/riscv/rvv/base/abi-callee-saved-2-save-restore.c: New test.
* gcc.target/riscv/rvv/base/abi-callee-saved-2-zcmp.c: New test.
* gcc.target/riscv/rvv/base/abi-callee-saved-2.c: New test.
RISC-V: Part-1: Select suitable vector registers for vector type args and returns
I post the vector register calling convention rules from in the proposal[1]
directly here:
v0 is used to pass the first vector mask argument to a function, and to return
vector mask result from a function. v8-v23 are used to pass vector data
arguments, vector tuple arguments and the rest vector mask arguments to a
function, and to return vector data and vector tuple results from a function.
Each vector data type and vector tuple type has an LMUL attribute that
indicates a vector register group. The value of LMUL indicates the number of
vector registers in the vector register group and requires the first vector
register number in the vector register group must be a multiple of it. For
example, the LMUL of `vint64m8_t` is 8, so v8-v15 vector register group can be
allocated to this type, but v9-v16 can not because the v9 register number is
not a multiple of 8. If LMUL is less than 1, it is treated as 1. If it is a
vector mask type, its LMUL is 1.
Each vector tuple type also has an NFIELDS attribute that indicates how many
vector register groups the type contains. Thus a vector tuple type needs to
take up LMUL×NFIELDS registers.
The rules for passing vector arguments are as follows:
1. For the first vector mask argument, use v0 to pass it. The argument has now
been allocated.
2. For vector data arguments or rest vector mask arguments, starting from the
v8 register, if a vector register group between v8-v23 that has not been
allocated can be found and the first register number is a multiple of LMUL,
then allocate this vector register group to the argument and mark these
registers as allocated. Otherwise, pass it by reference. The argument has now
been allocated.
3. For vector tuple arguments, starting from the v8 register, if NFIELDS
consecutive vector register groups between v8-v23 that have not been allocated
can be found and the first register number is a multiple of LMUL, then allocate
these vector register groups to the argument and mark these registers as
allocated. Otherwise, pass it by reference. The argument has now been allocated.
NOTE: It should be stressed that the search for the appropriate vector register
groups starts at v8 each time and does not start at the next register after the
registers are allocated for the previous vector argument. Therefore, it is
possible that the vector register number allocated to a vector argument can be
less than the vector register number allocated to previous vector arguments.
For example, for the function
`void foo (vint32m1_t a, vint32m2_t b, vint32m1_t c)`, according to the rules
of allocation, v8 will be allocated to `a`, v10-v11 will be allocated to `b`
and v9 will be allocated to `c`. This approach allows more vector registers to
be allocated to arguments in some cases.
Vector values are returned in the same manner as the first named argument of
the same type would be passed.
* config/riscv/riscv-protos.h (builtin_type_p): New function for checking vector type.
* config/riscv/riscv-vector-builtins.cc (builtin_type_p): Ditto.
* config/riscv/riscv.cc (struct riscv_arg_info): New fields.
(riscv_init_cumulative_args): Setup variant_cc field.
(riscv_vector_type_p): New function for checking vector type.
(riscv_hard_regno_nregs): Hoist declare.
(riscv_get_vector_arg): Subroutine of riscv_get_arg_info.
(riscv_get_arg_info): Support vector cc.
(riscv_function_arg_advance): Update cum.
(riscv_pass_by_reference): Handle vector args.
(riscv_v_abi): New function return vector abi.
(riscv_return_value_is_vector_type_p): New function for check vector arguments.
(riscv_arguments_is_vector_type_p): New function for check vector returns.
(riscv_fntype_abi): Implement TARGET_FNTYPE_ABI.
(TARGET_FNTYPE_ABI): Implement TARGET_FNTYPE_ABI.
* config/riscv/riscv.h (GCC_RISCV_H): Define macros for vector abi.
(MAX_ARGS_IN_VECTOR_REGISTERS): Ditto.
(MAX_ARGS_IN_MASK_REGISTERS): Ditto.
(V_ARG_FIRST): Ditto.
(V_ARG_LAST): Ditto.
(enum riscv_cc): Define all RISCV_CC variants.
* config/riscv/riscv.opt: Add --param=riscv-vector-abi.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/abi-call-args-1-run.c: New test.
* gcc.target/riscv/rvv/base/abi-call-args-1.c: New test.
* gcc.target/riscv/rvv/base/abi-call-args-2-run.c: New test.
* gcc.target/riscv/rvv/base/abi-call-args-2.c: New test.
* gcc.target/riscv/rvv/base/abi-call-args-3-run.c: New test.
* gcc.target/riscv/rvv/base/abi-call-args-3.c: New test.
* gcc.target/riscv/rvv/base/abi-call-args-4-run.c: New test.
* gcc.target/riscv/rvv/base/abi-call-args-4.c: New test.
* gcc.target/riscv/rvv/base/abi-call-error-1.c: New test.
* gcc.target/riscv/rvv/base/abi-call-return-run.c: New test.
* gcc.target/riscv/rvv/base/abi-call-return.c: New test.
Jakub Jelinek [Wed, 6 Sep 2023 06:51:00 +0000 (08:51 +0200)]
c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X
Now that _Float{16,32,64,128,32x,64x,128x} and
{f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard,
I think it is undesirable to pedwarn about these for -std=c2x, so this
patch uses pedwarn_c11 instead. In c-family/, we don't have that function
and am not sure it would be very clean to define dummy pedwarn_c11 in the
C++ FE, so the patch just does what pedwarn_c11 does using pedwarn/warning.
2023-09-06 Jakub Jelinek <jakub@redhat.com>
gcc/c-family/
* c-lex.cc (interpret_float): For C diagnostics on FN and FNx suffixes
append " before C2X" to diagnostics text and follow behavior of
pedwarn_c11.
gcc/c/
* c-decl.cc (declspecs_add_type): Use pedwarn_c11 rather than pedwarn
for _FloatN{,x} diagnostics and append " before C2X" to the diagnostic
text.
gcc/testsuite/
* gcc.dg/c11-floatn-1.c: New test.
* gcc.dg/c11-floatn-2.c: New test.
* gcc.dg/c11-floatn-3.c: New test.
* gcc.dg/c11-floatn-4.c: New test.
* gcc.dg/c11-floatn-5.c: New test.
* gcc.dg/c11-floatn-6.c: New test.
* gcc.dg/c11-floatn-7.c: New test.
* gcc.dg/c11-floatn-8.c: New test.
* gcc.dg/c2x-floatn-1.c: New test.
* gcc.dg/c2x-floatn-2.c: New test.
* gcc.dg/c2x-floatn-3.c: New test.
* gcc.dg/c2x-floatn-4.c: New test.
* gcc.dg/c2x-floatn-5.c: New test.
* gcc.dg/c2x-floatn-6.c: New test.
* gcc.dg/c2x-floatn-7.c: New test.
* gcc.dg/c2x-floatn-8.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-1.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_sqrt_run-2.c: New test.
Jason Merrill [Tue, 5 Sep 2023 21:36:28 +0000 (17:36 -0400)]
c++: [[no_unique_address]] and cv-qualified type
We were checking for overlap using same_type_p and therefore allocating two
Empty subobjects at the same offset because one was cv-qualified.
This gives the warning at the location of the class name rather than the
member declaration, but this should be a rare enough issue that it doesn't
seem worth trying to be more precise.
projects / thirdparty / gcc.git / log
