This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] build-many-glibcs: Remove no_isolate from SH config
On 13/03/2017 20:44, Adhemerval Zanella wrote:
>
>
> On 13/03/2017 20:17, Joseph Myers wrote:
>> On Mon, 13 Mar 2017, Adhemerval Zanella wrote:
>>
>>> On 13/03/2017 13:40, Joseph Myers wrote:
>>>> On Mon, 13 Mar 2017, Adhemerval Zanella wrote:
>>>>
>>>>> Now with d40dbe7 SH build does not require more the no_isolate gcc
>>>>> options to correct build glibc (since SH build now does not generate
>>>>> a trap anymore). This patch removes the unrequired options from
>>>>> SH config.
>>>>
>>>> no_isolate is *only* used for SH, so should be removed completely if
>>>> removed from use for SH.
>>>>
>>>
>>> Right, I thought about letting the options for possible other future
>>> architectures that might face the same issue. I will remove it.
>>
>> It seems this broke the build for SH with GCC mainline (same
>> multiple-definitions errors that are symptoms of needing these options);
>> please revert.
>>
>> https://sourceware.org/ml/libc-testresults/2017-q1/msg00248.html
>>
>
> Right, I will revert and check what is not failing with default
> version.
>
Joseph, I tracked down the issue and it is due the snippet:
sysdeps/wordsize-32/divdi3.c:
133 else
134 {
135 /* qq = NN / 0d */
136
137 if (d0 == 0)
138 d0 = 1 / d0; /* Divide intentionally by zero. */
GCC 6.3 and older lowers it to a software division call (__sdivsi3_i4i)
while GCC 7.0 with -fisolate-erroneous-paths-dereference found the
undefined behaviour and transform to a trap and subsequent abort call.
So I think we have some options:
1. Revert the patch and make SH toolchain compile with
-fno-isolate-erroneous-paths-dereference (there is no need for
add -fno-isolate-erroneous-paths-attribute).
2. Build divdi3 for SH explicit with -fno-isolate-erroneous-paths-attribute.
3. Port libgcc r205444 with add an __udivmoddi4 implementation for
architectures that do not have division instruction (which does not
generate a trap for division by 0).
I would prefer either 2 or 3.