On Sat, 19 Aug 2023, 11:45 FX Coudert, wrote:
> Hi,
>
> > That seems like a bug in the aarch64-darwin port.
> > 1.0q should definitely be __float128 rather than _Float128.
>
> Is there a simple way to test what type 1.0q is, in C? I tried using
> _Generic, but it says
>
> > a.c:7:52: error: ‘_Gen
Hi,
> That seems like a bug in the aarch64-darwin port.
> 1.0q should definitely be __float128 rather than _Float128.
Is there a simple way to test what type 1.0q is, in C? I tried using _Generic,
but it says
> a.c:7:52: error: ‘_Generic’ specifies two compatible types
> 7 | int i = _Gene
On Sat, Aug 19, 2023 at 11:58:31AM +0200, Jakub Jelinek via Gcc wrote:
> well. So, if aarch64-darwin wants 64-bit long double, the question is if
> it should have __float128 support and q suffix support at all. If it
> should, then it needs to initialize float128t_type_node to a distinct type
> i
On Sat, Aug 19, 2023 at 10:25:50AM +0100, Jonathan Wakely wrote:
> On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc wrote:
> >
> > Hello,
> >
> > On the WIP aarch64-darwin port of GCC
> > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> > failures which are due to the
Hi,
> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.
That’s weird. I create it in this way:
+ /* Populate the float128 node if it is not already done so that the FEs
+ know it is available. */
+ if (float128_type_node == NULL_TREE)
+{
+ float128_type_node =
On Fri, 18 Aug 2023 at 20:08, FX Coudert via Gcc wrote:
>
> Hello,
>
> On the WIP aarch64-darwin port of GCC
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> failures which are due to the following:
>
> 1. The testsuite check_effective_target_has_q_floating_suffix ch
Hi Jakub,
I should have pinged you, I see you recently touched that code.
FX
> Le 18 août 2023 à 21:07, FX Coudert a écrit :
>
> Hello,
>
> On the WIP aarch64-darwin port of GCC
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite
> failures which are due to the foll
>Just for the record (in case someone else has the same thoughts)
>and because I'd already written most of the reply, I also
>replied to your first email. See last for your follow-up.
>
>> What has the alignment of type 'long long' to do with structure
>> packing?
>
>Only the obvious(?): if long l
> Date: Wed, 07 Dec 2005 09:18:53 +0100
> From: "Jan Beulich" <[EMAIL PROTECTED]>
Just for the record (in case someone else has the same thoughts)
and because I'd already written most of the reply, I also
replied to your first email. See last for your follow-up.
> What has the alignment of type
>> While most of these changes appear to be correct, I see a regression
on
>> *-*-netware* (which by default uses packed structures) in
>> gcc.dg/20030321-1.c, and I believe the warning tested for cannot be
>> expected (since the code generating the warning tests
>>
>> TYPE_ALIGN (TREE_TYPE (*node
>> While most of these changes appear to be correct, I see a regression
on
>> *-*-netware* (which by default uses packed structures) in
>> gcc.dg/20030321-1.c, and I believe the warning tested for cannot be
>> expected (since the code generating the warning tests
>>
>> TYPE_ALIGN (TREE_TYPE (*node
> Date: Tue, 06 Dec 2005 18:02:51 +0100
> From: "Jan Beulich" <[EMAIL PROTECTED]>
> >2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]>
> >
> > * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c,
> > gcc.dg/pr17112-1.c, g++.dg/other/packed1.C,
> > g++.dg/other/crash-4.C, g
12 matches
Mail list logo
