This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][Middle-end]patch for fixing PR 86519
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.
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