[patch] tighten toplevel guard on ibm-ldouble.c

[patch] tighten toplevel guard on ibm-ldouble.c

[Olivier Hainque]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

Hello,

With a forthcoming micro cleanup patch to the 32bits powerpc-vxworks
port (arranging to define __powerpc__ in addition to a few others), 
the port fails to build with:

  In file included from ../../../../src/libgcc/config/rs6000/ibm-ldouble.c:384:
  ../../../../src/libgcc/soft-fp/quad.h:72:1: error: unable to emulate 'TF'

The port doesn't support 128bit floats so the attempt to compile
ibm-ldouble.c is surprising.

The whole source is guarded with a number of conditions already:

#if (defined (__MACH__) || defined (__powerpc__) || defined (_AIX)) \
  && !defined (__rtems__)

The file starts with:

/* 128-bit long double support routines for Darwin.

so presumably none of this is needed when the target
doesn't have support for 128bit FP types at all.

rs6000_init_libfuncs tells us when we get to initialize
float128 libcalls:

rs6000_init_libfuncs (void)
{
/* __float128 support.  */
if (TARGET_FLOAT128_TYPE)
  ...

/* AIX/Darwin/64-bit Linux quad floating point routines.  */
if (TARGET_LONG_DOUBLE_128)
  ...
}

Then rs6000_cpu_cpp_builtins tells what macros get
defined when the two target attributes above are true:

if (TARGET_FLOAT128_TYPE)
  builtin_define ("__FLOAT128_TYPE__");

if (TARGET_LONG_DOUBLE_128)
  {
    builtin_define ("__LONG_DOUBLE_128__");

This suggests the attached patchlet, which cures the VxWorks
build issue.

I'd appreciate feedback on the idea before going on with
further testing deemed appropriate.

How does that look ?

Thanks in advance!

With Kind Regards,

Olivier

2018-10-03  Olivier Hainque  <hainque@adacore.com>

	libgcc/
	* config/rs6000/ibm-ldouble.c: Augment the toplevel guard with
	defined (__FLOAT128_TYPE__) || defined (__LONG_DOUBLE_128__).


[-- Attachment #2: ibm-ldouble.diff --]
[-- Type: application/octet-stream, Size: 512 bytes --]

--- libgcc/config/rs6000/ibm-ldouble.c
+++ libgcc/config/rs6000/ibm-ldouble.c
@@ -46,7 +46,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
    the lower numbered register or lower addressed memory.  */
 
 #if (defined (__MACH__) || defined (__powerpc__) || defined (_AIX)) \
-    && !defined (__rtems__)
+  && !defined (__rtems__) \
+  && (defined (__LONG_DOUBLE_128__) || defined (__FLOAT128_TYPE__))
 
 #define fabs(x) __builtin_fabs(x)
 #define isless(x, y) __builtin_isless (x, y)

Re: [patch] tighten toplevel guard on ibm-ldouble.c

[Segher Boessenkool]

Hi Olivier,

On Wed, Oct 03, 2018 at 09:35:35PM +0200, Olivier Hainque wrote:
> With a forthcoming micro cleanup patch to the 32bits powerpc-vxworks
> port (arranging to define __powerpc__ in addition to a few others), 
> the port fails to build with:
> 
>   In file included from ../../../../src/libgcc/config/rs6000/ibm-ldouble.c:384:
>   ../../../../src/libgcc/soft-fp/quad.h:72:1: error: unable to emulate 'TF'
> 
> The port doesn't support 128bit floats so the attempt to compile
> ibm-ldouble.c is surprising.
> 
> The whole source is guarded with a number of conditions already:
> 
> #if (defined (__MACH__) || defined (__powerpc__) || defined (_AIX)) \
>   && !defined (__rtems__)
> 
> The file starts with:
> 
> /* 128-bit long double support routines for Darwin.
> 
> so presumably none of this is needed when the target
> doesn't have support for 128bit FP types at all.
> 
> rs6000_init_libfuncs tells us when we get to initialize
> float128 libcalls:
> 
> rs6000_init_libfuncs (void)
> {
> /* __float128 support.  */
> if (TARGET_FLOAT128_TYPE)
>   ...
> 
> /* AIX/Darwin/64-bit Linux quad floating point routines.  */
> if (TARGET_LONG_DOUBLE_128)
>   ...
> }
> 
> Then rs6000_cpu_cpp_builtins tells what macros get
> defined when the two target attributes above are true:
> 
> if (TARGET_FLOAT128_TYPE)
>   builtin_define ("__FLOAT128_TYPE__");
> 
> if (TARGET_LONG_DOUBLE_128)
>   {
>     builtin_define ("__LONG_DOUBLE_128__");
> 
> This suggests the attached patchlet, which cures the VxWorks
> build issue.
> 
> I'd appreciate feedback on the idea before going on with
> further testing deemed appropriate.
> 
> How does that look ?

I think it looks fine.  Okay for trunk after some testing.

(Please don't use application/octet-stream for patches btw).


Segher

Re: [patch] tighten toplevel guard on ibm-ldouble.c

[Olivier Hainque]

Hi Segher,

> On 05 Oct 2018, at 11:35, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
> I think it looks fine.  Okay for trunk after some testing.

Thanks for your feedback.

I can't get a pristine mainline to build on our powerpc-linux
host - SEGVs from the newly built cc1 during libgcc. Updated
ulimits helped a bit, investigating ...

> (Please don't use application/octet-stream for patches btw).

Ah, huh, ok. My mailer probably picked the
attachement type from the .diff extension. 

Thanks for the note, I'll see what I can do. 

Cheers,

Olivier

Re: [patch] tighten toplevel guard on ibm-ldouble.c

[Olivier Hainque]

Hi Segher,

> On 8 Oct 2018, at 04:42, Olivier Hainque <hainque@adacore.com> wrote:
> 
>> I think it looks fine.  Okay for trunk after some testing.
> 
> I can't get a pristine mainline to build on our powerpc-linux
> host - SEGVs from the newly built cc1 during libgcc. Updated
> ulimits helped a bit, investigating ...

Sorted the SEGVs out. The patch bootstraps on powerpc-linux
and the resulting libgcc's all have contents for ibm-ldouble.o,
unlike when building for powerpc-vxworks.

Will commit.

Thanks again for your feedback!

With Kind Regards,

Olivier