Re: [PATCH] configure: respect --with-build-time-tools [PR43301]
Hello, Eric,
Thanks for looking into this.
On Aug 1, 2022, Eric Gallager via Gcc-patches wrote:
>> This just reassigns the value that was retrieved a couple of lines
>> above from the very same variable.
> Oh, ok, so I guess this isn't necessary after all?
Yeah, I don't see how this patch could make any difference as to the
reported problem.
> In which case we can just close 43301 as INVALID then?
AFAICT, with_build_time_tools is dealt with in the top level configure,
setting up *_FOR_TARGET after searching for the tool names in the
specified location.
However, there's a potentially confusing consequence of the current
code: gcc/configure looks for ./as$build_exeext in the build tree, and
uses that without overwriting it if found, so if an earlier configure
run created an 'as' script, a reconfigure will just use it, without
creating the file again, even if it would have changed
ORIGINAL_AS_FOR_TARGET in it.
I suppose if the patch was tested by the original submitter on a clean
build tree, so it would *appear* to have made a difference in fixing the
problem, while it was actually just a no-op, and the apparent fix was a
consequence of the clean build tree.
So, the patch is not useful, but we may want to avoid the confusing
scenario somehow.
I suppose the point of not creating such a tiny script again is not to
avoid unnecessary rebuilding of dependencies (I don't even see how
dependencies on the script would come into play), so creating it again
wouldn't hurt. However, we wish to avoid overwriting an assembler
copied into the build tree for use by gcc during the build. Perhaps:
-elif test -x as$build_exeext; then
+elif test -x as$build_exeext \
+ && { test "x$build_exeext" != "x" \
+|| test "x`grep '^# Invoke as, ld or nm from the build tree' \
+ as`" = "x"; }; then
WDYT?
--
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about
[committed] c: improvements to address space diagnostics
This adds a clarifying "note" to address space mismatch diagnostics.
For example, it improves the diagnostic for
gcc.target/i386/addr-space-typeck-2.c from:
addr-space-typeck-2.c: In function 'test_bad_call':
addr-space-typeck-2.c:12:22: error: passing argument 2 of 'expects_seg_gs'
from pointer to non-enclosed address space
12 | expects_seg_gs (0, ptr, 1);
| ^~~
to:
addr-space-typeck-2.c: In function 'test_bad_call':
addr-space-typeck-2.c:12:22: error: passing argument 2 of 'expects_seg_gs'
from pointer to non-enclosed address space
12 | expects_seg_gs (0, ptr, 1);
| ^~~
addr-space-typeck-2.c:7:51: note: expected '__seg_gs void *' but argument
is of type 'void *'
7 | extern void expects_seg_gs (int i, void __seg_gs *param, int j);
|~~~^
I took the liberty of adding the test coverage to i386 since we need
a specific target to test this on.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1922-ge8bc6918b31e63.
gcc/c/ChangeLog:
* c-typeck.cc (build_c_cast): Quote names of address spaces in
diagnostics.
(convert_for_assignment): Add a note to address space mismatch
diagnostics, specifying the expected and actual types.
gcc/testsuite/ChangeLog:
* gcc.target/i386/addr-space-typeck-1.c: New test.
* gcc.target/i386/addr-space-typeck-2.c: New test.
Signed-off-by: David Malcolm
---
gcc/c/c-typeck.cc | 27 +--
.../gcc.target/i386/addr-space-typeck-1.c | 22 +++
.../gcc.target/i386/addr-space-typeck-2.c | 25 +
3 files changed, 66 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/addr-space-typeck-1.c
create mode 100644 gcc/testsuite/gcc.target/i386/addr-space-typeck-2.c
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index fd0a7f81a7a..8514488b7a5 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -6032,18 +6032,18 @@ build_c_cast (location_t loc, tree type, tree expr)
if (!addr_space_superset (as_to, as_from, _common))
{
if (ADDR_SPACE_GENERIC_P (as_from))
- warning_at (loc, 0, "cast to %s address space pointer "
+ warning_at (loc, 0, "cast to %qs address space pointer "
"from disjoint generic address space pointer",
c_addr_space_name (as_to));
else if (ADDR_SPACE_GENERIC_P (as_to))
warning_at (loc, 0, "cast to generic address space pointer "
- "from disjoint %s address space pointer",
+ "from disjoint %qs address space pointer",
c_addr_space_name (as_from));
else
- warning_at (loc, 0, "cast to %s address space pointer "
- "from disjoint %s address space pointer",
+ warning_at (loc, 0, "cast to %qs address space pointer "
+ "from disjoint %qs address space pointer",
c_addr_space_name (as_to),
c_addr_space_name (as_from));
}
@@ -7252,6 +7252,8 @@ convert_for_assignment (location_t location, location_t
expr_loc, tree type,
if (!null_pointer_constant_p (rhs)
&& asr != asl && !targetm.addr_space.subset_p (asr, asl))
{
+ auto_diagnostic_group d;
+ bool diagnosed = true;
switch (errtype)
{
case ic_argpass:
@@ -7259,7 +7261,8 @@ convert_for_assignment (location_t location, location_t
expr_loc, tree type,
const char msg[] = G_("passing argument %d of %qE from "
"pointer to non-enclosed address space");
if (warnopt)
- warning_at (expr_loc, warnopt, msg, parmnum, rname);
+ diagnosed
+ = warning_at (expr_loc, warnopt, msg, parmnum, rname);
else
error_at (expr_loc, msg, parmnum, rname);
break;
@@ -7269,7 +7272,7 @@ convert_for_assignment (location_t location, location_t
expr_loc, tree type,
const char msg[] = G_("assignment from pointer to "
"non-enclosed address space");
if (warnopt)
- warning_at (location, warnopt, msg);
+ diagnosed = warning_at (location, warnopt, msg);
else
error_at (location, msg);
break;
@@ -7280,7 +7283,7 @@ convert_for_assignment (location_t location, location_t
expr_loc, tree type,
const char msg[] = G_("initialization from pointer to "
"non-enclosed address space");
if (warnopt)
- warning_at
[committed] docs: fix copy error in -Wanalyzer-putenv-of-auto-var
Pushed to trunk as r13-1921-gffd12be1394a49.
gcc/ChangeLog:
* doc/invoke.texi (-Wanalyzer-putenv-of-auto-var): Fix copy
error.
Signed-off-by: David Malcolm
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index e8cd60103e4..863580b3710 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10023,7 +10023,7 @@ See
@uref{https://cwe.mitre.org/data/definitions/476.html, CWE-476: NULL Pointer
@opindex Wanalyzer-putenv-of-auto-var
@opindex Wno-analyzer-putenv-of-auto-var
This warning requires @option{-fanalyzer}, which enables it; use
-@option{-Wno-analyzer-possible-null-dereference} to disable it.
+@option{-Wno-analyzer-putenv-of-auto-var} to disable it.
This diagnostic warns for paths through the code in which a
call to @code{putenv} is passed a pointer to an automatic variable
--
2.26.3
[COMMITTED,gcc12] c: Fix location for _Pragma tokens [PR97498]
Hello-
This backport from r13-1596 to GCC 12 has been committed after
pre-approval. This was a straightforward cherry-pick from master with no
adjustments needed. I would like to note that subsequent to r13-1596, Thomas
made a few commits to the libgomp testsuite to test for new diagnostic notes
output after this patch; I have not backported these since I was not sure if
that would be appropriate. I did verify that the libgomp testsuite changes
work OK as-is on this branch, i.e. do not introduce any new failures,
including with offloading enabled.
-Lewis
c: Fix location for _Pragma tokens [PR97498]
The handling of #pragma GCC diagnostic uses input_location, which is not always
as precise as needed; in particular the relative location of some tokens and a
_Pragma directive will crucially determine whether a given diagnostic is enabled
or suppressed in the desired way. PR97498 shows how the C frontend ends up with
input_location pointing to the beginning of the line containing a _Pragma()
directive, resulting in the wrong behavior if the diagnostic to be modified
pertains to some tokens found earlier on the same line. This patch fixes that by
addressing two issues:
a) libcpp was not assigning a valid location to the CPP_PRAGMA token
generated by the _Pragma directive.
b) C frontend was not setting input_location to something reasonable.
With this change, the C frontend is able to change input_location to point to
the _Pragma token as needed.
This is just a two-line fix (one for each of a) and b)), the testsuite changes
were needed only because the location on the tested warnings has been somewhat
improved, so the tests need to look for the new locations.
gcc/c/ChangeLog:
PR preprocessor/97498
* c-parser.cc (c_parser_pragma): Set input_location to the
location of the pragma, rather than the start of the line.
libcpp/ChangeLog:
PR preprocessor/97498
* directives.cc (destringize_and_run): Override the location of
the CPP_PRAGMA token from a _Pragma directive to the location of
the expansion point, as is done for the tokens lexed from it.
gcc/testsuite/ChangeLog:
PR preprocessor/97498
* c-c++-common/pr97498.c: New test.
* c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
* c-c++-common/gomp/pragma-5.c: Likewise.
* gcc.dg/pragma-message.c: Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
improved warning locations.
* testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
(cherry picked from commit 0587cef3d7962a8b0f44779589ba2920dd3d71e5)
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 129dd727ef3..f679d53706a 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -12378,6 +12378,7 @@ c_parser_pragma (c_parser *parser, enum pragma_context
context, bool *if_p)
unsigned int id;
const char *construct = NULL;
+ input_location = c_parser_peek_token (parser)->location;
id = c_parser_peek_token (parser)->pragma_kind;
gcc_assert (id != PRAGMA_NONE);
diff --git a/gcc/testsuite/c-c++-common/gomp/pragma-3.c
b/gcc/testsuite/c-c++-common/gomp/pragma-3.c
index c1dee1bcc62..ae18e9b8886 100644
--- a/gcc/testsuite/c-c++-common/gomp/pragma-3.c
+++ b/gcc/testsuite/c-c++-common/gomp/pragma-3.c
@@ -1,13 +1,14 @@
/* { dg-additional-options "-fdump-tree-original" } */
/* PR preprocessor/103165 */
-#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message
(\"Test\") at(compilation)")
+#define inner(...) #__VA_ARGS__ ; _Pragma("omp error severity(warning) message
(\"Test\") at(compilation)") /* { dg-line inner_location } */
#define outer(...) inner(__VA_ARGS__)
void
f (void)
{
- const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error'
encountered: Test" } */
+ const char *str = outer(inner(1,2));
+ /* { dg-warning "'pragma omp error' encountered: Test" "inner expansion" {
target *-*-* } inner_location } */
}
#if 0
diff --git a/gcc/testsuite/c-c++-common/gomp/pragma-5.c
b/gcc/testsuite/c-c++-common/gomp/pragma-5.c
index af54b682789..8124f701502 100644
--- a/gcc/testsuite/c-c++-common/gomp/pragma-5.c
+++ b/gcc/testsuite/c-c++-common/gomp/pragma-5.c
@@ -1,13 +1,14 @@
/* { dg-additional-options "-fdump-tree-original" } */
/* PR preprocessor/103165 */
-#define inner(...) #__VA_ARGS__ ; _Pragma ( " omp error severity
(warning) message (\"Test\") at(compilation)" )
+#define inner(...) #__VA_ARGS__ ; _Pragma ( " omp error severity
(warning) message (\"Test\") at(compilation)" ) /* { dg-line
inner_location } */
#define outer(...) inner(__VA_ARGS__)
void
f (void)
{
- const char *str = outer(inner(1,2)); /* { dg-warning "'pragma omp error'
encountered: Test" } */
+ const char *str = outer(inner(1,2));
+ /* { dg-warning "'pragma omp error' encountered: Test" "inner expansion" {
[PATCH 2/3 v3] testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal changes
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/c2x-predefined-macros.c: New test.
* gcc.dg/c2x-utf8str-type.c: New test.
* gcc.dg/c2x-utf8str.c: New test.
* gcc.dg/gnu2x-predefined-macros.c: New test.
* gcc.dg/gnu2x-utf8str-type.c: New test.
* gcc.dg/gnu2x-utf8str.c: New test.
---
.../atomic/c2x-stdatomic-lockfree-char8_t.c | 42 +++
.../atomic/gnu2x-stdatomic-lockfree-char8_t.c | 5 +++
gcc/testsuite/gcc.dg/c11-utf8str-type.c | 6 +++
gcc/testsuite/gcc.dg/c17-utf8str-type.c | 6 +++
gcc/testsuite/gcc.dg/c2x-utf8str-type.c | 6 +++
gcc/testsuite/gcc.dg/c2x-utf8str.c| 34 +++
.../gcc.dg/gnu2x-predefined-macros.c | 5 +++
gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c | 5 +++
gcc/testsuite/gcc.dg/gnu2x-utf8str.c | 34 +++
9 files changed, 143 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
create mode 100644
gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
create mode 100644 gcc/testsuite/gcc.dg/c11-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/c17-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str.c
create mode 100644 gcc/testsuite/gcc.dg/gnu2x-predefined-macros.c
create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str.c
diff --git a/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
new file mode 100644
index 000..1b692f55ed0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
@@ -0,0 +1,42 @@
+/* Test atomic_is_lock_free for char8_t. */
+/* { dg-do run } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+#include
+#include
+
+extern void abort (void);
+
+_Atomic __CHAR8_TYPE__ ac8a;
+atomic_char8_t ac8t;
+
+#define CHECK_TYPE(MACRO, V1, V2) \
+ do \
+{ \
+ int r1 = MACRO; \
+ int r2 = atomic_is_lock_free (); \
+ int r3 = atomic_is_lock_free (); \
+ if (r1 != 0 && r1 != 1 && r1 != 2) \
+ abort (); \
+ if (r2 != 0 && r2 != 1) \
+ abort (); \
+ if (r3 != 0 && r3 != 1) \
+ abort (); \
+ if (r1 == 2 && r2 != 1) \
+ abort (); \
+ if (r1 == 2 && r3 != 1) \
+ abort (); \
+ if (r1 == 0 && r2 != 0) \
+ abort (); \
+ if (r1 == 0 && r3 != 0) \
+ abort (); \
+} \
+ while (0)
+
+int
+main ()
+{
+ CHECK_TYPE (ATOMIC_CHAR8_T_LOCK_FREE, ac8a, ac8t);
+
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
new file mode 100644
index 000..27a3cfe3552
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
@@ -0,0 +1,5 @@
+/* Test atomic_is_lock_free for char8_t with -std=gnu2x. */
+/* { dg-do run } */
+/* { dg-options "-std=gnu2x -pedantic-errors" } */
+
+#include "c2x-stdatomic-lockfree-char8_t.c"
diff --git a/gcc/testsuite/gcc.dg/c11-utf8str-type.c
b/gcc/testsuite/gcc.dg/c11-utf8str-type.c
new file mode 100644
index 000..8be9abb9686
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-utf8str-type.c
@@ -0,0 +1,6 @@
+/* Test C11 UTF-8 string literal type. */
+/* { dg-do compile } */
+/* { dg-options "-std=c11" } */
+
+_Static_assert (_Generic (u8"text", char*: 1, default: 2) == 1, "UTF-8 string
literals have an unexpected type");
+_Static_assert (_Generic (u8"x"[0], char: 1, default: 2) == 1, "UTF-8 string
literal elements have an unexpected type");
diff --git a/gcc/testsuite/gcc.dg/c17-utf8str-type.c
b/gcc/testsuite/gcc.dg/c17-utf8str-type.c
new file mode 100644
index 000..515c6db3970
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c17-utf8str-type.c
@@ -0,0 +1,6 @@
+/* Test C17 UTF-8 string literal type. */
+/* { dg-do compile } */
+/* { dg-options "-std=c17" } */
+
+_Static_assert (_Generic (u8"text", char*: 1, default: 2) == 1, "UTF-8 string
literals have an unexpected type");
+_Static_assert (_Generic (u8"x"[0], char: 1, default: 2) == 1, "UTF-8 string
literal elements have
Re: [PATCH 2/3 v2] testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal changes
On 8/1/22 3:13 PM, Joseph Myers wrote:
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
new file mode 100644
index 000..3456105563a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
@@ -0,0 +1,11 @@
+/* Test C2X predefined macros. */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x" } */
+
+#if !defined(__CHAR8_TYPE__)
+# error __CHAR8_TYPE__ is not defined!
+#endif
+
+#if !defined(__GCC_ATOMIC_CHAR8_T_LOCK_FREE)
+# error __GCC_ATOMIC_CHAR8_T_LOCK_FREE is not defined!
+#endif
These aren't macros defined by C2X. You could argue that they are part of
the stable interface provided by GCC for e.g. libc implementations to use,
and so should be tested as such, but any such test shouldn't suggest it's
testing a standard feature (and should have a better name to describe what
it's actually testing rather than suggesting it's about predefined macros
in general).
Fair point. This test is redundant anyway; these macros are directly or
indirectly exercised by the other tests. I'll just remove it.
Tom.
Re: [PATCH, rs6000] Add multiply-add expand pattern [PR103109]
Hi! On Mon, Jul 25, 2022 at 01:11:47PM +0800, HAO CHEN GUI wrote: > +(define_insn "madddi4_lowpart" > + [(set (match_operand:DI 0 "gpc_reg_operand" "=r") > + (subreg:DI > + (plus:TI > + (mult:TI (any_extend:TI > +(match_operand:DI 1 "gpc_reg_operand" "r")) > + (any_extend:TI > +(match_operand:DI 2 "gpc_reg_operand" "r"))) > + (any_extend:TI > + (match_operand:DI 3 "gpc_reg_operand" "r"))) > + 8))] > + "TARGET_POWERPC64 && TARGET_MADDLD && BYTES_BIG_ENDIAN" > + "maddld %0,%1,%2,%3" > + [(set_attr "type" "mul")]) So, hrm. This (as well as the _le version) simplifies to just the :DI ops, without subreg. Not properly simplified patterns like this will not ever match, so most optimisations on this will not work :-( Segher
Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases
On Mon, Aug 1, 2022 at 12:05 PM H.J. Lu via Gcc-patches
wrote:
>
> On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
> >
> > On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
> > >
> > > On Jul 27, 2022, "H.J. Lu" wrote:
> > >
> > > > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva
> > > > wrote:
> > >
> > > >> The use of @GOTOFF for locally-bound but externally-visible symbols
> > > >> (e.g. protected visibility) also breaks pointer identity if the
> > > >> canonical address ends up preempted by a PLT entry.
> > >
> > > > Here is a different fix:
> > >
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598667.html
> > >
> > > Oh, thanks, I'd missed that.
> > >
> > > It doesn't seem to fix the part of the problem I quoted above, though.
> > > I think fixing that requires testing the visibility, to make sure the
> > > symbol's canonical address cannot be preempted, which may occur with
> > > local binding, if the symbol is protected and referenced in the main
> > > program, otherwise pointer identity is broken again, admittedly for a
> > > more obscure case, but pointer identity was the point of the PR.
> >
> > The protected symbol issue isn't IFUNC specific. The protected
> > symbol handling is changed in glibc 2.36 and binutils 2.39. Only
> > the address of the protected symbol definition should be used as
> > its address.
> >
> > > >> * config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
> > > >> chain looking for an ifunc, as in gcc.target/i386/mvc10.c.
> > >
> > > You may also need to do something like this bit for mvc10.c on ia32 PIE.
> > > Because the ifunc is called through an alias, AFAICT we don't even
> > > notice that the call target is (an alias to) an ifunc. GCC's
> > > gotoff_operand predicate accepts it, but binutils (the linker, IIRC)
> > > then rejects that reference, because the named symbol is an alias to an
> > > ifunc.
> >
> > Yes, this change is needed.
>
> I think this fix should be applied to default_binds_local_p_3:
>
> if (lookup_attribute ("weakref", DECL_ATTRIBUTES (exp))
> || (!targetm.ifunc_ref_local_ok ()
> && TREE_CODE (exp) == FUNCTION_DECL
> && cgraph_node::get (exp)
> && cgraph_node::get (exp)->ifunc_resolver))
> return false;
>
> since the ifunc_resolver check won't work on aliases.
>
> --
> H.J.
A note if people are going to refactor default_binds_local_p_3 or add
a new default_binds_local_p_* variant (unrelated to the ifunc
problem):
extern_protected_data == true is now legacy. For new variants we want
all extern_protected_data == false.
Re: [PATCH 2/3 v2] testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal changes
On Mon, 1 Aug 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> new file mode 100644
> index 000..3456105563a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c2x-predefined-macros.c
> @@ -0,0 +1,11 @@
> +/* Test C2X predefined macros. */
> +/* { dg-do compile } */
> +/* { dg-options "-std=c2x" } */
> +
> +#if !defined(__CHAR8_TYPE__)
> +# error __CHAR8_TYPE__ is not defined!
> +#endif
> +
> +#if !defined(__GCC_ATOMIC_CHAR8_T_LOCK_FREE)
> +# error __GCC_ATOMIC_CHAR8_T_LOCK_FREE is not defined!
> +#endif
These aren't macros defined by C2X. You could argue that they are part of
the stable interface provided by GCC for e.g. libc implementations to use,
and so should be tested as such, but any such test shouldn't suggest it's
testing a standard feature (and should have a better name to describe what
it's actually testing rather than suggesting it's about predefined macros
in general).
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases
On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
>
> On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
> >
> > On Jul 27, 2022, "H.J. Lu" wrote:
> >
> > > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva
> > > wrote:
> >
> > >> The use of @GOTOFF for locally-bound but externally-visible symbols
> > >> (e.g. protected visibility) also breaks pointer identity if the
> > >> canonical address ends up preempted by a PLT entry.
> >
> > > Here is a different fix:
> >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598667.html
> >
> > Oh, thanks, I'd missed that.
> >
> > It doesn't seem to fix the part of the problem I quoted above, though.
> > I think fixing that requires testing the visibility, to make sure the
> > symbol's canonical address cannot be preempted, which may occur with
> > local binding, if the symbol is protected and referenced in the main
> > program, otherwise pointer identity is broken again, admittedly for a
> > more obscure case, but pointer identity was the point of the PR.
>
> The protected symbol issue isn't IFUNC specific. The protected
> symbol handling is changed in glibc 2.36 and binutils 2.39. Only
> the address of the protected symbol definition should be used as
> its address.
>
> > >> * config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
> > >> chain looking for an ifunc, as in gcc.target/i386/mvc10.c.
> >
> > You may also need to do something like this bit for mvc10.c on ia32 PIE.
> > Because the ifunc is called through an alias, AFAICT we don't even
> > notice that the call target is (an alias to) an ifunc. GCC's
> > gotoff_operand predicate accepts it, but binutils (the linker, IIRC)
> > then rejects that reference, because the named symbol is an alias to an
> > ifunc.
>
> Yes, this change is needed.
I think this fix should be applied to default_binds_local_p_3:
if (lookup_attribute ("weakref", DECL_ATTRIBUTES (exp))
|| (!targetm.ifunc_ref_local_ok ()
&& TREE_CODE (exp) == FUNCTION_DECL
&& cgraph_node::get (exp)
&& cgraph_node::get (exp)->ifunc_resolver))
return false;
since the ifunc_resolver check won't work on aliases.
--
H.J.
Re: [PATCH] btf: do not use the CHAR `encoding' bit for BTF
On 7/26/22 14:58, Indu Bhagat wrote:
> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote:
>>
>> Contrary to CTF and our previous expectations, as per [1], turns out
>> that in BTF:
>>
>> 1) The `encoding' field in integer types shall not be treated as a
>> bitmap, but as an enumerated, i.e. these bits are exclusive to each
>> other.
>>
>> 2) The CHAR bit in `encoding' shall _not_ be set when emitting types
>> for char nor `unsigned char'.
>>
>
> Hmm...well. At this time, I suggest we make a note of this in the btf.h
> for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR
> should not be set for char / unsigned char).
Agreed it would be good to add this note.
>
>> Consequently this patch clears the CHAR bit before emitting the
>> variable part of BTF integral types. It also updates the testsuite
>> accordingly, expanding it to check for BOOL bits.
>>
>> [1]
>> https://lore.kernel.org/bpf/a73586ad-f2dc-0401-1eba-2004357b7...@fb.com/T/#t
>>
>> gcc/ChangeLog:
>>
>> * btfout.cc (output_asm_btf_vlen_bytes): Do not use the CHAR
>> encoding bit in BTF.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.dg/debug/btf/btf-int-1.c: Do not check for char bits in
>> bti_encoding and check for bool bits.
>> ---
>> gcc/btfout.cc | 4
>> gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c | 18 +++---
>> 2 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
>> index 31af50521da..576f73d47cf 100644
>> --- a/gcc/btfout.cc
>> +++ b/gcc/btfout.cc
>> @@ -914,6 +914,10 @@ output_asm_btf_vlen_bytes (ctf_container_ref ctfc,
>> ctf_dtdef_ref dtd)
>> if (dtd->dtd_data.ctti_size < 1)
>> break;
>>
>> + /* In BTF the CHAR `encoding' seems to not be used, so clear it
>> + here. */
>> + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR;
>> +
>
> [Added David Faust]
>
> What do you think about doing this in btf_dtd_emit_preprocess_cb () for
> types where kind == BTF_KIND_INT. This is the place where BTF specific
> massaging of type info takes place.
Sorry for the delay.
I think this could be done in either place. I lean slightly in favor
of doing it here as implemented in this patch. Other integer encodings
are not specifically massaged into BTF; we leave the in-memory
representation the same as CTF and just write them out according to the
BTF rules since both formats hold the same information, and this function
is where we do that.
In my opinion, this is a similar case. It is not wrong hold on to the
information (internally) that this is a char type, rather it is a quirk
of the other BTF encoding rules which means it _is_ wrong to ever set the
bit saying as much when writing the BTF info (at least for now...).
So, this patch LGTM, but please add a brief note in btf.h that the CHAR
flag is currently not to be used.
Thanks
>
>> encoding = BTF_INT_DATA (dtd->dtd_u.dtu_enc.cte_format,
>> dtd->dtd_u.dtu_enc.cte_offset,
>> dtd->dtd_u.dtu_enc.cte_bits);
>> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
>> b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
>> index 2381decd6ff..87d9758e9cb 100644
>> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
>> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
>> @@ -4,7 +4,8 @@
>> | 0 | encoding | offset | 00 | bits |
>> encoding:
>>signed 1 << 24
>> - char2 << 24
>> + char2 << 24 (not used)
>> + bool4 << 24
>>
>> All offsets in this test should be 0.
>> This test does _not_ check number of bits, as it may vary between
>> targets.
>> @@ -13,13 +14,14 @@
>> /* { dg-do compile } */
>> /* { dg-options "-O0 -gbtf -dA" } */
>>
>> -/* Check for 8 BTF_KIND_INT types. */
>> -/* { dg-final { scan-assembler-times "\[\t \]0x100\[\t
>> \]+\[^\n\]*btt_info" 8 } } */
>> +/* Check for 9 BTF_KIND_INT types. */
>> +/* { dg-final { scan-assembler-times "\[\t \]0x100\[\t
>> \]+\[^\n\]*btt_info" 9 } } */
>>
>> -/* Check the signed/char flags, but not bit size. */
>> -/* { dg-final { scan-assembler-times "\[\t \]0x1..\[\t
>> \]+\[^\n\]*bti_encoding" 3 } } */
>> -/* { dg-final { scan-assembler-times "\[\t \]0x2..\[\t
>> \]+\[^\n\]*bti_encoding" 1 } } */
>> -/* { dg-final { scan-assembler-times "\[\t \]0x3..\[\t
>> \]+\[^\n\]*bti_encoding" 1 } } */
>> +/* Check the signed flags, but not bit size. */
>> +/* { dg-final { scan-assembler-times "\[\t \]0x1..\[\t
>> \]+\[^\n\]*bti_encoding" 4 } } */
>> +/* { dg-final { scan-assembler-times "\[\t \]0x..\[\t
>> \]+\[^\n\]*bti_encoding" 3 } } */
>> +/* { dg-final { scan-assembler-times "\[\t \]0x.\[\t
>> \]+\[^\n\]*bti_encoding" 1 } } */
>> +/* { dg-final { scan-assembler-times "\[\t \]0x4..\[\t
>> \]+\[^\n\]*bti_encoding" 1 } } */
>>
>> /* Check that there is a string entry for each type name. */
>> /* { dg-final {
[PATCH 1/1 v2] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.
Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the preprocessor
(see c_option_is_from_cpp_diagnostics). This change modifies the
-Wc++20-compat option definition to register it as a preprocessor option
so that its associated diagnostics can be suppressed. The changes also
implicitly disable the option in C++20 and later modes. These changes
are consistent with the definition of the -Wc++11-compat option.
This support is motivated by the need to suppress the following diagnostic
otherwise issued in C++17 and earlier modes due to the char8_t typedef
present in the uchar.h header file in glibc 2.36.
warning: identifier ‘char8_t’ is a keyword in C++20 [-Wc++20-compat]
Tests are added to validate suppression of both -Wc++11-compat and
-Wc++20-compat related diagnostics (fixes were only needed for the C++20
case).
Fixes https://gcc.gnu.org/PR106423.
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Disable -Wc++20-compat diagnostics
in C++20 and later.
* c.opt (Wc++20-compat): Enable hooks for the preprocessor.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/keywords2.C: New test.
* g++.dg/cpp2a/keywords2.C: New test.
libcpp/ChangeLog:
* include/cpplib.h (cpp_warning_reason): Add CPP_W_CXX20_COMPAT.
* init.cc (cpp_create_reader): Add cpp_warn_cxx20_compat.
---
gcc/c-family/c-opts.cc | 7 +++
gcc/c-family/c.opt | 2 +-
gcc/cp/parser.cc | 5 -
gcc/testsuite/g++.dg/cpp0x/keywords2.C | 16
gcc/testsuite/g++.dg/cpp2a/keywords2.C | 13 +
libcpp/include/cpplib.h| 4
libcpp/init.cc | 1 +
7 files changed, 46 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/keywords2.C
create mode 100644 gcc/testsuite/g++.dg/cpp2a/keywords2.C
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..1ea37ba9742 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1046,6 +1046,13 @@ c_common_post_options (const char **pfilename)
else if (warn_narrowing == -1)
warn_narrowing = 0;
+ if (cxx_dialect >= cxx20)
+{
+ /* Don't warn about C++20 compatibility changes in C++20 or later. */
+ warn_cxx20_compat = 0;
+ cpp_opts->cpp_warn_cxx20_compat = 0;
+}
+
/* C++17 has stricter evaluation order requirements; let's use some of them
for earlier C++ as well, so chaining works as expected. */
if (c_dialect_cxx ()
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 44e1a60ce24..dfdebd596ef 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -455,7 +455,7 @@ Wc++2a-compat
C++ ObjC++ Warning Alias(Wc++20-compat) Undocumented
Wc++20-compat
-C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ ObjC++,Wall)
+C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ ObjC++,Wall)
Init(0) CPP(cpp_warn_cxx20_compat) CppReason(CPP_W_CXX20_COMPAT)
Warn about C++ constructs whose meaning differs between ISO C++ 2017 and ISO
C++ 2020.
Wc++11-extensions
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 4f67441eeb1..c3584446827 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -924,7 +924,10 @@ cp_lexer_saving_tokens (const cp_lexer* lexer)
/* Store the next token from the preprocessor in *TOKEN. Return true
if we reach EOF. If LEXER is NULL, assume we are handling an
initial #pragma pch_preprocess, and thus want the lexer to return
- processed strings. */
+ processed strings.
+
+ Diagnostics issued from this function must have their controlling option (if
+ any) in c.opt annotated as a libcpp option via the CppReason property. */
static void
cp_lexer_get_preprocessor_token (unsigned flags, cp_token *token)
diff --git a/gcc/testsuite/g++.dg/cpp0x/keywords2.C
b/gcc/testsuite/g++.dg/cpp0x/keywords2.C
new file mode 100644
index 000..d67d01e31ed
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/keywords2.C
@@ -0,0 +1,16 @@
+// { dg-do compile { target c++98_only } }
+// { dg-options "-Wc++11-compat" }
+
+// Validate suppression of -Wc++11-compat diagnostics.
+#pragma GCC diagnostic ignored "-Wc++11-compat"
+int alignof;
+int alignas;
+int constexpr;
+int decltype;
+int noexcept;
+int nullptr;
+int static_assert;
+int thread_local;
+int _Alignas;
+int _Alignof;
+int _Thread_local;
diff --git a/gcc/testsuite/g++.dg/cpp2a/keywords2.C
b/gcc/testsuite/g++.dg/cpp2a/keywords2.C
new file mode 100644
index 000..8714a7b26b7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/keywords2.C
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++17_down } }
+// { dg-options "-Wc++20-compat" }
+
+// Validate suppression of -Wc++20-compat diagnostics.
+#pragma GCC diagnostic ignored "-Wc++20-compat"
+int constinit;
+int consteval;
+int
[PATCH 2/3 v2] testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal changes
This change provides new tests for the core language and compiler
dependent library changes adopted for C2X via WG14 N2653.
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test.
* gcc.dg/c2x-predefined-macros.c: New test.
* gcc.dg/c2x-utf8str-type.c: New test.
* gcc.dg/c2x-utf8str.c: New test.
* gcc.dg/gnu2x-predefined-macros.c: New test.
* gcc.dg/gnu2x-utf8str-type.c: New test.
* gcc.dg/gnu2x-utf8str.c: New test.
---
.../atomic/c2x-stdatomic-lockfree-char8_t.c | 42 +++
.../atomic/gnu2x-stdatomic-lockfree-char8_t.c | 5 +++
gcc/testsuite/gcc.dg/c11-utf8str-type.c | 6 +++
gcc/testsuite/gcc.dg/c17-utf8str-type.c | 6 +++
gcc/testsuite/gcc.dg/c2x-predefined-macros.c | 11 +
gcc/testsuite/gcc.dg/c2x-utf8str-type.c | 6 +++
gcc/testsuite/gcc.dg/c2x-utf8str.c| 34 +++
.../gcc.dg/gnu2x-predefined-macros.c | 5 +++
gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c | 5 +++
gcc/testsuite/gcc.dg/gnu2x-utf8str.c | 34 +++
10 files changed, 154 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
create mode 100644
gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
create mode 100644 gcc/testsuite/gcc.dg/c11-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/c17-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-predefined-macros.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-utf8str.c
create mode 100644 gcc/testsuite/gcc.dg/gnu2x-predefined-macros.c
create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str-type.c
create mode 100644 gcc/testsuite/gcc.dg/gnu2x-utf8str.c
diff --git a/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
new file mode 100644
index 000..1b692f55ed0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
@@ -0,0 +1,42 @@
+/* Test atomic_is_lock_free for char8_t. */
+/* { dg-do run } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+#include
+#include
+
+extern void abort (void);
+
+_Atomic __CHAR8_TYPE__ ac8a;
+atomic_char8_t ac8t;
+
+#define CHECK_TYPE(MACRO, V1, V2) \
+ do \
+{ \
+ int r1 = MACRO; \
+ int r2 = atomic_is_lock_free (); \
+ int r3 = atomic_is_lock_free (); \
+ if (r1 != 0 && r1 != 1 && r1 != 2) \
+ abort (); \
+ if (r2 != 0 && r2 != 1) \
+ abort (); \
+ if (r3 != 0 && r3 != 1) \
+ abort (); \
+ if (r1 == 2 && r2 != 1) \
+ abort (); \
+ if (r1 == 2 && r3 != 1) \
+ abort (); \
+ if (r1 == 0 && r2 != 0) \
+ abort (); \
+ if (r1 == 0 && r3 != 0) \
+ abort (); \
+} \
+ while (0)
+
+int
+main ()
+{
+ CHECK_TYPE (ATOMIC_CHAR8_T_LOCK_FREE, ac8a, ac8t);
+
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
new file mode 100644
index 000..27a3cfe3552
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
@@ -0,0 +1,5 @@
+/* Test atomic_is_lock_free for char8_t with -std=gnu2x. */
+/* { dg-do run } */
+/* { dg-options "-std=gnu2x -pedantic-errors" } */
+
+#include "c2x-stdatomic-lockfree-char8_t.c"
diff --git a/gcc/testsuite/gcc.dg/c11-utf8str-type.c
b/gcc/testsuite/gcc.dg/c11-utf8str-type.c
new file mode 100644
index 000..8be9abb9686
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-utf8str-type.c
@@ -0,0 +1,6 @@
+/* Test C11 UTF-8 string literal type. */
+/* { dg-do compile } */
+/* { dg-options "-std=c11" } */
+
+_Static_assert (_Generic (u8"text", char*: 1, default: 2) == 1, "UTF-8 string
literals have an unexpected type");
+_Static_assert (_Generic (u8"x"[0], char: 1, default: 2) == 1, "UTF-8 string
literal elements have an unexpected type");
diff --git a/gcc/testsuite/gcc.dg/c17-utf8str-type.c
b/gcc/testsuite/gcc.dg/c17-utf8str-type.c
new file mode 100644
index 000..515c6db3970
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c17-utf8str-type.c
@@ -0,0 +1,6 @@
+/* Test C17 UTF-8 string literal type. */
+/* { dg-do compile } */
+/* { dg-options "-std=c17" } */
+
+_Static_assert (_Generic (u8"text", char*: 1, default: 2) == 1, "UTF-8 string
literals have
[PATCH 1/3 v2] C: Implement C2X N2653 char8_t and UTF-8 string literal changes
This patch implements the core language and compiler dependent library
changes adopted for C2X via WG14 N2653. The changes include:
- Change of type for UTF-8 string literals from array of const char to
array of const char8_t (unsigned char).
- A new atomic_char8_t typedef.
- A new ATOMIC_CHAR8_T_LOCK_FREE macro defined in terms of the existing
__GCC_ATOMIC_CHAR8_T_LOCK_FREE predefined macro.
gcc/ChangeLog:
* ginclude/stdatomic.h (atomic_char8_t,
ATOMIC_CHAR8_T_LOCK_FREE): New typedef and macro.
gcc/c/ChangeLog:
* c-parser.c (c_parser_string_literal): Use char8_t as the type
of CPP_UTF8STRING when char8_t support is enabled.
* c-typeck.c (digest_init): Allow initialization of an array
of character type by a string literal with type array of
char8_t.
gcc/c-family/ChangeLog:
* c-lex.c (lex_string, lex_charconst): Use char8_t as the type
of CPP_UTF8CHAR and CPP_UTF8STRING when char8_t support is
enabled.
* c-opts.c (c_common_post_options): Set flag_char8_t if
targeting C2x.
---
gcc/c-family/c-lex.cc| 13 +
gcc/c-family/c-opts.cc | 4 ++--
gcc/c/c-parser.cc| 16 ++--
gcc/c/c-typeck.cc| 2 +-
gcc/ginclude/stdatomic.h | 6 ++
5 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc
index 8bfa4f4024f..0b6f94e18a8 100644
--- a/gcc/c-family/c-lex.cc
+++ b/gcc/c-family/c-lex.cc
@@ -1352,7 +1352,14 @@ lex_string (const cpp_token *tok, tree *valp, bool
objc_string, bool translate)
default:
case CPP_STRING:
case CPP_UTF8STRING:
- value = build_string (1, "");
+ if (type == CPP_UTF8STRING && flag_char8_t)
+ {
+ value = build_string (TYPE_PRECISION (char8_type_node)
+ / TYPE_PRECISION (char_type_node),
+ ""); /* char8_t is 8 bits */
+ }
+ else
+ value = build_string (1, "");
break;
case CPP_STRING16:
value = build_string (TYPE_PRECISION (char16_type_node)
@@ -1425,9 +1432,7 @@ lex_charconst (const cpp_token *token)
type = char16_type_node;
else if (token->type == CPP_UTF8CHAR)
{
- if (!c_dialect_cxx ())
- type = unsigned_char_type_node;
- else if (flag_char8_t)
+ if (flag_char8_t)
type = char8_type_node;
else
type = char_type_node;
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..108adc5caf8 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1059,9 +1059,9 @@ c_common_post_options (const char **pfilename)
if (flag_sized_deallocation == -1)
flag_sized_deallocation = (cxx_dialect >= cxx14);
- /* char8_t support is new in C++20. */
+ /* char8_t support is implicitly enabled in C++20 and C2X. */
if (flag_char8_t == -1)
-flag_char8_t = (cxx_dialect >= cxx20);
+flag_char8_t = (cxx_dialect >= cxx20) || flag_isoc2x;
if (flag_extern_tls_init)
{
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 92049d1a101..fa9395986de 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -7447,7 +7447,14 @@ c_parser_string_literal (c_parser *parser, bool
translate, bool wide_ok)
default:
case CPP_STRING:
case CPP_UTF8STRING:
- value = build_string (1, "");
+ if (type == CPP_UTF8STRING && flag_char8_t)
+ {
+ value = build_string (TYPE_PRECISION (char8_type_node)
+ / TYPE_PRECISION (char_type_node),
+ ""); /* char8_t is 8 bits */
+ }
+ else
+ value = build_string (1, "");
break;
case CPP_STRING16:
value = build_string (TYPE_PRECISION (char16_type_node)
@@ -7472,9 +7479,14 @@ c_parser_string_literal (c_parser *parser, bool
translate, bool wide_ok)
{
default:
case CPP_STRING:
-case CPP_UTF8STRING:
TREE_TYPE (value) = char_array_type_node;
break;
+case CPP_UTF8STRING:
+ if (flag_char8_t)
+ TREE_TYPE (value) = char8_array_type_node;
+ else
+ TREE_TYPE (value) = char_array_type_node;
+ break;
case CPP_STRING16:
TREE_TYPE (value) = char16_array_type_node;
break;
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index fd0a7f81a7a..231f4e980b6 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -8045,7 +8045,7 @@ digest_init (location_t init_loc, tree type, tree init,
tree origtype,
if (char_array)
{
- if (typ2 != char_type_node)
+ if (typ2 != char_type_node && typ2 != char8_type_node)
incompat_string_cst = true;
}
else if (!comptypes (typ1, typ2))
diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
index bfcfdf664c7..9f2475b739d 100644
Re: [PATCH V2] btf: emit linkage information in BTF_KIND_FUNC entries
> On 7/12/22 08:13, Jose E. Marchesi via Gcc-patches wrote:
>>
>> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
>> annotation reflecting the linkage of functions (static, global). For
>> whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
>> instead of adding a variable-part to the record like it is done with
>> other entry kinds.
>>
>> This patch makes GCC to include this linkage info in BTF_KIND_FUNC
>> entries.
>>
>> Tested in bpf-unknown-none target.
>
> LGTM
> Thanks.
Pushed to master.
Thanks.
>>
>> gcc/ChangeLog:
>>
>> PR debug/106263
>> * ctfc.h (struct ctf_dtdef): Add field linkage.
>> * ctfc.cc (ctf_add_function): Set ctti_linkage.
>> * dwarf2ctf.cc (gen_ctf_function_type): Pass a linkage for
>> function types and subprograms.
>> * btfout.cc (btf_asm_func_type): Emit linkage information for the
>> function.
>> (btf_dtd_emit_preprocess_cb): Propagate the linkage information
>> for functions.
>>
>> gcc/testsuite/ChangeLog:
>>
>> PR debug/106263
>> * gcc.dg/debug/btf/btf-function-4.c: New test.
>> * gcc.dg/debug/btf/btf-function-5.c: Likewise.
>> ---
>> gcc/btfout.cc | 6 +-
>> gcc/ctfc.cc | 3 ++-
>> gcc/ctfc.h | 3 ++-
>> gcc/dwarf2ctf.cc| 4 +++-
>> gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c | 14 ++
>> gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c | 14 ++
>> 6 files changed, 40 insertions(+), 4 deletions(-)
>> create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c
>> create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c
>>
>> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
>> index 31af50521da..594cba84910 100644
>> --- a/gcc/btfout.cc
>> +++ b/gcc/btfout.cc
>> @@ -463,6 +463,7 @@ btf_dtd_emit_preprocess_cb (ctf_container_ref ctfc,
>> ctf_dtdef_ref dtd)
>>ctf_dtdef_ref func_dtd = ggc_cleared_alloc ();
>>func_dtd->dtd_data = dtd->dtd_data;
>>func_dtd->dtd_data.ctti_type = dtd->dtd_type;
>> + func_dtd->linkage = dtd->linkage;
>>
>>vec_safe_push (funcs, func_dtd);
>>num_types_created++;
>> @@ -740,7 +741,10 @@ static void
>> btf_asm_func_type (ctf_dtdef_ref dtd)
>> {
>>dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
>> - dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0, 0), "btt_info");
>> + dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0,
>> + dtd->linkage),
>> + "btt_info: kind=%u, kflag=%u, linkage=%u",
>> + BTF_KIND_FUNC, 0, dtd->linkage);
>>dw2_asm_output_data (4, get_btf_id (dtd->dtd_data.ctti_type), "btt_type");
>> }
>>
>> diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
>> index f24e7bff948..9773358a475 100644
>> --- a/gcc/ctfc.cc
>> +++ b/gcc/ctfc.cc
>> @@ -777,7 +777,7 @@ ctf_add_function_arg (ctf_container_ref ctfc, dw_die_ref
>> func,
>> ctf_id_t
>> ctf_add_function (ctf_container_ref ctfc, uint32_t flag, const char * name,
>>const ctf_funcinfo_t * ctc, dw_die_ref die,
>> - bool from_global_func)
>> + bool from_global_func, int linkage)
>> {
>>ctf_dtdef_ref dtd;
>>ctf_id_t type;
>> @@ -791,6 +791,7 @@ ctf_add_function (ctf_container_ref ctfc, uint32_t flag,
>> const char * name,
>>type = ctf_add_generic (ctfc, flag, name, , die);
>>
>>dtd->from_global_func = from_global_func;
>> + dtd->linkage = linkage;
>>dtd->dtd_data.ctti_info = CTF_TYPE_INFO (CTF_K_FUNCTION, flag, vlen);
>>/* Caller must make sure CTF types for ctc->ctc_return are already added.
>> */
>>dtd->dtd_data.ctti_type = (uint32_t) ctc->ctc_return;
>> diff --git a/gcc/ctfc.h b/gcc/ctfc.h
>> index 001e544ef08..bcf3a43ae1b 100644
>> --- a/gcc/ctfc.h
>> +++ b/gcc/ctfc.h
>> @@ -161,6 +161,7 @@ struct GTY ((for_user)) ctf_dtdef
>>ctf_itype_t dtd_data; /* Type node. */
>>bool from_global_func; /* Whether this type was added from a global
>> function. */
>> + uint32_t linkage; /* Used in function types. 0=local,
>> 1=global. */
>>union GTY ((desc ("ctf_dtu_d_union_selector (&%1)")))
>>{
>> /* struct, union, or enum. */
>> @@ -423,7 +424,7 @@ extern ctf_id_t ctf_add_forward (ctf_container_ref,
>> uint32_t, const char *,
>> extern ctf_id_t ctf_add_typedef (ctf_container_ref, uint32_t, const char *,
>> ctf_id_t, dw_die_ref);
>> extern ctf_id_t ctf_add_function (ctf_container_ref, uint32_t, const char *,
>> - const ctf_funcinfo_t *, dw_die_ref, bool);
>> + const ctf_funcinfo_t *, dw_die_ref, bool,
>> int);
>> extern ctf_id_t ctf_add_sou (ctf_container_ref, uint32_t, const char *,
>> uint32_t,
Re: [PATCH, rs6000] Add multiply-add expand pattern [PR103109]
On Mon, Aug 01, 2022 at 02:19:32PM +0800, Kewen.Lin wrote:
> > new file mode 100644
> > index 000..256e05d5677
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr103109.c
> > @@ -0,0 +1,16 @@
> > +/* { dg-do compile { target { lp64 } } } */
>
> Since the guard is TARGET_POWERPC64, should use has_arch_ppc64?
Yes, we should almost never have lp64 in testcases anymore, since now we
have has_arch_ppc64. Previously we had only has_powerpc64, which is a
very different thing unfortunately.
> > +/* { dg-require-effective-target powerpc_p9modulo_ok } */
>
> Need effective target int128 as well?
Yes. This was hidden by the lp64 test, which skips on -m32 already :-)
> > +/* { dg-options "-mdejagnu-cpu=power9 -O2" } */
> > +/* { dg-final { scan-assembler-times {\mmaddld\M} 2 } } */
> > +/* { dg-final { scan-assembler-times {\mmaddhd\M} 1 } } */
> > +/* { dg-final { scan-assembler-times {\mmaddhdu\M} 1 } } */
> > +
> > +__int128 test (long a, long b, long c)
> > +{
> > + return (__int128) a * (__int128) b + (__int128) c;
> > +}
> > +
> > +unsigned __int128 testu (unsigned long a, unsigned long b, unsigned long c)
> > +{
> > + return (unsigned __int128) a * (unsigned __int128) b + (unsigned
> > __int128) c;
> > +}
(You only need to cast the first here always, the rest is promoted
automatically).
> Not sure there is some coverage for this kind of multiply-add (promoted first
> then mul and add), if no, it seems better to add one runnable test case.
Good point. We won't automatically see it from the compiler build
itself for example, int128 isn't used there.
Segher
Re: [PATCH, rs6000] Add multiply-add expand pattern [PR103109]
Hi! On Mon, Jul 25, 2022 at 01:11:47PM +0800, HAO CHEN GUI wrote: > This patch adds an expand and several insns for multiply-add with > three 64bit operands. > PR target/103109 > * config/rs6000/rs6000.md (maddditi4): New pattern for > multiply-add. Please don't break lines unnecessarily. > +(define_expand "maddditi4" > + [(set (match_operand:TI 0 "gpc_reg_operand") > + (plus:TI > + (mult:TI (any_extend:TI > + (match_operand:DI 1 "gpc_reg_operand")) > +(any_extend:TI > + (match_operand:DI 2 "gpc_reg_operand"))) > + (any_extend:TI > + (match_operand:DI 3 "gpc_reg_operand"] Broken indentation, should be (define_expand "maddditi4" [(set (match_operand:TI 0 "gpc_reg_operand") (plus:TI (mult:TI (any_extend:TI (match_operand:DI 1 "gpc_reg_operand")) (any_extend:TI (match_operand:DI 2 "gpc_reg_operand"))) (any_extend:TI (match_operand:DI 3 "gpc_reg_operand"] > + "TARGET_POWERPC64 && TARGET_MADDLD" TARGET_MADDLD should itself already include TARGET_POWERPC64. Could you please send a separate patch for that first? > +(define_insn "madddi4_lowpart" > + [(set (match_operand:DI 0 "gpc_reg_operand" "=r") > + (subreg:DI > + (plus:TI > + (mult:TI (any_extend:TI > +(match_operand:DI 1 "gpc_reg_operand" "r")) > + (any_extend:TI > +(match_operand:DI 2 "gpc_reg_operand" "r"))) > + (any_extend:TI > + (match_operand:DI 3 "gpc_reg_operand" "r"))) > + 8))] [(set (match_operand:DI 0 "gpc_reg_operand" "=r") (subreg:DI (plus:TI (mult:TI (any_extend:TI (match_operand:DI 1 "gpc_reg_operand" "r")) (any_extend:TI (match_operand:DI 2 "gpc_reg_operand" "r"))) (any_extend:TI (match_operand:DI 3 "gpc_reg_operand" "r"))) 8))] (and similar for _le of course). Segher
Re: [PATCH] configure: respect --with-build-time-tools [PR43301]
On Mon, Aug 1, 2022 at 3:54 AM Andreas Schwab wrote:
>
> On Jul 31 2022, Eric Gallager via Gcc-patches wrote:
>
> > It just makes the configure script respect the --with-build-time-tools
> > flag.
>
> Why does it make any difference?
>
See the original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301
> > diff --git a/configure b/configure
> > index 65d7078dbe7..4d46b94ebc4 100755
> > --- a/configure
> > +++ b/configure
> > @@ -12850,7 +12850,9 @@ fi
> > # Check whether --with-build-time-tools was given.
> > if test "${with_build_time_tools+set}" = set; then :
> >withval=$with_build_time_tools; case x"$withval" in
> > - x/*) ;;
> > + x/*)
> > + with_build_time_tools=$withval
>
> This just reassigns the value that was retrieved a couple of lines
> above from the very same variable.
>
Oh, ok, so I guess this isn't necessary after all? In which case we
can just close 43301 as INVALID then?
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836
> On Aug 1, 2022, at 3:38 AM, Richard Biener wrote: > > On Fri, 29 Jul 2022, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for your comments and suggestions. (And sorry for my late >> reply). >> >>> On Jul 28, 2022, at 3:26 AM, Richard Biener wrote: >>> >>> On Tue, 19 Jul 2022, Qing Zhao wrote: >>> From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001 From: Qing Zhao Date: Mon, 18 Jul 2022 17:04:12 + Subject: [PATCH 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array Add the following new option -fstrict-flex-array[=n] and a corresponding attribute strict_flex_array to GCC: '-fstrict-flex-array' Treat the trailing array of a structure as a flexible array member in a stricter way. The positive form is equivalent to '-fstrict-flex-array=3', which is the strictest. A trailing array is treated as a flexible array member only when it is declared as a flexible array member per C99 standard onwards. The negative form is equivalent to '-fstrict-flex-array=0', which is the least strict. All trailing arrays of structures are treated as flexible array members. '-fstrict-flex-array=LEVEL' Treat the trailing array of a structure as a flexible array member in a stricter way. The value of LEVEL controls the level of strictness. The possible values of LEVEL are the same as for the 'strict_flex_array' attribute (*note Variable Attributes::). You can control this behavior for a specific trailing array field of a structure by using the variable attribute 'strict_flex_array' attribute (*note Variable Attributes::). 'strict_flex_array (LEVEL)' The 'strict_flex_array' attribute should be attached to the trailing array field of a structure. It specifies the level of strictness of treating the trailing array field of a structure as a flexible array member. LEVEL must be an integer betwen 0 to 3. LEVEL=0 is the least strict level, all trailing arrays of structures are treated as flexible array members. LEVEL=3 is the strictest level, only when the trailing array is declared as a flexible array member per C99 standard onwards ([]), it is treated as a flexible array member. There are two more levels in between 0 and 3, which are provided to support older codes that use GCC zero-length array extension ([0]) or one-size array as flexible array member ([1]): When LEVEL is 1, the trailing array is treated as a flexible array member when it is declared as either [], [0], or [1]; When LEVEL is 2, the trailing array is treated as a flexible array member when it is declared as either [], or [0]. This attribute can be used with or without '-fstrict-flex-array'. When both the attribute and the option present at the same time, the level of the strictness for the specific trailing array field is determined by the attribute. gcc/c-family/ChangeLog: * c-attribs.cc (handle_strict_flex_array_attribute): New function. (c_common_attribute_table): New item for strict_flex_array. * c.opt (fstrict-flex-array): New option. (fstrict-flex-array=): New option. gcc/c/ChangeLog: * c-decl.cc (add_flexible_array_elts_to_size): Call new utility routine flexible_array_member_p. (is_flexible_array_member_p): New function. (finish_struct): Set the new DECL_NOT_FLEXARRAY flag. gcc/ChangeLog: * doc/extend.texi: Document strict_flex_array attribute. * doc/invoke.texi: Document -fstrict-flex-array[=n] option. * tree-core.h (struct tree_decl_common): New bit field decl_not_flexarray. * tree.cc (component_ref_size): Reorg by using new utility functions. (flexible_array_member_p): New function. (zero_length_array_p): Likewise. (one_element_array_p): Likewise. (flexible_array_type_p): Likewise. * tree.h (DECL_NOT_FLEXARRAY): New flag. (zero_length_array_p): New function prototype. (one_element_array_p): Likewise. (flexible_array_member_p): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/strict-flex-array-1.c: New test. --- gcc/c-family/c-attribs.cc | 47 gcc/c-family/c.opt | 7 ++ gcc/c/c-decl.cc| 91 +-- gcc/doc/extend.texi| 25 gcc/doc/invoke.texi| 27 - gcc/testsuite/gcc.dg/strict-flex-array-1.c | 31 + gcc/tree-core.h| 5 +- gcc/tree.cc| 130
Re: [x86_64 PATCH] PR target/106481: Handle CONST_WIDE_INT in REG_EQUAL during STV.
On Mon, Aug 1, 2022 at 3:43 PM Roger Sayle wrote:
>
>
> This patch resolves PR target/106481, and is an oversight in my recent
> battles with REG_EQUAL notes during TImode STV (see PR target/106278
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598416.html).
>
> The patch above's/current behaviour is that we check that the mode of
> the REG_EQUAL note is TImode before using PUT_MODE to set it to V1TImode.
> However, the new test case reveals that this doesn't consider REG_EQUAL
> notes that are CONST_INT or CONST_WIDE_INT, i.e. that are VOIDmode,
> and so STV produces:
>
> (insn 85 84 86 2 (set (reg:V1TI 113)
> (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal}
> (expr_list:REG_EQUAL (const_wide_int 0x00004)
> (nil)))
>
> which causes problems as the const_wide_int isn't a valid immediate
> constant for V1TImode. With this patch, we now generate the correct:
>
> (insn 85 84 86 2 (set (reg:V1TI 113)
> (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal}
> (expr_list:REG_EQUAL (const_vector:V1TI [
> (const_wide_int 0x00004)
> ])
> (nil)))
>
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures. Ok for mainline?
>
>
> 2022-08-01 Roger Sayle
>
> gcc/ChangeLog
> PR target/106481
> * config/i386/i386-features.cc (timode_scalar_chain::convert_insn):
> Convert a CONST_SCALAR_INT_P in a REG_EQUAL note into a V1TImode
> CONST_VECTOR.
>
> gcc/testsuite/ChangeLog
> PR target/106481
> * gcc.target/i386/pr106481.c: New test case.
OK, but how about we restructure the conditions a bit, like in the
attached patch?
Uros.
diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index e4cc4a30590..e3ecc22580a 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1353,8 +1353,15 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
if (GET_MODE (dst) == V1TImode)
{
tmp = find_reg_equal_equiv_note (insn);
- if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
- PUT_MODE (XEXP (tmp, 0), V1TImode);
+ if (tmp)
+ {
+ if (GET_MODE (XEXP (tmp, 0)) == TImode)
+ PUT_MODE (XEXP (tmp, 0), V1TImode);
+ else if (CONST_SCALAR_INT_P (XEXP (tmp, 0)))
+ XEXP (tmp, 0)
+ = gen_rtx_CONST_VECTOR (V1TImode,
+ gen_rtvec (1, XEXP (tmp, 0)));
+ }
}
break;
case MEM:
Re: [GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836
> On Aug 1, 2022, at 3:13 AM, Richard Biener wrote:
>
> On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>>
>>
>>> On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
>>>
>>> On Tue, 19 Jul 2022, Qing Zhao wrote:
>>>
From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Jul 2022 18:12:26 +
Subject: [PATCH 2/2] Use new flag DECL_NOT_FLEXARRAY in
__builtin_object_size
[PR101836]
Use new flag DECL_NOT_FLEXARRAY to determine whether the trailing array
of a structure is flexible array member in __builtin_object_size.
gcc/ChangeLog:
PR tree-optimization/101836
* tree-object-size.cc (addr_object_size): Use array_at_struct_end_p
and DECL_NOT_FLEXARRAY to determine a flexible array member reference.
gcc/testsuite/ChangeLog:
PR tree-optimization/101836
* gcc.dg/pr101836.c: New test.
* gcc.dg/pr101836_1.c: New test.
* gcc.dg/pr101836_2.c: New test.
* gcc.dg/pr101836_3.c: New test.
* gcc.dg/pr101836_4.c: New test.
* gcc.dg/pr101836_5.c: New test.
* gcc.dg/strict-flex-array-2.c: New test.
* gcc.dg/strict-flex-array-3.c: New test.
---
gcc/testsuite/gcc.dg/pr101836.c| 60 ++
gcc/testsuite/gcc.dg/pr101836_1.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_2.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_3.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_4.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_5.c | 60 ++
gcc/testsuite/gcc.dg/strict-flex-array-2.c | 60 ++
gcc/testsuite/gcc.dg/strict-flex-array-3.c | 60 ++
gcc/tree-object-size.cc| 18 +++
9 files changed, 489 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr101836.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_1.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_2.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_3.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_4.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_5.c
create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-2.c
create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-3.c
diff --git a/gcc/testsuite/gcc.dg/pr101836.c
b/gcc/testsuite/gcc.dg/pr101836.c
new file mode 100644
index 000..e5b4e5160a4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101836.c
@@ -0,0 +1,60 @@
+/* -fstrict-flex-array is aliased with -ftrict-flex-array=3, which is the
+ strictest, only [] is treated as flexible array. */
+/* PR tree-optimization/101836 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fstrict-flex-array" } */
+
+#include
+
+#define expect(p, _v) do { \
+size_t v = _v; \
+if (p == v) \
+printf("ok: %s == %zd\n", #p, p); \
+else \
+ { \
+ printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
+__builtin_abort (); \
+ } \
+} while (0);
+
+struct trailing_array_1 {
+int a;
+int b;
+int c[4];
+};
+
+struct trailing_array_2 {
+int a;
+int b;
+int c[1];
+};
+
+struct trailing_array_3 {
+int a;
+int b;
+int c[0];
+};
+struct trailing_array_4 {
+int a;
+int b;
+int c[];
+};
+
+void __attribute__((__noinline__)) stuff(
+struct trailing_array_1 *normal,
+struct trailing_array_2 *trailing_1,
+struct trailing_array_3 *trailing_0,
+struct trailing_array_4 *trailing_flex)
+{
+expect(__builtin_object_size(normal->c, 1), 16);
+expect(__builtin_object_size(trailing_1->c, 1), 4);
+expect(__builtin_object_size(trailing_0->c, 1), 0);
+expect(__builtin_object_size(trailing_flex->c, 1), -1);
+}
+
+int main(int argc, char *argv[])
+{
+stuff((void *)argv[0], (void *)argv[0], (void *)argv[0], (void
*)argv[0]);
+
+return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/pr101836_1.c
b/gcc/testsuite/gcc.dg/pr101836_1.c
new file mode 100644
index 000..30ea20427a5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101836_1.c
@@ -0,0 +1,60 @@
+/* -fstrict-flex-array=3 is the strictest, only [] is treated as
+ flexible array. */
+/* PR tree-optimization/101836 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fstrict-flex-array=3" } */
+
+#include
+
+#define expect(p, _v) do { \
+size_t v = _v; \
+if (p == v) \
+
[PATCH] tree-optimization/106495 - avoid threading to possibly never executed edge
The following builds upon the logic of the PR105679 fix by avoiding
to thread to a known edge that is predicted as probably never executed.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/106495
* tree-ssa-threadbackward.cc
(back_threader_profitability::profitable_path_p): If known_edge
is probably never executed avoid threading.
---
gcc/tree-ssa-threadbackward.cc | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index 90f5331c265..0519f2a8c4b 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -777,6 +777,13 @@ back_threader_profitability::profitable_path_p (const
vec _path,
"exceeds PARAM_MAX_FSM_THREAD_PATH_INSNS.\n");
return false;
}
+ if (taken_edge && probably_never_executed_edge_p (cfun, taken_edge))
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file, " FAIL: Jump-thread path not considered: "
+"path leads to probably never executed edge.\n");
+ return false;
+ }
edge entry = find_edge (m_path[m_path.length () - 1],
m_path[m_path.length () - 2]);
if (probably_never_executed_edge_p (cfun, entry))
--
2.35.3
[x86_64 PATCH] PR target/106481: Handle CONST_WIDE_INT in REG_EQUAL during STV.
This patch resolves PR target/106481, and is an oversight in my recent
battles with REG_EQUAL notes during TImode STV (see PR target/106278
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598416.html).
The patch above's/current behaviour is that we check that the mode of
the REG_EQUAL note is TImode before using PUT_MODE to set it to V1TImode.
However, the new test case reveals that this doesn't consider REG_EQUAL
notes that are CONST_INT or CONST_WIDE_INT, i.e. that are VOIDmode,
and so STV produces:
(insn 85 84 86 2 (set (reg:V1TI 113)
(reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal}
(expr_list:REG_EQUAL (const_wide_int 0x00004)
(nil)))
which causes problems as the const_wide_int isn't a valid immediate
constant for V1TImode. With this patch, we now generate the correct:
(insn 85 84 86 2 (set (reg:V1TI 113)
(reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal}
(expr_list:REG_EQUAL (const_vector:V1TI [
(const_wide_int 0x00004)
])
(nil)))
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures. Ok for mainline?
2022-08-01 Roger Sayle
gcc/ChangeLog
PR target/106481
* config/i386/i386-features.cc (timode_scalar_chain::convert_insn):
Convert a CONST_SCALAR_INT_P in a REG_EQUAL note into a V1TImode
CONST_VECTOR.
gcc/testsuite/ChangeLog
PR target/106481
* gcc.target/i386/pr106481.c: New test case.
Thanks again,
Roger
--
diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index aa5de71..c1564c4 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -1355,6 +1355,10 @@ timode_scalar_chain::convert_insn (rtx_insn *insn)
tmp = find_reg_equal_equiv_note (insn);
if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode)
PUT_MODE (XEXP (tmp, 0), V1TImode);
+ else if (tmp && CONST_SCALAR_INT_P (XEXP (tmp, 0)))
+ XEXP (tmp, 0) = gen_rtx_CONST_VECTOR (V1TImode,
+ gen_rtvec (1,
+XEXP (tmp, 0)));
}
break;
case MEM:
diff --git a/gcc/testsuite/gcc.target/i386/pr106481.c
b/gcc/testsuite/gcc.target/i386/pr106481.c
new file mode 100644
index 000..8cc7048
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr106481.c
@@ -0,0 +1,17 @@
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop
-Wno-psabi" } */
+
+typedef int V __attribute__((vector_size (64)));
+typedef __int128 W __attribute__((vector_size (64)));
+
+W w;
+V bar (void);
+
+void
+foo (V v, W)
+{
+ foo ((V){4, ~0}, (W) v);
+ foo (v, w);
+ bar ();
+}
+
Re: [PATCH] match.pd: Add new division pattern [PR104992]
Here is the patch that I pushed. Thanks for the feedback.
Thanks
-Sam
On Thu, Jul 28, 2022 at 3:03 AM Richard Biener
wrote:
> On Wed, Jul 27, 2022 at 9:57 PM Sam Feifer wrote:
> >
> >
> >> _Complex int are strange beasts, I'd simply avoid the transform for
> them.
> >>
> >
> > I added to the match.pd rule to not simplify if the operands are
> complex. There is now a test case for complex types to make sure they do
> not simplify. I had to move the "dg-do run" test to g++.dg to accommodate
> the complex type function that is included (even though there isn't a
> runtime test for complex types).
> >
> >> Can you please move the pattern next to the existing div/mod patterns,
> >> like after the related
> >>
> >
> > done :)
> >
> >> /* Simplify (A / B) * B + (A % B) -> A. */
> >> (for div (trunc_div ceil_div floor_div round_div)
> >> mod (trunc_mod ceil_mod floor_mod round_mod)
> >> (simplify
> >>(plus:c (mult:c (div @0 @1) @1) (mod @0 @1))
> >>@0))
> >>
> >> pattern?
> >>
> >> +/* x / y * y == x -> x % y == 0. */
> >> +(simplify
> >> + (eq (mult (trunc_div @0 @1) @1) @0)
> >> + (eq (trunc_mod @0 @1) { build_zero_cst TREE_TYPE(@0); }))
> >>
> >> there are parens missing around the TREE_TYPE (@0), how did you test
> >> the patch? You probably want :s on the trunc_div and as Andrew said
> >> :c on the eq and the mult.
> >
> >
> > I made those changes to the rule. The rule worked without the
> parentheses, which is probably why I didn't notice they were missing.
> Attached is an updated patch file.
>
> +/* x / y * y == x -> x % y == 0. */
> +(simplify
> + (eq:c (mult:c (trunc_div:s @0 @1) @1) @0)
> + (if (TREE_CODE (TREE_TYPE (@0)) != COMPLEX_TYPE
> + && TREE_CODE (TREE_TYPE (@1)) != COMPLEX_TYPE)
>
> Testing this only for @0 is enough, we don't allow mixed types for
> trunc_div or mult.
>
> +(eq (trunc_mod @0 @1) { build_zero_cst (TREE_TYPE(@0)); })))
>
> space before (@0) in 'TREE_TYPE(@0)'
>
> OK with those changes.
>
> Thanks,
> Richard.
>
>
>
> > Thanks
> > -Sam
> >
> >>
> >> Richard.
> >>
> >> > Thanks
> >> > -Sam
> >> >
> >> >
> >> > > For vector try (which works for both the C and C++ front-end):
> >> > > #define vector __attribute__((vector_size(4*sizeof(int)) ))
> >> > > vector int f(vector int x, vector int y)
> >> > > {
> >> > > return x == x / y * y;
> >> > > }
> >> > >
> >> > > That is for the vector case, == still returns a vector type.
> >> > >
> >> > > Thanks,
> >> > > Andrew Pinski
> >> > >
> >> > > >
> >> > > > Thanks
> >> > > > -Sam
> >> > > >
> >> > > >> Thanks,
> >> > > >> Andrew Pinski
> >> > > >>
> >> > > >> > diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c
> >> > > b/gcc/testsuite/gcc.dg/pr104992-1.c
> >> > > >> > new file mode 100644
> >> > > >> > index 000..a80e5e180ce
> >> > > >> > --- /dev/null
> >> > > >> > +++ b/gcc/testsuite/gcc.dg/pr104992-1.c
> >> > > >> > @@ -0,0 +1,30 @@
> >> > > >> > +/* PR tree-optimization/104992 */
> >> > > >> > +/* { dg-do run } */
> >> > > >> > +/* { dg-options "-O2"} */
> >> > > >> > +
> >> > > >> > +#include "pr104992.c"
> >> > > >> > +
> >> > > >> > +int main () {
> >> > > >> > +
> >> > > >> > +/* Should be true. */
> >> > > >> > +if (!foo(6, 3)
> >> > > >> > +|| !bar(12, 2)
> >> > > >> > +|| !baz(34, 17)
> >> > > >> > +|| !qux(50, 10)
> >> > > >> > +|| !fred(16, 8)
> >> > > >> > +|| !baz(-9, 3)
> >> > > >> > +|| !baz(9, -3)
> >> > > >> > +|| !baz(-9, -3)
> >> > > >> > +) {
> >> > > >> > +__builtin_abort();
> >> > > >> > + }
> >> > > >> > +
> >> > > >> > +/* Should be false. */
> >> > > >> > +if (foo(5, 30)
> >> > > >> > +|| bar(72, 27)
> >> > > >> > +|| baz(42, 15)) {
> >> > > >> > +__builtin_abort();
> >> > > >> > +}
> >> > > >> > +
> >> > > >> > +return 0;
> >> > > >> > +}
> >> > > >> > diff --git a/gcc/testsuite/gcc.dg/pr104992.c
> >> > > b/gcc/testsuite/gcc.dg/pr104992.c
> >> > > >> > new file mode 100644
> >> > > >> > index 000..b4b0ca53118
> >> > > >> > --- /dev/null
> >> > > >> > +++ b/gcc/testsuite/gcc.dg/pr104992.c
> >> > > >> > @@ -0,0 +1,35 @@
> >> > > >> > +/* PR tree-optimization/104992 */
> >> > > >> > +/* { dg-do compile } */
> >> > > >> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
> >> > > >> > +
> >> > > >> > +/* Form from PR. */
> >> > > >> > +__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
> >> > > >> > +{
> >> > > >> > +return x / y * y == x;
> >> > > >> > +}
> >> > > >> > +
> >> > > >> > +__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
> >> > > >> > +return x == x / y * y;
> >> > > >> > +}
> >> > > >> > +
> >> > > >> > +/* Signed test case. */
> >> > > >> > +__attribute__((noipa)) unsigned baz (int x, int y) {
> >> > > >> > +return x / y * y == x;
> >> > > >> > +}
> >> > > >> > +
> >> > > >> > +/* Changed order. */
> >> > > >> > +__attribute__((noipa)) unsigned qux (unsigned x, unsigned y)
Re: [RFC] Teach vectorizer to deal with bitfield reads
On Mon, 1 Aug 2022, Andre Vieira (lists) wrote: > > On 29/07/2022 11:52, Richard Biener wrote: > > On Fri, 29 Jul 2022, Jakub Jelinek wrote: > > > >> On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via > >> Gcc-patches wrote: > >>> The 'only on the vectorized code path' remains the same though as > >>> vect_recog > >>> also only happens on the vectorized code path right? > >> if conversion (in some cases) duplicates a loop and guards one copy with > >> an ifn which resolves to true if that particular loop is vectorized and > >> false otherwise. So, then changes that shouldn't be done in case of > >> vectorization failure can be done on the for vectorizer only copy of the > >> loop. > > And just to mention, one issue with lowering of bitfield accesses > > is bitfield inserts which, on some architectures (hello m68k) have > > instructions operating on memory directly. For those it's difficult > > to not regress in code quality if a bitfield store becomes a > > read-modify-write cycle. That's one of the things holding this > > back. One idea would be to lower to .INSV directly for those targets > > (but presence of insv isn't necessarily indicating support for > > memory destinations). > > > > Richard. > Should I account for that when vectorizing though? From what I can tell (no > TARGET_VECTOR_* hooks implemented) m68k does not have vectorization support. No. > So the question is, are there currently any targets that vectorize and have > vector bitfield-insert/extract support? If they don't exist I suggest we worry > about it when it comes around, if not just for the fact that we wouldn't be > able to test it right now. > > If this is about not lowering on the non-vectorized path, see my previous > reply, I never intended to do that in the vectorizer. I just thought it was > the plan to do lowering eventually. Yes, for the vectorized path this all isn't an issue - and btw the advantage with if-conversion is that you get VN of the result "for free", the RMW cycle of bitfield stores likely have reads to share (and also redundant stores in the end, but ...). And yes, the plan was to do lowering generally. Just the simplistic approaches (my last one was a lowering pass somewhen after IPA, IIRC combined with SRA) run into some issues, like that on m68k, but IIRC also some others. So I wouldn't hold my breath, but then just somebody needs to do the work and think about how to deal with m68k and the likes... Richard.
Re: [PATCH v2] cselib: add function to check if SET is redundant [PR106187]
On 30/07/2022 20:57, Jeff Law via Gcc-patches wrote: On 7/29/2022 7:52 AM, Richard Earnshaw via Gcc-patches wrote: A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new and earlier store do not conflict then the set is not truly redundant. This can happen, for example, if objects of different types share a stack slot. To fix this we define a new function in cselib that first checks for equality and if that is successful then finds the earlier store in the value history and checks the alias sets. The routine is used in two places elsewhere in the compiler. Firstly in cfgcleanup and secondly in postreload. gcc/ChangeLog: * alias.h (mems_same_for_tbaa_p): Declare. * alias.cc (mems_same_for_tbaa_p): New function. * dse.cc (record_store): Use it instead of open-coding alias check. * cselib.h (cselib_redundant_set_p): Declare. * cselib.cc: Include alias.h (cselib_redundant_set_p): New function. * cfgcleanup.cc: (mark_effect): Use cselib_redundant_set_p instead of rtx_equal_for_cselib_p. * postreload.c (reload_cse_simplify): Use cselib_redundant_set_p. (reload_cse_noop_set_p): Delete. Seems quite reasonable. The only question I would have would be whether or not you considered including the aliasing info into the hashing used by cselib. You'd probably still need the bulk of this patch as well since we could presumably still get a hash conflict with two stores of the same value to the same location, but with different alias sets (it's just much less likely), so perhaps it doesn't really buy us anything. I thought about this, but if the alias set were included in the hash, then surely you'd get every alias set in a different value. Then you'd miss the cases where the alias sets do conflict even though they are not the same. Anyway, the values /are/ the same so in some circumstances you might want to know that. Ideally this would include a testcase. You might be able to turn that non-executawble reduced case into something useful by scanning the post-reload dumps. I considered this as well, but the testcase I have is far too fragile, I think. The existing test only fails on Arm, only fails on 11.2 (not 11.3 or gcc-12 onwards), relies on two objects with the same value being in distinct alias sets but still assigned to the same stack slot and for some copy dance to end up trying to write back the original value to the same slot but with a non-conflicting set. And finally, the scheduler has to then try to move a load past the non-aliasing store. To get anywhere close to this I think we'd need something akin to the gimple reader but for RTL so that we could set up all the conditions for the failure without the risk of an earlier transform blowing the test away. I even considered whether we could start with a gimple dump and bypassing all the tree/gimple transformations, but even that would be still at the mercy of the stack-slot allocation algorithm. Jeff R.
Re: [RFC] Teach vectorizer to deal with bitfield reads
On 29/07/2022 11:52, Richard Biener wrote: On Fri, 29 Jul 2022, Jakub Jelinek wrote: On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches wrote: The 'only on the vectorized code path' remains the same though as vect_recog also only happens on the vectorized code path right? if conversion (in some cases) duplicates a loop and guards one copy with an ifn which resolves to true if that particular loop is vectorized and false otherwise. So, then changes that shouldn't be done in case of vectorization failure can be done on the for vectorizer only copy of the loop. And just to mention, one issue with lowering of bitfield accesses is bitfield inserts which, on some architectures (hello m68k) have instructions operating on memory directly. For those it's difficult to not regress in code quality if a bitfield store becomes a read-modify-write cycle. That's one of the things holding this back. One idea would be to lower to .INSV directly for those targets (but presence of insv isn't necessarily indicating support for memory destinations). Richard. Should I account for that when vectorizing though? From what I can tell (no TARGET_VECTOR_* hooks implemented) m68k does not have vectorization support. So the question is, are there currently any targets that vectorize and have vector bitfield-insert/extract support? If they don't exist I suggest we worry about it when it comes around, if not just for the fact that we wouldn't be able to test it right now. If this is about not lowering on the non-vectorized path, see my previous reply, I never intended to do that in the vectorizer. I just thought it was the plan to do lowering eventually.
Re: [RFC] Teach vectorizer to deal with bitfield reads
On 29/07/2022 11:31, Jakub Jelinek wrote: On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches wrote: The 'only on the vectorized code path' remains the same though as vect_recog also only happens on the vectorized code path right? if conversion (in some cases) duplicates a loop and guards one copy with an ifn which resolves to true if that particular loop is vectorized and false otherwise. So, then changes that shouldn't be done in case of vectorization failure can be done on the for vectorizer only copy of the loop. Jakub I'm pretty sure vect_recog patterns have no effect on scalar codegen if the vectorization fails too. The patterns live as new vect_stmt_info's and no changes are actually done to the scalar loop. That was the point I was trying to make, but it doesn't matter that much, as I said I am happy to do this in if convert.
[PATCH v5] LoongArch: add movable attribute
Changes v4 -> v5: Fix changelog. No code change.
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my mind
but forgot to remove the line copied from M32R doc.)
-- >8 --
A linker script and/or a section attribute may locate a local object in
some way unexpected by the code model, leading to a link failure. This
happens when the Linux kernel loads a module with "local" per-CPU
variables.
Add an attribute to explicitly mark an variable with the address
unlimited by the code model so we would be able to work around such
problems.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_attribute_table):
New attribute table.
(TARGET_ATTRIBUTE_TABLE): Define the target hook.
(loongarch_handle_addr_global_attribute): New static function.
(loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
SYMBOL_REF_DECL with addr_global attribute.
(loongarch_use_anchors_for_symbol_p): New static function.
(TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
* doc/extend.texi (Variable Attributes): Document new
LoongArch specific attribute.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/addr-global.c: New test.
---
gcc/config/loongarch/loongarch.cc | 63 +++
gcc/doc/extend.texi | 16 +
.../gcc.target/loongarch/attr-movable.c | 29 +
3 files changed, 108 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/attr-movable.c
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 79687340dfd..6b6026700a6 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1643,6 +1643,15 @@ loongarch_classify_symbol (const_rtx x)
&& !loongarch_symbol_binds_local_p (x))
return SYMBOL_GOT_DISP;
+ if (SYMBOL_REF_P (x))
+{
+ tree decl = SYMBOL_REF_DECL (x);
+ /* A movable symbol may be moved away from the +/- 2GiB range around
+the PC, so we have to use GOT. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+ return SYMBOL_GOT_DISP;
+}
+
return SYMBOL_PCREL;
}
@@ -6068,6 +6077,54 @@ loongarch_starting_frame_offset (void)
return crtl->outgoing_args_size;
}
+static tree
+loongarch_handle_movable_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
+{
+ tree decl = *node;
+ if (TREE_CODE (decl) == VAR_DECL)
+{
+ if (DECL_CONTEXT (decl)
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && !TREE_STATIC (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "%qE attribute cannot be specified for local "
+ "variables", name);
+ *no_add_attrs = true;
+ }
+}
+ else
+{
+ warning (OPT_Wattributes, "%qE attribute ignored", name);
+ *no_add_attrs = true;
+}
+ return NULL_TREE;
+}
+
+static const struct attribute_spec loongarch_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
+ affects_type_identity, handler, exclude } */
+ { "movable", 0, 0, true, false, false, false,
+loongarch_handle_movable_attribute, NULL },
+ /* The last attribute spec is set to be NULL. */
+ {}
+};
+
+bool
+loongarch_use_anchors_for_symbol_p (const_rtx symbol)
+{
+ tree decl = SYMBOL_REF_DECL (symbol);
+
+ /* A movable attribute indicates the linker may move the symbol away,
+ so the use of anchor may cause relocation overflow. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+return false;
+
+ return default_use_anchors_for_symbol_p (symbol);
+}
+
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
#define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6256,6 +6313,12 @@ loongarch_starting_frame_offset (void)
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+#undef TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
+
+#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
+#define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-loongarch.h"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7fe7f8817cd..322d8c05a04 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7314,6 +7314,7 @@ attributes.
* Blackfin Variable Attributes::
* H8/300 Variable Attributes::
* IA-64 Variable Attributes::
+* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
@@ -8098,6 +8099,21 @@ defined by shared libraries.
[PATCH v4] LoongArch: add movable attribute
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my mind
but forgot to remove the line copied from M32R doc.)
-- >8 --
A linker script and/or a section attribute may locate a local object in
some way unexpected by the code model, leading to a link failure. This
happens when the Linux kernel loads a module with "local" per-CPU
variables.
Add an attribute to explicitly mark an variable with the address
unlimited by the code model so we would be able to work around such
problems.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_attribute_table):
New attribute table.
(TARGET_ATTRIBUTE_TABLE): Define the target hook.
(loongarch_handle_addr_global_attribute): New static function.
(loongarch_classify_symbol): Return SYMBOL_GOT_DISP for
SYMBOL_REF_DECL with addr_global attribute.
(loongarch_use_anchors_for_symbol_p): New static function.
(TARGET_USE_ANCHORS_FOR_SYMBOL_P): Define the target hook.
* doc/extend.texi (Variable Attributes): Document new
LoongArch specific attribute.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/addr-global.c: New test.
---
gcc/config/loongarch/loongarch.cc | 63 +++
gcc/doc/extend.texi | 16 +
.../gcc.target/loongarch/attr-movable.c | 29 +
3 files changed, 108 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/attr-movable.c
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 79687340dfd..6b6026700a6 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1643,6 +1643,15 @@ loongarch_classify_symbol (const_rtx x)
&& !loongarch_symbol_binds_local_p (x))
return SYMBOL_GOT_DISP;
+ if (SYMBOL_REF_P (x))
+ {
+ tree decl = SYMBOL_REF_DECL (x);
+ /* A movable symbol may be moved away from the +/- 2GiB range around
+ the PC, so we have to use GOT. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+ return SYMBOL_GOT_DISP;
+ }
+
return SYMBOL_PCREL;
}
@@ -6068,6 +6077,54 @@ loongarch_starting_frame_offset (void)
return crtl->outgoing_args_size;
}
+static tree
+loongarch_handle_movable_attribute (tree *node, tree name, tree, int,
+ bool *no_add_attrs)
+{
+ tree decl = *node;
+ if (TREE_CODE (decl) == VAR_DECL)
+ {
+ if (DECL_CONTEXT (decl)
+ && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
+ && !TREE_STATIC (decl))
+ {
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "%qE attribute cannot be specified for local "
+ "variables", name);
+ *no_add_attrs = true;
+ }
+ }
+ else
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored", name);
+ *no_add_attrs = true;
+ }
+ return NULL_TREE;
+}
+
+static const struct attribute_spec loongarch_attribute_table[] =
+{
+ /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
+ affects_type_identity, handler, exclude } */
+ { "movable", 0, 0, true, false, false, false,
+ loongarch_handle_movable_attribute, NULL },
+ /* The last attribute spec is set to be NULL. */
+ {}
+};
+
+bool
+loongarch_use_anchors_for_symbol_p (const_rtx symbol)
+{
+ tree decl = SYMBOL_REF_DECL (symbol);
+
+ /* A movable attribute indicates the linker may move the symbol away,
+ so the use of anchor may cause relocation overflow. */
+ if (decl && lookup_attribute ("movable", DECL_ATTRIBUTES (decl)))
+ return false;
+
+ return default_use_anchors_for_symbol_p (symbol);
+}
+
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
#define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -6256,6 +6313,12 @@ loongarch_starting_frame_offset (void)
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+#undef TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE loongarch_attribute_table
+
+#undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
+#define TARGET_USE_ANCHORS_FOR_SYMBOL_P loongarch_use_anchors_for_symbol_p
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-loongarch.h"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7fe7f8817cd..322d8c05a04 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -7314,6 +7314,7 @@ attributes.
* Blackfin Variable Attributes::
* H8/300 Variable Attributes::
* IA-64 Variable Attributes::
+* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
@@ -8098,6 +8099,21 @@ defined by shared libraries.
@end table
+@node LoongArch Variable Attributes
+@subsection LoongArch Variable Attributes
+
+One attribute is currently defined for the LoongArch.
+
+@table @code
+@item movable
+@cindex @code{movable} variable attribute, LoongArch
+Use this attribute on the LoongArch to mark an object possible to be moved
+by the linker, so its address is unlimited by the local data section range
+specified by the code
[PATCH] lto: replace $target with $host in configure.ac [PR106170]
Pushed as obvious. Martin PR lto/106170 lto-plugin/ChangeLog: * configure.ac: Replace $target with $host. * configure: Regenerate. --- lto-plugin/configure| 2 +- lto-plugin/configure.ac | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lto-plugin/configure b/lto-plugin/configure index fdb8a5964b4..f165eaeb194 100755 --- a/lto-plugin/configure +++ b/lto-plugin/configure @@ -6015,7 +6015,7 @@ fi use_locking=no ac_lto_plugin_extra_ldflags= -case $target in +case $host in riscv*) # do not use locking as pthread depends on libatomic ;; diff --git a/lto-plugin/configure.ac b/lto-plugin/configure.ac index e69a7bd9ec0..0a7202782ae 100644 --- a/lto-plugin/configure.ac +++ b/lto-plugin/configure.ac @@ -91,7 +91,7 @@ AM_CONDITIONAL(LTO_PLUGIN_USE_SYMVER_SUN, [test "x$lto_plugin_use_symver" = xsun use_locking=no ac_lto_plugin_extra_ldflags= -case $target in +case $host in riscv*) # do not use locking as pthread depends on libatomic ;; -- 2.37.1
Re: [PATCH] tree-optimization/105679 - disable backward threading of unlikely entry
> On 1 Aug 2022, at 09:21, Richard Biener via Gcc-patches
> wrote:
>
> On Sun, 31 Jul 2022, Iain Sandoe wrote:
>
>> Hi Richi,
>>
>>> On 29 Jul 2022, at 09:54, Richard Biener via Gcc-patches
>>> wrote:
>>>
>>> The following makes the backward threader reject threads whose entry
>>> edge is probably never executed according to the profile. That in
>>> particular, for the testcase, avoids threading the irq == 1 check
>>> on the path where irq > 31, thereby avoiding spurious -Warray-bounds
>>> diagnostics
>>
>> This breaks bootstrap on i686-darwin{9,17} with what looks like a valid
>> warning (werrors on stage2)
>>
>> cc1plus … -O2 -Wall … is enough to.
>>
>> I can repeat it on a cross from x86_64-darwin19, so I can probably reduce
>> the .ii (it’s like 2M5 raw) and file a PR if you like - depends if the
>> solution might be obvious to you …
>
> Can you open a bugreport and attach full preprocessed source at start?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106496
> Note at the start of the function we have
>
> if (m_path.length () <= 1)
> return false;
>
> so
>
> edge entry = find_edge (m_path[m_path.length () - 1],
> m_path[m_path.length () - 2]);
>
> is known to not access m_path out-of-bounds ...
yes, I saw that .. so I guess somehow that information is getting dropped.
thanks
Iain
>
> Thanks,
> Richard.
>
>>
>> thanks
>> Iain
>>
>>
>>
>> In file included from /src-local/gcc-master/gcc/hash-table.h:248,
>> from /src-local/gcc-master/gcc/coretypes.h:486,
>> from /src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:22:
>> In member function ‘T& vec::operator[](unsigned int) [with T
>> = basic_block_def*; A = va_heap]’,
>>inlined from ‘const T& vec::operator[](unsigned int) const [with T =
>> basic_block_def*]’ at /src-local/gcc-master/gcc/vec.h:1486:20,
>>inlined from ‘bool back_threader_profitability::profitable_path_p(const
>> vec&, tree, edge, bool*)’ at
>> /src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:781:37:
>> /src-local/gcc-master/gcc/vec.h:890:19: warning: array subscript 4294967294
>> is above array bounds of ‘basic_block_def* [1]’ [-Warray-bounds]
>> 890 | return m_vecdata[ix];
>> | ~^
>> /src-local/gcc-master/gcc/vec.h: In member function ‘bool
>> back_threader_profitability::profitable_path_p(const vec&,
>> tree, edge, bool*)’:
>> /src-local/gcc-master/gcc/vec.h:635:5: note: while referencing
>> ‘vec::m_vecdata’
>> 635 | T m_vecdata[1];
>> | ^
>>
>> =
>
> --
> Richard Biener
> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
> Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
> HRB 36809 (AG Nuernberg)
Re: [PATCH] tree-optimization/105679 - disable backward threading of unlikely entry
On Sun, 31 Jul 2022, Iain Sandoe wrote:
> Hi Richi,
>
> > On 29 Jul 2022, at 09:54, Richard Biener via Gcc-patches
> > wrote:
> >
> > The following makes the backward threader reject threads whose entry
> > edge is probably never executed according to the profile. That in
> > particular, for the testcase, avoids threading the irq == 1 check
> > on the path where irq > 31, thereby avoiding spurious -Warray-bounds
> > diagnostics
>
> This breaks bootstrap on i686-darwin{9,17} with what looks like a valid
> warning (werrors on stage2)
>
> cc1plus … -O2 -Wall … is enough to.
>
> I can repeat it on a cross from x86_64-darwin19, so I can probably reduce the
> .ii (it’s like 2M5 raw) and file a PR if you like - depends if the solution
> might be obvious to you …
Can you open a bugreport and attach full preprocessed source at start?
Note at the start of the function we have
if (m_path.length () <= 1)
return false;
so
edge entry = find_edge (m_path[m_path.length () - 1],
m_path[m_path.length () - 2]);
is known to not access m_path out-of-bounds ...
Thanks,
Richard.
>
> thanks
> Iain
>
>
>
> In file included from /src-local/gcc-master/gcc/hash-table.h:248,
> from /src-local/gcc-master/gcc/coretypes.h:486,
> from /src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:22:
> In member function ‘T& vec::operator[](unsigned int) [with T
> = basic_block_def*; A = va_heap]’,
> inlined from ‘const T& vec::operator[](unsigned int) const [with T =
> basic_block_def*]’ at /src-local/gcc-master/gcc/vec.h:1486:20,
> inlined from ‘bool back_threader_profitability::profitable_path_p(const
> vec&, tree, edge, bool*)’ at
> /src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:781:37:
> /src-local/gcc-master/gcc/vec.h:890:19: warning: array subscript 4294967294
> is above array bounds of ‘basic_block_def* [1]’ [-Warray-bounds]
> 890 | return m_vecdata[ix];
> | ~^
> /src-local/gcc-master/gcc/vec.h: In member function ‘bool
> back_threader_profitability::profitable_path_p(const vec&,
> tree, edge, bool*)’:
> /src-local/gcc-master/gcc/vec.h:635:5: note: while referencing
> ‘vec::m_vecdata’
> 635 | T m_vecdata[1];
> | ^
>
> =
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
Re: [PATCH] configure: respect --with-build-time-tools [PR43301]
On Jul 31 2022, Eric Gallager via Gcc-patches wrote:
> It just makes the configure script respect the --with-build-time-tools
> flag.
Why does it make any difference?
> diff --git a/configure b/configure
> index 65d7078dbe7..4d46b94ebc4 100755
> --- a/configure
> +++ b/configure
> @@ -12850,7 +12850,9 @@ fi
> # Check whether --with-build-time-tools was given.
> if test "${with_build_time_tools+set}" = set; then :
>withval=$with_build_time_tools; case x"$withval" in
> - x/*) ;;
> + x/*)
> + with_build_time_tools=$withval
This just reassigns the value that was retrieved a couple of lines
above from the very same variable.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836
On Fri, 29 Jul 2022, Qing Zhao wrote: > Hi, Richard, > > Thanks a lot for your comments and suggestions. (And sorry for my late reply). > > > On Jul 28, 2022, at 3:26 AM, Richard Biener wrote: > > > > On Tue, 19 Jul 2022, Qing Zhao wrote: > > > >> From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001 > >> From: Qing Zhao > >> Date: Mon, 18 Jul 2022 17:04:12 + > >> Subject: [PATCH 1/2] Add a new option -fstrict-flex-array[=n] and new > >> attribute strict_flex_array > >> > >> Add the following new option -fstrict-flex-array[=n] and a corresponding > >> attribute strict_flex_array to GCC: > >> > >> '-fstrict-flex-array' > >>Treat the trailing array of a structure as a flexible array member > >>in a stricter way. The positive form is equivalent to > >>'-fstrict-flex-array=3', which is the strictest. A trailing array > >>is treated as a flexible array member only when it is declared as a > >>flexible array member per C99 standard onwards. The negative form > >>is equivalent to '-fstrict-flex-array=0', which is the least > >>strict. All trailing arrays of structures are treated as flexible > >>array members. > >> > >> '-fstrict-flex-array=LEVEL' > >>Treat the trailing array of a structure as a flexible array member > >>in a stricter way. The value of LEVEL controls the level of > >>strictness. > >> > >>The possible values of LEVEL are the same as for the > >>'strict_flex_array' attribute (*note Variable Attributes::). > >> > >>You can control this behavior for a specific trailing array field > >>of a structure by using the variable attribute 'strict_flex_array' > >>attribute (*note Variable Attributes::). > >> > >> 'strict_flex_array (LEVEL)' > >>The 'strict_flex_array' attribute should be attached to the > >>trailing array field of a structure. It specifies the level of > >>strictness of treating the trailing array field of a structure as a > >>flexible array member. LEVEL must be an integer betwen 0 to 3. > >> > >>LEVEL=0 is the least strict level, all trailing arrays of > >>structures are treated as flexible array members. LEVEL=3 is the > >>strictest level, only when the trailing array is declared as a > >>flexible array member per C99 standard onwards ([]), it is treated > >>as a flexible array member. > >> > >>There are two more levels in between 0 and 3, which are provided to > >>support older codes that use GCC zero-length array extension ([0]) > >>or one-size array as flexible array member ([1]): When LEVEL is 1, > >>the trailing array is treated as a flexible array member when it is > >>declared as either [], [0], or [1]; When LEVEL is 2, the trailing > >>array is treated as a flexible array member when it is declared as > >>either [], or [0]. > >> > >>This attribute can be used with or without '-fstrict-flex-array'. > >>When both the attribute and the option present at the same time, > >>the level of the strictness for the specific trailing array field > >>is determined by the attribute. > >> > >> gcc/c-family/ChangeLog: > >> > >>* c-attribs.cc (handle_strict_flex_array_attribute): New function. > >>(c_common_attribute_table): New item for strict_flex_array. > >>* c.opt (fstrict-flex-array): New option. > >>(fstrict-flex-array=): New option. > >> > >> gcc/c/ChangeLog: > >> > >>* c-decl.cc (add_flexible_array_elts_to_size): Call new utility > >>routine flexible_array_member_p. > >>(is_flexible_array_member_p): New function. > >>(finish_struct): Set the new DECL_NOT_FLEXARRAY flag. > >> > >> gcc/ChangeLog: > >> > >>* doc/extend.texi: Document strict_flex_array attribute. > >>* doc/invoke.texi: Document -fstrict-flex-array[=n] option. > >>* tree-core.h (struct tree_decl_common): New bit field > >>decl_not_flexarray. > >>* tree.cc (component_ref_size): Reorg by using new utility functions. > >>(flexible_array_member_p): New function. > >>(zero_length_array_p): Likewise. > >>(one_element_array_p): Likewise. > >>(flexible_array_type_p): Likewise. > >>* tree.h (DECL_NOT_FLEXARRAY): New flag. > >>(zero_length_array_p): New function prototype. > >>(one_element_array_p): Likewise. > >>(flexible_array_member_p): Likewise. > >> > >> gcc/testsuite/ChangeLog: > >> > >>* gcc.dg/strict-flex-array-1.c: New test. > >> --- > >> gcc/c-family/c-attribs.cc | 47 > >> gcc/c-family/c.opt | 7 ++ > >> gcc/c/c-decl.cc| 91 +-- > >> gcc/doc/extend.texi| 25 > >> gcc/doc/invoke.texi| 27 - > >> gcc/testsuite/gcc.dg/strict-flex-array-1.c | 31 + > >> gcc/tree-core.h| 5 +- > >> gcc/tree.cc| 130 ++--- > >> gcc/tree.h
Re: [Ada PATCH] Update configure to check for a recent gnat Ada compiler.
> GCC fails to bootstrap when configured with --enable-languages=all on
> machines that have older versions of GNAT installed as the system Ada
> compiler. In configure, it's not sufficient to check whether gnat is
> available, but whether a sufficiently recent version of GNAT is
> installed. This patch tweaks config/acx.m4 so that conftest.adb also
> contains a reference to System.CRTL.int64 as required by the current
> version of gcc/ada/osint.adb. This fixes the build when the system
> Ada is GNAT v4.8.5 (on Redhat 7) by disabling ada, but continues to
> work fine when the system Ada is GNAT v11.3.1.
>
> Tested in x86_64-pc-linux-gnu. Ok for mainline?
>
>
> 2022-07-30 Roger Sayle
>
> ChangeLog
> * config/acx.me (AC_PROG_GNAT): Update conftest.adb to include
> features required of the host gnat compiler.
> * configure: Regenerate.
>
> Thanks in advance,
> Roger
> --
>
> diff --git a/config/acx.m4 b/config/acx.m4
> index b86c4f9..bd3e7f8 100644
> --- a/config/acx.m4
> +++ b/config/acx.m4
> @@ -396,6 +396,10 @@ AC_CHECK_TOOL(GNATMAKE, gnatmake, no)
> AC_CACHE_CHECK([whether compiler driver understands Ada],
I'd suggest changing the text above to e.g. "whether compiler driver
understands Ada and is recent enough"
OK with this change, thanks!
>acx_cv_cc_gcc_supports_ada,
> [cat >conftest.adb < +pragma Warnings (Off);
> +with System.CRTL;
> +pragma Warnings (On);
> +use type System.CRTL.int64;
> procedure conftest is begin null; end conftest;
> EOF
> acx_cv_cc_gcc_supports_ada=no
> diff --git a/configure b/configure
> index 65d7078..3ddcc9f 100755
> --- a/configure
> +++ b/configure
> @@ -5608,6 +5608,10 @@ if ${acx_cv_cc_gcc_supports_ada+:} false; then :
>$as_echo_n "(cached) " >&6
> else
>cat >conftest.adb < +pragma Warnings (Off);
> +with System.CRTL;
> +pragma Warnings (On);
> +use type System.CRTL.int64;
> procedure conftest is begin null; end conftest;
> EOF
> acx_cv_cc_gcc_supports_ada=no
Re: [GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836
On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>
> > On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
> >
> > On Tue, 19 Jul 2022, Qing Zhao wrote:
> >
> >> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
> >> From: Qing Zhao
> >> Date: Mon, 18 Jul 2022 18:12:26 +
> >> Subject: [PATCH 2/2] Use new flag DECL_NOT_FLEXARRAY in
> >> __builtin_object_size
> >> [PR101836]
> >>
> >> Use new flag DECL_NOT_FLEXARRAY to determine whether the trailing array
> >> of a structure is flexible array member in __builtin_object_size.
> >>
> >> gcc/ChangeLog:
> >>
> >>PR tree-optimization/101836
> >>* tree-object-size.cc (addr_object_size): Use array_at_struct_end_p
> >>and DECL_NOT_FLEXARRAY to determine a flexible array member reference.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >>PR tree-optimization/101836
> >>* gcc.dg/pr101836.c: New test.
> >>* gcc.dg/pr101836_1.c: New test.
> >>* gcc.dg/pr101836_2.c: New test.
> >>* gcc.dg/pr101836_3.c: New test.
> >>* gcc.dg/pr101836_4.c: New test.
> >>* gcc.dg/pr101836_5.c: New test.
> >>* gcc.dg/strict-flex-array-2.c: New test.
> >>* gcc.dg/strict-flex-array-3.c: New test.
> >> ---
> >> gcc/testsuite/gcc.dg/pr101836.c| 60 ++
> >> gcc/testsuite/gcc.dg/pr101836_1.c | 60 ++
> >> gcc/testsuite/gcc.dg/pr101836_2.c | 60 ++
> >> gcc/testsuite/gcc.dg/pr101836_3.c | 60 ++
> >> gcc/testsuite/gcc.dg/pr101836_4.c | 60 ++
> >> gcc/testsuite/gcc.dg/pr101836_5.c | 60 ++
> >> gcc/testsuite/gcc.dg/strict-flex-array-2.c | 60 ++
> >> gcc/testsuite/gcc.dg/strict-flex-array-3.c | 60 ++
> >> gcc/tree-object-size.cc| 18 +++
> >> 9 files changed, 489 insertions(+), 9 deletions(-)
> >> create mode 100644 gcc/testsuite/gcc.dg/pr101836.c
> >> create mode 100644 gcc/testsuite/gcc.dg/pr101836_1.c
> >> create mode 100644 gcc/testsuite/gcc.dg/pr101836_2.c
> >> create mode 100644 gcc/testsuite/gcc.dg/pr101836_3.c
> >> create mode 100644 gcc/testsuite/gcc.dg/pr101836_4.c
> >> create mode 100644 gcc/testsuite/gcc.dg/pr101836_5.c
> >> create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-2.c
> >> create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-3.c
> >>
> >> diff --git a/gcc/testsuite/gcc.dg/pr101836.c
> >> b/gcc/testsuite/gcc.dg/pr101836.c
> >> new file mode 100644
> >> index 000..e5b4e5160a4
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/pr101836.c
> >> @@ -0,0 +1,60 @@
> >> +/* -fstrict-flex-array is aliased with -ftrict-flex-array=3, which is the
> >> + strictest, only [] is treated as flexible array. */
> >> +/* PR tree-optimization/101836 */
> >> +/* { dg-do run } */
> >> +/* { dg-options "-O2 -fstrict-flex-array" } */
> >> +
> >> +#include
> >> +
> >> +#define expect(p, _v) do { \
> >> +size_t v = _v; \
> >> +if (p == v) \
> >> +printf("ok: %s == %zd\n", #p, p); \
> >> +else \
> >> + { \
> >> + printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
> >> +__builtin_abort (); \
> >> + } \
> >> +} while (0);
> >> +
> >> +struct trailing_array_1 {
> >> +int a;
> >> +int b;
> >> +int c[4];
> >> +};
> >> +
> >> +struct trailing_array_2 {
> >> +int a;
> >> +int b;
> >> +int c[1];
> >> +};
> >> +
> >> +struct trailing_array_3 {
> >> +int a;
> >> +int b;
> >> +int c[0];
> >> +};
> >> +struct trailing_array_4 {
> >> +int a;
> >> +int b;
> >> +int c[];
> >> +};
> >> +
> >> +void __attribute__((__noinline__)) stuff(
> >> +struct trailing_array_1 *normal,
> >> +struct trailing_array_2 *trailing_1,
> >> +struct trailing_array_3 *trailing_0,
> >> +struct trailing_array_4 *trailing_flex)
> >> +{
> >> +expect(__builtin_object_size(normal->c, 1), 16);
> >> +expect(__builtin_object_size(trailing_1->c, 1), 4);
> >> +expect(__builtin_object_size(trailing_0->c, 1), 0);
> >> +expect(__builtin_object_size(trailing_flex->c, 1), -1);
> >> +}
> >> +
> >> +int main(int argc, char *argv[])
> >> +{
> >> +stuff((void *)argv[0], (void *)argv[0], (void *)argv[0], (void
> >> *)argv[0]);
> >> +
> >> +return 0;
> >> +}
> >> diff --git a/gcc/testsuite/gcc.dg/pr101836_1.c
> >> b/gcc/testsuite/gcc.dg/pr101836_1.c
> >> new file mode 100644
> >> index 000..30ea20427a5
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/pr101836_1.c
> >> @@ -0,0 +1,60 @@
> >> +/* -fstrict-flex-array=3 is the strictest, only [] is treated as
> >> + flexible array. */
> >> +/* PR tree-optimization/101836 */
> >> +/* { dg-do run } */
> >> +/* { dg-options "-O2 -fstrict-flex-array=3" } */
> >> +
> >> +#include
> >> +
> >> +#define expect(p, _v) do { \
> >> +size_t v = _v; \
> >> +if (p == v) \
> >> +printf("ok: %s == %zd\n", #p, p); \
> >> +else \
> >> + { \
>
Re: [PATCH, rs6000] Add multiply-add expand pattern [PR103109]
Hi Haochen,
Thanks for the patch, some comments are inlined.
on 2022/7/25 13:11, HAO CHEN GUI wrote:
> Hi,
> This patch adds an expand and several insns for multiply-add with
> three 64bit operands.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
>
> ChangeLog
> 2022-07-22 Haochen Gui
>
> gcc/
> PR target/103109
> * config/rs6000/rs6000.md (maddditi4): New pattern for
> multiply-add.
> (madddi4_lowpart): New.
> (madddi4_lowpart_le): New.
> (madddi4_highpart): New.
> (madddi4_highpart_le): New.
>
> gcc/testsuite/
> PR target/103109
> * gcc.target/powerpc/pr103109.c: New.
>
> patch.diff
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index c55ee7e171a..4f3b56e103e 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -3226,6 +3226,97 @@ (define_insn "*maddld4"
>"maddld %0,%1,%2,%3"
>[(set_attr "type" "mul")])
>
> +(define_expand "maddditi4"
> + [(set (match_operand:TI 0 "gpc_reg_operand")
> + (plus:TI
> + (mult:TI (any_extend:TI
> + (match_operand:DI 1 "gpc_reg_operand"))
> +(any_extend:TI
> + (match_operand:DI 2 "gpc_reg_operand")))
> + (any_extend:TI
> + (match_operand:DI 3 "gpc_reg_operand"]
> + "TARGET_POWERPC64 && TARGET_MADDLD"
> +{
> + rtx op0_lo = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 8 :
> 0);
> + rtx op0_hi = gen_rtx_SUBREG (DImode, operands[0], BYTES_BIG_ENDIAN ? 0 :
> 8);
> +
> + if (BYTES_BIG_ENDIAN)
> +{
> + emit_insn (gen_madddi4_lowpart (op0_lo, operands[1], operands[2],
> + operands[3]));
> + emit_insn (gen_madddi4_highpart (op0_hi, operands[1], operands[2],
> + operands[3]));
> +}
> + else
> +{
> + emit_insn (gen_madddi4_lowpart_le (op0_lo, operands[1], operands[2],
> + operands[3]));
> + emit_insn (gen_madddi4_highpart_le (op0_hi, operands[1],
> operands[2],
> + operands[3]));
> +}
> + DONE;
> +})
> +
> +(define_insn "madddi4_lowpart"
> + [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
> + (subreg:DI
> + (plus:TI
> + (mult:TI (any_extend:TI
> +(match_operand:DI 1 "gpc_reg_operand" "r"))
> + (any_extend:TI
> +(match_operand:DI 2 "gpc_reg_operand" "r")))
> + (any_extend:TI
> + (match_operand:DI 3 "gpc_reg_operand" "r")))
> + 8))]
> + "TARGET_POWERPC64 && TARGET_MADDLD && BYTES_BIG_ENDIAN"
> + "maddld %0,%1,%2,%3"
> + [(set_attr "type" "mul")])
> +
> +(define_insn "madddi4_lowpart_le"
> + [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
> + (subreg:DI
> + (plus:TI
> + (mult:TI (any_extend:TI
> +(match_operand:DI 1 "gpc_reg_operand" "r"))
> + (any_extend:TI
> +(match_operand:DI 2 "gpc_reg_operand" "r")))
> + (any_extend:TI
> + (match_operand:DI 3 "gpc_reg_operand" "r")))
> + 0))]
> + "TARGET_POWERPC64 && TARGET_MADDLD && !BYTES_BIG_ENDIAN"
> + "maddld %0,%1,%2,%3"
> + [(set_attr "type" "mul")]
> +
> +(define_insn "madddi4_highpart"
> + [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
> + (subreg:DI
> + (plus:TI
> + (mult:TI (any_extend:TI
> +(match_operand:DI 1 "gpc_reg_operand" "r"))
> + (any_extend:TI
> +(match_operand:DI 2 "gpc_reg_operand" "r")))
> + (any_extend:TI
> + (match_operand:DI 3 "gpc_reg_operand" "r")))
> + 0))]
> + "TARGET_POWERPC64 && TARGET_MADDLD && BYTES_BIG_ENDIAN"
> + "maddhd %0,%1,%2,%3"
> + [(set_attr "type" "mul")])
> +
> +(define_insn "madddi4_highpart_le"
> + [(set (match_operand:DI 0 "gpc_reg_operand" "=r")
> + (subreg:DI
> + (plus:TI
> + (mult:TI (any_extend:TI
> +(match_operand:DI 1 "gpc_reg_operand" "r"))
> + (any_extend:TI
> +(match_operand:DI 2 "gpc_reg_operand" "r")))
> + (any_extend:TI
> + (match_operand:DI 3 "gpc_reg_operand" "r")))
> + 8))]
> + "TARGET_POWERPC64 && TARGET_MADDLD && !BYTES_BIG_ENDIAN"
> + "maddhd %0,%1,%2,%3"
> + [(set_attr "type" "mul")])
> +
> (define_insn "udiv3"
>[(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
> (udiv:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr103109.c
> b/gcc/testsuite/gcc.target/powerpc/pr103109.c
> new file mode 100644
> index 000..256e05d5677
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr103109.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile { target { lp64 } } } */
Since the guard is TARGET_POWERPC64, should
[COMMITTED] Make irange dependency explicit for range_of_ssa_name_with_loop_info.
Even though ranger is type agnostic, SCEV seems to only work with
integers. This patch removes some FIXME notes making it explicit that
bounds_of_var_in_loop only works with iranges.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-fold.cc (fold_using_range::range_of_phi): Only
query SCEV for integers.
(fold_using_range::range_of_ssa_name_with_loop_info): Remove
irange check.
---
gcc/gimple-range-fold.cc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 6f907df5bf5..7665c954f2b 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -853,12 +853,14 @@ fold_using_range::range_of_phi (vrange , gphi *phi,
fur_source )
}
// If SCEV is available, query if this PHI has any knonwn values.
- if (scev_initialized_p () && !POINTER_TYPE_P (TREE_TYPE (phi_def)))
+ if (scev_initialized_p ()
+ && !POINTER_TYPE_P (TREE_TYPE (phi_def))
+ && irange::supports_p (TREE_TYPE (phi_def)))
{
- value_range loop_range;
class loop *l = loop_containing_stmt (phi);
if (l && loop_outer (l))
{
+ int_range_max loop_range;
range_of_ssa_name_with_loop_info (loop_range, phi_def, l, phi, src);
if (!loop_range.varying_p ())
{
@@ -1337,9 +1339,7 @@ fold_using_range::range_of_ssa_name_with_loop_info
(irange , tree name,
{
gcc_checking_assert (TREE_CODE (name) == SSA_NAME);
tree min, max, type = TREE_TYPE (name);
- // FIXME: Remove the supports_p() once all this can handle floats, etc.
- if (irange::supports_p (type)
- && bounds_of_var_in_loop (, , src.query (), l, phi, name))
+ if (bounds_of_var_in_loop (, , src.query (), l, phi, name))
{
if (TREE_CODE (min) != INTEGER_CST)
{
--
2.37.1
[COMMITTED] const_tree conversion of vrange::supports_*
Make all vrange::supports_*_p methods const_tree as they can end up
being called from functions that are const_tree.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.cc (vrange::supports_type_p): Use const_tree.
(irange::supports_type_p): Same.
(frange::supports_type_p): Same.
* value-range.h (Value_Range::supports_type_p): Same.
(irange::supports_p): Same.
---
gcc/value-range.cc | 6 +++---
gcc/value-range.h | 16
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 2923f4f5a0e..7adbf55c6a6 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -105,7 +105,7 @@ vrange::type () const
}
bool
-vrange::supports_type_p (tree) const
+vrange::supports_type_p (const_tree) const
{
return false;
}
@@ -229,7 +229,7 @@ vrange::dump (FILE *file) const
}
bool
-irange::supports_type_p (tree type) const
+irange::supports_type_p (const_tree type) const
{
return supports_p (type);
}
@@ -416,7 +416,7 @@ frange::operator== (const frange ) const
}
bool
-frange::supports_type_p (tree type) const
+frange::supports_type_p (const_tree type) const
{
return supports_p (type);
}
diff --git a/gcc/value-range.h b/gcc/value-range.h
index e43fbe30f27..c6ab955c407 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -78,7 +78,7 @@ public:
virtual void accept (const class vrange_visitor ) const = 0;
virtual void set (tree, tree, value_range_kind = VR_RANGE);
virtual tree type () const;
- virtual bool supports_type_p (tree type) const;
+ virtual bool supports_type_p (const_tree type) const;
virtual void set_varying (tree type);
virtual void set_undefined ();
virtual bool union_ (const vrange &);
@@ -122,8 +122,8 @@ public:
virtual void set_undefined () override;
// Range types.
- static bool supports_p (tree type);
- virtual bool supports_type_p (tree type) const override;
+ static bool supports_p (const_tree type);
+ virtual bool supports_type_p (const_tree type) const override;
virtual tree type () const override;
// Iteration over sub-ranges.
@@ -336,7 +336,7 @@ class frange : public vrange
public:
frange ();
frange (const frange &);
- static bool supports_p (tree type)
+ static bool supports_p (const_tree type)
{
// Disabled until floating point range-ops come live.
return 0 && SCALAR_FLOAT_TYPE_P (type);
@@ -347,7 +347,7 @@ public:
virtual void set_undefined () override;
virtual bool union_ (const vrange &) override;
virtual bool intersect (const vrange &) override;
- virtual bool supports_type_p (tree type) const override;
+ virtual bool supports_type_p (const_tree type) const override;
virtual void accept (const vrange_visitor ) const override;
frange& operator= (const frange &);
bool operator== (const frange &) const;
@@ -457,7 +457,7 @@ public:
operator vrange &();
operator const vrange &() const;
void dump (FILE *) const;
- static bool supports_type_p (tree type);
+ static bool supports_type_p (const_tree type);
// Convenience methods for vrange compatability.
void set (tree min, tree max, value_range_kind kind = VR_RANGE)
@@ -588,7 +588,7 @@ Value_Range::operator const vrange &() const
// Return TRUE if TYPE is supported by the vrange infrastructure.
inline bool
-Value_Range::supports_type_p (tree type)
+Value_Range::supports_type_p (const_tree type)
{
return irange::supports_p (type) || frange::supports_p (type);
}
@@ -730,7 +730,7 @@ irange::nonzero_p () const
}
inline bool
-irange::supports_p (tree type)
+irange::supports_p (const_tree type)
{
return INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type);
}
--
2.37.1
[COMMITTED] Cleanups to frange.
These are some assorted cleanups to the frange class to make it easier
to drop in an implementation with FP endpoints:
* frange::set() had some asserts limiting the type of arguments
passed. There's no reason why we can't handle all the variants.
Worse comes to worse, we can always return a VARYING which is
conservative and correct.
* frange::normalize_kind() now returns a boolean that can be used in
union and intersection to indicate that the range changed.
* Implement vrp_val_max and vrp_val_min for floats. Also, move them
earlier in the header file so frange can use them.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.cc (tree_compare): New.
(frange::set): Make more general.
(frange::normalize_kind): Cleanup and return bool.
(frange::union_): Use normalize_kind return value.
(frange::intersect): Same.
(frange::verify_range): Remove unnecessary else.
* value-range.h (vrp_val_max): Move before frange class.
(vrp_val_min): Same.
(frange::frange): Remove set to m_type.
---
gcc/value-range.cc | 102 +
gcc/value-range.h | 70 ++-
2 files changed, 105 insertions(+), 67 deletions(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 7adbf55c6a6..dc06f8b0078 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -260,66 +260,93 @@ frange::accept (const vrange_visitor ) const
v.visit (*this);
}
-// Setter for franges. Currently only singletons are supported.
+// Helper function to compare floats. Returns TRUE if op1 .CODE. op2
+// is nonzero.
+
+static inline bool
+tree_compare (tree_code code, tree op1, tree op2)
+{
+ return !integer_zerop (fold_build2 (code, integer_type_node, op1, op2));
+}
+
+// Setter for franges.
void
frange::set (tree min, tree max, value_range_kind kind)
{
- gcc_checking_assert (kind == VR_RANGE);
- gcc_checking_assert (operand_equal_p (min, max));
gcc_checking_assert (TREE_CODE (min) == REAL_CST);
+ gcc_checking_assert (TREE_CODE (max) == REAL_CST);
+
+ if (kind == VR_UNDEFINED)
+{
+ set_undefined ();
+ return;
+}
+
+ // Treat VR_ANTI_RANGE and VR_VARYING as varying.
+ if (kind != VR_RANGE)
+{
+ set_varying (TREE_TYPE (min));
+ return;
+}
m_kind = kind;
m_type = TREE_TYPE (min);
- REAL_VALUE_TYPE *const cst = TREE_REAL_CST_PTR (min);
- if (real_isnan (cst))
-m_props.nan_set_yes ();
- else
-m_props.nan_set_no ();
-
- if (real_isinf (cst))
+ // Mark NANness.
+ if (real_isnan (TREE_REAL_CST_PTR (min))
+ || real_isnan (TREE_REAL_CST_PTR (max)))
{
- if (real_isneg (cst))
- {
- m_props.inf_set_no ();
- m_props.ninf_set_yes ();
- }
- else
- {
- m_props.inf_set_yes ();
- m_props.ninf_set_no ();
- }
+ gcc_checking_assert (operand_equal_p (min, max));
+ m_props.nan_set_yes ();
}
else
+m_props.nan_set_no ();
+
+ bool is_min = vrp_val_is_min (min);
+ bool is_max = vrp_val_is_max (max);
+
+ // Mark when the endpoints can't be INF.
+ if (!is_min)
+m_props.ninf_set_no ();
+ if (!is_max)
+m_props.inf_set_no ();
+
+ // Mark when the endpoints are definitely INF.
+ if (operand_equal_p (min, max))
{
- m_props.inf_set_no ();
- m_props.ninf_set_no ();
+ if (is_min)
+ m_props.ninf_set_yes ();
+ else if (is_max)
+ m_props.inf_set_yes ();
}
+ // Check for swapped ranges.
+ gcc_checking_assert (m_props.nan_yes_p ()
+ || tree_compare (LE_EXPR, min, max));
+
if (flag_checking)
verify_range ();
}
-// Normalize range to VARYING or UNDEFINED, or vice versa.
+// Normalize range to VARYING or UNDEFINED, or vice versa. Return
+// TRUE if anything changed.
//
// A range with no known properties can be dropped to VARYING.
// Similarly, a VARYING with any properties should be dropped to a
// VR_RANGE. Normalizing ranges upon changing them ensures there is
// only one representation for a given range.
-void
+bool
frange::normalize_kind ()
{
if (m_kind == VR_RANGE)
{
// No FP properties set means varying.
- if (m_props.nan_varying_p ()
- && m_props.inf_varying_p ()
- && m_props.ninf_varying_p ())
+ if (m_props.varying_p ())
{
set_varying (m_type);
- return;
+ return true;
}
// Undefined is viral.
if (m_props.nan_undefined_p ()
@@ -327,17 +354,19 @@ frange::normalize_kind ()
|| m_props.ninf_undefined_p ())
{
set_undefined ();
- return;
+ return true;
}
}
else if (m_kind == VR_VARYING)
{
// If a VARYING has any FP properties, it's no longer VARYING.
- if (!m_props.nan_varying_p ()
- || !m_props.inf_varying_p ()
- || !m_props.ninf_varying_p ())
- m_kind = VR_RANGE;
+
