on 2022/12/13 14:14, Michael Meissner wrote:
> On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote:
>> Without or with patch #1, the below ICE in libgcc exists, the ICE should have
>> nothing to do with the special handling for building_libgcc in patch #1. I
>> think patch #2 which makes
On Tue, Dec 13, 2022 at 01:14:39AM -0500, Michael Meissner wrote:
> On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote:
> > Without or with patch #1, the below ICE in libgcc exists, the ICE should
> > have
> > nothing to do with the special handling for building_libgcc in patch #1. I
> >
I have submitted a new replacement patch for this patch:
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608368.html
--
Michael Meissner, IBM
PO Box
On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote:
> Without or with patch #1, the below ICE in libgcc exists, the ICE should have
> nothing to do with the special handling for building_libgcc in patch #1. I
> think patch #2 which makes _Float128 and __float128 use the same internal
>
on 2022/12/9 06:04, Michael Meissner wrote:
> On Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>> on 2022/12/7 14:44, Michael Meissner wrote:
>>> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
Hi Mike,
Thanks for fixing this!
Could you
On Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> on 2022/12/7 14:44, Michael Meissner wrote:
> > On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
> >> Hi Mike,
> >>
> >> Thanks for fixing this!
> >>
> >> Could you help to elaborate why we need to disable it
Hi Mike,
on 2022/12/7 14:44, Michael Meissner wrote:
> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>> Thanks for fixing this!
>>
>> Could you help to elaborate why we need to disable it during libgcc building?
>
> When you are building libgcc, you are building the
On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> Thanks for fixing this!
>
> Could you help to elaborate why we need to disable it during libgcc building?
When you are building libgcc, you are building the __mulkc3, __divkc3
functions. The mapping in the compiler
Hi Mike,
Thanks for fixing this!
on 2022/11/2 10:40, Michael Meissner wrote:
> This function reworks how the complex multiply and divide built-in functions
> are
> done. Previously we created built-in declarations for doing long double
> complex
> multiply and divide when long double is IEEE
] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
| https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604835.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Can we please get this patch reviewed? GCC 13 won't build on Fedora 37 (which
defaults to long double being IEEE 128-bit) without the 3 patches in this set.
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID
Ping patch:
| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR
target/107299
| Message-ID:
This patch is needed to build GCC on Fedora 36 where the default for long
double is now IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Ayer
This function reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long
13 matches
Mail list logo
