This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ICE with -fno-sso-struct=none (PR driver/78957)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 4 Jan 2017 13:31:28 +0100
- Subject: Re: [PATCH] Fix ICE with -fno-sso-struct=none (PR driver/78957)
- Authentication-results: sourceware.org; auth=none
- References: <20170102192726.GH21933@tucnak> <CAFiYyc3jFQXnsGSV5iuJuEc6cm0Sa=3=amDcirP46brRpRvXjw@mail.gmail.com> <20170104114031.GI21933@tucnak>
On Wed, Jan 4, 2017 at 12:40 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Jan 04, 2017 at 12:27:09PM +0100, Richard Biener wrote:
>> On Mon, Jan 2, 2017 at 8:27 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > Enum options should not allow negative form, otherwise the option handling
>> > ICEs on it. -fsso-struct= allows only big-endian or little-endian,
>> > -fno-sso-struct=big-endian or -fno-sso-struct=whatever makes no sense.
>> >
>> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> Ok, but maybe .opt processing can add RejectNegative on its own for
>> Enum switches then?
>
> Rather than implicit RejectNegative it might be better to just diagnose
> such options as invalid. If you agree, I can implement that as follow-up.
> Also note that RejectNegative is only needed on the Enum switches that have
> the default negatives (that is [Wfm] prefixed I think).
That would be nice.
>> For the vectorizer we have (for backward compatibility):
>>
>> fvect-cost-model
>> Common RejectNegative Alias(fvect-cost-model=,dynamic)
>> Enables the dynamic vectorizer cost model. Preserved for backward
>> compatibility.
>>
>> fno-vect-cost-model
>> Common RejectNegative Alias(fvect-cost-model=,unlimited)
>> Enables the unlimited vectorizer cost model. Preserved for backward
>> compatibility.
>
> That is a non-= non-Enum option though.
Yes, we do have the Enum variant (with RejectNegative) as well.
> And not sure why this actually
> is RejectNegative, wouldn't
> Common Alias(fvect-cost-model=,dynamic,unlimited)
> work just on fvect-cost-model (can test that)?
Good question ;) If it works, ok.
> In this case there is no -fsso-struct option (what would it mean), so
> -fno-sso-struct isn't there either (again, what would that mean).
> The only thing that would make sense IMHO would be to allow
> not just big-endian and little-endian, but also native, so one can
> cancel earlier -fsso-struct= like
> gcc ... -fsso-struct=little-endian ... -fsso-struct=native ...
> and have it act as if neither of those options appeared.
> CCing Eric who has added this option.
Yeah, I agree for -fsso-struct it doesn't make sense to have a -fno-sso-struct.
For the vectorizer we transitioned from -f[no-]vect-cost-model to a
tristate using an Enum and keeping the old form working was requied.
Richard.
>
> Jakub