On 08/23/2017 01:12 AM, Uros Bizjak wrote:
> On Wed, Aug 23, 2017 at 7:23 AM, Daniel Santos <daniel.san...@pobox.com>
> wrote:
>> On 08/22/2017 03:00 PM, Uros Bizjak wrote:
>>> On Tue, Aug 22, 2017 at 9:47 PM, Daniel Santos <daniel.san...@pobox.com>
>>> wrote:
>>>>> Please add UNKNOWN_ABI to the enum and initialize -mabi in i386.opt to
>>>>> UNKNOWN_ABI.
>>>> It would seem to me that UNSPECIFIED_ABI would be a better value name.
>>>>
>>>> Also, I don't really understand what opts_set and opts are, except that I
>>>> had
>>>> guessed opts_set is what the user asked for (or didn't ask for) and opts is
>>>> what we're going to actually use. Am I close?
>>> Yes. opts_set is a flag that user specified an option at the command line.
>>>
>>> However, I fail to see what is the problem. If nothing was specified,
>>> then opts->x_ix86_abi is set to DEFAULT_ABI.
>> That is not what is happening. If -mabi=sysv is specified, then the
>> test (!opts_set->x_ix86_abi) is true since the value of SYSV_ABI is
>> zero. When that is evaluated as true, then the abi is set to
>> DEFAULT_ABI, which on Windows is MS_ABI, thus ignoring the command line
>> option.
> Let's use the following patch:
>
> --cut here--
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 3c82ae64f4f2..f8590f663285 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -5682,7 +5682,7 @@ ix86_option_override_internal (bool main_args_p,
> ? PMODE_DI : PMODE_SI;
>
> if (!opts_set->x_ix86_abi)
> - opts->x_ix86_abi = DEFAULT_ABI;
> + printf ("Using default ABI\n"), opts->x_ix86_abi = DEFAULT_ABI;
>
> /* For targets using ms ABI enable ms-extensions, if not
> explicit turned off. For non-ms ABI we turn off this
> --cut here--
>
> $ ./cc1 -O2 -quiet hello.c
> Using default ABI
> $ ./cc1 -O2 -mabi=sysv -quiet hello.c
> $
> $ ./cc1 -O2 -mabi=sysv -quiet hello.c
> $
>
> Again, opts_set is set to true when the option is specified on the
> command line, it has nothing to do with the value of the option.
Interesting, I get the same result and in fact I can't reproduce the bug
anymore. Either I made a mistake somewhere (likely) or something else
fixed the problem (less likely). I'll try again from where the trunk
was when I filed the bug and close it either invalid or fixed depending
upon which it is.
Thanks!
Daniel
>> I'm guessing that if we don't specify an Init() option then it will
>> default to zero? We just need a valid way to differentiate when
>> -mabi=sysv has been passed from when nothing has been passed.
> Yes, it defaults to zero, but since we live in c++ world nowadays, we
> can't initialize enum with integer zero...
>
> Uros.
