Hello, Kewen,

Thanks for the feedback.

On Mar 27, 2023, "Kewen.Lin" <li...@linux.ibm.com> wrote:

> on 2023/3/25 16:37, Alexandre Oliva via Gcc-patches wrote:
>> 
>> When long double is 64-bit wide, as on vxworks, the rs6000 backend
>> defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but
>> pr99708.c expected both to be always defined.  Adjust the test to
>> match the implementation.

> There is one patch from Mike to define type __ibm128 even without
> IEEE 128-bit floating point support, it's at the link:

> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599984.html

> I would expect this issue would be gone if the adjustment on the
> support of type __ibm128 gets landed in future.

Yeah, the issue would then be gone, but the patch is compatible with
that proposed change: if __ibm128 and the corresponding SIZEOF macro are
defined, the proposed change is a no-op.

> So maybe we can just xfail this for longdouble64?  What do you
> think?

I wouldn't object to that, and I could even write and test the alternate
patch for that, but I fail to understand why that would be more
desirable.  Would you be so kind as to enlighten me?

Thanks,

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Reply via email to