On Fri, Oct 16, 2015 at 3:31 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Fri, Oct 16, 2015 at 2:35 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>> On Fri, Oct 16, 2015 at 8:43 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>> On Thu, Oct 15, 2015 at 9:30 PM, Uros Bizjak <ubiz...@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.
