> On Aug 22, 2018, at 5:01 PM, Jeff Law <l...@redhat.com> wrote:
>
> On 08/22/2018 11:05 AM, Qing Zhao wrote:
>>
>>> On Aug 22, 2018, at 10:50 AM, Rainer Orth <r...@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?
Qing
>
> Another approach might be to scan the RTL dumps. But if there were a
> target that didn't have direct jumps and requires a hi+lo_sum style
> sequence to load a symbolic constant it would fail.
>
> jeff
