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

[Qing Zhao <qing.zhao@oracle.com>]

> 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?

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