Re: [PATCH][Middle-end]patch for fixing PR 86519

[Jeff Law <law@redhat.com>]

On 08/23/2018 10:13 AM, Qing Zhao wrote:
> 
>> On Aug 22, 2018, at 5:01 PM, Jeff Law <law@redhat.com> wrote:
>>
>> On 08/22/2018 11:05 AM, Qing Zhao wrote:
>>>
>>>> On Aug 22, 2018, at 10:50 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>>>>
>>>> Hi Qing,
>>>>
>>>>> From the comments you put into PR86519, for SPARC, looks like that only
>>>>> 32-bit sparc has the problem.
>>>>> sparcv9 does NOT have the same issue.
>>>>>
>>>>> I was trying to find the string to represent 32-bit sparc target, but
>>>>> haven’t found it.
>>>>>
>>>>> my guess is:   sparc32*-*-*,  is this correct?
>>>>
>>>> no, certainly not.  You need to use something like sparc*-*-* && ilp32
>>>> to catch the 32-bit multilib in both sparc-*-* and sparcv9-*-*
>>>> configurations.  This is similar to { i?86-*-* x86_64-*-* } && ilp32 on x86.
>>>
>>> thanks for the info.
>>>
>>>>
>>>> I'm still doubtful that enumerating target after target which all fail
>>>> the original test for unrelated reasons is the way to go, especially
>>>> given that there are others affected besides mips and sparc.
>>>
>>> I am not sure, either.
>>>
>>> however, given the available directives provided in testing suite, what’s the better solution
>>> to this problem?
>> We could move the test into the i386 target specific test directory.
>> It'll still get good coverage that way and it'll be naturally restricted
>> to a target where we don't have to worry about the function name we're
>> scanning for showing up in undesirable contexts.
> 
> I will do this.  is it better to add it to both i386 and aarch64 target?
If we've got verification that it's working on aarch64, then adding it
to both is fine.

jeff
>