Re: [PATCH] Check sorting of MAINTAINERS
Hi!
On 2022-01-10T17:14:00+0100, Martin Liška wrote:
> The script is capable of checking if MAINTAINER names are sorted
> alphabetically.
Irrespective of the pre-existing issue that a concept of a first and a
last name doesn't exist in all cultures, and thus sorting by the latter
is questionable, there also seems to be some Python syntax issue here:
Running [...]/source-gcc/gcc/testsuite/gcc.src/maintainers.exp ...
Executing on host: python3 --version(timeout = 300)
spawn python3 --version
Python 3.4.3
Executing on host:
[...]/source-gcc/gcc/testsuite/../../contrib/check-MAINTAINERS.py
[...]/source-gcc/gcc/testsuite/../../MAINTAINERS (timeout = 300)
spawn [...]/source-gcc/gcc/testsuite/../../contrib/check-MAINTAINERS.py
[...]/source-gcc/gcc/testsuite/../../MAINTAINERS
File "[...]/source-gcc/gcc/testsuite/../../contrib/check-MAINTAINERS.py",
line 71
print(f'Line should not start with space: "{line}"')
^
SyntaxError: invalid syntax
1 { File
"[...]/source-gcc/gcc/testsuite/../../contrib/check-MAINTAINERS.py", line 71
print(f'Line should not start with space: "{line}"')
^
SyntaxError: invalid syntax
}
FAIL: check-MAINTAINERS.py
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
[PATCH] Enhance vec_pack_trunc for integral mode mask.
For testcase in PR, the patch supports QI:4 -> HI:16 pack with
multi steps(first pack QI:4 -> QI:8 through vec_pack_sbool_trunc_qi,
then pack QI:8 -> HI:16 through vec_pack_trunc_hi).
Similar for QI:2 -> HI:16 which is test4 in mask-pack-prefer-128.c.
Bootstrapped both with and w/o '--with-arch=native --with-cpu=native'
on CLX.
Regtested for x86_64-pc-linux-gnu{-m32,} and
x86_64-pc-linux-gnu{-m32\ -march=cascadelake,\ -march=cascadelake} on CLX.
This patch can partially fix the regression in PR since it enable
vectorization for epilogue.
I'm also working on another patch to prevent mask pack for testcase in PR,
and there will be a separate patch.
Ok for trunk?
gcc/ChangeLog:
PR target/103771
* tree-vect-stmts.c (supportable_narrowing_operation): Enhance
integral mode mask pack by multi steps which takes
vec_pack_sbool_trunc_optab as start when elements number is
less than BITS_PER_UNITS.
gcc/testsuite/ChangeLog:
* gcc.target/i386/mask-pack-prefer128.c: New test.
* gcc.target/i386/mask-pack-prefer128.c: New test.
* gcc.target/i386/pr103771.c: New test.
---
.../gcc.target/i386/mask-pack-prefer128.c | 8
.../gcc.target/i386/mask-pack-prefer256.c | 8
gcc/testsuite/gcc.target/i386/pr103771.c | 18 ++
gcc/tree-vect-stmts.c | 11 ---
4 files changed, 42 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/mask-pack-prefer128.c
create mode 100644 gcc/testsuite/gcc.target/i386/mask-pack-prefer256.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr103771.c
diff --git a/gcc/testsuite/gcc.target/i386/mask-pack-prefer128.c
b/gcc/testsuite/gcc.target/i386/mask-pack-prefer128.c
new file mode 100644
index 000..c9ea37c7ed3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mask-pack-prefer128.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-march=skylake-avx512 -O3 -fopenmp-simd
-fdump-tree-vect-details -mprefer-vector-width=128" } */
+/* Disabling epilogues until we find a better way to deal with scans. */
+/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 10 "vect" } } */
+/* { dg-final { scan-assembler-not "maskmov" } } */
+
+#include "mask-pack.c"
diff --git a/gcc/testsuite/gcc.target/i386/mask-pack-prefer256.c
b/gcc/testsuite/gcc.target/i386/mask-pack-prefer256.c
new file mode 100644
index 000..841f51b4041
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mask-pack-prefer256.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-march=skylake-avx512 -O3 -fopenmp-simd
-fdump-tree-vect-details -mprefer-vector-width=256" } */
+/* Disabling epilogues until we find a better way to deal with scans. */
+/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 10 "vect" } } */
+/* { dg-final { scan-assembler-not "maskmov" } } */
+
+#include "mask-pack.c"
diff --git a/gcc/testsuite/gcc.target/i386/pr103771.c
b/gcc/testsuite/gcc.target/i386/pr103771.c
new file mode 100644
index 000..a1a9952b6a8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr103771.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-march=cascadelake -O3 -fdump-tree-vect-details
-mprefer-vector-width=128" } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
+
+typedef unsigned char uint8_t;
+
+static uint8_t x264_clip_uint8 (int x)
+{
+ return x & (~255) ? (-x) >> 31 : x;
+}
+
+void
+mc_weight (uint8_t* __restrict dst, uint8_t* __restrict src,
+ int i_width,int i_scale)
+{
+ for(int x = 0; x < i_width; x++)
+dst[x] = x264_clip_uint8 (src[x] * i_scale);
+}
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index f2625a2ff40..4baf5e36127 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -12111,6 +12111,7 @@ supportable_narrowing_operation (enum tree_code code,
tree intermediate_type, prev_type;
machine_mode intermediate_mode, prev_mode;
int i;
+ unsigned HOST_WIDE_INT n_elts;
bool uns;
*multi_step_cvt = 0;
@@ -12120,8 +12121,10 @@ supportable_narrowing_operation (enum tree_code code,
c1 = VEC_PACK_TRUNC_EXPR;
if (VECTOR_BOOLEAN_TYPE_P (narrow_vectype)
&& VECTOR_BOOLEAN_TYPE_P (vectype)
- && TYPE_MODE (narrow_vectype) == TYPE_MODE (vectype)
- && SCALAR_INT_MODE_P (TYPE_MODE (vectype)))
+ && SCALAR_INT_MODE_P (TYPE_MODE (vectype))
+ && (TYPE_MODE (narrow_vectype) == TYPE_MODE (vectype)
+ || (TYPE_VECTOR_SUBPARTS (vectype).is_constant (_elts)
+ && n_elts < BITS_PER_UNIT)))
optab1 = vec_pack_sbool_trunc_optab;
else
optab1 = optab_for_tree_code (c1, vectype, optab_default);
@@ -12213,7 +12216,9 @@ supportable_narrowing_operation (enum tree_code code,
if (VECTOR_BOOLEAN_TYPE_P
Re: [PATCH] Fix tree-optimization/101941: IPA splitting out function with error attribute
On Mon, Jan 17, 2022 at 10:36 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Fri, Jan 14, 2022 at 09:41:35AM +0100, Jan Hubicka via Gcc-patches wrote:
> > > > > > > --- a/gcc/ipa-split.c
> > > > > > > +++ b/gcc/ipa-split.c
> > > > > > > @@ -873,7 +873,7 @@ visit_bb (basic_block bb, basic_block
> > > > > > > return_bb,
> > > > > > > gimple *stmt = gsi_stmt (bsi);
> > > > > > > tree op;
> > > > > > > ssa_op_iter iter;
> > > > > > > - tree decl;
> > > > > > > + tree decl = NULL_TREE;
> > > > > > >
> > > > > > > if (is_gimple_debug (stmt))
> > > > > > > continue;
> > > > > > > @@ -927,6 +927,16 @@ visit_bb (basic_block bb, basic_block
> > > > > > > return_bb,
> > Decl is initialized in
> > if (gimple_code (stmt) == GIMPLE_CALL
> > && (decl = gimple_call_fndecl (stmt)) != NULL_TREE
> > && fndecl_built_in_p (decl, BUILT_IN_NORMAL))
> >
> > I think this is confusing. I would change it to
> > if (gimple_code (stmt) == GIMPLE_CALL
> > && (decl = gimple_call_fndecl (stmt)) != NULL_TREE
> > {
> > if (fndecl_built_in_p (decl, BUILT_IN_NORMAL))
> > ... existing code ...
> > if (decl && (lookup_attribute ("warning", DECL_ATTRIBUTES (decl))
> > || lookup_attribute ("error", DECL_ATTRIBUTES (decl
> > ... your code ...
> > }
> > OK with that change.
>
> Perhaps even
> /* Check builtins that prevent splitting. */
> if (gimple_code (stmt) == GIMPLE_CALL)
> if (tree decl = gimple_call_fndecl (stmt))
> {
> if (fndecl_built_in_p (decl, BUILT_IN_NORMAL))
> ...
> if (lookup_attribute || lookup_attribute)
> ...
> }
> ?
Yes that looks good, I am just finished up the patch and going to run
a full bootstrap/test to make sure I didn't mess up.
I had originally trying not to reindent the code to make it easier to
see what was being added but I think re-indentation is correct after
all.
Thanks
Andrew
>
> Jakub
>
Re: [PATCH] Fix for GCC '-MF' option cannot deal with long paths in Windows
On Mon, Jan 17, 2022 at 8:35 AM Sundeep KOKKONDA via Gcc-patches wrote: > > Hello, > > > > The '-MF' option cannot deal with path size >256 characters in Windows. This > patch is to fix this long path issue with -MF option. > > Let me know is it ok to commit? I don't think this is the right place to put this. Maybe a better way to implement this is to have a wrapper around fopen for windows and do it that way. Does open have the same issue? Thanks, Andrew Pinski > > > > > > -- > > Thanks, > > Sundeep K. >
Re: [PATCH 2/6] libstdc++: Import the fast_float library
> From: Patrick Palka via Gcc-patches > Date: Sun, 16 Jan 2022 19:06:48 +0100 > We're going to use the fast_float library in our (compiled-in) > floating-point std::from_chars implementation for faster and more > portable parsing of binary32/64 decimal strings. > > The single file fast_float.h is an amalgamation of the entire library, > which can be (re)generated with the command > > python3 ./script/amalgamate.py --license=MIT \ > > $GCC_SRC/libstdc++-v3/c++17/fast_float/fast_float.h > > [1]: https://github.com/fastfloat/fast_float > > libstdc++-v3/ChangeLog: > > * src/c++17/fast_float/LOCAL_PATCHES: New file. > * src/c++17/fast_float/MERGE: New file. > * src/c++17/fast_float/README.fd: New file, copied from the > fast_float library sources. > * src/c++17/fast_float/fast_float.h: New file, an amalgamation > of the fast_float library. This broke builds for newlib targets, as they don't have but . See PR104080 for details. After the obvious fix, there seems to be some additional type mismatch also quoted in the bugzilla. Not thrilled by large stage3 changes. The fallout risk should have been obvious. :( (And after this, there's a regress-84 to sort out. Bah.) brgds, H-P
[PATCH] testsuite: Adjust possibly fragile slp-perm-9.c [PR104015]
Hi,
As discussed in PR104015, the test case slp-perm-9.c can be
fragile when vectorizer tries to use different vectorisation
strategies.
As Richard suggested, this patch tries to make the check not
sensitive on the re-trying times by removing the times checking.
To still retain the test coverage on unnecessary re-trying, for
example this exposed PR104015 on Power9, I added two test cases
to powerpc test bucket.
Tested on x86_64-redhat-linux, aarch64-linux-gnu and
powerpc64-linux-gnu Power8 and powerpc64le-linux-gnu
Power9/Power10.
Is it ok for trunk?
BR,
Kewen
-
gcc/testsuite/ChangeLog:
PR tree-optimization/104015
* gcc.dg/vect/slp-perm-9.c: Adjust.
* gcc.target/powerpc/pr104015-1.c: New test.
* gcc.target/powerpc/pr104015-2.c: New test.
---
gcc/testsuite/gcc.dg/vect/slp-perm-9.c| 4 +--
gcc/testsuite/gcc.target/powerpc/pr104015-1.c | 28 +++
gcc/testsuite/gcc.target/powerpc/pr104015-2.c | 28 +++
3 files changed, 57 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr104015-1.c
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr104015-2.c
diff --git a/gcc/testsuite/gcc.dg/vect/slp-perm-9.c
b/gcc/testsuite/gcc.dg/vect/slp-perm-9.c
index 873eddf223e..154c00af598 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-perm-9.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-perm-9.c
@@ -61,9 +61,7 @@ int main (int argc, const char* argv[])
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
{ vect_perm_short || vect32 } || vect_load_lanes } } } } */
/* We don't try permutes with a group size of 3 for variable-length
vectors. */
-/* { dg-final { scan-tree-dump-times "permutation requires at least three
vectors" 1 "vect" { target { vect_perm_short && { { ! vect_perm3_short } && { !
vect_partial_vectors_usage_1 } } } xfail vect_variable_length } } } */
-/* Try to vectorize the epilogue using partial vectors. */
-/* { dg-final { scan-tree-dump-times "permutation requires at least three
vectors" 2 "vect" { target { vect_perm_short && { { ! vect_perm3_short } &&
vect_partial_vectors_usage_1 } } xfail vect_variable_length } } } */
+/* { dg-final { scan-tree-dump "permutation requires at least three vectors"
"vect" { target { vect_perm_short && { ! vect_perm3_short } } xfail
vect_variable_length } } } */
/* { dg-final { scan-tree-dump-not "permutation requires at least three
vectors" "vect" { target vect_perm3_short } } } */
/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" {
target { { ! { vect_perm3_short || vect32 } } || vect_load_lanes } } } } */
/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" {
target { { vect_perm3_short || vect32 } && { ! vect_load_lanes } } } } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr104015-1.c
b/gcc/testsuite/gcc.target/powerpc/pr104015-1.c
new file mode 100644
index 000..895c243aaf8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr104015-1.c
@@ -0,0 +1,28 @@
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2 -ftree-vectorize
-fno-vect-cost-model -fdump-tree-vect-details" } */
+
+/* As PR104015, we don't expect vectorizer will re-try some vector modes
+ for epilogues on Power9, since Power9 doesn't support partial vector
+ by defaut. */
+
+#include
+#define N 200
+
+void __attribute__((noinline))
+foo (unsigned short *__restrict__ pInput, unsigned short *__restrict__ pOutput)
+{
+ unsigned short i, a, b, c;
+
+ for (i = 0; i < N / 3; i++)
+{
+ a = *pInput++;
+ b = *pInput++;
+ c = *pInput++;
+
+ *pOutput++ = a + b + c + 3;
+ *pOutput++ = a + b + c + 12;
+ *pOutput++ = a + b + c + 1;
+}
+}
+
+/* { dg-final { scan-tree-dump-not "Re-trying epilogue analysis with vector
mode" "vect" } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr104015-2.c
b/gcc/testsuite/gcc.target/powerpc/pr104015-2.c
new file mode 100644
index 000..1b66a64f47c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr104015-2.c
@@ -0,0 +1,28 @@
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-mdejagnu-cpu=power10 -O2 -ftree-vectorize
-fno-vect-cost-model -fdump-tree-vect-details" } */
+
+/* Power10 support partial vector for epilogue by default, it's expected
+ vectorizer would re-try for it once. */
+
+#include
+#define N 200
+
+void __attribute__((noinline))
+foo (unsigned short *__restrict__ pInput, unsigned short *__restrict__ pOutput)
+{
+ unsigned short i, a, b, c;
+
+ for (i = 0; i < N / 3; i++)
+{
+ a = *pInput++;
+ b = *pInput++;
+ c = *pInput++;
+
+ *pOutput++ = a + b + c + 3;
+ *pOutput++ = a + b + c + 12;
+ *pOutput++ = a + b + c + 1;
+}
+}
+
+/* Vector with length instructions lxvl/stxvl are only enabled for 64 bit. */
+/* { dg-final { scan-tree-dump-times "Re-trying epilogue analysis with vector
Re: [PATCH] [i386]Adjust testcase for --target_board='unix{-m64\ -march=cascadelake}'
On Tue, Jan 18, 2022 at 10:57 AM liuhongt via Gcc-patches
wrote:
>
> Change scan-assembler from "\tucomisd" to "\t\[v\]?ucomisd".
It's an obvious "fix", Pushed to trunk.
>
> refer to https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076241.html
>
> gcc/testsuite/ChangeLog:
>
> * g++.target/i386/pr103973-1.C: Change scan-assembler from
> "\tucomisd" to "\t\[v\]?ucomisd".
> * g++.target/i386/pr103973-11.C: Ditto.
> * g++.target/i386/pr103973-13.C: Ditto.
> * g++.target/i386/pr103973-15.C: Ditto.
> * g++.target/i386/pr103973-3.C: Ditto.
> * g++.target/i386/pr103973-5.C: Ditto.
> * g++.target/i386/pr103973-7.C: Ditto.
> * g++.target/i386/pr103973-9.C: Ditto.
> * gcc.target/i386/pr103973-1.c: Ditto.
> * gcc.target/i386/pr103973-11.c: Ditto.
> * gcc.target/i386/pr103973-13.c: Ditto.
> * gcc.target/i386/pr103973-15.c: Ditto.
> * gcc.target/i386/pr103973-3.c: Ditto.
> * gcc.target/i386/pr103973-5.c: Ditto.
> * gcc.target/i386/pr103973-7.c: Ditto.
> * gcc.target/i386/pr103973-9.c: Ditto.
> ---
> gcc/testsuite/g++.target/i386/pr103973-1.C | 4 ++--
> gcc/testsuite/g++.target/i386/pr103973-11.C | 4 ++--
> gcc/testsuite/g++.target/i386/pr103973-13.C | 4 ++--
> gcc/testsuite/g++.target/i386/pr103973-15.C | 4 ++--
> gcc/testsuite/g++.target/i386/pr103973-3.C | 4 ++--
> gcc/testsuite/g++.target/i386/pr103973-5.C | 4 ++--
> gcc/testsuite/g++.target/i386/pr103973-7.C | 4 ++--
> gcc/testsuite/g++.target/i386/pr103973-9.C | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-1.c | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-11.c | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-13.c | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-15.c | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-3.c | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-5.c | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-7.c | 4 ++--
> gcc/testsuite/gcc.target/i386/pr103973-9.c | 4 ++--
> 16 files changed, 32 insertions(+), 32 deletions(-)
>
> diff --git a/gcc/testsuite/g++.target/i386/pr103973-1.C
> b/gcc/testsuite/g++.target/i386/pr103973-1.C
> index 77f8b4ea325..d7e2e89d895 100644
> --- a/gcc/testsuite/g++.target/i386/pr103973-1.C
> +++ b/gcc/testsuite/g++.target/i386/pr103973-1.C
> @@ -1,8 +1,8 @@
> // PR target/103973
> // { dg-do run }
> // { dg-options "-O2 -std=c++20 -save-temps" }
> -// { dg-final { scan-assembler-not "'\tucomisd" { target { ! ia32 } } } }
> -// { dg-final { scan-assembler-times "\tcomisd" 2 { target { ! ia32 } } } }
> +// { dg-final { scan-assembler-not "'\t\[v\]?ucomisd" { target { ! ia32 } }
> } }
> +// { dg-final { scan-assembler-times "\t\[v\]?comisd" 2 { target { ! ia32 }
> } } }
>
> #include
>
> diff --git a/gcc/testsuite/g++.target/i386/pr103973-11.C
> b/gcc/testsuite/g++.target/i386/pr103973-11.C
> index 549c1cc0027..535de21ce86 100644
> --- a/gcc/testsuite/g++.target/i386/pr103973-11.C
> +++ b/gcc/testsuite/g++.target/i386/pr103973-11.C
> @@ -1,8 +1,8 @@
> // PR target/103973
> // { dg-do run }
> // { dg-options "-O2 -save-temps -std=c++20" }
> -// { dg-final { scan-assembler-not "'\tucomiss" { target { ! ia32 } } } }
> -// { dg-final { scan-assembler-times "\tcomiss" 2 { target { ! ia32 } } } }
> +// { dg-final { scan-assembler-not "'\t\[v\]?ucomiss" { target { ! ia32 } }
> } }
> +// { dg-final { scan-assembler-times "\t\[v\]?comiss" 2 { target { ! ia32 }
> } } }
>
> #define double_type float
> #include "pr103973-9.C"
> diff --git a/gcc/testsuite/g++.target/i386/pr103973-13.C
> b/gcc/testsuite/g++.target/i386/pr103973-13.C
> index fdd13b99795..a3d4ac5048a 100644
> --- a/gcc/testsuite/g++.target/i386/pr103973-13.C
> +++ b/gcc/testsuite/g++.target/i386/pr103973-13.C
> @@ -1,8 +1,8 @@
> // PR target/103973
> // { dg-do run }
> // { dg-options "-O2 -ffast-math -std=c++20 -save-temps" }
> -// { dg-final { scan-assembler-not "'\tucomisd" { target { ! ia32 } } } }
> -// { dg-final { scan-assembler-times "\tcomisd" 2 { target { ! ia32 } } } }
> +// { dg-final { scan-assembler-not "'\t\[v\]?ucomisd" { target { ! ia32 } }
> } }
> +// { dg-final { scan-assembler-times "\t\[v\]?comisd" 2 { target { ! ia32 }
> } } }
>
> #include
>
> diff --git a/gcc/testsuite/g++.target/i386/pr103973-15.C
> b/gcc/testsuite/g++.target/i386/pr103973-15.C
> index 1b20b12f934..4143d39edc5 100644
> --- a/gcc/testsuite/g++.target/i386/pr103973-15.C
> +++ b/gcc/testsuite/g++.target/i386/pr103973-15.C
> @@ -1,8 +1,8 @@
> // PR target/103973
> // { dg-do run }
> // { dg-options "-O2 -ffast-math -save-temps -std=c++20" }
> -// { dg-final { scan-assembler-not "'\tucomiss" { target { ! ia32 } } } }
> -// { dg-final { scan-assembler-times "\tcomiss" 2 { target { ! ia32 } } } }
> +// { dg-final { scan-assembler-not "'\t\[v\]?ucomiss" { target { ! ia32 } }
> } }
> +// { dg-final { scan-assembler-times "\t\[v\]?comiss" 2 { target { ! ia32 }
> } } }
>
> #define
[PATCH] [i386]Adjust testcase for --target_board='unix{-m64\ -march=cascadelake}'
Change scan-assembler from "\tucomisd" to "\t\[v\]?ucomisd".
refer to https://gcc.gnu.org/pipermail/gcc-regression/2022-January/076241.html
gcc/testsuite/ChangeLog:
* g++.target/i386/pr103973-1.C: Change scan-assembler from
"\tucomisd" to "\t\[v\]?ucomisd".
* g++.target/i386/pr103973-11.C: Ditto.
* g++.target/i386/pr103973-13.C: Ditto.
* g++.target/i386/pr103973-15.C: Ditto.
* g++.target/i386/pr103973-3.C: Ditto.
* g++.target/i386/pr103973-5.C: Ditto.
* g++.target/i386/pr103973-7.C: Ditto.
* g++.target/i386/pr103973-9.C: Ditto.
* gcc.target/i386/pr103973-1.c: Ditto.
* gcc.target/i386/pr103973-11.c: Ditto.
* gcc.target/i386/pr103973-13.c: Ditto.
* gcc.target/i386/pr103973-15.c: Ditto.
* gcc.target/i386/pr103973-3.c: Ditto.
* gcc.target/i386/pr103973-5.c: Ditto.
* gcc.target/i386/pr103973-7.c: Ditto.
* gcc.target/i386/pr103973-9.c: Ditto.
---
gcc/testsuite/g++.target/i386/pr103973-1.C | 4 ++--
gcc/testsuite/g++.target/i386/pr103973-11.C | 4 ++--
gcc/testsuite/g++.target/i386/pr103973-13.C | 4 ++--
gcc/testsuite/g++.target/i386/pr103973-15.C | 4 ++--
gcc/testsuite/g++.target/i386/pr103973-3.C | 4 ++--
gcc/testsuite/g++.target/i386/pr103973-5.C | 4 ++--
gcc/testsuite/g++.target/i386/pr103973-7.C | 4 ++--
gcc/testsuite/g++.target/i386/pr103973-9.C | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-1.c | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-11.c | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-13.c | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-15.c | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-3.c | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-5.c | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-7.c | 4 ++--
gcc/testsuite/gcc.target/i386/pr103973-9.c | 4 ++--
16 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/gcc/testsuite/g++.target/i386/pr103973-1.C
b/gcc/testsuite/g++.target/i386/pr103973-1.C
index 77f8b4ea325..d7e2e89d895 100644
--- a/gcc/testsuite/g++.target/i386/pr103973-1.C
+++ b/gcc/testsuite/g++.target/i386/pr103973-1.C
@@ -1,8 +1,8 @@
// PR target/103973
// { dg-do run }
// { dg-options "-O2 -std=c++20 -save-temps" }
-// { dg-final { scan-assembler-not "'\tucomisd" { target { ! ia32 } } } }
-// { dg-final { scan-assembler-times "\tcomisd" 2 { target { ! ia32 } } } }
+// { dg-final { scan-assembler-not "'\t\[v\]?ucomisd" { target { ! ia32 } } } }
+// { dg-final { scan-assembler-times "\t\[v\]?comisd" 2 { target { ! ia32 } }
} }
#include
diff --git a/gcc/testsuite/g++.target/i386/pr103973-11.C
b/gcc/testsuite/g++.target/i386/pr103973-11.C
index 549c1cc0027..535de21ce86 100644
--- a/gcc/testsuite/g++.target/i386/pr103973-11.C
+++ b/gcc/testsuite/g++.target/i386/pr103973-11.C
@@ -1,8 +1,8 @@
// PR target/103973
// { dg-do run }
// { dg-options "-O2 -save-temps -std=c++20" }
-// { dg-final { scan-assembler-not "'\tucomiss" { target { ! ia32 } } } }
-// { dg-final { scan-assembler-times "\tcomiss" 2 { target { ! ia32 } } } }
+// { dg-final { scan-assembler-not "'\t\[v\]?ucomiss" { target { ! ia32 } } } }
+// { dg-final { scan-assembler-times "\t\[v\]?comiss" 2 { target { ! ia32 } }
} }
#define double_type float
#include "pr103973-9.C"
diff --git a/gcc/testsuite/g++.target/i386/pr103973-13.C
b/gcc/testsuite/g++.target/i386/pr103973-13.C
index fdd13b99795..a3d4ac5048a 100644
--- a/gcc/testsuite/g++.target/i386/pr103973-13.C
+++ b/gcc/testsuite/g++.target/i386/pr103973-13.C
@@ -1,8 +1,8 @@
// PR target/103973
// { dg-do run }
// { dg-options "-O2 -ffast-math -std=c++20 -save-temps" }
-// { dg-final { scan-assembler-not "'\tucomisd" { target { ! ia32 } } } }
-// { dg-final { scan-assembler-times "\tcomisd" 2 { target { ! ia32 } } } }
+// { dg-final { scan-assembler-not "'\t\[v\]?ucomisd" { target { ! ia32 } } } }
+// { dg-final { scan-assembler-times "\t\[v\]?comisd" 2 { target { ! ia32 } }
} }
#include
diff --git a/gcc/testsuite/g++.target/i386/pr103973-15.C
b/gcc/testsuite/g++.target/i386/pr103973-15.C
index 1b20b12f934..4143d39edc5 100644
--- a/gcc/testsuite/g++.target/i386/pr103973-15.C
+++ b/gcc/testsuite/g++.target/i386/pr103973-15.C
@@ -1,8 +1,8 @@
// PR target/103973
// { dg-do run }
// { dg-options "-O2 -ffast-math -save-temps -std=c++20" }
-// { dg-final { scan-assembler-not "'\tucomiss" { target { ! ia32 } } } }
-// { dg-final { scan-assembler-times "\tcomiss" 2 { target { ! ia32 } } } }
+// { dg-final { scan-assembler-not "'\t\[v\]?ucomiss" { target { ! ia32 } } } }
+// { dg-final { scan-assembler-times "\t\[v\]?comiss" 2 { target { ! ia32 } }
} }
#define double_type float
#include "pr103973-13.C"
diff --git a/gcc/testsuite/g++.target/i386/pr103973-3.C
b/gcc/testsuite/g++.target/i386/pr103973-3.C
index 3d4476cbc17..9ff1c5c527b 100644
--- a/gcc/testsuite/g++.target/i386/pr103973-3.C
+++ b/gcc/testsuite/g++.target/i386/pr103973-3.C
@@ -1,8 +1,8 @@
// PR target/103973
// {
[PATCH, rs6000] Enable absolute jump table for PPC Linux
Hi, This patch enables absolute jump table on PPC Linux. When PIC is set, the absolute jump tables are placed in RELRO section. Otherwise, they're placed in rodata section. Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Is this okay for trunk? Any recommendations? Thanks a lot. ChangeLog 2022-01-18 Haochen Gui gcc/ * config/rs6000/linux64.h (JUMP_TABLES_IN_TEXT_SECTION): Define. (rs6000_linux64_override_options): Define rs6000_relative_jumptables. patch.diff diff --git a/gcc/config/rs6000/linux64.h b/gcc/config/rs6000/linux64.h index d617f346f81..2e257c60f8c 100644 --- a/gcc/config/rs6000/linux64.h +++ b/gcc/config/rs6000/linux64.h @@ -239,7 +239,7 @@ extern int dot_symbols; /* Indicate that jump tables go in the text section. */ #undef JUMP_TABLES_IN_TEXT_SECTION -#define JUMP_TABLES_IN_TEXT_SECTION TARGET_64BIT +#define JUMP_TABLES_IN_TEXT_SECTION 0 /* The linux ppc64 ABI isn't explicit on whether aggregates smaller than a doubleword should be padded upward or downward. You could diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 319182e94d9..7e196e8a43b 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -3576,6 +3576,8 @@ rs6000_linux64_override_options () error (INVALID_32BIT, "cmodel"); } } + + rs6000_relative_jumptables = 0; } #endif
[PATCH] RISC-V: Change default ISA version into 20191213
Bump default ISA spec to newer version 20191213, current default ISA spec
is 2.2, but it's already out of date for a long time, sync with binutils
ISA version, convention in toolchain use.
gcc/ChangeLog:
* config.gcc: Modify default isa_spec version.
---
gcc/config.gcc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index f1b8d832c6f..47dc5a71917 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4641,12 +4641,12 @@ case "${target}" in
esac
case "${with_isa_spec}" in
- ""|default|2.2)
- tm_defines="${tm_defines}
TARGET_DEFAULT_ISA_SPEC=ISA_SPEC_CLASS_2P2"
- ;;
- 20191213 | 201912)
+ ""|default|20191213|201912)
tm_defines="${tm_defines}
TARGET_DEFAULT_ISA_SPEC=ISA_SPEC_CLASS_20191213"
;;
+ 2.2)
+ tm_defines="${tm_defines}
TARGET_DEFAULT_ISA_SPEC=ISA_SPEC_CLASS_2P2"
+ ;;
20190608 | 201906)
tm_defines="${tm_defines}
TARGET_DEFAULT_ISA_SPEC=ISA_SPEC_CLASS_20190608"
;;
--
2.25.1
[PATCH] libgccjit: Add option to hide stderr logs [PR104073]
Hi.
This option will be useful for rustc_codegen_gcc to hide the error
about unsupported 128-bit integer types.
David, if you know of a better way to check if these types are
supported than creating such a type and checking if it causes an error,
I will not need this patch.
Thanks for the reviews!
From 002c6803ac7069bf18eabd6729e31de8e2be6128 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 9 Jan 2022 13:46:35 -0500
Subject: [PATCH] libgccjit: Add option to hide stderr logs [PR104073]
2022-01-17 Antoni Boucher get_debug_string (),
- errmsg);
- else
-fprintf (stderr, "%s: error: %s\n",
- ctxt_progname,
- errmsg);
+ bool hide_log_stderr =
+get_bool_option (GCC_JIT_BOOL_OPTION_HIDE_LOG_STDERR);
+
+ if (!hide_log_stderr)
+ {
+if (loc)
+ fprintf (stderr, "%s: %s: error: %s\n",
+ ctxt_progname,
+ loc->get_debug_string (),
+ errmsg);
+else
+ fprintf (stderr, "%s: error: %s\n",
+ ctxt_progname,
+ errmsg);
+ }
if (!m_error_count)
{
@@ -1682,6 +1688,7 @@ static const char * const
"GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING",
"GCC_JIT_BOOL_OPTION_SELFCHECK_GC",
"GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES"
+ "GCC_JIT_BOOL_OPTION_HIDE_LOG_STDERR"
};
static const char * const
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 2a5ffacb1fe..272b862c164 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -241,6 +241,9 @@ enum gcc_jit_bool_option
their location on stderr. */
GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES,
+ /* If true, gcc_jit_context_release will not print the errors to stderr. */
+ GCC_JIT_BOOL_OPTION_HIDE_LOG_STDERR,
+
GCC_JIT_NUM_BOOL_OPTIONS
};
--
2.26.2.7.g19db9cfb68.dirty
Re: [PATCH] libgccjit: Add support for register variables [PR104072]
I missed the comment about the new define, so here's the updated patch.
Le lundi 17 janvier 2022 à 19:24 -0500, Antoni Boucher via Jit a
écrit :
> Hi.
> This patch add supports for register variables in libgccjit.
>
> It passes the JIT tests, but since I added a function in reginfo.c, I
> wonder if I should run the whole testsuite.
>
> Thanks for the review.
From 2d372a741e9ef29eb377f9edfc6c539d1b2722e5 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 29 Aug 2021 10:54:55 -0400
Subject: [PATCH] libgccjit: Add support for register variables [PR104072]
2022-01-17 Antoni Boucher
gcc/jit/
PR target/104072
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_lvalue_set_register_name.
* dummy-frontend.c: Clear the global_regs cache to avoid an
issue where compiling multiple times the same code gives an
error about assigning the same register to 2 global variables.
* jit-playback.h: New function (set_register_name).
* jit-recording.c: New function (set_register_name) and add
support for register variables.
* jit-recording.h: New field (m_reg_name) and new function
(set_register_name).
* libgccjit.c: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.h: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag.
gcc/
* reginfo.c: New function (clear_global_regs_cache).
* system.h: New function (clear_global_regs_cache).
gcc/testsuite/
* jit.dg/all-non-failing-tests.h: Add new
test-register-variable.
* jit.dg/test-register-variable.c: New test.
---
gcc/jit/docs/topics/compatibility.rst | 9
gcc/jit/docs/topics/expressions.rst | 20 +++
gcc/jit/dummy-frontend.c | 2 +
gcc/jit/jit-playback.h| 9
gcc/jit/jit-recording.c | 18 +--
gcc/jit/jit-recording.h | 9 ++--
gcc/jit/libgccjit.c | 12 +
gcc/jit/libgccjit.h | 12 +
gcc/jit/libgccjit.map | 9
gcc/reginfo.c | 8 +++
gcc/system.h | 2 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 ++
gcc/testsuite/jit.dg/test-register-variable.c | 54 +++
13 files changed, 161 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-register-variable.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 16cebe31a10..cd0ae4838a2 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -302,3 +302,12 @@ thread-local storage model of a variable:
section of a variable:
* :func:`gcc_jit_lvalue_set_link_section`
+
+.. _LIBGCCJIT_ABI_21:
+
+``LIBGCCJIT_ABI_21``
+---
+``LIBGCCJIT_ABI_21`` covers the addition of an API entrypoint to set the
+register name of a variable:
+
+ * :func:`gcc_jit_lvalue_set_register_name`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 791a20398ca..afe333a520f 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -738,6 +738,26 @@ where the rvalue is computed by reading from the storage area.
#ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
+.. function:: void
+ gcc_jit_lvalue_set_register_name (gcc_jit_lvalue *lvalue,
+const char *reg_name);
+
+ Set the register name of a variable.
+ The parameter ``reg_name`` must be non-NULL. Analogous to:
+
+ .. code-block:: c
+
+ register int variable asm ("r12");
+
+ in C.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_21`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_register_name
+
Global variables
diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
index 84ff359bfe3..04d8fc6ab48 100644
--- a/gcc/jit/dummy-frontend.c
+++ b/gcc/jit/dummy-frontend.c
@@ -599,6 +599,8 @@ jit_langhook_init (void)
build_common_builtin_nodes ();
+ clear_global_regs_cache ();
+
/* The default precision for floating point numbers. This is used
for floating point constants with abstract type. This may
eventually be controllable by a command line option. */
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index c93d7055d43..af4427c4503 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see
#include // for std::pair
#include "timevar.h"
+#include "varasm.h"
#include "jit-recording.h"
@@ -701,6 +702,14 @@ public:
set_decl_section_name (as_tree (), name);
}
+ void
+ set_register_name (const char* reg_name)
+ {
+
Re: [PATCH] libgccjit: Add support for bitcasts [PR104071]
I was missing the define, so I added it. Here's the new patch with it. Le lundi 17 janvier 2022 à 17:18 -0500, Antoni Boucher via Jit a écrit : > Hi. > This patch add support for bitcasts in libgccjit. > > It passes the JIT tests, but since I added a function in tree.c, I > wonder if I should run the whole testsuite. > > David, you can now disregard my question in my email about 128-bit > integers regarding my issue with initialize_sizetypes being called > multiple times because this patch fix this issue. > I turns out there was a cache of types that needed to be cleared when > you initialize the JIT. > > The check for sizes is pending, because it requires the updates to > get_size I made in my patch for 128-bit integers. > > Thanks for the review! From 8457f791b08feb0372a76d6a076cc976b59e8e24 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Wed, 9 Jun 2021 18:29:14 -0400 Subject: [PATCH] libgccjit: Add support for bitcasts [PR104071] 2022-01-17 Antoni Boucher gcc/jit/ PR target/104071 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_context_new_bitcast. * dummy-frontend.c: clear the cache of non-standard integer types to avoid having issues with some optimizations of bitcast where the SSA_NAME will have a size of a cached integer type that should have been invalidated, causing a comparison of integer constant to fail. * jit-playback.c: New function (new_bitcast). * jit-playback.h: New function (new_bitcast). * jit-recording.c: New functions (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer). * jit-recording.h: New calss (bitcast) and new function (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer, bitcast::get_precedence). * libgccjit.c: New function (gcc_jit_context_new_bitcast) * libgccjit.h: New function (gcc_jit_context_new_bitcast) * libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag. gcc/testsuite/ PR target/104071 * jit.dg/all-non-failing-tests.h: Add new test-bitcast. * jit.dg/test-bitcast.c: New test. gcc/ PR target/104071 * tree.c: New function (clear_nonstandard_integer_type_cache). * tree.h: New function (clear_nonstandard_integer_type_cache). --- gcc/jit/docs/topics/compatibility.rst| 9 +++ gcc/jit/docs/topics/expressions.rst | 17 + gcc/jit/dummy-frontend.c | 2 + gcc/jit/jit-playback.c | 13 gcc/jit/jit-playback.h | 5 ++ gcc/jit/jit-recording.c | 66 gcc/jit/jit-recording.h | 32 ++ gcc/jit/libgccjit.c | 28 + gcc/jit/libgccjit.h | 15 + gcc/jit/libgccjit.map| 6 ++ gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++ gcc/testsuite/jit.dg/test-bitcast.c | 60 ++ gcc/tree.c | 8 +++ gcc/tree.h | 1 + 14 files changed, 272 insertions(+) create mode 100644 gcc/testsuite/jit.dg/test-bitcast.c diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index 16cebe31a10..b5a6b704dda 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -302,3 +302,12 @@ thread-local storage model of a variable: section of a variable: * :func:`gcc_jit_lvalue_set_link_section` + +.. _LIBGCCJIT_ABI_20: + +``LIBGCCJIT_ABI_20`` +--- +``LIBGCCJIT_ABI_20`` covers the addition of an API entrypoint to bitcast a +value from one type to another: + + * :func:`gcc_jit_context_new_bitcast` diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 791a20398ca..1328a53f70f 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -649,6 +649,23 @@ Type-coercion * int <-> bool * P* <-> Q*, for pointer types P and Q +.. function:: gcc_jit_rvalue *\ + gcc_jit_context_new_bitcast (gcc_jit_context *ctxt,\ + gcc_jit_location *loc,\ + gcc_jit_rvalue *rvalue,\ + gcc_jit_type *type) + + Given an rvalue of T, bitcast it to another type. + + The type of rvalue must be the same size as the size of ``type``. + + This entrypoint was added in :ref:`LIBGCCJIT_ABI_20`; you can test for + its presence using + + .. code-block:: c + + #ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast + Lvalues --- diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c index 84ff359bfe3..c3da97642e3 100644 --- a/gcc/jit/dummy-frontend.c +++ b/gcc/jit/dummy-frontend.c @@ -592,6 +592,8 @@ jit_langhook_init (void)
[PATCH] libgccjit: Add support for register variables [PR104072]
Hi.
This patch add supports for register variables in libgccjit.
It passes the JIT tests, but since I added a function in reginfo.c, I
wonder if I should run the whole testsuite.
Thanks for the review.
From 328eca2be438c4a05c21942b4b2c3650ff7de0eb Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Sun, 29 Aug 2021 10:54:55 -0400
Subject: [PATCH] libgccjit: Add support for register variables [PR104072]
2022-01-17 Antoni Boucher
gcc/jit/
PR target/104072
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_lvalue_set_register_name.
* dummy-frontend.c: Clear the global_regs cache to avoid an
issue where compiling multiple times the same code gives an
error about assigning the same register to 2 global variables.
* jit-playback.h: New function (set_register_name).
* jit-recording.c: New function (set_register_name) and add
support for register variables.
* jit-recording.h: New field (m_reg_name) and new function
(set_register_name).
* libgccjit.c: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.h: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag.
gcc/
* reginfo.c: New function (clear_global_regs_cache).
* system.h: New function (clear_global_regs_cache).
gcc/testsuite/
* jit.dg/all-non-failing-tests.h: Add new
test-register-variable.
* jit.dg/test-register-variable.c: New test.
---
gcc/jit/docs/topics/compatibility.rst | 9
gcc/jit/docs/topics/expressions.rst | 20 +++
gcc/jit/dummy-frontend.c | 2 +
gcc/jit/jit-playback.h| 9
gcc/jit/jit-recording.c | 18 +--
gcc/jit/jit-recording.h | 9 ++--
gcc/jit/libgccjit.c | 12 +
gcc/jit/libgccjit.h | 7 +++
gcc/jit/libgccjit.map | 9
gcc/reginfo.c | 8 +++
gcc/system.h | 2 +
gcc/testsuite/jit.dg/all-non-failing-tests.h | 3 ++
gcc/testsuite/jit.dg/test-register-variable.c | 54 +++
13 files changed, 156 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-register-variable.c
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 16cebe31a10..cd0ae4838a2 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -302,3 +302,12 @@ thread-local storage model of a variable:
section of a variable:
* :func:`gcc_jit_lvalue_set_link_section`
+
+.. _LIBGCCJIT_ABI_21:
+
+``LIBGCCJIT_ABI_21``
+---
+``LIBGCCJIT_ABI_21`` covers the addition of an API entrypoint to set the
+register name of a variable:
+
+ * :func:`gcc_jit_lvalue_set_register_name`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 791a20398ca..afe333a520f 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -738,6 +738,26 @@ where the rvalue is computed by reading from the storage area.
#ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
+.. function:: void
+ gcc_jit_lvalue_set_register_name (gcc_jit_lvalue *lvalue,
+const char *reg_name);
+
+ Set the register name of a variable.
+ The parameter ``reg_name`` must be non-NULL. Analogous to:
+
+ .. code-block:: c
+
+ register int variable asm ("r12");
+
+ in C.
+
+ This entrypoint was added in :ref:`LIBGCCJIT_ABI_21`; you can test for
+ its presence using
+
+ .. code-block:: c
+
+ #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_register_name
+
Global variables
diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
index 84ff359bfe3..04d8fc6ab48 100644
--- a/gcc/jit/dummy-frontend.c
+++ b/gcc/jit/dummy-frontend.c
@@ -599,6 +599,8 @@ jit_langhook_init (void)
build_common_builtin_nodes ();
+ clear_global_regs_cache ();
+
/* The default precision for floating point numbers. This is used
for floating point constants with abstract type. This may
eventually be controllable by a command line option. */
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index c93d7055d43..af4427c4503 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3. If not see
#include // for std::pair
#include "timevar.h"
+#include "varasm.h"
#include "jit-recording.h"
@@ -701,6 +702,14 @@ public:
set_decl_section_name (as_tree (), name);
}
+ void
+ set_register_name (const char* reg_name)
+ {
+set_user_assembler_name (as_tree (), reg_name);
+DECL_REGISTER (as_tree ()) = 1;
+DECL_HARD_REGISTER (as_tree ()) = 1;
+ }
+
private:
bool mark_addressable (location
Re: [PATCH] c++: error message for dependent template members [PR70417]
On Sat, Jan 15, 2022 at 3:28 AM Anthony Sharp
wrote:
> Hi Jason,
>
> Hope you are well. Apologies, I've not had time to sit down and look at
> this since last month I quit my old job, then I had family around for the
> whole of the Christmas period, and then even more recently I've had to
> start my new job.
>
> In any case happy that you managed to figure it all out. I noticed the
> small regression at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025.
> To be honest I wouldn't even know how to begin to go about fixing that so
> perhaps it's best if I leave that to you? I guess it's not playing well
> with the use of warn_missing_template_keyword. Maybe I didn't set that
> variable up properly or something.
>
FYI it seems to be a latent bug that cp_rollback_tokens doesn't also roll
back input_location, not a bug in the new code.
> Kind regards,
> Anthony
>
> On Thu, 13 Jan 2022 at 21:01, Jason Merrill wrote:
>
>> On 12/9/21 10:51, Jason Merrill wrote:
>> > On 12/4/21 12:23, Anthony Sharp wrote:
>> >> Hi Jason,
>> >>
>> >> Hope you are well. Apologies for not coming back sooner.
>> >>
>> >> >I'd put it just above the definition of saved_token_sentinel in
>> >> parser.c.
>> >>
>> >> Sounds good, done.
>> >>
>> >> >Maybe cp_parser_require_end_of_template_parameter_list? Either way
>> >> is fine.
>> >>
>> >> Even better, have changed it.
>> >>
>> >> >Hmm, good point; operators that are member functions must be
>> >> non-static,
>> >> >so we couldn't be doing a comparison of the address of the function.
>> >>
>> >> In that case I have set it to return early there.
>> >>
>> >> >So declarator_p should be true there. I'll fix that.
>> >>
>> >> Thank you.
>> >>
>> >> >> + if (next_token->keyword == RID_TEMPLATE)
>> >> >> +{
>> >> >> + /* But at least make sure it's properly formed (e.g. see
>> >> PR19397). */
>> >> >> + if (cp_lexer_peek_nth_token (parser->lexer, 2)->type ==
>> >> CPP_NAME)
>> >> >> + return 1;
>> >> >> +
>> >> >> + return -1;
>> >> >> +}
>> >> >> +
>> >> >> + /* Could be a ~ referencing the destructor of a class template.
>> >> */
>> >> >> + if (next_token->type == CPP_COMPL)
>> >> >> +{
>> >> >> + /* It could only be a template. */
>> >> >> + if (cp_lexer_peek_nth_token (parser->lexer, 2)->type ==
>> >> CPP_NAME)
>> >> >> + return 1;
>> >> >> +
>> >> >> + return -1;
>> >> >> +}
>> >> >
>> >> >Why don't these check for the < ?
>> >>
>> >> I think perhaps I could have named the function better; instead of
>> >> next_token_begins_template_id, how's about
>> >> next_token_begins_template_name?
>> >> That's all I intended to check for.
>> >
>> > You're using it to control whether we try to parse a template-id, and
>> > it's used to initialize variables named looks_like_template_id, so I
>> > think better to keep the old name.
>> >
>> >> In the first case, something like "->template some_name" will always be
>> >> intended as a template, so no need to check for the <. If there were
>> >> default
>> >> template arguments you could also validly omit the <> completely, I
>> think
>> >> (could be wrong).
>> >
>> > Or if the template arguments can be deduced, yes:
>> >
>> > template struct A
>> > {
>> >template void f(U u);
>> > };
>> >
>> > template void g(A a)
>> > {
>> >a->template f(42);
>> > }
>> >
>> > But 'f' is still not a template-id.
>> >
>> > ...
>> >
>> > Actually, it occurs to me that you might be better off handling this in
>> > cp_parser_template_name, something like the below, to avoid the complex
>> > duplicate logic in the id-expression handling.
>> >
>> > Note that in this patch I'm using "any_object_scope" as a proxy for
>> "I'm
>> > parsing an expression", since !is_declaration doesn't work for that; as
>> > a result, this doesn't handle the static member function template case.
>> > For that you'd probably still need to pass down a flag so that
>> > cp_parser_template_name knows it's being called from
>> > cp_parser_id_expression.
>> >
>> > Your patch has a false positive on
>> >
>> > template struct A { };
>> > template void f()
>> > {
>> >A();
>> > };
>> >
>> > which my patch checks in_template_argument_list_p to avoid, though
>> > checking any_object_scope also currently avoids it.
>> >
>> > What do you think?
>>
>> I decided that it made more sense to keep the check in
>> cp_parser_id_expression like you had it, but I moved it to the end to
>> simplify the logic. Here's what I'm applying, thanks!
>
>
Re: [PATCH] PR fortran/103692 - [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062
Hi Harald, after lengthy debugging of this PR it became obvious that we killed the typespec while trying to expand an empty array constructor. Bad idea, but easy to fix. Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch? OK. Thanks for the patch! Best regards Thomas
[PATCH] libgccjit: Add support for bitcasts [PR104071]
Hi. This patch add support for bitcasts in libgccjit. It passes the JIT tests, but since I added a function in tree.c, I wonder if I should run the whole testsuite. David, you can now disregard my question in my email about 128-bit integers regarding my issue with initialize_sizetypes being called multiple times because this patch fix this issue. I turns out there was a cache of types that needed to be cleared when you initialize the JIT. The check for sizes is pending, because it requires the updates to get_size I made in my patch for 128-bit integers. Thanks for the review! From 35e113b51c416af0c13bc7eb160ff6c0cbcff813 Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Wed, 9 Jun 2021 18:29:14 -0400 Subject: [PATCH] libgccjit: Add support for bitcasts [PR104071] 2022-01-17 Antoni Boucher gcc/jit/ PR target/104071 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI tag. * docs/topics/expressions.rst: Add documentation for the function gcc_jit_context_new_bitcast. * dummy-frontend.c: clear the cache of non-standard integer types to avoid having issues with some optimizations of bitcast where the SSA_NAME will have a size of a cached integer type that should have been invalidated, causing a comparison of integer constant to fail. * jit-playback.c: New function (new_bitcast). * jit-playback.h: New function (new_bitcast). * jit-recording.c: New functions (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer). * jit-recording.h: New calss (bitcast) and new function (new_bitcast, bitcast::replay_into, bitcast::visit_children, bitcast::make_debug_string, bitcast::write_reproducer, bitcast::get_precedence). * libgccjit.c: New function (gcc_jit_context_new_bitcast) * libgccjit.h: New function (gcc_jit_context_new_bitcast) * libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag. gcc/testsuite/ PR target/104071 * jit.dg/all-non-failing-tests.h: Add new test-bitcast. * jit.dg/test-bitcast.c: New test. gcc/ PR target/104071 * tree.c: New function (clear_nonstandard_integer_type_cache). * tree.h: New function (clear_nonstandard_integer_type_cache). --- gcc/jit/docs/topics/compatibility.rst| 9 +++ gcc/jit/docs/topics/expressions.rst | 10 +++ gcc/jit/dummy-frontend.c | 2 + gcc/jit/jit-playback.c | 13 gcc/jit/jit-playback.h | 5 ++ gcc/jit/jit-recording.c | 66 gcc/jit/jit-recording.h | 32 ++ gcc/jit/libgccjit.c | 28 + gcc/jit/libgccjit.h | 9 +++ gcc/jit/libgccjit.map| 6 ++ gcc/testsuite/jit.dg/all-non-failing-tests.h | 10 +++ gcc/testsuite/jit.dg/test-bitcast.c | 60 ++ gcc/tree.c | 8 +++ gcc/tree.h | 1 + 14 files changed, 259 insertions(+) create mode 100644 gcc/testsuite/jit.dg/test-bitcast.c diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index 16cebe31a10..b5a6b704dda 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -302,3 +302,12 @@ thread-local storage model of a variable: section of a variable: * :func:`gcc_jit_lvalue_set_link_section` + +.. _LIBGCCJIT_ABI_20: + +``LIBGCCJIT_ABI_20`` +--- +``LIBGCCJIT_ABI_20`` covers the addition of an API entrypoint to bitcast a +value from one type to another: + + * :func:`gcc_jit_context_new_bitcast` diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 791a20398ca..6e0b5db777b 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -649,6 +649,16 @@ Type-coercion * int <-> bool * P* <-> Q*, for pointer types P and Q +.. function:: gcc_jit_rvalue *\ + gcc_jit_context_new_bitcast (gcc_jit_context *ctxt,\ + gcc_jit_location *loc,\ + gcc_jit_rvalue *rvalue,\ + gcc_jit_type *type) + + Given an rvalue of T, bitcast it to another type. + + The type of rvalue must be the same size as the size of ``type``. + Lvalues --- diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c index 84ff359bfe3..c3da97642e3 100644 --- a/gcc/jit/dummy-frontend.c +++ b/gcc/jit/dummy-frontend.c @@ -592,6 +592,8 @@ jit_langhook_init (void) global_dc->begin_diagnostic = jit_begin_diagnostic; global_dc->end_diagnostic = jit_end_diagnostic; + clear_nonstandard_integer_type_cache (); + build_common_tree_nodes (false); /* I don't know why this has to be done explicitly. */ diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c index 1d64caf4e20..4ad2f6ce41d 100644 ---
[PATCH] PR fortran/103692 - [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062
Dear Fortranners,
after lengthy debugging of this PR it became obvious that we killed
the typespec while trying to expand an empty array constructor.
Bad idea, but easy to fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch?
Thanks,
Harald
From b9be44b422063c6c1f7a4bb50245ba4051e76136 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 17 Jan 2022 22:52:08 +0100
Subject: [PATCH] Fortran: handle expansion of zero-sized array constructors
gcc/fortran/ChangeLog:
PR fortran/103692
* array.c (gfc_expand_constructor): Handle zero-sized array
constructors.
gcc/testsuite/ChangeLog:
PR fortran/103692
* gfortran.dg/pr102520.f90: Adjust error messages.
* gfortran.dg/pr103692.f90: New test.
---
gcc/fortran/array.c| 3 +++
gcc/testsuite/gfortran.dg/pr102520.f90 | 6 ++
gcc/testsuite/gfortran.dg/pr103692.f90 | 23 +++
3 files changed, 28 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr103692.f90
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 472304326e8..f1d92e00c98 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -1883,6 +1883,9 @@ gfc_expand_constructor (gfc_expr *e, bool fatal)
gfc_expr *f;
bool rc;
+ if (gfc_is_size_zero_array (e))
+return true;
+
/* If we can successfully get an array element at the max array size then
the array is too big to expand, so we just return. */
f = gfc_get_array_element (e, flag_max_array_constructor);
diff --git a/gcc/testsuite/gfortran.dg/pr102520.f90 b/gcc/testsuite/gfortran.dg/pr102520.f90
index 1c98c185c17..d2ea8f3a424 100644
--- a/gcc/testsuite/gfortran.dg/pr102520.f90
+++ b/gcc/testsuite/gfortran.dg/pr102520.f90
@@ -5,8 +5,6 @@ program p
type t
end type
type(t), parameter :: a(4) = shape(1) ! { dg-error "Incompatible" }
- type(t), parameter :: b(2,2) = reshape(a,[2,2]) ! { dg-error "Incompatible" }
- type(t), parameter :: c(2,2) = transpose(b) ! { dg-error "Unclassifiable" }
+ type(t), parameter :: b(2,2) = reshape(a,[2,2]) ! { dg-error "must be an array" }
+ type(t), parameter :: c(2,2) = transpose(b) ! { dg-error "must be of rank 2" }
end
-
-! { dg-error "Different shape for array assignment" " " { target *-*-* } 7 }
diff --git a/gcc/testsuite/gfortran.dg/pr103692.f90 b/gcc/testsuite/gfortran.dg/pr103692.f90
new file mode 100644
index 000..9687a3cec9d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103692.f90
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+! PR fortran/103692 - ICE in expand_constructor
+! Contributed by G.Steinmetz
+
+program p
+ character(3), parameter :: a(4) = 'abc'
+ character(*), parameter :: b(*) = (a(2:1))
+ character(*), parameter :: y(*) = [(a(2:1))]
+ character(*), parameter :: u(*) = a(2:1)
+ character(*), parameter :: v(*) = [a(2:1)]
+ character(*), parameter :: w(-1) = (a(2:1))
+ character(*), parameter :: x(-1) = a(2:1)
+ character(5), parameter :: c(3,3) = 'def'
+ character(*), parameter :: d(*) = [(c(2:1,2:))]
+ character(*), parameter :: e(*,*) = (c(2:1,2:))
+ if (len(b) /= 3 .or. size (b) /= 0) stop 1
+ if (len(y) /= 3 .or. size (y) /= 0) stop 2
+ if (len(d) /= 5 .or. size (d) /= 0) stop 3
+ if (len(e) /= 5 .or. any (shape (e) /= [0,2])) stop 4
+end
+
+! { dg-final { scan-tree-dump-not "_gfortran_stop_numeric" "original" } }
--
2.31.1
Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
On 1/13/22 12:01, Martin Liška wrote: Hello. Based on the discussion with release managers, the change is going to happen after stage4 begins. Martin Hi. The renaming patches have been just installed and I've built a few target compilers so far. I'll be online in ~10 hours from now so I can address potential issues caused by the patch. One note: I would recommend using: git config log.follow true That causes git log following changes of a file before it was renamed so that one can get a complete history. Cheers, Martin
Re: [PATCH] git-backport: support renamed .cc files in commit message.
On 1/12/22 16:54, Martin Liška wrote: There's a patch that enhances git-backport so that it updates commit messages for files which name ends now with .cc and is still .c on a branch. The patch has been installed as I've made the renaming now. Cheers, Martin
Re: [PATCH 6/6] libstdc++: Import MSVC floating-point std::from_chars testcases
On Mon, Jan 17, 2022 at 5:54 AM Jonathan Wakely wrote: > > > > On Sun, 16 Jan 2022 at 18:17, Patrick Palka via Libstdc++ > wrote: >> >> libstdc++-v3/ChangeLog: >> >> * testsuite/20_util/from_chars/double.cc: New test, consisting >> of testcases extracted from the MSVC STL testsuite. >> * testsuite/20_util/from_chars/float.cc: New test. >> --- >> .../testsuite/20_util/from_chars/double.cc| 1674 + >> .../testsuite/20_util/from_chars/float.cc | 290 +++ >> 2 files changed, 1964 insertions(+) >> create mode 100644 libstdc++-v3/testsuite/20_util/from_chars/double.cc >> create mode 100644 libstdc++-v3/testsuite/20_util/from_chars/float.cc >> >> diff --git a/libstdc++-v3/testsuite/20_util/from_chars/double.cc >> b/libstdc++-v3/testsuite/20_util/from_chars/double.cc >> new file mode 100644 >> index 000..ce53a1c56c2 >> --- /dev/null >> +++ b/libstdc++-v3/testsuite/20_util/from_chars/double.cc >> @@ -0,0 +1,1674 @@ >> +// This file consists of testcases extracted from the MSVC STL testsuite. >> + >> +// Copyright (c) Microsoft Corporation. >> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception > > > I think we should probably move (or copy) the > libstdc++-v3/include/pstl/LICENSE.txt file to another directory, since we > have files using this licence in other places too. > > Please hold off committing this one while I think about that (and remind me > if you don't hear back from me with a decision). Will do. I committed the rest of the series, thanks a lot!
Re: [PATCH] rs6000: Fix cpu selection w/ isel (PR100108)
Hi! On Mon, Jan 17, 2022 at 09:06:25PM +0100, Sebastian Huber wrote: > On 11/01/2022 09:10, Sebastian Huber wrote: > >On 20/04/2021 17:00, Segher Boessenkool wrote: > >>There are various non-IBM CPUs with isel as well, so it is easiest if we > >>just don't consider that flag here (it is not needed). > >> > >>2021-04-20 Segher Boessenkool > >> > >>PR target/100108 > >>* config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not > >>consider > >>OPTION_MASK_ISEL. > >>--- > >>Committed to trunk and 11. Will do 10 in a week or so. > > > >sorry for the late response, however, I noticed a GCC build issue with > >this patch: [ big snip ] > >/tmp/ccZJ18fW.s: Assembler messages: > >/tmp/ccZJ18fW.s:24: Error: unrecognized opcode: `isel' > >make: *** [Makefile:501: _negvdi2.o] Error 1 > > > >The assembler is called like this: > > > >/tmp/sh/b-gcc-powerpc-rtems6/./gcc/as -I > >/home/EB/sebastian_h/src/gcc/libgcc/../newlib/libc/sys/rtems/include -I > >. -I . -I ../../../.././gcc -I /home/EB/sebastian_h/src/gcc/libgcc -I > >/home/EB/sebastian_h/src/gcc/libgcc/. -I > >/home/EB/sebastian_h/src/gcc/libgcc/../gcc -I > >/home/EB/sebastian_h/src/gcc/libgcc/../include -a32 -me500 -mbig -o > >_negvdi2.o _negvdi2.s > > > >Using -me500 seems to be all right, however, the file contains a machine > >directive: > > > > .file "libgcc2.c" > > .machine ppc > > .section ".text" > > > >If I remove the ".machine ppc" by hand, the file can be assembled with > >the above command line. > > > >The affect of the patch is: > > > >diff -u _negvdi2.s.before _negvdi2.s.after > >--- _negvdi2.s.before 2022-01-11 09:07:43.313828636 +0100 > >+++ _negvdi2.s.after 2022-01-11 08:54:08.424946502 +0100 > >@@ -1,5 +1,5 @@ > > .file "libgcc2.c" > >- .machine power9 > >+ .machine ppc Which is "correct". rs6000_machine_from_flags should be updated to know about these CPUs: if you have a -mcpu= that outputs instructions that are not .machine ppc (or ppc64), the compiler should emit some appropriate .machine instead. > I can try to fix this, however, for me it is not really clear in which > direction this should be fixed. I can build the GCC 10.3.0 release (it > uses .machine power9). The GCC 10 branch is broken (it uses .machine > ppc). Using the .machine directive and a command line option (-me500) > seems to be a bit inconsistent. It should be one or the other. Exactly. > Would a patch which changes .machine ppc to .machine e500 for -mcpu=8540 > be the right way to fix this issue? Yes :-) Do you have the info needed to make a patch like this for all FSL CPUs? Segher
Re: [PATCH] rs6000: Fix cpu selection w/ isel (PR100108)
On 11/01/2022 09:10, Sebastian Huber wrote: Hello Segher, On 20/04/2021 17:00, Segher Boessenkool wrote: There are various non-IBM CPUs with isel as well, so it is easiest if we just don't consider that flag here (it is not needed). 2021-04-20 Segher Boessenkool PR target/100108 * config/rs6000/rs6000.c (rs6000_machine_from_flags): Do not consider OPTION_MASK_ISEL. --- Committed to trunk and 11. Will do 10 in a week or so. sorry for the late response, however, I noticed a GCC build issue with this patch: /tmp/sh/b-gcc-powerpc-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-powerpc-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-powerpc-rtems6/powerpc-rtems6/m8540/nof/newlib/ -isystem /tmp/sh/b-gcc-powerpc-rtems6/powerpc-rtems6/m8540/nof/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-powerpc-rtems6/powerpc-rtems6/bin/ -B/tmp/sh/i-powerpc-rtems6/powerpc-rtems6/lib/ -isystem /tmp/sh/i-powerpc-rtems6/powerpc-rtems6/include -isystem /tmp/sh/i-powerpc-rtems6/powerpc-rtems6/sys-include -mcpu=8540 -msoft-float -g -O2 -O2 -I/home/EB/sebastian_h/src/gcc/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../../.././gcc -I/home/EB/sebastian_h/src/gcc/libgcc -I/home/EB/sebastian_h/src/gcc/libgcc/. -I/home/EB/sebastian_h/src/gcc/libgcc/../gcc -I/home/EB/sebastian_h/src/gcc/libgcc/../include -DHAVE_CC_TLS -o _negvdi2.o -MT _negvdi2.o -MD -MP -MF _negvdi2.dep -DL_negvdi2 -c /home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /tmp/ccZJ18fW.s: Assembler messages: /tmp/ccZJ18fW.s:24: Error: unrecognized opcode: `isel' make: *** [Makefile:501: _negvdi2.o] Error 1 The assembler is called like this: /tmp/sh/b-gcc-powerpc-rtems6/./gcc/as -I /home/EB/sebastian_h/src/gcc/libgcc/../newlib/libc/sys/rtems/include -I . -I . -I ../../../.././gcc -I /home/EB/sebastian_h/src/gcc/libgcc -I /home/EB/sebastian_h/src/gcc/libgcc/. -I /home/EB/sebastian_h/src/gcc/libgcc/../gcc -I /home/EB/sebastian_h/src/gcc/libgcc/../include -a32 -me500 -mbig -o _negvdi2.o _negvdi2.s Using -me500 seems to be all right, however, the file contains a machine directive: .file "libgcc2.c" .machine ppc .section ".text" If I remove the ".machine ppc" by hand, the file can be assembled with the above command line. The affect of the patch is: diff -u _negvdi2.s.before _negvdi2.s.after --- _negvdi2.s.before 2022-01-11 09:07:43.313828636 +0100 +++ _negvdi2.s.after 2022-01-11 08:54:08.424946502 +0100 @@ -1,5 +1,5 @@ .file "libgcc2.c" - .machine power9 + .machine ppc .section ".text" .Ltext0: .align 2 I can try to fix this, however, for me it is not really clear in which direction this should be fixed. I can build the GCC 10.3.0 release (it uses .machine power9). The GCC 10 branch is broken (it uses .machine ppc). Using the .machine directive and a command line option (-me500) seems to be a bit inconsistent. It should be one or the other. Would a patch which changes .machine ppc to .machine e500 for -mcpu=8540 be the right way to fix this issue? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH 4/6] libstdc++: Adjust fast_float's over/underflow behavior for conformnace
On Mon, Jan 17, 2022 at 5:49 AM Jonathan Wakely wrote:
>
>
>
> On Sun, 16 Jan 2022 at 18:12, Patrick Palka via Libstdc++
> wrote:
>>
>> This makes fast_float handle the situation where std::from_chars is
>> specified to return result_out_of_range, i.e. when the parsed value
>> is outside the representable range of the floating-point type.
>>
>> This adjusts fast_float's behavior in case of over/underflow: instead of
>> returning errc{} and setting value to +-0 or +-infinity, return
>> result_out_of_range and don't modify value, as per [charconv.from.chars]/1.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * src/c++17/fast_float/LOCAL_PATCHES: Update.
>> * src/c++17/fast_float/fast_float.h (from_chars_advanced): In
>> case of over/underflow, return errc::result_out_of_range and don't
>> modify 'value'.
>>
>
> Typo in the commit summary line "conformnace".
>
> OK for trunk.
>
> Please report this as an issue to the upstream project, if you didn't already
> (and if they haven't documented this as an intentional deviation from the
> standard).
This behavior difference isn't documented AFAICT, so I reported the
issue upstream at https://github.com/fastfloat/fast_float/issues/120
[PATCH] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer
* `-Werror` can cause issues when a more recent version of GCC compiles
an older version:
- https://bugs.gentoo.org/229059
- https://bugs.gentoo.org/475350
- https://bugs.gentoo.org/667104
---
libatomic/configure.ac| 6 --
libbacktrace/configure.ac | 7 ---
libgomp/configure.ac | 6 --
libitm/configure.ac | 6 --
libsanitizer/configure.ac | 9 +
libsanitizer/libbacktrace/Makefile.am | 2 --
6 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/libatomic/configure.ac b/libatomic/configure.ac
index f350b9b3509..5a9f69bb74d 100644
--- a/libatomic/configure.ac
+++ b/libatomic/configure.ac
@@ -251,10 +251,12 @@ LIBAT_ENABLE_SYMVERS
CFLAGS="$save_CFLAGS"
AC_CACHE_SAVE
+AC_ARG_ENABLE([werror], [
+ AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
# Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
# Add CET specific flags if CET is enabled
GCC_CET_FLAGS(CET_FLAGS)
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 0dfd82bc03e..a2858e6ecde 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -145,10 +145,11 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings
-Wstrict-prototypes \
-Wmissing-format-attribute -Wcast-qual],
[WARN_FLAGS])
-if test -n "${with_target_subdir}"; then
+AC_ARG_ENABLE([werror], [
+ AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
+AS_IF([test "x$enable_werror" != "xno" && test -n "${with_target_subdir}"], [
WARN_FLAGS="$WARN_FLAGS -Werror"
-fi
-
+])
AC_SUBST(WARN_FLAGS)
if test -n "${with_target_subdir}"; then
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index bfb613b91f0..c3062dc5a07 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -121,10 +121,12 @@ AC_SUBST(CFLAGS)
# in both places for now and restore CFLAGS at the end of config.
save_CFLAGS="$CFLAGS"
+AC_ARG_ENABLE([werror], [
+ AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
# Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
# Find other programs we need.
AC_CHECK_TOOL(AR, ar)
diff --git a/libitm/configure.ac b/libitm/configure.ac
index ac81b146845..ad99d14098e 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -261,10 +261,12 @@ GCC_CHECK_ELF_STYLE_WEAKREF
CFLAGS="$save_CFLAGS"
AC_CACHE_SAVE
+AC_ARG_ENABLE([werror], [
+ AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
# Add -Wall -Werror if we are using GCC.
-if test "x$GCC" = "xyes"; then
+AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
XCFLAGS="$XCFLAGS -Wall -Werror"
-fi
+])
XCFLAGS="$XCFLAGS $XPCFLAGS"
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index 13cd302030d..64eb42afc83 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -400,6 +400,15 @@ fi
AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
+AC_ARG_ENABLE([werror], [
+ AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
+
+WARN_FLAGS="-W -Wall -Wwrite-strings -Wmissing-format-attribute -Wcast-qual"
+AS_IF([test "x$enable_werror" != "xno"], [
+ WARN_FLAGS="$WARN_FLAGS -Werror"
+])
+AC_SUBST([WARN_FLAGS])
+
# Determine what GCC version number to use in filesystem paths.
GCC_BASE_VER
diff --git a/libsanitizer/libbacktrace/Makefile.am
b/libsanitizer/libbacktrace/Makefile.am
index 16accd468df..0cf8d2104c0 100644
--- a/libsanitizer/libbacktrace/Makefile.am
+++ b/libsanitizer/libbacktrace/Makefile.am
@@ -34,8 +34,6 @@ ACLOCAL_AMFLAGS = -I ../.. -I ../../config
AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \
-I ../../libgcc -I .. -I $(top_srcdir) -I $(top_srcdir)/../libbacktrace
-WARN_FLAGS = -W -Wall -Wwrite-strings -Wmissing-format-attribute \
--Wcast-qual -Werror
C_WARN_FLAGS = $(WARN_FLAGS) -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition
CXX_WARN_FLAGS = $(WARN_FLAGS) -Wno-unused-parameter
AM_CFLAGS = $(C_WARN_FLAGS)
--
2.34.1
[PATCH] tree-optimization/104038 - Limit the number of relations registered per basic block.
As mentioned in the PR, this demonstrates the potentially quadratic
performance behaviour of adding transitive relations over a series of
cascading calculations.
As the lookup in a basic block is also linear in nature, I think for
this release it makes sense to simply limit the number of relations we
can register in any given block.
I compiled all the c++ files in gcc, and there was only one BB in
fold-const that had more than 30 relations.. and it was a smaller case
of this sort of transitive behaviour.. and it capped out at 120 relations.
I added a new --param, and defaulted it to 200. It has a range of
0-, choosing 0 would in effect turn off relations.. which is also
handy. Caveat: this flag does not affect equivalences since they are
processed in a completely different way.
I ran the testcase with the max and it finished fine.
I couldn't create a simple/smallish testcase to run, so I didn't
include one.
Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?
Andrew
commit 33149a818e8ef25691a159b6f7903c982b22b541
Author: Andrew MacLeod
Date: Mon Jan 17 12:03:18 2022 -0500
Limit the number of relations registered per basic block.
In pathological cases, the number of transitive relations being added is
potentially quadratic. Lookups for relations in a block is linear in
nature, so simply limit the number of relations to some reasonable number.
PR tree-optimization/104038
* doc/invoke.texi (relation-block-limit): New.
* params.opt (relation-block-limit): New.
* value-relation.cc (dom_oracle::register_relation): Check for NULL
record before invoking transitive registery.
(dom_oracle::set_one_relation): Check limit before creating record.
(dom_oracle::register_transitives): Stop when no record created.
* value-relation.h (relation_chain_head::m_num_relations): New.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7f2205e4a85..106f535dc51 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15088,6 +15088,9 @@ per supernode, before terminating analysis.
Maximum depth of logical expression evaluation ranger will look through
when evaluating outgoing edge ranges.
+@item relation-block-limit
+Maximum number of relations the oracle will register in a basic block.
+
@item openacc-kernels
Specify mode of OpenACC `kernels' constructs handling.
With @option{--param=openacc-kernels=decompose}, OpenACC `kernels'
diff --git a/gcc/params.opt b/gcc/params.opt
index 665071fbed1..b07663daa05 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -915,6 +915,10 @@ Common Joined UInteger Var(param_ranger_logical_depth) Init(6) IntegerRange(1, 9
Maximum depth of logical expression evaluation ranger will look through when
evaluating outgoing edge ranges.
+-param=relation-block-limit=
+Common Joined UInteger Var(param_relation_block_limit) Init(200) IntegerRange(0, ) Param Optimization
+Maximum number of relations the oracle will register in a basic block.
+
-param=rpo-vn-max-loop-depth=
Common Joined UInteger Var(param_rpo_vn_max_loop_depth) Init(7) IntegerRange(2, 65536) Param Optimization
Maximum depth of a loop nest to fully value-number optimistically.
diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index 1e495bdf94c..32ca693c464 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -889,13 +889,14 @@ dom_oracle::register_relation (basic_block bb, relation_kind k, tree op1,
else
{
relation_chain *ptr = set_one_relation (bb, k, op1, op2);
- register_transitives (bb, *ptr);
+ if (ptr)
+ register_transitives (bb, *ptr);
}
}
// Register relation K between OP! and OP2 in block BB.
// This creates the record and searches for existing records in the dominator
-// tree to merge with.
+// tree to merge with. Return the record, or NULL if no record was created.
relation_chain *
dom_oracle::set_one_relation (basic_block bb, relation_kind k, tree op1,
@@ -940,6 +941,13 @@ dom_oracle::set_one_relation (basic_block bb, relation_kind k, tree op1,
}
else
{
+ if (m_relations[bbi].m_num_relations >= param_relation_block_limit)
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, " Not registered due to bb being full\n");
+ return NULL;
+ }
+ m_relations[bbi].m_num_relations++;
// Check for an existing relation further up the DOM chain.
// By including dominating relations, The first one found in any search
// will be the aggregate of all the previous ones.
@@ -1040,7 +1048,8 @@ dom_oracle::register_transitives (basic_block root_bb,
value_relation nr (relation.kind (), r1, r2);
if (nr.apply_transitive (*ptr))
{
- set_one_relation (root_bb, nr.kind (), nr.op1 (), nr.op2 ());
+ if (!set_one_relation (root_bb, nr.kind (), nr.op1 (), nr.op2 ()))
+ return;
if
Re: [PATCH v3] c++: designated init of char array by string constant [PR55227]
Attached (the cut n paste looks like it removed some whitespace formatting) 0001-c-designated-init-of-char-array-by-string-constant-P.patch Description: Binary data
Re: PING^5 [PATCH v4 0/2] Implement indirect external access
Ping, could a global maintainer take a look at this? On Mon, Jan 03, 2022 at 07:32:25PM -0800, H.J. Lu via Gcc-patches wrote: > On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu wrote: > > > > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu wrote: > > > > > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu wrote: > > > > > > > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu wrote: > > > > > > > > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu wrote: > > > > > > > > > > > > Changes in the v4 patch. > > > > > > > > > > > > 1. Add nodirect_extern_access attribute. > > > > > > > > > > > > Changes in the v3 patch. > > > > > > > > > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been > > > > > > added to > > > > > > GNU binutils 2.38. But the -z indirect-extern-access linker option > > > > > > is > > > > > > only available for Linux/x86. However, the --max-cache-size=SIZE > > > > > > linker > > > > > > option was also addded within a day. --max-cache-size=SIZE is used > > > > > > to > > > > > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > > > > > > > > > Changes in the v2 patch. > > > > > > > > > > > > 1. Rename the option to -fdirect-extern-access. > > > > > > > > > > > > --- > > > > > > On systems with copy relocation: > > > > > > * A copy in executable is created for the definition in a shared > > > > > > library > > > > > > at run-time by ld.so. > > > > > > * The copy is referenced by executable and shared libraries. > > > > > > * Executable can access the copy directly. > > > > > > > > > > > > Issues are: > > > > > > * Overhead of a copy, time and space, may be visible at run-time. > > > > > > * Read-only data in the shared library becomes read-write copy in > > > > > > executable at run-time. > > > > > > * Local access to data with the STV_PROTECTED visibility in the > > > > > > shared > > > > > > library must use GOT. > > > > > > > > > > > > On systems without function descriptor, function pointers vary > > > > > > depending > > > > > > on where and how the functions are defined. > > > > > > * If the function is defined in executable, it can be the address of > > > > > > function body. > > > > > > * If the function, including the function with STV_PROTECTED > > > > > > visibility, > > > > > > is defined in the shared library, it can be the address of the PLT > > > > > > entry > > > > > > in executable or shared library. > > > > > > > > > > > > Issues are: > > > > > > * The address of function body may not be used as its function > > > > > > pointer. > > > > > > * ld.so needs to search loaded shared libraries for the function > > > > > > pointer > > > > > > of the function with STV_PROTECTED visibility. > > > > > > > > > > > > Here is a proposal to remove copy relocation and use canonical > > > > > > function > > > > > > pointer: > > > > > > > > > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > > > > > use GOT. > > > > > > a. Linker may optimize out GOT access if the data is defined in > > > > > > PIE or > > > > > > non-PIE. > > > > > > 2. Read-only data in the shared library remain read-only at run-time > > > > > > 3. Address of global data with the STV_PROTECTED visibility in the > > > > > > shared > > > > > > library is the address of data body. > > > > > > a. Can use IP-relative access. > > > > > > b. May need GOT without IP-relative access. > > > > > > 4. For systems without function descriptor, > > > > > > a. All global function pointers of undefined functions in PIE and > > > > > > non-PIE must use GOT. Linker may optimize out GOT access if the > > > > > > function is defined in PIE or non-PIE. > > > > > > b. Function pointer of functions with the STV_PROTECTED > > > > > > visibility in > > > > > > executable and shared library is the address of function body. > > > > > >i. Can use IP-relative access. > > > > > >ii. May need GOT without IP-relative access. > > > > > >iii. Branches to undefined functions may use PLT. > > > > > > 5. Single global definition marker: > > > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED: > > > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > > > > > > > > > to indicate the needed properties by the object file. > > > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > > > > > > > > > to indicate that the object file requires canonical function > > > > > > pointers and > > > > > > cannot be used with copy relocation. This bit should be cleared in > > > > > > executable when there are non-GOT or non-PLT relocations in > > > > > > relocatable > > > > > > input files without this bit set. > > > > > > > > > > > > a. Protected symbol access within the shared library can be > > > > > > treated as > > > > > > local. > > > > > > b. Copy relocation should be disallowed at link-time and run-time. > > > > > > c. GOT function pointer
[PATCH v3] c++: designated init of char array by string constant [PR55227]
V3 addresses Jason's review point - it.undoes unnecessary variable renames
(back from arr_init to str_init)
Also address "FIXME: this code is duplicated from reshape_init" in
cp_complete_array_type by always calling reshape_init on init-list.
PR c++/55227
gcc/cp/ChangeLog:
* decl.c (reshape_init_r): Only call has_designator_check when
first_initializer_p or for the inner constructor element.
(cp_complete_array_type): Call reshape_init on braced-init-list.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/desig20.C: New test.
---
gcc/cp/decl.c| 28
gcc/testsuite/g++.dg/cpp2a/desig20.C | 48 +++
2 files changed, 58 insertions(+), 18 deletions(-)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 0e37f1a59bc..425840b1cd9 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6811,6 +6811,7 @@ reshape_init_r (tree type, reshape_iter *d, tree
first_initializer_p,
{
tree str_init = init;
tree stripped_str_init = stripped_init;
+ reshape_iter stripd = {};
/* Strip one level of braces if and only if they enclose a single
element (as allowed by [dcl.init.string]). */
@@ -6818,7 +6819,8 @@ reshape_init_r (tree type, reshape_iter *d, tree
first_initializer_p,
&& TREE_CODE (stripped_str_init) == CONSTRUCTOR
&& CONSTRUCTOR_NELTS (stripped_str_init) == 1)
{
- str_init = (*CONSTRUCTOR_ELTS (stripped_str_init))[0].value;
+ stripd.cur = CONSTRUCTOR_ELT (stripped_str_init, 0);
+ str_init = stripd.cur->value;
stripped_str_init = tree_strip_any_location_wrapper (str_init);
}
@@ -6827,7 +6829,8 @@ reshape_init_r (tree type, reshape_iter *d, tree
first_initializer_p,
array types (one value per array element). */
if (TREE_CODE (stripped_str_init) == STRING_CST)
{
- if (has_designator_problem (d, complain))
+ if ((first_initializer_p && has_designator_problem (d, complain))
+ || (stripd.cur && has_designator_problem (, complain)))
return error_mark_node;
d->cur++;
return str_init;
@@ -9544,22 +9547,11 @@ cp_complete_array_type (tree *ptype, tree
initial_value, bool do_default)
if (initial_value)
{
/* An array of character type can be initialized from a
- brace-enclosed string constant.
-
- FIXME: this code is duplicated from reshape_init. Probably
- we should just call reshape_init here? */
- if (char_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (*ptype)))
- && TREE_CODE (initial_value) == CONSTRUCTOR
- && !vec_safe_is_empty (CONSTRUCTOR_ELTS (initial_value)))
- {
- vec *v = CONSTRUCTOR_ELTS (initial_value);
- tree value = (*v)[0].value;
- STRIP_ANY_LOCATION_WRAPPER (value);
-
- if (TREE_CODE (value) == STRING_CST
- && v->length () == 1)
- initial_value = value;
- }
+ brace-enclosed string constant so call reshape_init to
+ remove the optional braces from a braced string literal. */
+ if (BRACE_ENCLOSED_INITIALIZER_P (initial_value))
+ initial_value = reshape_init (*ptype, initial_value,
+ tf_warning_or_error);
/* If any of the elements are parameter packs, we can't actually
complete this type now because the array size is dependent. */
diff --git a/gcc/testsuite/g++.dg/cpp2a/desig20.C
b/gcc/testsuite/g++.dg/cpp2a/desig20.C
new file mode 100644
index 000..daadfa58855
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/desig20.C
@@ -0,0 +1,48 @@
+// PR c++/55227
+// Test designated initializer for char array by string constant
+
+// { dg-options "" }
+
+struct C {char a[2];};
+
+/* Case a, designated, unbraced, string-literal of the exact same size
+ as the initialized char array; valid and accepted before and after. */
+C a = {.a="a"};
+
+/* Cases b,c,d, designated, braced or mimatched-size, string literal,
+ previously rejected; "C99 designator 'a' outside aggregate initializer". */
+C b = {.a=""};
+C c = {.a={""}};
+C d = {.a={"a"}};
+
+/* Case e, designated char array field and braced, designated array element(s)
+ (with GNU [N]= extension) valid and accepted before and after. */
+C e = {.a={[0]='a'}};
+
+/* Cases f,g,h, braced string literal, 'designated' within inner braces;
+ invalid, previously accepted as positional with 'designator' ignored. */
+C f = {{[0]="a"}}; // { dg-error "C99 designator .0. outside
aggregate initializer" }
+C g = {{.a="a"}}; // { dg-error "C99 designator .a. outside aggregate
initializer" }
+C h = {{.b="a"}}; // { dg-error "C99 designator .b. outside aggregate
initializer" }
+
+char a2[][10] = { [0] = { "aaa" } };
+
+struct D { C c; int a[8]; };
+
+D x = { .c {.a={"a"}}, .a={1,2,3,4,5,6,7,8} };
+
+struct A { union { int a; char c[4]; }; };
+
+A non = { .c = "c++" };
+
+template
+void t()
+{
+ C ca[] = { {.a=""}, {.a={""}}, };
+
+}
+
+void u()
+{
+ return t();
+}
--
2.35.0-rc1
[r12-6637 Regression] FAIL: g++.target/i386/pr103973-9.C scan-assembler-times \tcomisd 2 on Linux/x86_64
On Linux/x86_64,
463d9108766dcbb6a1051985e6c840a46897fe10 is the first bad commit
commit 463d9108766dcbb6a1051985e6c840a46897fe10
Author: Jakub Jelinek
Date: Mon Jan 17 13:39:05 2022 +0100
widening_mul, i386: Improve spaceship expansion on x86 [PR103973]
caused
FAIL: gcc.target/i386/pr103973-11.c scan-assembler-times \tcomiss 4
FAIL: gcc.target/i386/pr103973-13.c scan-assembler-times \tcomisd 4
FAIL: gcc.target/i386/pr103973-15.c scan-assembler-times \tcomiss 4
FAIL: gcc.target/i386/pr103973-1.c scan-assembler-times \tcomisd 4
FAIL: gcc.target/i386/pr103973-3.c scan-assembler-times \tcomiss 4
FAIL: gcc.target/i386/pr103973-5.c scan-assembler-times \tcomisd 4
FAIL: gcc.target/i386/pr103973-7.c scan-assembler-times \tcomiss 4
FAIL: gcc.target/i386/pr103973-9.c scan-assembler-times \tcomisd 4
FAIL: g++.target/i386/pr103973-11.C scan-assembler-times \tcomiss 2
FAIL: g++.target/i386/pr103973-13.C scan-assembler-times \tcomisd 2
FAIL: g++.target/i386/pr103973-15.C scan-assembler-times \tcomiss 2
FAIL: g++.target/i386/pr103973-1.C scan-assembler-times \tcomisd 2
FAIL: g++.target/i386/pr103973-3.C scan-assembler-times \tcomiss 2
FAIL: g++.target/i386/pr103973-5.C scan-assembler-times \tcomisd 2
FAIL: g++.target/i386/pr103973-7.C scan-assembler-times \tcomiss 2
FAIL: g++.target/i386/pr103973-9.C scan-assembler-times \tcomisd 2
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-6637/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-11.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-13.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-15.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-1.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-3.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-5.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-7.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr103973-9.c --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-11.C --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-13.C --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-15.C --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-1.C --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-3.C --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-5.C --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-7.C --target_board='unix{-m64\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="i386.exp=g++.target/i386/pr103973-9.C --target_board='unix{-m64\
-march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
Re: PING 4 [PATCH v2 2/2] add -Wdangling-pointer [PR #63272]
On 1/17/22 06:46, Stephan Bergmann wrote:
On 10/01/2022 22:51, Martin Sebor via Gcc-patches wrote:
Last ping for this stage 1 feature before stage 3 ends:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
This hits somewhat unexpectedly at (test case reduced from a hit in
LibreOffice)
Thanks for the small test case! It seems like the PHI handling
(conditionals) might overly simplistic. Let me look into it.
I tried to set up OpenOffice for testing with the latest GCC but
couldn't get the build to finish (it failed downloading some
unavailable prerequisites). I don't remember what problem I ran
into with LibreOffice; it was before I upgraded to Fedora 35 just
a couple of weeks ago. Let me retry again (the build is still
downloading tarballs).
In the meantime, do you have any tips or suggestions getting it
set up that aren't on the instructions page below? (Especially
for using an alternate compiler and non-default options.)
https://wiki.documentfoundation.org/Development/BuildingOnLinux#Fedora.2FRedHat
Martin
$ cat test.cc
#include
struct S1 {
S1(int);
~S1();
};
struct S2 { S2(std::initializer_list); };
S2 f1();
S2 f2(bool b) { return b ? f1() : S2{0}; }
$ g++ -Wdangling-pointer -c test.cc
test.cc: In function ‘S2 f2(bool)’:
test.cc:8:42: warning: dangling pointer to an unnamed temporary may be
used [-Wdangling-pointer=]
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
test.cc:8:39: note: unnamed temporary defined here
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
test.cc:8:42: warning: dangling pointer to an unnamed temporary may be
used [-Wdangling-pointer=]
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
test.cc:8:39: note: unnamed temporary defined here
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
Re: [PATCH] c++: ICE with noexcept and canonical types [PR101715]
On 1/14/22 19:22, Marek Polacek wrote:
This is a "canonical types differ for identical types" ICE, which started
with r11-4682. It's a bit tricky to explain. Consider:
template struct S {
S bar() noexcept(T::value); // #1
S foo() noexcept(T::value); // #2
};
template S S::foo() noexcept(T::value) {} // #3
We ICE because #3 and #2 have the same type, but their canonical types
differ: TYPE_CANONICAL (#3) == #2 but TYPE_CANONICAL (#2) == #1.
The member functions #1 and #2 have the same type. However, since their
noexcept-specifier is deferred, when parsing them, we create a variant for
both of them, because DEFERRED_PARSE cannot be compared. In other words,
build_cp_fntype_variant's
tree v = TYPE_MAIN_VARIANT (type);
for (; v; v = TYPE_NEXT_VARIANT (v))
if (cp_check_qualified_type (v, type, type_quals, rqual, raises, late))
return v;
will *not* find an existing variant when creating a method_type for #2, so we
have to create a new one.
But then we perform delayed parsing and call fixup_deferred_exception_variants
for #1 and #2. f_d_e_v will replace TYPE_RAISES_EXCEPTIONS with the newly
parsed noexcept-specifier. It also sets TYPE_CANONICAL (#2) to #1. Both
noexcepts turned out to be the same, so now we have two equivalent variants in
the list! I.e.,
+-+ +-+ +-+
| main | | #2 | | #1 |
| S S::(S*) |->| S S::(S*) |->| S S::(S*) |->NULL
|-| | noex(T::value) | | noex(T::value) |
+-+ +-+ +-+
Then we get to #3. As for #1 and #2, grokdeclarator calls build_memfn_type,
which ends up calling build_cp_fntype_variant, which will use the loop
above to look for an existing variant. The first one that matches
cp_check_qualified_type will be used, so we use #2 rather than #1, and the
TYPE_CANONICAL mismatch follows. Hopefully that makes sense.
Why doesn't the TYPE_CANONICAL (v) == v check prevent this?
As for the fix, I didn't think I could rewrite the method_type #2 with #1
because the type may have escaped via decltype. So my approach is to
elide #2 from the list, so when looking for a matching variant, we always
find #1 (#2 remains live though, which admittedly sounds sort of dodgy).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
PR c++/101715
gcc/cp/ChangeLog:
* tree.c (fixup_deferred_exception_variants): Remove duplicate
variants after parsing the exception specifications.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept72.C: New test.
* g++.dg/cpp0x/noexcept73.C: New test.
---
gcc/cp/tree.c | 16 +++-
gcc/testsuite/g++.dg/cpp0x/noexcept72.C | 21 +
gcc/testsuite/g++.dg/cpp0x/noexcept73.C | 13 +
3 files changed, 49 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept72.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept73.C
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 7f7de86b4e8..2efad49e7c1 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -2804,8 +2804,9 @@ fixup_deferred_exception_variants (tree type, tree raises)
/* Though sucky, this walk will process the canonical variants
first. */
+ tree prev = NULL_TREE;
for (tree variant = TYPE_MAIN_VARIANT (type);
- variant; variant = TYPE_NEXT_VARIANT (variant))
+ variant; prev = variant, variant = TYPE_NEXT_VARIANT (variant))
if (TYPE_RAISES_EXCEPTIONS (variant) == original)
{
gcc_checking_assert (variant != TYPE_MAIN_VARIANT (type));
@@ -2827,6 +2828,19 @@ fixup_deferred_exception_variants (tree type, tree
raises)
v = build_cp_fntype_variant (TYPE_CANONICAL (variant),
rqual, cr, false);
TYPE_CANONICAL (variant) = v;
+
+ /* If VARIANT became a duplicate (cp_check_qualified_type-wise)
+ of an existing variant in the variant list of TYPE after we
+ have parsed its exception specification, elide it. Otherwise,
+ build_cp_fntype_variant would use it, leading to "canonical
+ types differ for identical types." */
+ for (v = TYPE_MAIN_VARIANT (type); v; v = TYPE_NEXT_VARIANT (v))
+ if (v != variant
+ /* The main variant will not have TYPE_RAISES_EXCEPTIONS
+so PREV should never be null. */
+ && cp_check_qualified_type (v, variant, var_quals,
+ rqual, cr, false))
+ TYPE_NEXT_VARIANT (prev) = TYPE_NEXT_VARIANT (variant);
}
else
TYPE_RAISES_EXCEPTIONS (variant) = raises;
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept72.C
b/gcc/testsuite/g++.dg/cpp0x/noexcept72.C
new file mode 100644
index
Re: [PATCH] Fix tree-optimization/101941: IPA splitting out function with error attribute
On Fri, Jan 14, 2022 at 09:41:35AM +0100, Jan Hubicka via Gcc-patches wrote:
> > > > > > --- a/gcc/ipa-split.c
> > > > > > +++ b/gcc/ipa-split.c
> > > > > > @@ -873,7 +873,7 @@ visit_bb (basic_block bb, basic_block return_bb,
> > > > > > gimple *stmt = gsi_stmt (bsi);
> > > > > > tree op;
> > > > > > ssa_op_iter iter;
> > > > > > - tree decl;
> > > > > > + tree decl = NULL_TREE;
> > > > > >
> > > > > > if (is_gimple_debug (stmt))
> > > > > > continue;
> > > > > > @@ -927,6 +927,16 @@ visit_bb (basic_block bb, basic_block
> > > > > > return_bb,
> Decl is initialized in
> if (gimple_code (stmt) == GIMPLE_CALL
> && (decl = gimple_call_fndecl (stmt)) != NULL_TREE
> && fndecl_built_in_p (decl, BUILT_IN_NORMAL))
>
> I think this is confusing. I would change it to
> if (gimple_code (stmt) == GIMPLE_CALL
> && (decl = gimple_call_fndecl (stmt)) != NULL_TREE
> {
> if (fndecl_built_in_p (decl, BUILT_IN_NORMAL))
> ... existing code ...
> if (decl && (lookup_attribute ("warning", DECL_ATTRIBUTES (decl))
> || lookup_attribute ("error", DECL_ATTRIBUTES (decl
> ... your code ...
> }
> OK with that change.
Perhaps even
/* Check builtins that prevent splitting. */
if (gimple_code (stmt) == GIMPLE_CALL)
if (tree decl = gimple_call_fndecl (stmt))
{
if (fndecl_built_in_p (decl, BUILT_IN_NORMAL))
...
if (lookup_attribute || lookup_attribute)
...
}
?
Jakub
Re: Ping Re: [PATCH] middle-end: move initialization of stack_limit_rtx [PR103163]
On 1/17/22 1:29 AM, Richard Biener wrote: On Mon, Jan 17, 2022 at 4:15 AM Sandra Loosemore wrote: On 1/8/22 9:24 PM, Sandra Loosemore wrote: This patch fixes the ICE I reported in PR103163. We were initializing stack_limit_rtx before the register properties it depends on were getting set. I moved it to the same function where stack_pointer_rtx, frame_pointer_rtx, etc are being initialized. Besides nios2 where I observed it, this bug was also reported to affect powerpc. Anybody want to check it there? Otherwise, OK to check in? Ping? https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587958.html This move will now also re-initialize the pointer during target_reinit (), is that desired and correct? I did consider that when I wrote the patch -- I can't claim to be an expert on the re-initialization parts of the compiler any more (it's been so long since I worked on that refactoring, and my brain is suffering from bit rot), but it seems reasonable to handle stack_limit_rtx the same way as other frame-related rtx variables, in case the register properties have changed in some way that would affect them. -Sandra
Re: [PATCH] middle-end/101292 - invalid memory access with warning control
On 1/17/22 07:32, Richard Biener via Gcc-patches wrote:
The warning control falls into the C++ trap of using a reference
to old hashtable contents for a put operation which can end up
re-allocating that before reading from the old freed referenced to
source. Fixed by introducing a temporary.
I think a better place to fix this and avoid the gotcha once and
for all is in the GCC hash_map: C++ containers are expected to
handle the insertion of own elements gracefully.
Martin
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2022-01-17 Richard Biener
PR middle-end/101292
* diagnostic-spec.c (copy_warning): Make sure to not
reference old hashtable content on possible resize.
* warning-control.cc (copy_warning): Likewise.
---
gcc/diagnostic-spec.c | 5 -
gcc/warning-control.cc | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gcc/diagnostic-spec.c b/gcc/diagnostic-spec.c
index a8af229d677..4341ccfaae9 100644
--- a/gcc/diagnostic-spec.c
+++ b/gcc/diagnostic-spec.c
@@ -195,7 +195,10 @@ copy_warning (location_t to, location_t from)
else
{
if (from_spec)
- nowarn_map->put (to, *from_spec);
+ {
+ nowarn_spec_t tem = *from_spec;
+ nowarn_map->put (to, tem);
+ }
else
nowarn_map->remove (to);
}
diff --git a/gcc/warning-control.cc b/gcc/warning-control.cc
index f9808bf4392..fa39ecab421 100644
--- a/gcc/warning-control.cc
+++ b/gcc/warning-control.cc
@@ -206,7 +206,8 @@ void copy_warning (ToType to, FromType from)
gcc_assert (supp);
gcc_checking_assert (nowarn_map);
- nowarn_map->put (to_loc, *from_spec);
+ nowarn_spec_t tem = *from_spec;
+ nowarn_map->put (to_loc, tem);
}
else
{
Re: [Patch][V5][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.
Thanks. I just committed the patch to gcc12 as: https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359400.html Qing > On Jan 17, 2022, at 5:36 AM, Richard Biener > wrote: > > On Sat, Jan 15, 2022 at 5:49 PM Qing Zhao wrote: >> >> Hi, Richard, >> >> This is the updated version for the change of "Enable -Wuninitialized + >> -ftrivial-auto-var-init for address taken variables”. >> >> Compared to the previous patch, I mainly made the following change: >> >> Delete the 4th parameter of “warn_uninit”, construct the warning message >> string based on the value of OPT and VAR. >> >> This patch has been bootstrapped and regressing tested on both X86 and >> aarch64. >> >> Okay for GCC12? >> >> thanks. >> >> Qing. >> >> == >> Enable -Wuninitialized + -ftrivial-auto-var-init for address >> taken variables. >> >> With -ftrivial-auto-var-init, the address taken auto variable is replaced >> with >> a temporary variable during gimplification, and the original auto variable >> might >> be eliminated by compiler optimization completely. As a result, the current >> uninitialized warning analysis cannot get enough information from the IR, >> therefore the uninitialized warnings for address taken variable cannot be >> issued based on the current implemenation of -ftrival-auto-var-init. >> >> For more info please refer to: >> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577431.html >> >> In order to improve this situation, we can improve uninitialized analysis >> for address taken auto variables with -ftrivial-auto-var-init as following: >> >> for the following stmt: >> >>_1 = .DEFERRED_INIT (4, 2, &"alt_reloc"[0]); >>if (_1 != 0) >> >> The original variable DECL has been eliminated from the IR, all the necessary >> information that is needed for reporting the warnings for DECL can be >> acquired >> from the call to .DEFERRED_INIT. >> >>A. the name string of DECL from the 3rd parameter of the call; >>B. the location of the DECL from the location of the call; >>C. the call can also be used to hold the information on whether the >> warning >> has been issued or not to suppress warning messages when needed; >> >> The current testing cases for uninitialized warnings + >> -ftrivial-auto-var-init >> are adjusted to reflect the fact that we can issue warnings for address taken >> variables. > > OK. > > Thanks, > Richard. > >> gcc/ChangeLog: >> >> 2022-01-14 qing zhao >> >>* tree-ssa-uninit.c (warn_uninit): Delete the 4th parameter. Handle >>.DEFERRED_INIT call with an anonymous SSA_NAME specially. >>(check_defs): Handle .DEFERRED_INIT call with an anonymous SSA_NAME >>specially. >>(warn_uninit_phi_uses): Delete the 4th actual when call warn_uninit. >>(warn_uninitialized_vars): Likewise. >>(warn_uninitialized_phi): Likewise. >> >> The complete patch is:
Re: [PATCH] c++: Fix cp_genericize_target_expr for TARGET_EXPRs created for global initialization [PR104031]
On 1/17/22 03:56, Jakub Jelinek wrote:
Hi!
The following patch is miscompiled, cp_genericize_target_expr expects
that for the constant part split_nonconstant_init will emit an INIT_EXPR
that will initialize it, but that doesn't happen and instead we get
DECL_INITIAL on the TARGET_EXPR_SLOT that isn't initialized anywhere
in the IL.
The problem is that the TARGET_EXPR has been created while
current_function_decl was NULL, it is inside a global var initializer.
That means the build_local_temp created VAR_DECL has NULL DECL_CONTEXT.
Later on when genericizing the ssdf (current_function_decl is already
non-NULL), the new cp_genericize_target_expr is called and during
split_nonconstant_init it checks is_local_temp, but that due to the NULL
DECL_CONTEXT returns false. DECL_CONTEXT is set only later on during
gimplification.
The following patch fixes it by setting DECL_CONTEXT also inside of
cp_genericize_target_expr, which fixes the testcase. But if there are
better spots to do that, please let me know...
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-01-17 Jakub Jelinek
PR c++/104031
* cp-gimplify.c (cp_genericize_target_expr): Set DECL_CONTEXT of
TARGET_EXPR_SLOT to current_function_decl if it was NULL.
* g++.dg/cpp1y/pr104031.C: New test.
--- gcc/cp/cp-gimplify.c.jj 2022-01-14 12:09:13.003250834 +0100
+++ gcc/cp/cp-gimplify.c2022-01-16 21:34:52.300937996 +0100
@@ -930,6 +930,11 @@ cp_genericize_init_expr (tree *stmt_p)
static void
cp_genericize_target_expr (tree *stmt_p)
{
+ /* If TARGET_EXPR is created for some global var initializer, the slot
+ will have NULL and so is_local_temp will return false for it. If
+ this is a ssdf, set DECL_CONTEXT now. */
+ if (DECL_CONTEXT (TARGET_EXPR_SLOT (*stmt_p)) == NULL_TREE)
+DECL_CONTEXT (TARGET_EXPR_SLOT (*stmt_p)) = current_function_decl;
cp_genericize_init (_EXPR_INITIAL (*stmt_p),
TARGET_EXPR_INITIAL (*stmt_p),
TARGET_EXPR_SLOT (*stmt_p));
We could use a local variable for TARGET_EXPR_SLOT (*stmt_p) instead of
repeating it. OK either way.
--- gcc/testsuite/g++.dg/cpp1y/pr104031.C.jj2022-01-16 21:30:14.977838079
+0100
+++ gcc/testsuite/g++.dg/cpp1y/pr104031.C 2022-01-16 21:30:46.028401294
+0100
@@ -0,0 +1,23 @@
+// PR c++/104031
+// { dg-do run { target c++14 } }
+// { dg-options "-O2" }
+
+struct A {
+ A () {}
+ ~A () {}
+};
+struct B {
+ A a;
+ int b = 0;
+};
+struct C
+{
+ [[gnu::noipa]]
+ C (B x) { if (x.b != 42) __builtin_abort (); }
+};
+static C c ({ .a = A{}, .b = 42 });
+
+int
+main ()
+{
+}
Jakub
[PATCH] Fix for GCC '-MF' option cannot deal with long paths in Windows
Hello, The '-MF' option cannot deal with path size >256 characters in Windows. This patch is to fix this long path issue with -MF option. Let me know is it ok to commit? -- Thanks, Sundeep K. c-opts.patch Description: Binary data
Re: [PATCH, OpenMP] PR103642 - Fix omp-low ICE for indirect references based off component access
Ping. On 2022/1/3 10:15 PM, Chung-Lin Tang wrote: This issue was triggered after the patch extending syntax for component access in map clauses (https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ab29cf0bb68960c) In gimplify_scan_omp_clauses, the case for handling indirect accesses (which creates firstprivate ptr and zero-length array section map for such decls) was erroneously went into for non-pointer cases (here being the base struct decl), so added the appropriate checks there. Added new testcase is a compile only test for the ICE. The original omptests t-partial-struct test actually should not execute correctly, because for map(t.s->a[:N]), map(t.s[:1]) is not implicitly mapped, thus the entire offloaded access does not work as is. (fixing that omptests test is out of scope here) Tested without regressions, okay for trunk? Thanks, Chung-Lin 2022-01-03 Chung-Lin Tang gcc/ChangeLog: PR middle-end/103642 * gimplify.c (gimplify_scan_omp_clauses): Do not do indir_p handling for non-pointer or non-reference-to-pointer cases. gcc/testsuite/ChangeLog: * c-c++-common/gomp/pr103642.c: New test.
[PATCH] middle-end/101292 - invalid memory access with warning control
The warning control falls into the C++ trap of using a reference
to old hashtable contents for a put operation which can end up
re-allocating that before reading from the old freed referenced to
source. Fixed by introducing a temporary.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2022-01-17 Richard Biener
PR middle-end/101292
* diagnostic-spec.c (copy_warning): Make sure to not
reference old hashtable content on possible resize.
* warning-control.cc (copy_warning): Likewise.
---
gcc/diagnostic-spec.c | 5 -
gcc/warning-control.cc | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gcc/diagnostic-spec.c b/gcc/diagnostic-spec.c
index a8af229d677..4341ccfaae9 100644
--- a/gcc/diagnostic-spec.c
+++ b/gcc/diagnostic-spec.c
@@ -195,7 +195,10 @@ copy_warning (location_t to, location_t from)
else
{
if (from_spec)
- nowarn_map->put (to, *from_spec);
+ {
+ nowarn_spec_t tem = *from_spec;
+ nowarn_map->put (to, tem);
+ }
else
nowarn_map->remove (to);
}
diff --git a/gcc/warning-control.cc b/gcc/warning-control.cc
index f9808bf4392..fa39ecab421 100644
--- a/gcc/warning-control.cc
+++ b/gcc/warning-control.cc
@@ -206,7 +206,8 @@ void copy_warning (ToType to, FromType from)
gcc_assert (supp);
gcc_checking_assert (nowarn_map);
- nowarn_map->put (to_loc, *from_spec);
+ nowarn_spec_t tem = *from_spec;
+ nowarn_map->put (to_loc, tem);
}
else
{
--
2.31.1
[Committed] Change kind of integer literal to fix a testcase.
As Thomas reported in
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588448.html
a test added in my recent allocate clause patch fails on m32. It was due
to default kind for integer matching c_intptr_t for m32. I have now
changed it to 0_1 so that always integer with kind=1 is used.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/allocate-2.f90: Change 0 to 0_1.
---
gcc/testsuite/gfortran.dg/gomp/allocate-2.f90 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/gomp/allocate-2.f90
b/gcc/testsuite/gfortran.dg/gomp/allocate-2.f90
index 88b2d26872d..657ff44d023 100644
--- a/gcc/testsuite/gfortran.dg/gomp/allocate-2.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/allocate-2.f90
@@ -33,7 +33,7 @@ subroutine foo(x)
x=5
!$omp end parallel
- !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected integer
expression of the 'omp_allocator_handle_kind' kind at .1." }
+ !$omp parallel allocate (0_1: x) private(x) ! { dg-error "Expected integer
expression of the 'omp_allocator_handle_kind' kind at .1." }
x=6
!$omp end parallel
--
2.25.1
Re: [PATCH] disable aggressive_loop_optimizations until niter ready
Richard Biener writes:
> On Fri, 14 Jan 2022, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Thu, 13 Jan 2022, guojiufu wrote:
>> >
>> >> On 2022-01-03 22:30, Richard Biener wrote:
>> >> > On Wed, 22 Dec 2021, Jiufu Guo wrote:
>> >> >
>> >> >> Hi,
>> >> >> ...
>> >> >>
>> >> >> Bootstrap and regtest pass on ppc64* and x86_64. Is this ok for trunk?
>> >> >
may means infer_loop_bounds_from_undefined may not useful
before IV's scev is ready.
> override the global caching of analyze_scalar_evolution the per
> SSA name cache for SCEV analysis isn't overridden. That also means
> computing the estimates early will break your patch (I've
> tested calling estimate_numbers_of_iterations explicitely from
> loop distribution for example).
Calling simple_iv_with_niters/simple_iv early may break the patch,
because only inside number_of_iterations_exit_assumptions, the flag
is disabled.
>
> What I'm trying to see is whether we can do some more concious
> setup of control IV computation and estimate computation. While
> your patch produces the desired result it is far from obvious
> why exactly it does this since it also does it in a "midlevel"
> place (of course my attempts to do it in a more obvious position
> failed).
>
> But first of all yes, we should disallow / early out on recursions
> via public APIs like estimate_numbers_of_iterations (already done)
> or number_of_latch_executions (missing) or
> number_of_iterations_exit[_assumptions] (very difficult there).
I'm wondering if we can set loop->nb_iterations=chrec_dont_know
or chrec_known in number_of_iterations_exit_assumption at the
begining, and use it as a guard to avoid recursions on them.
>
> IMHO that we lazily compute estimate_numbers_of_iterations and that
> computes niter for each exit of a loop is a misdesign - the estimate
> should be computed from the toplevel, and maybe independently for
> each exit? I think that Honza changed it this way to make sure the
> estimates are always available when queried but I may mis-remember.
>
> With your patch, ontop of that limiting recursion of
> number_of_latch_executions doesn't break the positive effect
> at least.
>
> One unwanted side-effect of your patch might be that the
> computed estimate is now recorded w/o infer_loop_bounds_from_undefined
> which means it could be worse (and we won't re-compute it).
Yes, estimate was computed but infer_loop_bounds_from_undefined was
not called, and it will never be called before estimate is reset.
>
> All in all it is somewhat of a mess and I'm not convinced your
> patch is an improvement in this regard :/ It looks like there's
> a chicken and egg problem with using and recording (at least one)
> control IV and SCEV caching whilst searching for one.
Thanks for your comments, and welcome any sugguestions!
BR,
Jiufu
>
> Richard.
>
>
>> >
>> > I also tried
>> >
>> > diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
>> > index 935d2d4d8f3..d1787ba39b6 100644
>> > --- a/gcc/tree-ssa-loop-ivopts.c
>> > +++ b/gcc/tree-ssa-loop-ivopts.c
>> > @@ -8093,6 +8093,8 @@ tree_ssa_iv_optimize_loop (struct ivopts_data *data,
>> > class loop *loop,
>> >fprintf (dump_file, "\n");
>> > }
>> >
>> > + estimate_numbers_of_iterations (loop);
>> > +
>> >body = get_loop_body (loop);
>> >data->body_includes_call = loop_body_includes_call (body,
>> > loop->num_nodes);
>> >renumber_gimple_stmt_uids_in_blocks (body, loop->num_nodes);
>> >
>> > to get into the cycles from the "correct" entry but that does
>> > not help either. Nor does
>> >
>> > diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
>> > index b767056aeb0..f058be04836 100644
>> > --- a/gcc/tree-ssa-loop-niter.c
>> > +++ b/gcc/tree-ssa-loop-niter.c
>> > @@ -2534,6 +2534,14 @@ number_of_iterations_exit_assumptions (class loop
>> > *loop, edge exit,
>> >&& !POINTER_TYPE_P (type))
>> > return false;
>> >
>> > + if (loop->estimate_state == EST_NOT_COMPUTED)
>> > +{
>> > + bool saved = flag_aggressive_loop_optimizations;
>> > + flag_aggressive_loop_optimizations = false;
>> > + estimate_numbers_of_iterations (loop);
>> > + flag_aggressive_loop_optimizations = saved;
>> > +}
>> > +
>> >tree iv0_niters = NULL_TREE;
>> >if (!simple_iv_with_niters (loop, loop_containing_stmt (stmt),
>> > op0, , safe ? _niters : NULL,
>> > false))
>> >
>> > or
>> >
>> > diff --git a/gcc/tree-scalar-evolution.c b/gcc/tree-scalar-evolution.c
>> > index 61d72c278a1..d1af89eb459 100644
>> > --- a/gcc/tree-scalar-evolution.c
>> > +++ b/gcc/tree-scalar-evolution.c
>> > @@ -518,7 +518,8 @@ set_scalar_evolution (basic_block instantiated_below,
>> > tree scalar, tree chrec)
>> > nb_set_scev++;
>> > }
>> >
>> > - *scalar_info = chrec;
>> > + if (*scalar_info == chrec_not_analyzed_yet)
>> > +*scalar_info = chrec;
>> > }
>> >
>> > /* Retrieve the chrec associated to SCALAR
Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
On 14/01/2022 12:20, Tobias Burnus wrote:
> On 14.01.22 12:55, Jakub Jelinek via Fortran wrote:
>> If we want to check intptr_t, we should guard the dg-error with
>> "" { target { lp64 || llp64 } }
>> or so.
>
> Well, if we want to use intptr_t, we could use be explicitly as with:
>
> use iso_c_binding, only: c_intptr_t
> ! use omp_lib, only: omp_allocator_handle_kind
> ... ('implicit none' etc.)
> integer, parameter :: omp_allocator_handle_kind = c_intptr_t
> ...
> integer(kind=omp_allocator_handle_kind)
>
> (@Abid: The 'use omp_lib' line is commented as in gcc/testsuite/*/gomp/,
> the OpenMP module/header from libgomp is not available - and then a
> stub parameter is created.)
>
>> Otherwise yes, we can add some other kind and hope it is not the
>> same as omp_allocator_handle_kind. Or we can do both,
>> keep the current one with the target lp64 || llp64 and
>> add another one with some integer(kind=1).
>
> For just testing something invalid, I think it makes more sense to just set
> it to kind=1.
>
> For checking the valid value, using c_intptr_t seems to make more sense than
> restricting it to (l)l64.
Problem was with the literal 0 having same kind as c_intptr_t for m32. So there
was no diagnostic in
that case. I am going to change it 0_1 to make the test more robust.
Thanks,
--
Hafiz Abid Qadeer
Mentor, a Siemens Business
Re: PING 4 [PATCH v2 2/2] add -Wdangling-pointer [PR #63272]
On 10/01/2022 22:51, Martin Sebor via Gcc-patches wrote:
Last ping for this stage 1 feature before stage 3 ends:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html
This hits somewhat unexpectedly at (test case reduced from a hit in
LibreOffice)
$ cat test.cc
#include
struct S1 {
S1(int);
~S1();
};
struct S2 { S2(std::initializer_list); };
S2 f1();
S2 f2(bool b) { return b ? f1() : S2{0}; }
$ g++ -Wdangling-pointer -c test.cc
test.cc: In function ‘S2 f2(bool)’:
test.cc:8:42: warning: dangling pointer to an unnamed temporary may be used
[-Wdangling-pointer=]
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
test.cc:8:39: note: unnamed temporary defined here
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
test.cc:8:42: warning: dangling pointer to an unnamed temporary may be used
[-Wdangling-pointer=]
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
test.cc:8:39: note: unnamed temporary defined here
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
| ^
Re: [PATCH] widening_mul, i386, v2: Improve spaceship expansion on x86 [PR103973]
On Mon, Jan 17, 2022 at 01:04:40PM +0100, Richard Biener wrote:
> > I guess it depends, for code that can only be called during the expand pass
> > dropping it should be just fine, for code that can be called also (or only)
> > later I think adding JUMP_LABEL and correct LABEL_NUSES is needed because
> > nothing will fix it up afterwards.
>
> I'm noting that
>
> + /* BB must have no executable statements. */
> + gimple_stmt_iterator gsi = gsi_after_labels (bb);
> + if (phi_nodes (bb))
> +return false;
>
> disallows blocks with just a virtual PHI which wouldn't be
> "executable". Not sure if anything will break when we fix that.
Note I'm only moving the existing function from phiopt to tree-cfg.c
so that I can use it from tree-ssa-math-opts.c. But all the
cond_only_block_p uses in phiopt and now in tree-ssa-maht-opts.c too
only call it on single_pred_p (bb) basic blocks, so I don't see
what the virtual PHI on those would be good for.
> For code generation we rely on RTL opts to merge compare/scc
> and the subsequent branches on -1/0/1/[-2], correct? I wonder
> whether that works on other targets as well or whether a
> asm-goto with "optab" UNSPEC text would be more forward looking?
Yes, we rely on some RTL opts, like we rely on it for e.g. the overflow
builtins or various other cases and they seem to be doing their job
well on my testing. Initially I thought the optab would have 6 arguments,
2 comparison args and 4 labels and I'd emit a switch in the
tree-ssa-math-opts.c (I even wrote such code). But it didn't work really
well, the switch in some cases wasn't really optimized, and optimization
passes after the widening_mul liked e.g. to propagate the .SPACESHIP
lhs into some but not all the PHI args if there were any etc.
Emitting a function that returns -1/0/1/2 worked better, especially if
the target attempts to emit it as a series of conditional jumps
with small bbs that just set those values. RTL opts later on will
merge the jumps with further jumps that test the .SPACESHIP result,
or will turn some of the conditional jumps into scc etc.
> The restriction to scalar floats is probably because with
> scalar integers we're doing fine and with vectors we'd need some
> very much different tricks, right?
Sure, for vectors we couldn't use branches etc.
I'm not really sure how would one write a vector version of the
spaceship actually. The primary use case is C++ with <=>, but <=>
returns std::*_ordering which is an aggregate and one that isn't
very easy to turn into an integer even, switch doesn't work,
only if (... == std::partial_ordering::equality) ... else if (...
(unless I'm missing something).
But even in C, maybe:
typedef float V __attribute__((vector_size (16)));
typedef int W __attribute__((vector_size (16)));
W
foo (V x, V y)
{
return (x != y) & (((x < y) & (W) { -1, -1, -1, -1 }) | ((x > y) & (W) { 1,
1, 1, 1 }) | ((W) { 2, 2, 2, 2 } & ~(x < y) & ~(x > y)));
}
but it isn't clear how I'd optimize it at the assembly, where
we currently emit:
vbroadcastss.LC2(%rip), %xmm2
vcmpltps%xmm0, %xmm1, %xmm3
vbroadcastss.LC3(%rip), %xmm4
vpand %xmm3, %xmm2, %xmm2
vcmpltps%xmm1, %xmm0, %xmm3
vpor%xmm3, %xmm2, %xmm2
vcmpneq_oqps%xmm1, %xmm0, %xmm3
vcmpneqps %xmm1, %xmm0, %xmm0
vpandn %xmm4, %xmm3, %xmm3
vpor%xmm3, %xmm2, %xmm2
vpand %xmm0, %xmm2, %xmm0
ret
.LC2:
.long 1
.align 4
.LC3:
.long 2
> The middle-end changes look OK, I don't see anything that
> couldn't be changed if other targets run into problems with
> getting similar optimized code.
Thanks.
Jakub
[PATCH][www][pushed] Clarify GCC versioning, esp. the DEV-PHASE.
--- htdocs/develop.html | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/htdocs/develop.html b/htdocs/develop.html index 263cbc79..1ac48b09 100644 --- a/htdocs/develop.html +++ b/htdocs/develop.html @@ -266,8 +266,10 @@ way and on the following timeline: VersionDEV-PHASEWhen 5.0.0(experimental) during active development of GCC 5 (stage 1 to 3) + 5.0.1(experimental) + during the stabilization period of GCC 5 (stage 4) 5.0.1(prerelease) - during the stabilization period of GCC 5 + after branching for the release of GCC 5.1 6.0.0(experimental) during active development of GCC 6 (stage 1 to 3) 5.1.0 @@ -278,12 +280,12 @@ way and on the following timeline: for the second release from the GCC 5 branch 5.2.1 during development on the branch post the 5.2.0 release - 6.0.1(prerelease) - during the stabilization period of GCC 6 + 6.0.1(experimental) + during the stabilization period of GCC 6 (stage 4) ... To summarize, the first release of GCC 5 will be GCC 5.1.0 while -development snapshots will be GCC 5.0.0 and snapshots from the +development snapshots will be GCC 5.0.0 or GCC 5.0.1 and snapshots from the release branch GCC 5.n.1. Rationale -- 2.31.1
[committed] libstdc++: Define header for C++23
Tested x86_64-linux, pushed to trunk. Add the header and a new libstdc++_libbacktrace.a library that provides the implementation. For now, the new library is only built if --enable-libstdcxx-backtrace=yes is used. As with the Filesystem TS, the new library is only provided as a static archive. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): New macro. * configure.ac: Use GLIBCXX_ENABLE_BACKTRACE. * include/Makefile.am: Add new header. * include/Makefile.in: Regenerate. * include/std/stacktrace: New header. * include/std/version (__cpp_lib_stacktrace): Define. * Makefile.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * doc/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.am: Regenerate. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++17/Makefile.in: Regenerate. * src/c++20/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * src/filesystem/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * src/libbacktrace/Makefile.am: New file. * src/libbacktrace/Makefile.in: New file. * src/libbacktrace/backtrace-rename.h: New file. * src/libbacktrace/backtrace-supported.h.in: New file. * src/libbacktrace/config.h.in: New file. * testsuite/lib/libstdc++.exp (check_effective_target_stacktrace): New proc. * testsuite/20_util/stacktrace/entry.cc: New test. * testsuite/20_util/stacktrace/synopsis.cc: New test. * testsuite/20_util/stacktrace/version.cc: New test. --- libstdc++-v3/Makefile.in | 7 + libstdc++-v3/acinclude.m4 | 138 ++- libstdc++-v3/config.h.in | 10 + libstdc++-v3/configure| 317 ++- libstdc++-v3/configure.ac | 3 + libstdc++-v3/doc/Makefile.in | 7 + libstdc++-v3/include/Makefile.am | 1 + libstdc++-v3/include/Makefile.in | 8 + libstdc++-v3/include/std/stacktrace | 672 ++ libstdc++-v3/include/std/version | 3 + libstdc++-v3/libsupc++/Makefile.in| 7 + libstdc++-v3/po/Makefile.in | 7 + libstdc++-v3/python/Makefile.in | 7 + libstdc++-v3/src/Makefile.am | 11 +- libstdc++-v3/src/Makefile.in | 14 +- libstdc++-v3/src/c++11/Makefile.in| 7 + libstdc++-v3/src/c++17/Makefile.in| 7 + libstdc++-v3/src/c++20/Makefile.in| 7 + libstdc++-v3/src/c++98/Makefile.in| 7 + libstdc++-v3/src/filesystem/Makefile.in | 7 + libstdc++-v3/src/libbacktrace/Makefile.am | 101 ++ libstdc++-v3/src/libbacktrace/Makefile.in | 860 ++ .../src/libbacktrace/backtrace-rename.h | 41 + .../src/libbacktrace/backtrace-supported.h.in | 61 ++ libstdc++-v3/src/libbacktrace/config.h.in | 184 .../testsuite/20_util/stacktrace/entry.cc | 53 ++ .../testsuite/20_util/stacktrace/synopsis.cc | 46 + .../testsuite/20_util/stacktrace/version.cc | 11 + libstdc++-v3/testsuite/Makefile.in| 7 + libstdc++-v3/testsuite/lib/libstdc++.exp | 8 + 30 files changed, 2605 insertions(+), 14 deletions(-) create mode 100644 libstdc++-v3/include/std/stacktrace create mode 100644 libstdc++-v3/src/libbacktrace/Makefile.am create mode 100644 libstdc++-v3/src/libbacktrace/Makefile.in create mode 100644 libstdc++-v3/src/libbacktrace/backtrace-rename.h create mode 100644 libstdc++-v3/src/libbacktrace/backtrace-supported.h.in create mode 100644 libstdc++-v3/src/libbacktrace/config.h.in create mode 100644 libstdc++-v3/testsuite/20_util/stacktrace/entry.cc create mode 100644 libstdc++-v3/testsuite/20_util/stacktrace/synopsis.cc create mode 100644 libstdc++-v3/testsuite/20_util/stacktrace/version.cc diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index b770d5bcdc4..336c690f07b 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -49,7 +49,7 @@ AC_DEFUN([GLIBCXX_CONFIGURE], [ # Keep these sync'd with the list in Makefile.am. The first provides an # expandable list at autoconf time; the second provides an expandable list # (i.e., shell variable) at configure time. - m4_define([glibcxx_SUBDIRS],[include libsupc++ src src/c++98 src/c++11 src/c++17 src/c++20 src/filesystem doc po testsuite python]) + m4_define([glibcxx_SUBDIRS],[include libsupc++ src src/c++98 src/c++11 src/c++17 src/c++20 src/filesystem src/libbacktrace doc po testsuite python]) SUBDIRS='glibcxx_SUBDIRS' # These need to be absolute paths, yet at the same time need to @@ -4801,6 +4801,142 @@
GCC 12.0.1 Status Report (2022-01-17), Stage 4 starts now
Status == The GCC master branch is now in regression and documentation fixing mode (Stage 4) in preparation for the release of GCC 13. Re-opening of general development will happen once we reach zero P1 regressions which is when we branch for the release. Time wise history projects that to happen around mid to end of April 2022. Take the quality data below with a big grain of salt - most of the new P3 classified bugs will become P1 or P2 (generally every regression against GCC 11 is to be considered P1 if it concerns primary or secondary platforms). Quality Data Priority # Change from last report --- --- P1 38+ 8 P2 310 + 3 P3 286 + 7 P4 221 + 1 P5 25 --- --- Total P1-P3 634 + 18 Total 880 + 19 Previous Report === https://gcc.gnu.org/pipermail/gcc/2022-January/238060.html
[committed] libstdc++: Document final option names for enabling C++20
Pushed to trunk. libstdc++-v3/ChangeLog: * doc/xml/manual/status_cxx2020.xml: Use final C++20 option names. * doc/html/manual/status.html: Regenerate. --- libstdc++-v3/doc/html/manual/status.html | 4 ++-- libstdc++-v3/doc/xml/manual/status_cxx2020.xml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml index cebe36a8d5e..7e2582668ed 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml @@ -10,8 +10,8 @@ -In this implementation the -std=gnu++2a or --std=c++2a flag must be used to enable language +In this implementation the -std=gnu++20 or +-std=c++20 flag must be used to enable language and library features. See dialect options. The pre-defined symbol -- 2.31.1
[committed] libstdc++: Rename non-reserved macros in config header [PR103650]
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/103650
* include/Makefile.am: Rename LT_OBJDIR and STDC_HEADERS.
* include/Makefile.in: Regenerate.
* testsuite/17_intro/headers/c++1998/103650.cc: New test.
---
libstdc++-v3/include/Makefile.am| 2 ++
libstdc++-v3/include/Makefile.in| 2 ++
.../testsuite/17_intro/headers/c++1998/103650.cc| 13 +
3 files changed, 17 insertions(+)
create mode 100644 libstdc++-v3/testsuite/17_intro/headers/c++1998/103650.cc
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 8b1300e0f29..65b2b4e64af 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1343,6 +1343,8 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
-e 's/PACKAGE/_GLIBCXX_PACKAGE/g' \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
+ -e 's/LT_OBJDIR/_GLIBCXX_LT_OBJDIR/g' \
+ -e 's/STDC_HEADERS/_GLIBCXX_STDC_HEADERS/g' \
-e 's/_DARWIN_USE_64_BIT_INODE/_GLIBCXX_DARWIN_USE_64_BIT_INODE/g' \
-e 's/_FILE_OFFSET_BITS/_GLIBCXX_FILE_OFFSET_BITS/g' \
-e 's/_LARGE_FILES/_GLIBCXX_LARGE_FILES/g' \
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++1998/103650.cc
b/libstdc++-v3/testsuite/17_intro/headers/c++1998/103650.cc
new file mode 100644
index 000..356ffa310bc
--- /dev/null
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/103650.cc
@@ -0,0 +1,13 @@
+// { dg-do preprocess }
+
+// PR libstdc++/103650 libstdc++ headers defined LT_OBJDIR and STDC_HEADERS
+
+#define LT_OBJDIR 99
+#define STDC_HEADERS 99
+#include
+#if LT_OBJDIR != 99
+# error LT_OBJDIR redefined
+#endif
+#if STDC_HEADERS != 99
+# error STDC_HEADERS redefined
+#endif
--
2.31.1
Re: [PATCH] widening_mul, i386, v2: Improve spaceship expansion on x86 [PR103973]
On Sat, 15 Jan 2022, Jakub Jelinek wrote:
> On Sat, Jan 15, 2022 at 11:42:55AM +0100, Uros Bizjak wrote:
> > Yes, that would be nice. XFmode is used for long double, and not obsolete.
>
> Ok, that seems to work. Compared to the incremental patch I've posted, I
> also had to add handling of the case where we have just
> x == y ? 0 : x < y ? -1 : 1 (both for -ffast-math and non-ffast-math).
> Apparently even that is worth optimizing.
> Tested so far on the new testcases, will run full bootstrap/regtest tonight.
>
> > > Why? That seems to be a waste of time to me, unless something uses them
> > > already during expansion. Because pass_expand::execute
> > > runs:
> > > /* We need JUMP_LABEL be set in order to redirect jumps, and hence
> > > split edges which edge insertions might do. */
> > > rebuild_jump_labels (get_insns ());
> > > which resets all LABEL_NUSES to 0 (well, to:
> > > if (LABEL_P (insn))
> > > LABEL_NUSES (insn) = (LABEL_PRESERVE_P (insn) != 0);
> > > and then recomputes them and adds JUMP_LABEL if needed:
> > > JUMP_LABEL (insn) = label;
> >
> > I was not aware of that detail. Thanks for sharing (and I wonder if
> > all other cases should be removed from the source).
>
> I guess it depends, for code that can only be called during the expand pass
> dropping it should be just fine, for code that can be called also (or only)
> later I think adding JUMP_LABEL and correct LABEL_NUSES is needed because
> nothing will fix it up afterwards.
I'm noting that
+ /* BB must have no executable statements. */
+ gimple_stmt_iterator gsi = gsi_after_labels (bb);
+ if (phi_nodes (bb))
+return false;
disallows blocks with just a virtual PHI which wouldn't be
"executable". Not sure if anything will break when we fix that.
For code generation we rely on RTL opts to merge compare/scc
and the subsequent branches on -1/0/1/[-2], correct? I wonder
whether that works on other targets as well or whether a
asm-goto with "optab" UNSPEC text would be more forward looking?
The restriction to scalar floats is probably because with
scalar integers we're doing fine and with vectors we'd need some
very much different tricks, right?
The middle-end changes look OK, I don't see anything that
couldn't be changed if other targets run into problems with
getting similar optimized code.
Thanks,
Richard.
> 2022-01-15 Jakub Jelinek
>
> PR target/103973
> * tree-cfg.h (cond_only_block_p): Declare.
> * tree-ssa-phiopt.c (cond_only_block_p): Move function to ...
> * tree-cfg.c (cond_only_block_p): ... here. No longer static.
> * optabs.def (spaceship_optab): New optab.
> * internal-fn.def (SPACESHIP): New internal function.
> * internal-fn.h (expand_SPACESHIP): Declare.
> * internal-fn.c (expand_PHI): Formatting fix.
> (expand_SPACESHIP): New function.
> * tree-ssa-math-opts.c (optimize_spaceship): New function.
> (math_opts_dom_walker::after_dom_children): Use it.
> * config/i386/i386.md (spaceship3): New define_expand.
> * config/i386/i386-protos.h (ix86_expand_fp_spaceship): Declare.
> * config/i386/i386-expand.c (ix86_expand_fp_spaceship): New function.
> * doc/md.texi (spaceship@var{m}3): Document.
>
> * gcc.target/i386/pr103973-1.c: New test.
> * gcc.target/i386/pr103973-2.c: New test.
> * gcc.target/i386/pr103973-3.c: New test.
> * gcc.target/i386/pr103973-4.c: New test.
> * gcc.target/i386/pr103973-5.c: New test.
> * gcc.target/i386/pr103973-6.c: New test.
> * gcc.target/i386/pr103973-7.c: New test.
> * gcc.target/i386/pr103973-8.c: New test.
> * gcc.target/i386/pr103973-9.c: New test.
> * gcc.target/i386/pr103973-10.c: New test.
> * gcc.target/i386/pr103973-11.c: New test.
> * gcc.target/i386/pr103973-12.c: New test.
> * gcc.target/i386/pr103973-13.c: New test.
> * gcc.target/i386/pr103973-14.c: New test.
> * gcc.target/i386/pr103973-15.c: New test.
> * gcc.target/i386/pr103973-16.c: New test.
> * gcc.target/i386/pr103973-17.c: New test.
> * gcc.target/i386/pr103973-18.c: New test.
> * gcc.target/i386/pr103973-19.c: New test.
> * gcc.target/i386/pr103973-20.c: New test.
> * g++.target/i386/pr103973-1.C: New test.
> * g++.target/i386/pr103973-2.C: New test.
> * g++.target/i386/pr103973-3.C: New test.
> * g++.target/i386/pr103973-4.C: New test.
> * g++.target/i386/pr103973-5.C: New test.
> * g++.target/i386/pr103973-6.C: New test.
> * g++.target/i386/pr103973-7.C: New test.
> * g++.target/i386/pr103973-8.C: New test.
> * g++.target/i386/pr103973-9.C: New test.
> * g++.target/i386/pr103973-10.C: New test.
> * g++.target/i386/pr103973-11.C: New test.
> * g++.target/i386/pr103973-12.C: New test.
> * g++.target/i386/pr103973-13.C: New test.
> * g++.target/i386/pr103973-14.C: New
[Patch, fortran] PR64290 - [F03] No finalization at deallocation of LHS
Hi All,
Strictly speaking, the attached patch is branching out into a more
generalised attack on PR37336(Finalization) - [F03] Finish derived-type
finalization but most of it fixes PR64290.
I started work on this patch almost a year ago but had to drop it due
daytime work pressure and only picked it up again a couple of weeks back.
It is not, as yet, complete but I thought to post it in its present form
because stage 3 ended yesterday.
The main thrusts of the patch are:
(i) To correct the order taken by finalization and deallocation of
components for the lhs of assignments. This is done instead by a call to
Tobias' finalization wrapper, rather than performing finalization component
by component in structure_alloc_comps;
(ii) To add finalization of scalar derived type function results, again by
use of the finalization wrapper. This points to a problem that I haven't
yet managed to fix, F2018(7.5.6.3 para 5) "If an executable construct
references a nonpointer function, the result is finalized after execution
of the innermost executable construct containing the reference." I have
been struggling to avoid implementing this by introducing a finalization
block into gfc_se but have run out of ideas as to how to do it otherwise.
(eg. Try using a finalizable function as the actual argument of another
procedure.); and
(iii) Once (ii) is added, a segfault occurs if the derived type has
allocatable, finalizable components. (PR96122) This occurred because the
call to the component finalization wrapper was missing two arguments in the
call; most particularly 'byte_stride'.
There is still quite a lot to do to bring together common code chunks, fix
the ordering requirement of F2018 (7.5.6.3 para 5), add more testcases.
It's certainly not ready to be committed yet :-(
Regards
Paul
Fortran:Implement missing finalization features [PR64290]
2022-01-17 Paul Thomas
gcc/fortran
PR fortran/103854
* class.c (has_finalizer_component): Do not return true for
procedure pointer components.
PR fortran/96087
* class.c (finalize_component): Include the missing arguments
in the call to the component's finalizer wrapper.
PR fortran/64290
* resolve.c (resolve_where, gfc_resolve_where_code_in_forall,
gfc_resolve_forall_body, gfc_resolve_code): Check that the op
code is still EXEC_ASSIGN. If it is set lhs to must finalize.
* trans-array.c (structure_alloc_comps): Add boolean argument
to suppress finalization and use it for calls from
gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to
false.
(gfc_alloc_allocatable_for_assignment): Suppress finalization
by setting new arg in call to gfc_deallocate_alloc_comp_no_caf.
* trans-array.h : Add the new boolean argument to the prototype
of gfc_deallocate_alloc_comp_no_caf with a default of false.
* trans-expr.c (gfc_conv_procedure_call): Call finalizer for
finalizable scalar function results.
(gfc_trans_scalar_assign): Suppress finalization by setting new
argument in call to gfc_deallocate_alloc_comp_no_caf.
(gfc_assignment_finalizer_call): New function to provide
finalization on intrinsic assignment.
(trans_class_assignment, gfc_trans_assignment_1): Call it and
add the block between the rhs evaluation and any reallocation
on assignment that there might be.
gcc/testsuite/
PR fortran/64290
* gfortran.dg/finalize_38.f90 : New test.
* gfortran.dg/allocate_with_source_25.f90 : The number of final
calls goes down from 6 to 4.
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 2cb0c6572bd..18289eaffe8 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -896,7 +896,8 @@ has_finalizer_component (gfc_symbol *derived)
gfc_component *c;
for (c = derived->components; c; c = c->next)
-if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.allocatable)
+if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.allocatable
+ && c->attr.flavor != FL_PROCEDURE)
{
if (c->ts.u.derived->f2k_derived
&& c->ts.u.derived->f2k_derived->finalizers)
@@ -1059,7 +1060,8 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
{
/* Call FINAL_WRAPPER (comp); */
gfc_code *final_wrap;
- gfc_symbol *vtab;
+ gfc_symbol *vtab, *byte_stride;
+ gfc_expr *scalar, *size_expr, *fini_coarray_expr;
gfc_component *c;
vtab = gfc_find_derived_vtab (comp->ts.u.derived);
@@ -1068,12 +1070,54 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
break;
gcc_assert (c);
+
+ /* Set scalar argument for storage_size. */
+ gfc_get_symbol ("comp_byte_stride", sub_ns, _stride);
+ byte_stride->ts = e->ts;
+ byte_stride->attr.flavor = FL_VARIABLE;
+ byte_stride->attr.value = 1;
+ byte_stride->attr.artificial = 1;
+ gfc_set_sym_referenced (byte_stride);
+ gfc_commit_symbol (byte_stride);
+ scalar = gfc_lval_expr_from_sym (byte_stride);
+
final_wrap = gfc_get_code (EXEC_CALL);
final_wrap->symtree =
Re: [Patch][V5][Patch 2/2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables.
On Sat, Jan 15, 2022 at 5:49 PM Qing Zhao wrote: > > Hi, Richard, > > This is the updated version for the change of "Enable -Wuninitialized + > -ftrivial-auto-var-init for address taken variables”. > > Compared to the previous patch, I mainly made the following change: > > Delete the 4th parameter of “warn_uninit”, construct the warning message > string based on the value of OPT and VAR. > > This patch has been bootstrapped and regressing tested on both X86 and > aarch64. > > Okay for GCC12? > > thanks. > > Qing. > > == > Enable -Wuninitialized + -ftrivial-auto-var-init for address > taken variables. > > With -ftrivial-auto-var-init, the address taken auto variable is replaced with > a temporary variable during gimplification, and the original auto variable > might > be eliminated by compiler optimization completely. As a result, the current > uninitialized warning analysis cannot get enough information from the IR, > therefore the uninitialized warnings for address taken variable cannot be > issued based on the current implemenation of -ftrival-auto-var-init. > > For more info please refer to: > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577431.html > > In order to improve this situation, we can improve uninitialized analysis > for address taken auto variables with -ftrivial-auto-var-init as following: > > for the following stmt: > > _1 = .DEFERRED_INIT (4, 2, &"alt_reloc"[0]); > if (_1 != 0) > > The original variable DECL has been eliminated from the IR, all the necessary > information that is needed for reporting the warnings for DECL can be acquired > from the call to .DEFERRED_INIT. > > A. the name string of DECL from the 3rd parameter of the call; > B. the location of the DECL from the location of the call; > C. the call can also be used to hold the information on whether the > warning >has been issued or not to suppress warning messages when needed; > > The current testing cases for uninitialized warnings + -ftrivial-auto-var-init > are adjusted to reflect the fact that we can issue warnings for address taken > variables. OK. Thanks, Richard. > gcc/ChangeLog: > > 2022-01-14 qing zhao > > * tree-ssa-uninit.c (warn_uninit): Delete the 4th parameter. Handle > .DEFERRED_INIT call with an anonymous SSA_NAME specially. > (check_defs): Handle .DEFERRED_INIT call with an anonymous SSA_NAME > specially. > (warn_uninit_phi_uses): Delete the 4th actual when call warn_uninit. > (warn_uninitialized_vars): Likewise. > (warn_uninitialized_phi): Likewise. > > The complete patch is: >
[PATCH][pushed] Include tests that are not executed
The following tests are not executed because they have a bad
filename extension.
Fixed and pushed to master.
MartinFrom 803813918d6e6e02d4ebae6cb72cd8bb69c6133a Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 14 Jan 2022 13:52:50 +0100
Subject: [PATCH 2/2] Make the tests working.
---
gcc/testsuite/g++.dg/uninit-pred-loop-1_b.C | 2 +-
gcc/testsuite/g++.dg/uninit-pred-loop-1_c.C | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/g++.dg/uninit-pred-loop-1_b.C b/gcc/testsuite/g++.dg/uninit-pred-loop-1_b.C
index e4ef3d22c06..b17b9360192 100644
--- a/gcc/testsuite/g++.dg/uninit-pred-loop-1_b.C
+++ b/gcc/testsuite/g++.dg/uninit-pred-loop-1_b.C
@@ -11,7 +11,7 @@ int foo(int n)
_err = bar();
}
_err;
- }); /* { dg-warning "uninitialized" "warn on _err" } */
+ });
if (err == 0) return 17;
}
diff --git a/gcc/testsuite/g++.dg/uninit-pred-loop-1_c.C b/gcc/testsuite/g++.dg/uninit-pred-loop-1_c.C
index 7f6b41d31ff..711812aae1b 100644
--- a/gcc/testsuite/g++.dg/uninit-pred-loop-1_c.C
+++ b/gcc/testsuite/g++.dg/uninit-pred-loop-1_c.C
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-Wuninitialized -O2" } */
+/* { dg-options "-Wuninitialized -O2 -std=c++98" } */
extern int bar();
int foo(int n, int m)
@@ -15,7 +15,7 @@ int foo(int n, int m)
_err;
});
- if (err == 0) return 17; }); /* { dg-warning "uninitialized" "warn on _err" } */
+ if (err == 0) return 17;
}
return 18;
--
2.34.1
From 07ae64665b305758762cc5ddd6775a25fadbdf76 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 14 Jan 2022 13:40:58 +0100
Subject: [PATCH 1/2] Rename test-cases that are not executed.
---
.../g++.dg/{uninit-pred-loop-1_a.cc => uninit-pred-loop-1_a.C}| 0
.../g++.dg/{uninit-pred-loop-1_b.cc => uninit-pred-loop-1_b.C}| 0
.../g++.dg/{uninit-pred-loop-1_c.cc => uninit-pred-loop-1_c.C}| 0
.../g++.dg/{uninit-pred-loop_1.cc => uninit-pred-loop_1.C}| 0
4 files changed, 0 insertions(+), 0 deletions(-)
rename gcc/testsuite/g++.dg/{uninit-pred-loop-1_a.cc => uninit-pred-loop-1_a.C} (100%)
rename gcc/testsuite/g++.dg/{uninit-pred-loop-1_b.cc => uninit-pred-loop-1_b.C} (100%)
rename gcc/testsuite/g++.dg/{uninit-pred-loop-1_c.cc => uninit-pred-loop-1_c.C} (100%)
rename gcc/testsuite/g++.dg/{uninit-pred-loop_1.cc => uninit-pred-loop_1.C} (100%)
diff --git a/gcc/testsuite/g++.dg/uninit-pred-loop-1_a.cc b/gcc/testsuite/g++.dg/uninit-pred-loop-1_a.C
similarity index 100%
rename from gcc/testsuite/g++.dg/uninit-pred-loop-1_a.cc
rename to gcc/testsuite/g++.dg/uninit-pred-loop-1_a.C
diff --git a/gcc/testsuite/g++.dg/uninit-pred-loop-1_b.cc b/gcc/testsuite/g++.dg/uninit-pred-loop-1_b.C
similarity index 100%
rename from gcc/testsuite/g++.dg/uninit-pred-loop-1_b.cc
rename to gcc/testsuite/g++.dg/uninit-pred-loop-1_b.C
diff --git a/gcc/testsuite/g++.dg/uninit-pred-loop-1_c.cc b/gcc/testsuite/g++.dg/uninit-pred-loop-1_c.C
similarity index 100%
rename from gcc/testsuite/g++.dg/uninit-pred-loop-1_c.cc
rename to gcc/testsuite/g++.dg/uninit-pred-loop-1_c.C
diff --git a/gcc/testsuite/g++.dg/uninit-pred-loop_1.cc b/gcc/testsuite/g++.dg/uninit-pred-loop_1.C
similarity index 100%
rename from gcc/testsuite/g++.dg/uninit-pred-loop_1.cc
rename to gcc/testsuite/g++.dg/uninit-pred-loop_1.C
--
2.34.1
[PATCH] vect.exp: Rename .cc files in the folder to .C.
Hi. I would like to unify filenames in testsuite and one of the biggest offenders are vectorizer tests under g++.dg. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/testsuite/ChangeLog: * g++.dg/vect/param-max-aliased-pr26197.cc: Moved to... * g++.dg/vect/param-max-aliased-pr26197.C: ...here. * g++.dg/vect/pr102226.cc: Moved to... * g++.dg/vect/pr102226.C: ...here. * g++.dg/vect/pr102421.cc: Moved to... * g++.dg/vect/pr102421.C: ...here. * g++.dg/vect/pr102572.cc: Moved to... * g++.dg/vect/pr102572.C: ...here. * g++.dg/vect/pr102696.cc: Moved to... * g++.dg/vect/pr102696.C: ...here. * g++.dg/vect/pr102788.cc: Moved to... * g++.dg/vect/pr102788.C: ...here. * g++.dg/vect/pr103494.cc: Moved to... * g++.dg/vect/pr103494.C: ...here. * g++.dg/vect/pr19951.cc: Moved to... * g++.dg/vect/pr19951.C: ...here. * g++.dg/vect/pr21218.cc: Moved to... * g++.dg/vect/pr21218.C: ...here. * g++.dg/vect/pr21734_1.cc: Moved to... * g++.dg/vect/pr21734_1.C: ...here. * g++.dg/vect/pr21734_2.cc: Moved to... * g++.dg/vect/pr21734_2.C: ...here. * g++.dg/vect/pr22543.cc: Moved to... * g++.dg/vect/pr22543.C: ...here. * g++.dg/vect/pr33426-ivdep-2.cc: Moved to... * g++.dg/vect/pr33426-ivdep-2.C: ...here. * g++.dg/vect/pr33426-ivdep-3.cc: Moved to... * g++.dg/vect/pr33426-ivdep-3.C: ...here. * g++.dg/vect/pr33426-ivdep-4.cc: Moved to... * g++.dg/vect/pr33426-ivdep-4.C: ...here. * g++.dg/vect/pr33426-ivdep.cc: Moved to... * g++.dg/vect/pr33426-ivdep.C: ...here. * g++.dg/vect/pr33834_1.cc: Moved to... * g++.dg/vect/pr33834_1.C: ...here. * g++.dg/vect/pr33834_2.cc: Moved to... * g++.dg/vect/pr33834_2.C: ...here. * g++.dg/vect/pr33835.cc: Moved to... * g++.dg/vect/pr33835.C: ...here. * g++.dg/vect/pr33860.cc: Moved to... * g++.dg/vect/pr33860.C: ...here. * g++.dg/vect/pr33860a.cc: Moved to... * g++.dg/vect/pr33860a.C: ...here. * g++.dg/vect/pr36648.cc: Moved to... * g++.dg/vect/pr36648.C: ...here. * g++.dg/vect/pr37174.cc: Moved to... * g++.dg/vect/pr37174.C: ...here. * g++.dg/vect/pr43771.cc: Moved to... * g++.dg/vect/pr43771.C: ...here. * g++.dg/vect/pr44861.cc: Moved to... * g++.dg/vect/pr44861.C: ...here. * g++.dg/vect/pr45470-a.cc: Moved to... * g++.dg/vect/pr45470-a.C: ...here. * g++.dg/vect/pr45470-b.cc: Moved to... * g++.dg/vect/pr45470-b.C: ...here. * g++.dg/vect/pr50698.cc: Moved to... * g++.dg/vect/pr50698.C: ...here. * g++.dg/vect/pr51485.cc: Moved to... * g++.dg/vect/pr51485.C: ...here. * g++.dg/vect/pr58513.cc: Moved to... * g++.dg/vect/pr58513.C: ...here. * g++.dg/vect/pr6.cc: Moved to... * g++.dg/vect/pr6.C: ...here. * g++.dg/vect/pr60023.cc: Moved to... * g++.dg/vect/pr60023.C: ...here. * g++.dg/vect/pr60559.cc: Moved to... * g++.dg/vect/pr60559.C: ...here. * g++.dg/vect/pr60729.cc: Moved to... * g++.dg/vect/pr60729.C: ...here. * g++.dg/vect/pr60836.cc: Moved to... * g++.dg/vect/pr60836.C: ...here. * g++.dg/vect/pr60896.cc: Moved to... * g++.dg/vect/pr60896.C: ...here. * g++.dg/vect/pr61171.cc: Moved to... * g++.dg/vect/pr61171.C: ...here. * g++.dg/vect/pr64410.cc: Moved to... * g++.dg/vect/pr64410.C: ...here. * g++.dg/vect/pr68145.cc: Moved to... * g++.dg/vect/pr68145.C: ...here. * g++.dg/vect/pr68762-1.cc: Moved to... * g++.dg/vect/pr68762-1.C: ...here. * g++.dg/vect/pr68762-2.cc: Moved to... * g++.dg/vect/pr68762-2.C: ...here. * g++.dg/vect/pr70726.cc: Moved to... * g++.dg/vect/pr70726.C: ...here. * g++.dg/vect/pr70729-nest.cc: Moved to... * g++.dg/vect/pr70729-nest.C: ...here. * g++.dg/vect/pr70729.cc: Moved to... * g++.dg/vect/pr70729.C: ...here. * g++.dg/vect/pr70944.cc: Moved to... * g++.dg/vect/pr70944.C: ...here. * g++.dg/vect/pr71483.c: Moved to... * g++.dg/vect/pr71483.C: ...here. * g++.dg/vect/pr84362.cc: Moved to... * g++.dg/vect/pr84362.C: ...here. * g++.dg/vect/pr84556.cc: Moved to... * g++.dg/vect/pr84556.C: ...here. * g++.dg/vect/pr87621.cc: Moved to... * g++.dg/vect/pr87621.C: ...here. * g++.dg/vect/pr87914.cc: Moved to... * g++.dg/vect/pr87914.C: ...here. * g++.dg/vect/pr89653.cc: Moved to... * g++.dg/vect/pr89653.C: ...here. * g++.dg/vect/pr92595.cc: Moved to... * g++.dg/vect/pr92595.C: ...here. *
Re: [PATCH 6/6] libstdc++: Import MSVC floating-point std::from_chars testcases
On Sun, 16 Jan 2022 at 18:17, Patrick Palka via Libstdc++ < libstd...@gcc.gnu.org> wrote: > libstdc++-v3/ChangeLog: > > * testsuite/20_util/from_chars/double.cc: New test, consisting > of testcases extracted from the MSVC STL testsuite. > * testsuite/20_util/from_chars/float.cc: New test. > --- > .../testsuite/20_util/from_chars/double.cc| 1674 + > .../testsuite/20_util/from_chars/float.cc | 290 +++ > 2 files changed, 1964 insertions(+) > create mode 100644 libstdc++-v3/testsuite/20_util/from_chars/double.cc > create mode 100644 libstdc++-v3/testsuite/20_util/from_chars/float.cc > > diff --git a/libstdc++-v3/testsuite/20_util/from_chars/double.cc > b/libstdc++-v3/testsuite/20_util/from_chars/double.cc > new file mode 100644 > index 000..ce53a1c56c2 > --- /dev/null > +++ b/libstdc++-v3/testsuite/20_util/from_chars/double.cc > @@ -0,0 +1,1674 @@ > +// This file consists of testcases extracted from the MSVC STL testsuite. > + > +// Copyright (c) Microsoft Corporation. > +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception > I think we should probably move (or copy) the libstdc++-v3/include/pstl/LICENSE.txt file to another directory, since we have files using this licence in other places too. Please hold off committing this one while I think about that (and remind me if you don't hear back from me with a decision).
[pushed 4/3] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]
I managed to break a working patch by splitting it.
Now fixed.
From d7a44809924297a2ff26b6b1d040c72c22f07346 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Mon, 17 Jan 2022 11:45:46 +0100
Subject: [PATCH] Fortran: Ignore KIND argument of a few more intrinsics.
[PR103789]
After PR97896 for which some code was added to ignore the KIND argument
of the INDEX intrinsics, and PR87711 for which that was extended to LEN_TRIM
as well, this propagates it further to MASKL, MASKR, SCAN and VERIFY.
PR fortran/103789
gcc/fortran/ChangeLog:
* trans-array.c (arg_evaluated_for_scalarization): Add MASKL, MASKR,
SCAN and VERIFY to the list of intrinsics whose KIND argument is to be
ignored.
(cherry picked from commit c1c17a43e172ebc28f2cd247f6e83c5fdbc6219f)
---
gcc/fortran/trans-array.c | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 308213c57e3..dc89e97b0a1 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -11249,6 +11249,10 @@ arg_evaluated_for_scalarization (gfc_intrinsic_sym *function,
{
case GFC_ISYM_INDEX:
case GFC_ISYM_LEN_TRIM:
+ case GFC_ISYM_MASKL:
+ case GFC_ISYM_MASKR:
+ case GFC_ISYM_SCAN:
+ case GFC_ISYM_VERIFY:
if (strcmp ("kind", actual_arg.name) == 0)
return false;
--
2.34.1
Re: [PATCH 5/6] libstdc++: Use fast_float in std::from_chars for binary32/64
On Sun, 16 Jan 2022 at 18:09, Patrick Palka via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This makes our std::from_chars implementation use fast_float for parsing > chars_format::scientific/fixed/general parsing into binary32/64 values. > For other floating-point formats we still use the fallback implementation > that goes through the strtod family of functions. > > libstdc++-v3/ChangeLog: > > * src/c++17/floating_from_chars.cc: (USE_LIB_FAST_FLOAT): > Conditionally define, and use it to conditionally include > fast_float. > (from_chars): Use fast_float for float and double when > USE_LIB_FAST_FLOAT. > > OK for trunk.
Re: [PATCH 4/6] libstdc++: Adjust fast_float's over/underflow behavior for conformnace
On Sun, 16 Jan 2022 at 18:12, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This makes fast_float handle the situation where std::from_chars is
> specified to return result_out_of_range, i.e. when the parsed value
> is outside the representable range of the floating-point type.
>
> This adjusts fast_float's behavior in case of over/underflow: instead of
> returning errc{} and setting value to +-0 or +-infinity, return
> result_out_of_range and don't modify value, as per [charconv.from.chars]/1.
>
> libstdc++-v3/ChangeLog:
>
> * src/c++17/fast_float/LOCAL_PATCHES: Update.
> * src/c++17/fast_float/fast_float.h (from_chars_advanced): In
> case of over/underflow, return errc::result_out_of_range and don't
> modify 'value'.
>
>
Typo in the commit summary line "conformnace".
OK for trunk.
Please report this as an issue to the upstream project, if you didn't
already (and if they haven't documented this as an intentional deviation
from the standard).
Re: [PATCH 3/6] libstdc++: Apply modifications to our local copy of fast_float
On Sun, 16 Jan 2022 at 18:07, Patrick Palka via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This performs the following modifications to our local copy of fast_float > in order to make it more readily usable in our std::from_chars > implementation: > > * Remove system #includes > * Replace stray call to assert > * Use the standard chars_format and from_chars_result types > > libstdc++-v3/ChangeLog: > > * src/c++17/fast_float/LOCAL_PATCHES: Update. > * src/c++17/fast_float/fast_float.h: Apply local modifications. > > OK for trunk.
Re: [PATCH 2/6] libstdc++: Import the fast_float library
On Sun, 16 Jan 2022 at 18:13, Patrick Palka via Libstdc++ < libstd...@gcc.gnu.org> wrote: > We're going to use the fast_float library in our (compiled-in) > floating-point std::from_chars implementation for faster and more > portable parsing of binary32/64 decimal strings. > > The single file fast_float.h is an amalgamation of the entire library, > which can be (re)generated with the command > > python3 ./script/amalgamate.py --license=MIT \ > > $GCC_SRC/libstdc++-v3/c++17/fast_float/fast_float.h > Please mention that the script is in the fast_float repo (so people don't look for it in our repo). Please mention in the commit log that the code has a GPL-compatible licence. > > [1]: https://github.com/fastfloat/fast_float > > libstdc++-v3/ChangeLog: > > * src/c++17/fast_float/LOCAL_PATCHES: New file. > * src/c++17/fast_float/MERGE: New file. > * src/c++17/fast_float/README.fd: New file, copied from the > fast_float library sources. > * src/c++17/fast_float/fast_float.h: New file, an amalgamation > of the fast_float library. > > Signed-off-by: Patrick Palka > This project is great. The licence is compatible, and the licence text and copyright notices are preserved in the code being imported. The entire license text is present in the header, so there is no need for a separate licence file. The symbols that will be added to libstdc++ are not uglified, but the header is included inside an unnamed namespace, so we will not define any non-reserved symbols in libstdc++.a (and they aren't exported from libstdc++.so anyway). OK for trunk.
Re: [PATCH 1/6 v2] libstdc++: Directly implement hexfloat std::from_chars for binary32/64
On Sun, 16 Jan 2022 at 18:07, Patrick Palka via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Series tested on x86_64, i686, ppc64, ppc64le, aarch64, does it look OK for
> trunk?
>
OK, thanks.
> libstdc++-v3/ChangeLog:
>
> * src/c++17/floating_from_chars.cc: Include .
> (ascii_to_hexit, starts_with_ci): Define.
> (__floating_from_chars_hex): Define.
> (from_chars): Conditionally call __floating_from_chars_hex.
> (testsuite/20_util/from_chars/7.cc): New test.
> ---
> libstdc++-v3/src/c++17/floating_from_chars.cc | 376 ++
> .../testsuite/20_util/from_chars/7.cc | 151 +++
> 2 files changed, 527 insertions(+)
> create mode 100644 libstdc++-v3/testsuite/20_util/from_chars/7.cc
>
> diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc
> b/libstdc++-v3/src/c++17/floating_from_chars.cc
> index 479e042bb5f..b186da9a955 100644
> --- a/libstdc++-v3/src/c++17/floating_from_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
> @@ -31,6 +31,7 @@
> #define _GLIBCXX_USE_CXX11_ABI 1
>
> #include
> +#include
> #include
> #include
> #include
> @@ -396,6 +397,371 @@ namespace
>}
> #endif
>
> +#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
> + // If the given ASCII character represents a hexit, return that hexit.
> + // Otherwise return -1.
> + int
> + ascii_to_hexit(char ch)
> + {
> +if (ch >= '0' && ch <= '9')
> + return ch - '0';
> +if (ch >= 'a' && ch <= 'f')
> + return ch - 'a' + 10;
> +if (ch >= 'A' && ch <= 'F')
> + return ch - 'A' + 10;
> +return -1;
> + }
> +
> + // Return true iff [FIRST,LAST) begins with PREFIX, ignoring case.
> + bool
> + starts_with_ci(const char* first, const char* last, string_view prefix)
> + {
> +__glibcxx_requires_valid_range(first, last);
> +
> +for (char ch : prefix)
> + {
> + __glibcxx_assert(ch >= 'a' && ch <= 'z');
> + if (first == last || (*first != ch && *first != ch - 32))
> + return false;
> + ++first;
> + }
> +
> +return true;
> + }
> +
> + // An implementation of hexadecimal float parsing for binary32/64.
> + template
> + from_chars_result
> + __floating_from_chars_hex(const char* first, const char* last, T& value)
> + {
> +static_assert(is_same_v || is_same_v);
> +
> +using uint_t = conditional_t, uint32_t, uint64_t>;
> +constexpr int mantissa_width = is_same_v ? 23 : 52;
> +constexpr int exponent_width = is_same_v ? 8 : 11;
> +constexpr int exponent_bias = (1 << (exponent_width - 1)) - 1;
> +
> +__glibcxx_requires_valid_range(first, last);
> +if (first == last)
> + return {first, errc::invalid_argument};
> +
> +// Consume the sign bit.
> +const char* const orig_first = first;
> +bool sign_bit = false;
> +if (*first == '-')
> + {
> + sign_bit = true;
> + ++first;
> + }
> +
> +// Handle "inf", "infinity", "NaN" and variants thereof.
> +if (first != last)
> + if (*first == 'i' || *first == 'I' || *first == 'n' || *first ==
> 'N') [[unlikely]]
> + {
> + if (starts_with_ci(first, last, "inf"sv))
> + {
> + first += 3;
> + if (starts_with_ci(first, last, "inity"sv))
> + first += 5;
> +
> + uint_t result = 0;
> + result |= sign_bit;
> + result <<= exponent_width;
> + result |= (1ull << exponent_width) - 1;
> + result <<= mantissa_width;
> + memcpy(, , sizeof(result));
> +
> + return {first, errc{}};
> + }
> + else if (starts_with_ci(first, last, "nan"))
> + {
> + first += 3;
> +
> + if (first != last && *first == '(')
> + {
> + // Tentatively consume the '(' as we look for an optional
> + // n-char-sequence followed by a ')'.
> + const char* const fallback_first = first;
> + for (;;)
> + {
> + ++first;
> + if (first == last)
> + {
> + first = fallback_first;
> + break;
> + }
> +
> + char ch = *first;
> + if (ch == ')')
> + {
> + ++first;
> + break;
> + }
> + else if ((ch >= '0' && ch <= '9')
> + || (ch >= 'a' && ch <= 'z')
> + || (ch >= 'A' && ch <= 'Z')
> + || ch == '_')
> + continue;
> + else
> + {
> + first = fallback_first;
> + break;
> + }
> + }
> + }
> +
> +
[PATCH][pushed] Add check_effective_target_pytest3.
Hi.
The patch is about factoring out a function similar to
check_effective_target_python3.
Cheers,
Martin
gcc/testsuite/ChangeLog:
* lib/gcov.exp: Use check_effective_target_pytest3.
* lib/target-supports.exp: Add check_effective_target_pytest3.
---
gcc/testsuite/lib/gcov.exp| 9 -
gcc/testsuite/lib/target-supports.exp | 12
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/lib/gcov.exp b/gcc/testsuite/lib/gcov.exp
index dfa1b3686ab..6c57515e229 100644
--- a/gcc/testsuite/lib/gcov.exp
+++ b/gcc/testsuite/lib/gcov.exp
@@ -17,6 +17,8 @@
# Verify various kinds of gcov output: line counts, branch percentages,
# and call return percentages. None of this is language-specific.
+load_lib "target-supports.exp"
+
global GCOV
#
@@ -274,11 +276,8 @@ proc run-gcov-pytest { args } {
set testcase [remote_download host $testcase]
set result [remote_exec host $GCOV "$testcase -i"]
-set pytest_cmd "python3 -m pytest --color=no -rap -s --tb=no"
-set result [remote_exec host "$pytest_cmd --version"]
-set status [lindex $result 0]
-if { $status != 0 } then {
- unsupported "$subdir/$testcase run-gcov-pytest python3 pytest missing"
+if { ![check_effective_target_pytest3] } {
+ unsupported "$script pytest python3 is missing"
return
}
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 12c5ca5da33..fd48475a57c 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -11734,3 +11734,15 @@ proc check_effective_target_python3 { } {
return 0;
}
}
+
+# Return 1 if pytest module is available for python3.
+
+proc check_effective_target_pytest3 { } {
+set result [remote_exec host "python3 -m pytest --color=no -rap -s --tb=no
--version"]
+set status [lindex $result 0]
+if { $status == 0 } then {
+return 1;
+} else {
+return 0;
+}
+}
--
2.34.1
Re: [PATCH] libstdc++: Don't fail if math_errhandling is not defined
On Mon, 17 Jan 2022 at 10:22, Matthias Kretz wrote: > Tested on x86_64-linux and powerpc64le-linux. This fixes the > powerpc64le-linux > failure Jonathan reported. OK for trunk? > OK, thanks. > > Older glibc does not define math_errhandling with -ffast-math, in which > case floating-point exceptions are not used. > > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > * include/experimental/bits/simd.h (__floating_point_flags): Do > not rely on the presence of the math_errhandling macro. > --- > libstdc++-v3/include/experimental/bits/simd.h | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > > -- > ── > Dr. Matthias Kretz https://mattkretz.github.io > GSI Helmholtz Centre for Heavy Ion Research https://gsi.de > stdₓ::simd > ──
Re: [PATCH] Start using check-MAINTAINERS.py instead of legacy maintainers-verify.sh.
On 1/14/22 10:28, Martin Liška wrote: Ready to be installed? There's no reply, I'm going to push it. The current script is broken anyway. Cheers, Martin
[PATCH] libstdc++: Don't fail if math_errhandling is not defined
Tested on x86_64-linux and powerpc64le-linux. This fixes the powerpc64le-linux
failure Jonathan reported. OK for trunk?
Older glibc does not define math_errhandling with -ffast-math, in which
case floating-point exceptions are not used.
Signed-off-by: Matthias Kretz
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h (__floating_point_flags): Do
not rely on the presence of the math_errhandling macro.
---
libstdc++-v3/include/experimental/bits/simd.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
──
Dr. Matthias Kretz https://mattkretz.github.io
GSI Helmholtz Centre for Heavy Ion Research https://gsi.de
stdₓ::simd
──diff --git a/libstdc++-v3/include/experimental/bits/simd.h b/libstdc++-v3/include/experimental/bits/simd.h
index d837d0efb21..c991e3f223e 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -283,11 +283,20 @@ constexpr inline bool __have_power_vmx = __have_power_vsx;
namespace __detail
{
+ constexpr bool __handle_fpexcept =
+#ifdef math_errhandling
+math_errhandling & MATH_ERREXCEPT;
+#elif defined __FAST_MATH__
+false;
+#else
+true;
+#endif
+
constexpr std::uint_least64_t
__floating_point_flags()
{
std::uint_least64_t __flags = 0;
-if constexpr (math_errhandling & MATH_ERREXCEPT)
+if constexpr (__handle_fpexcept)
__flags |= 1;
#ifdef __FAST_MATH__
__flags |= 1 << 1;
Re: [r12-6585 Regression] FAIL: c-c++-common/Walloca-larger-than.c -Wc++-compat (test for excess errors) on Linux/x86_64
On 1/15/22 14:15, sunil.k.pandey wrote:
On Linux/x86_64,
d8b64476138671f3d89cd66f224a9b59e465631b is the first bad commit
commit d8b64476138671f3d89cd66f224a9b59e465631b
Author: Martin Liska
Date: Fri Jan 14 15:04:33 2022 +0100
testsuite: rename files in c-c++-common.
caused
FAIL: c-c++-common/Walloca-larger-than.c -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/Walloca-larger-than.c -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/Walloca-larger-than.c -std=gnu++2a (test for excess errors)
FAIL: c-c++-common/Walloca-larger-than.c -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/Walloca-larger-than.c -Wc++-compat (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-6585/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Walloca-larger-than.c --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Walloca-larger-than.c --target_board='unix{-m32\
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Walloca-larger-than.c --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="dg.exp=c-c++-common/Walloca-larger-than.c --target_board='unix{-m64\
-march=cascadelake}'"
Should be fixed on master.
Martin
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[PATCH][pushed] Fix test warnings.
PR testsuite/104035
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr57993-2.C: Fix warnings.
---
gcc/testsuite/g++.dg/torture/pr57993-2.C | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/gcc/testsuite/g++.dg/torture/pr57993-2.C
b/gcc/testsuite/g++.dg/torture/pr57993-2.C
index b7bffa89e41..529b5a9e59d 100644
--- a/gcc/testsuite/g++.dg/torture/pr57993-2.C
+++ b/gcc/testsuite/g++.dg/torture/pr57993-2.C
@@ -1,5 +1,7 @@
/* This ICEd due to an incomplete fix for PR57993. */
/* { dg-do compile } */
+/* { dg-additional-options "-Wno-return-type" } */
+
extern "C"
{
@@ -118,21 +120,21 @@ extern "C"
Stats;
static int All_Bicubic_Patch_Intersections (OBJECT * Object, RAY * Ray,
ISTACK * Depth_Stack);
- static int Inside_Bicubic_Patch (VECTOR IPoint, OBJECT * Object);
+ static int Inside_Bicubic_Patch (VECTOR IPoint, OBJECT * Object) { return 0;
}
static void Bicubic_Patch_Normal (VECTOR Result, OBJECT * Object,
- INTERSECTION * Inter);
+ INTERSECTION * Inter) {}
static void Bicubic_Patch_UVCoord (UV_VECT Result, OBJECT * Object,
-INTERSECTION * Inter);
- static BICUBIC_PATCH *Copy_Bicubic_Patch (OBJECT * Object);
+INTERSECTION * Inter) {}
+ static BICUBIC_PATCH *Copy_Bicubic_Patch (OBJECT * Object) { return 0; }
static void Translate_Bicubic_Patch (OBJECT * Object, VECTOR Vector,
- TRANSFORM * Trans);
+ TRANSFORM * Trans) {}
static void Rotate_Bicubic_Patch (OBJECT * Object, VECTOR Vector,
- TRANSFORM * Trans);
+ TRANSFORM * Trans) {}
static void Scale_Bicubic_Patch (OBJECT * Object, VECTOR Vector,
- TRANSFORM * Trans);
- static void Transform_Bicubic_Patch (OBJECT * Object, TRANSFORM * Trans);
- static void Invert_Bicubic_Patch (OBJECT * Object);
- static void Destroy_Bicubic_Patch (OBJECT * Object);
+ TRANSFORM * Trans) {}
+ static void Transform_Bicubic_Patch (OBJECT * Object, TRANSFORM * Trans) {}
+ static void Invert_Bicubic_Patch (OBJECT * Object) {}
+ static void Destroy_Bicubic_Patch (OBJECT * Object) {}
static METHODS Bicubic_Patch_Methods = {
All_Bicubic_Patch_Intersections, Inside_Bicubic_Patch,
Bicubic_Patch_Normal, Bicubic_Patch_UVCoord,
--
2.34.1
[PATCH][pushed] Fix test warnings.
PR testsuite/104035
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr57993-2.C: Fix warnings.
---
gcc/testsuite/g++.dg/torture/pr57993-2.C | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/gcc/testsuite/g++.dg/torture/pr57993-2.C
b/gcc/testsuite/g++.dg/torture/pr57993-2.C
index b7bffa89e41..529b5a9e59d 100644
--- a/gcc/testsuite/g++.dg/torture/pr57993-2.C
+++ b/gcc/testsuite/g++.dg/torture/pr57993-2.C
@@ -1,5 +1,7 @@
/* This ICEd due to an incomplete fix for PR57993. */
/* { dg-do compile } */
+/* { dg-additional-options "-Wno-return-type" } */
+
extern "C"
{
@@ -118,21 +120,21 @@ extern "C"
Stats;
static int All_Bicubic_Patch_Intersections (OBJECT * Object, RAY * Ray,
ISTACK * Depth_Stack);
- static int Inside_Bicubic_Patch (VECTOR IPoint, OBJECT * Object);
+ static int Inside_Bicubic_Patch (VECTOR IPoint, OBJECT * Object) { return 0;
}
static void Bicubic_Patch_Normal (VECTOR Result, OBJECT * Object,
- INTERSECTION * Inter);
+ INTERSECTION * Inter) {}
static void Bicubic_Patch_UVCoord (UV_VECT Result, OBJECT * Object,
-INTERSECTION * Inter);
- static BICUBIC_PATCH *Copy_Bicubic_Patch (OBJECT * Object);
+INTERSECTION * Inter) {}
+ static BICUBIC_PATCH *Copy_Bicubic_Patch (OBJECT * Object) { return 0; }
static void Translate_Bicubic_Patch (OBJECT * Object, VECTOR Vector,
- TRANSFORM * Trans);
+ TRANSFORM * Trans) {}
static void Rotate_Bicubic_Patch (OBJECT * Object, VECTOR Vector,
- TRANSFORM * Trans);
+ TRANSFORM * Trans) {}
static void Scale_Bicubic_Patch (OBJECT * Object, VECTOR Vector,
- TRANSFORM * Trans);
- static void Transform_Bicubic_Patch (OBJECT * Object, TRANSFORM * Trans);
- static void Invert_Bicubic_Patch (OBJECT * Object);
- static void Destroy_Bicubic_Patch (OBJECT * Object);
+ TRANSFORM * Trans) {}
+ static void Transform_Bicubic_Patch (OBJECT * Object, TRANSFORM * Trans) {}
+ static void Invert_Bicubic_Patch (OBJECT * Object) {}
+ static void Destroy_Bicubic_Patch (OBJECT * Object) {}
static METHODS Bicubic_Patch_Methods = {
All_Bicubic_Patch_Intersections, Inside_Bicubic_Patch,
Bicubic_Patch_Normal, Bicubic_Patch_UVCoord,
--
2.34.1
Re: [PATCH] libstdc++: Implement C++20 atomic and atomic
On Mon, 17 Jan 2022 at 09:39, Stephan Bergmann wrote:
> On 1/17/22 01:12, Jonathan Wakely via Libstdc++ wrote:
> > Here's the finished version of that patch, which is all inline in the
> > header, and performs faster too.
> >
> > Tested powerpc64le-linux and x86_64-linux.
> > Pushed to trunk.
>
> FYI, recent Clang still requires typename in two places to compile
> with -std=c++20,
>
> > diff --git a/libstdc++-v3/include/bits/shared_ptr_atomic.h
> b/libstdc++-v3/include/bits/shared_ptr_atomic.h
> > index 900499bae32..50aa46370ca 100644
> > --- a/libstdc++-v3/include/bits/shared_ptr_atomic.h
> > +++ b/libstdc++-v3/include/bits/shared_ptr_atomic.h
> > @@ -456,8 +456,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >typename _Tp::element_type* _M_ptr;
> >_Atomic_count _M_refcount;
> >
> > - static _Atomic_count::pointer
> > - _S_add_ref(_Atomic_count::pointer __p)
> > + static typename _Atomic_count::pointer
> > + _S_add_ref(typename _Atomic_count::pointer __p)
> >{
> > if (__p)
> > {
>
Sigh, yes, I already noticed this myself. Clang is wrong (P0634R0 gives an
example *very* similar to this as motivation for the change), but we need
to keep writing the code in C++17 style if we want to be compatible with
released versions of Clang.
Fixed by the attached patch, tested x86_64-linux and pushed to trunk.
commit a923345c72aef9ebb6b32f81f4825acc11085803
Author: Jonathan Wakely
Date: Mon Jan 17 09:42:35 2022
libstdc++: Add 'typename' to dependent types in atomic>
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h (_Sp_atomic): Add typename
to qualified-id for dependent type.
diff --git a/libstdc++-v3/include/bits/shared_ptr_atomic.h
b/libstdc++-v3/include/bits/shared_ptr_atomic.h
index 900499bae32..50aa46370ca 100644
--- a/libstdc++-v3/include/bits/shared_ptr_atomic.h
+++ b/libstdc++-v3/include/bits/shared_ptr_atomic.h
@@ -456,8 +456,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typename _Tp::element_type* _M_ptr;
_Atomic_count _M_refcount;
- static _Atomic_count::pointer
- _S_add_ref(_Atomic_count::pointer __p)
+ static typename _Atomic_count::pointer
+ _S_add_ref(typename _Atomic_count::pointer __p)
{
if (__p)
{
Re: [PATCH] libstdc++: Implement C++20 atomic and atomic
On 1/17/22 01:12, Jonathan Wakely via Libstdc++ wrote:
Here's the finished version of that patch, which is all inline in the
header, and performs faster too.
Tested powerpc64le-linux and x86_64-linux.
Pushed to trunk.
FYI, recent Clang still requires typename in two places to compile
with -std=c++20,
diff --git a/libstdc++-v3/include/bits/shared_ptr_atomic.h
b/libstdc++-v3/include/bits/shared_ptr_atomic.h
index 900499bae32..50aa46370ca 100644
--- a/libstdc++-v3/include/bits/shared_ptr_atomic.h
+++ b/libstdc++-v3/include/bits/shared_ptr_atomic.h
@@ -456,8 +456,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typename _Tp::element_type* _M_ptr;
_Atomic_count _M_refcount;
- static _Atomic_count::pointer
- _S_add_ref(_Atomic_count::pointer __p)
+ static typename _Atomic_count::pointer
+ _S_add_ref(typename _Atomic_count::pointer __p)
{
if (__p)
{
[PATCH] c++: Fix cp_genericize_target_expr for TARGET_EXPRs created for global initialization [PR104031]
Hi!
The following patch is miscompiled, cp_genericize_target_expr expects
that for the constant part split_nonconstant_init will emit an INIT_EXPR
that will initialize it, but that doesn't happen and instead we get
DECL_INITIAL on the TARGET_EXPR_SLOT that isn't initialized anywhere
in the IL.
The problem is that the TARGET_EXPR has been created while
current_function_decl was NULL, it is inside a global var initializer.
That means the build_local_temp created VAR_DECL has NULL DECL_CONTEXT.
Later on when genericizing the ssdf (current_function_decl is already
non-NULL), the new cp_genericize_target_expr is called and during
split_nonconstant_init it checks is_local_temp, but that due to the NULL
DECL_CONTEXT returns false. DECL_CONTEXT is set only later on during
gimplification.
The following patch fixes it by setting DECL_CONTEXT also inside of
cp_genericize_target_expr, which fixes the testcase. But if there are
better spots to do that, please let me know...
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-01-17 Jakub Jelinek
PR c++/104031
* cp-gimplify.c (cp_genericize_target_expr): Set DECL_CONTEXT of
TARGET_EXPR_SLOT to current_function_decl if it was NULL.
* g++.dg/cpp1y/pr104031.C: New test.
--- gcc/cp/cp-gimplify.c.jj 2022-01-14 12:09:13.003250834 +0100
+++ gcc/cp/cp-gimplify.c2022-01-16 21:34:52.300937996 +0100
@@ -930,6 +930,11 @@ cp_genericize_init_expr (tree *stmt_p)
static void
cp_genericize_target_expr (tree *stmt_p)
{
+ /* If TARGET_EXPR is created for some global var initializer, the slot
+ will have NULL and so is_local_temp will return false for it. If
+ this is a ssdf, set DECL_CONTEXT now. */
+ if (DECL_CONTEXT (TARGET_EXPR_SLOT (*stmt_p)) == NULL_TREE)
+DECL_CONTEXT (TARGET_EXPR_SLOT (*stmt_p)) = current_function_decl;
cp_genericize_init (_EXPR_INITIAL (*stmt_p),
TARGET_EXPR_INITIAL (*stmt_p),
TARGET_EXPR_SLOT (*stmt_p));
--- gcc/testsuite/g++.dg/cpp1y/pr104031.C.jj2022-01-16 21:30:14.977838079
+0100
+++ gcc/testsuite/g++.dg/cpp1y/pr104031.C 2022-01-16 21:30:46.028401294
+0100
@@ -0,0 +1,23 @@
+// PR c++/104031
+// { dg-do run { target c++14 } }
+// { dg-options "-O2" }
+
+struct A {
+ A () {}
+ ~A () {}
+};
+struct B {
+ A a;
+ int b = 0;
+};
+struct C
+{
+ [[gnu::noipa]]
+ C (B x) { if (x.b != 42) __builtin_abort (); }
+};
+static C c ({ .a = A{}, .b = 42 });
+
+int
+main ()
+{
+}
Jakub
Re: Ping Re: [PATCH] middle-end: move initialization of stack_limit_rtx [PR103163]
On Mon, Jan 17, 2022 at 4:15 AM Sandra Loosemore wrote: > > On 1/8/22 9:24 PM, Sandra Loosemore wrote: > > This patch fixes the ICE I reported in PR103163. We were initializing > > stack_limit_rtx before the register properties it depends on were > > getting set. I moved it to the same function where stack_pointer_rtx, > > frame_pointer_rtx, etc are being initialized. > > > > Besides nios2 where I observed it, this bug was also reported to affect > > powerpc. Anybody want to check it there? Otherwise, OK to check in? > > Ping? > > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587958.html This move will now also re-initialize the pointer during target_reinit (), is that desired and correct? Richard. > -Sandra
Extend test cases for references in OpenACC 'private' clauses (was: Test cases for references in OpenACC 'private' clauses)
Hi!
On 2022-01-17T09:01:54+0100, I wrote:
> I've now pushed to master branch in
> commit fbb438808e9b53a6e6b179a5787d609443acaad6
> "Test cases for references in OpenACC 'private' clauses", see attached.
... extended by commit b75aab194e3fe40b594d9a70eb7068dc9950bcf0
"Extend test cases for references in OpenACC 'private' clauses",
see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From b75aab194e3fe40b594d9a70eb7068dc9950bcf0 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Tue, 24 Aug 2021 18:33:04 +0200
Subject: [PATCH] Extend test cases for references in OpenACC 'private' clauses
libgomp/
* testsuite/libgomp.oacc-c++/privatized-ref-2.C: Extend.
* testsuite/libgomp.oacc-c++/privatized-ref-3.C: Likewise.
* testsuite/libgomp.oacc-fortran/privatized-ref-1.f95: Likewise.
---
.../libgomp.oacc-c++/privatized-ref-2.C | 128 +-
.../libgomp.oacc-c++/privatized-ref-3.C | 159 +-
.../libgomp.oacc-fortran/privatized-ref-1.f95 | 99 ++-
3 files changed, 364 insertions(+), 22 deletions(-)
diff --git a/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C b/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C
index 7091091cac2..520016ab59d 100644
--- a/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C
+++ b/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C
@@ -1,20 +1,87 @@
/* { dg-do run } */
+/* { dg-additional-options "-fopt-info-note-omp" }
+ { dg-additional-options "-foffload=-fopt-info-note-omp" } */
+
+/* { dg-additional-options "--param=openacc-privatization=noisy" }
+ { dg-additional-options "-foffload=--param=openacc-privatization=noisy" } */
+
+/* { dg-additional-options "-Wuninitialized" } */
+
+/* It's only with Tcl 8.5 (released in 2007) that "the variable 'varName'
+ passed to 'incr' may be unset, and in that case, it will be set to [...]",
+ so to maintain compatibility with earlier Tcl releases, we manually
+ initialize counter variables:
+ { dg-line l_dummy[variable c_compute 0 c_loop 0] }
+ { dg-message "dummy" "" { target iN-VAl-Id } l_dummy } to avoid
+ "WARNING: dg-line var l_dummy defined, but not used". */
+
#include
+void gangs (void)
+{
+ double res[65536];
+ int i;
+
+#pragma acc parallel copyout(res) num_gangs(64) /* { dg-line l_compute[incr c_compute] } */
+ /* { dg-note {variable 'i' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_compute$c_compute } */
+ /* { dg-note {variable 'j' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_compute$c_compute } */
+ {
+int i, j;
+#pragma acc loop collapse(2) gang /* { dg-line l_loop[incr c_loop] } */
+/* { dg-note {variable 'j' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop } */
+/* { dg-note {variable 'i' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop } */
+/* { dg-note {variable 'tmpvar' declared in block is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
+ But, with optimizations enabled, per the '*.ssa' dump ('gcc/tree-ssa.c:execute_update_addresses_taken'):
+ No longer having address taken: tmpvar
+ Now a gimple register: tmpvar
+ However, 'tmpvar' remains in the candidate set:
+ { dg-note {variable 'tmpvar' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
+ Now, for GCN offloading, 'adjust_private_decl' does the privatization change right away:
+ { dg-note {variable 'tmpvar' adjusted for OpenACC privatization level: 'gang'} "" { target openacc_radeon_accel_selected } l_loop$c_loop }
+ For nvptx offloading however, we first mark up 'tmpvar', and then later apply the privatization change -- or, with optimizations enabled, don't, because we then don't actually call 'expand_var_decl'.
+ { dg-note {variable 'tmpvar' adjusted for OpenACC privatization level: 'gang'} "" { target { openacc_nvidia_accel_selected && { ! __OPTIMIZE__ } } } l_loop$c_loop }
+ { dg-bogus {note: variable 'tmpvar' adjusted for OpenACC privatization level: 'gang'} "" { target { openacc_nvidia_accel_selected && __OPTIMIZE__ } } l_loop$c_loop }
+ */
+/* { dg-note {variable 'tmpref' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop } */
+for (i = 0; i < 256; i++)
+ {
+ for (j = 0; j < 256; j++)
+ {
+ int tmpvar;
+ int = tmpvar;
+ tmpref = (i * 256 + j) * 97;
+ res[i
Test cases for references in OpenACC 'private' clauses
Hi!
On 2019-09-20T14:17:33-0700, Julian Brown wrote:
> This patch ['Handle references in OpenACC "private" clauses'] [...]
..., and its prerequisite changes, in particular...
> [...] is intended as a somewhat temporary solution: it works for the
> newly-included tests, but is not very elegant.
..., and breaks other things, as discussed internally a while ago.
This will have to be done differently/analyzed in more detail.
The test cases however, amend with:
#pragma acc parallel copyout(res) num_gangs(64) num_workers(64)
+ /* { dg-warning "using num_workers \\(32\\), ignoring 64" "" { target
openacc_nvidia_accel_selected } .-1 } */
... etc., and 'libgomp.oacc-c++/privatized-ref-3.C',
'libgomp.oacc-fortran/privatized-ref-1.f95' with:
+/*TODO
+ { dg-xfail-run-if TODO { openacc_radeon_accel_selected && { !
__OPTIMIZE__ } } } */
... I've now pushed to master branch in
commit fbb438808e9b53a6e6b179a5787d609443acaad6
"Test cases for references in OpenACC 'private' clauses", see attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From fbb438808e9b53a6e6b179a5787d609443acaad6 Mon Sep 17 00:00:00 2001
From: Julian Brown
Date: Fri, 20 Sep 2019 13:53:10 -0700
Subject: [PATCH] Test cases for references in OpenACC 'private' clauses
libgomp/
* testsuite/libgomp.oacc-fortran/privatized-ref-1.f95: New test.
* testsuite/libgomp.oacc-c++/privatized-ref-2.C: New test.
* testsuite/libgomp.oacc-c++/privatized-ref-3.C: New test.
Co-authored-by: Thomas Schwinge
---
.../libgomp.oacc-c++/privatized-ref-2.C | 66
.../libgomp.oacc-c++/privatized-ref-3.C | 69 +
.../libgomp.oacc-fortran/privatized-ref-1.f95 | 76 +++
3 files changed, 211 insertions(+)
create mode 100644 libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C
create mode 100644 libgomp/testsuite/libgomp.oacc-c++/privatized-ref-3.C
create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-1.f95
diff --git a/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C b/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C
new file mode 100644
index 000..7091091cac2
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-2.C
@@ -0,0 +1,66 @@
+/* { dg-do run } */
+
+#include
+
+void workers (void)
+{
+ double res[65536];
+ int i;
+
+#pragma acc parallel copyout(res) num_gangs(64) num_workers(64)
+ /* { dg-warning "using num_workers \\(32\\), ignoring 64" "" { target openacc_nvidia_accel_selected } .-1 } */
+ {
+int i, j;
+#pragma acc loop gang
+for (i = 0; i < 256; i++)
+ {
+#pragma acc loop worker
+ for (j = 0; j < 256; j++)
+ {
+ int tmpvar;
+ int = tmpvar;
+ tmpref = (i * 256 + j) * 99;
+ res[i * 256 + j] = tmpref;
+ }
+ }
+ }
+
+ for (i = 0; i < 65536; i++)
+if (res[i] != i * 99)
+ abort ();
+}
+
+void vectors (void)
+{
+ double res[65536];
+ int i;
+
+#pragma acc parallel copyout(res) num_gangs(64) num_workers(64)
+ /* { dg-warning "using num_workers \\(32\\), ignoring 64" "" { target openacc_nvidia_accel_selected } .-1 } */
+ {
+int i, j;
+#pragma acc loop gang worker
+for (i = 0; i < 256; i++)
+ {
+#pragma acc loop vector
+ for (j = 0; j < 256; j++)
+ {
+ int tmpvar;
+ int = tmpvar;
+ tmpref = (i * 256 + j) * 101;
+ res[i * 256 + j] = tmpref;
+ }
+ }
+ }
+
+ for (i = 0; i < 65536; i++)
+if (res[i] != i * 101)
+ abort ();
+}
+
+int main (int argc, char *argv[])
+{
+ workers ();
+ vectors ();
+ return 0;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-3.C b/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-3.C
new file mode 100644
index 000..478876e3596
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c++/privatized-ref-3.C
@@ -0,0 +1,69 @@
+/* { dg-do run } */
+
+/*TODO
+ { dg-xfail-run-if TODO { openacc_radeon_accel_selected && { ! __OPTIMIZE__ } } } */
+
+#include
+
+void workers (void)
+{
+ double res[65536];
+ int i;
+
+#pragma acc parallel copyout(res) num_gangs(64) num_workers(64)
+ /* { dg-warning "using num_workers \\(32\\), ignoring 64" "" { target openacc_nvidia_accel_selected } .-1 } */
+ {
+int i, j;
+int tmpvar;
+int = tmpvar;
+#pragma acc loop gang
+for (i = 0; i < 256; i++)
+ {
+#pragma acc loop worker private(tmpref)
+ for (j = 0; j < 256; j++)
+ {
+ tmpref = (i * 256 + j) * 99;
+ res[i * 256 + j] = tmpref;
+ }
+ }
+ }
+
+ for (i = 0; i < 65536; i++)
+if (res[i] != i * 99)
+ abort ();
+}
+
+void vectors (void)
+{
+ double res[65536];
+ int i;
+
+#pragma acc parallel copyout(res) num_gangs(64) num_workers(64)
+ /* { dg-warning "using num_workers \\(32\\), ignoring 64" "" { target
