public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Joseph Myers <joseph@codesourcery.com>,
	Christophe Lyon <christophe.lyon@linaro.org>,
	law@redhat.com
Subject: Re: c: ignore initializers for elements of variable-size types [PR93577]
Date: Mon, 16 Mar 2020 18:59:34 +0000	[thread overview]
Message-ID: <mptsgi86s89.fsf@arm.com> (raw)
In-Reply-To: <CAKdteOaM0DEtVFBqf8RAMOn+EsQf-GqpjgVLdGwDJWGSgk77og@mail.gmail.com> (Christophe Lyon via Gcc-patches's message of "Fri, 13 Mar 2020 13:32:10 +0100")

Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> On Wed, 11 Mar 2020 at 00:37, Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> On Tue, 10 Mar 2020, Christophe Lyon wrote:
>>
>> > sizeless-1.c and sizeless-2.c have the same code, but the latter is
>> > compiled with -msve-vector-bits=256 and expects different
>> > warnings/errors.
>> > For line 33:
>> > svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr };
>> > we now have:
>> > sizeless-1.c:33:44: error: empty scalar initializer
>> > sizeless-1.c:33:44: note: (near initialization for '(anonymous)')
>> > and
>> > sizeless-2.c:33:44: error: initializer element is not constant
>> > sizeless-2.c:33:44: note: (near initialization for 'invalid_sve_sc_ptr')
>> > sizeless-2.c:33:44: error: SVE type 'svint8_t' does not have a fixed size
>> > so I think the error comes from the compound literal being treated
>> > differently with -msve-vector-bits=256
>>
>> I think the sizeless-2.c diagnostics are correct while there's a problem
>> in the sizeless-1.c case (the initializer is not empty, so it should not
>> be diagnosed as such).
>>
>> Does the process_init_element code
>>
>>   /* Ignore elements of an initializer for a variable-size type.
>>      Those are diagnosed in digest_init.  */
>>   if (COMPLETE_TYPE_P (constructor_type)
>>       && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
>>     return;
>>
>> fire for the sizeless-1.c case?  If so, maybe it needs to be restricted in
>> some way to apply only to variable size structs / unions / arrays rather
>> than whatever kind of variable-size type the SVE types are.
>
> It does. Type_size has POLY_INT_CST type.
>
> The attached small patch fixes the problem (tested on arm and aarch64).
> OK?

Thanks for doing this.  I'd wondered whether it should be based on
this or on VECTOR_TYPE_P, but FWIW, I agree basing it on this is best.

> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index d8025de..1302486 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -9968,7 +9968,8 @@ process_init_element (location_t loc, struct
> c_expr value, bool implicit,
>    /* Ignore elements of an initializer for a variable-size type.
>       Those are diagnosed in digest_init.  */
>    if (COMPLETE_TYPE_P (constructor_type)
> -      && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
> +      && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST
> +      && TREE_CODE (TYPE_SIZE (constructor_type)) != POLY_INT_CST)

Not worth respinning over, but since it hasn't been applied yet:
a shorter alternative is to replace the != INTEGER_CST test with
!poly_int_tree_p.

> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> index ec892a3..e53b871 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> @@ -83,7 +83,6 @@ statements (int n)
>    svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> type 'svint8_t'} } */
>    svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>    svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> cannot have SVE type 'svint8_t'} } */
> -                                   /* { dg-error {empty scalar
> initializer} "" { target *-*-* } .-1 } */
>    typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>
>    /* Assignment.  */
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> index 7174393..9986d27 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> @@ -83,7 +83,6 @@ statements (int n)
>    svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> type 'svint8_t'} } */
>    svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>    svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> cannot have SVE type 'svint8_t'} } */
> -                                   /* { dg-error {empty scalar
> initializer} "" { target *-*-* } .-1 } */
>    typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> have SVE type 'svint8_t'} } */
>
>    /* Assignment.  */

Jeff pointed out off-list that using:

   N:  ... /* { dg-error {...} } */
 N+1:      /* { dg-error {...} "" { target *-*-* } .-1 } */

led to two identical test names for line N.  This was causing the
results to fluctuate when using contrib/compare_tests (which I admit
I don't do, so hadn't noticed).  Your patch fixes the cases that
mattered, but for future-proofing reasons, this patch adds proper
test names for the remaining instances.

Tested on aarch64-linux-gnu and committed as obvious.

Richard


2020-03-16  Richard Sandiford  <richard.sandiford@arm.com>

gcc/testsuite/
	* gcc.target/aarch64/sve/acle/general-c/sizeless-1.c: Add a test
	name to .-1 dg-error tests.
	* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c: Likewise.
---
 .../gcc.target/aarch64/sve/acle/general-c/sizeless-1.c          | 2 +-
 .../gcc.target/aarch64/sve/acle/general-c/sizeless-2.c          | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
index ec892a3fc83..045963d5c76 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
@@ -31,7 +31,7 @@ union union1 {
 
 svint8_t *global_sve_sc_ptr;
 svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr }; /* { dg-error {initializer element is not constant} } */
-  /* { dg-error {SVE type 'svint8_t' does not have a fixed size} "" { target *-*-* } .-1 } */
+  /* { dg-error {SVE type 'svint8_t' does not have a fixed size} "2nd line" { target *-*-* } .-1 } */
 
 /* Sizeless arguments and return values.  */
 
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
index 71743930098..c7282faba46 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
@@ -31,7 +31,7 @@ union union1 {
 
 svint8_t *global_sve_sc_ptr;
 svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr }; /* { dg-error {initializer element is not constant} } */
-  /* { dg-error {SVE type 'svint8_t' does not have a fixed size} "" { target *-*-* } .-1 } */
+  /* { dg-error {SVE type 'svint8_t' does not have a fixed size} "2nd line" { target *-*-* } .-1 } */
 
 /* Sizeless arguments and return values.  */
 

  parent reply	other threads:[~2020-03-16 18:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 23:50 Joseph Myers
2020-03-09 14:58 ` Christophe Lyon
2020-03-10  0:51   ` Joseph Myers
2020-03-10 16:18     ` Christophe Lyon
2020-03-10 23:37       ` Joseph Myers
2020-03-13 12:32         ` Christophe Lyon
2020-03-13 21:47           ` Joseph Myers
2020-03-16 18:59           ` Richard Sandiford [this message]
2020-03-17  9:50             ` Christophe Lyon
2020-03-17 13:27             ` Christophe Lyon
2020-03-18 20:55               ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mptsgi86s89.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=christophe.lyon@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).