[PATCH] Fix pr67963

[H.J. Lu]

On Fri, Oct 16, 2015 at 3:31 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Oct 16, 2015 at 2:35 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> On Fri, Oct 16, 2015 at 8:43 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>> On Thu, Oct 15, 2015 at 9:30 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
>>>
>>>>>>> Do we support -O2 -march=lakemont with
>>>>>>>
>>>>>>> __attribute__((target("arch=silvermont")))
>>>>>>
>>>>>> Hm, no.
>>>>>>
>>>>>
>>>>> Do we issue an error or silently ignore
>>>>> __attribute__((target("arch=silvermont")))?
>>>>> If we don't support it, should we support
>>>>>
>>>>> -O2 -march=silvermont
>>>>>
>>>>> __attribute__((target("arch=lakemont")))
>>>>
>>>> Actually, we have to re-initialize:
>>>>
>>>>   opts->x_target_flags
>>>>     |= (TARGET_DEFAULT | TARGET_SUBTARGET_DEFAULT) & ~opts_set->x_target_flags;
>>>>
>>>> just before TARGET_SUBTARGET{32,64}_DEFAULT processing, and it will work.
>>>
>>> No, this won't work. The value of MASK_NO_FANCY_MATH depend on
>>> MASK_80387setting, and once fancy math bit is set, it couldn't be
>>> cleared for march != lakemont.
>>>
>>> It looks just like we want to error out when lakemont is enabled with -m80387.
>>
>> Like in the attached patch, that also slightly improves existing error
>> reporting.
>>
>
> We should use a bit instead of checking PROCESSOR_LAKEMONT
> so that we don't need to check another PROCESSOR_XXX for
> a new IA MCU processor.
>

Another related bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67985

We may be able to fix both in a patch.

-- 
H.J.