This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix ICE with -fno-sso-struct=none (PR driver/78957)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]