Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #17

[David Edelsohn]

On Tue, Oct 27, 2015 at 12:44 PM, Michael Meissner
 wrote:
> This patch adds a test to make sure __float128 and __ibm128 are not allowed to
> be combined in binary operations.  I re-ran the test suite on power8 little
> endian, and this test passed. Once the preceeding 16 patches are applied to 
> the
> tree, is this patch ok to commit into trunk?
>
> 2015-10-27  Michael Meissner  
>
> * gcc.target/powerpc/float128-mix.c: New test for IEEE 128-bit
> floating point.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #16

[David Edelsohn]

On Fri, Oct 23, 2015 at 2:03 PM, Michael Meissner
 wrote:
> This patch adds a test to make sure __float128 are passed and returned like
> vector objects, and not as IBM extended double did.
>
> This is the last subpatch of patch #7.  I have bootstrapped the compiler with
> all 16 subpatches installed, and there were no regressions.  Is it ok to
> install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * gcc.target/powerpc/float128-call.c: New test for -mfloat128 on
> PowerPC.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #06

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:40 PM, Michael Meissner
 wrote:
> This patch sets up all of the emulation functions.
>
> I have built the compiler with this patch and the previous subpatches (1-4).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.c (rs6000_init_libfuncs): Split libfunc
> setup into 3 functions: init_float128_ibm, init_float128_ieee, and
> rs6000_init_libfuncs. If -mfloat128, add IFmode functions for all
> of the traditional names that TFmode uses for handling IEEE
> extended double. If -mfloat128, add KFmode functions for all of
> the emulation functions. If -mabi=ieeelongdouble and -mfloat128,
> make TFmode use the same emulation functions as KFmode.
> (init_float128_ibm): Likewise.
> (init_float128_ieee): Likewise.

This seems to change the logic for initializing Darwin and AIX
libfuncs.  It may not be wrong, but I am a little concerned.  I
believe that they were defined unconditionally before and now they
only are defined if TARGET_LONG_DOUBLE_128.

Am I misunderstanding something?

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #09

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:47 PM, Michael Meissner
 wrote:
> This patch is the new patch from the last submission. It sets up a hook so 
> that
> the compiler will not allow IBM extended double and IEEE 128-bit floating 
> point
> to intermix in a binary expression without using an explicit conversion.
>
> I have built the compiler with this patch and the previous subpatches (1-8).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.c (TARGET_INVALID_BINARY_OP): Do not allow
> inter-mixing of IEEE 128-bit floating point with IBM extended
> double floating point.
> (rs6000_invalid_binary_op): Likewise.

Okay.  Assuming that Joseph's concerns are addressed in subsequent patches.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #07

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:43 PM, Michael Meissner
 wrote:
> This patch updates to use the unordered comparison function for IEEE 128-bit
> floating point to mimic the behaviour of SFmode/DFmode using the fcmpu
> instruction.
>
> It also restructures the code to allow a future change to drop in easier.
>
> I have built the compiler with this patch and the previous subpatches (1-6).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.c (rs6000_generate_compare): For IEEE
> 128-bit floating point comparisons, call the unordered comparison
> function instead of the ordered comparison function.
> (rs6000_expand_float128_convert): Deal with operands that are
> memory operands. Restructure the code to use a switch statement on
> the mode. Add support for TFmode defaulting to either IBM extended
> double or IEEE 128-bit floating point. If the underlying types are
> the same, use a move instead of a conversion function.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #15

[David Edelsohn]

On Fri, Oct 23, 2015 at 2:01 PM, Michael Meissner
 wrote:
> This patch adds the documentation.
>
> I have built the compiler with this patch and the previous subpatches (1-14).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * doc/extend.texi (Floating Types): Document __ibm128 and
> __float128 on PowerPC.
>
> * doc/invoke.texi (RS/6000 and PowerPC Options): Document
> -mfloat128 and -mno-float128.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #04

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:36 PM, Michael Meissner
 wrote:
> This patch allows SUBREG's for the reg_or_indexed_operand, which is used when
> you have an integral value in a float/vector register, and you want to move 
> the
> value (either via direct move on power8, or via store).
>
> I have built the compiler with this patch and the previous subpatches (1-3).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/predicates.md (reg_or_indexed_operand): Allow
> SUBREGs.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #14

[David Edelsohn]

On Fri, Oct 23, 2015 at 2:00 PM, Michael Meissner
 wrote:
> This patch makes TFmode be fully switchable for comparisons.
>
> I have built the compiler with this patch and the previous subpatches (1-13).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.md (cmptf_internal1): Use a mode iterator
> to add support for both types (IFmode, TFmode) that support IBM
> extended double.
> (cmp_internal1): Likewise.
> (cmptf_internal2): Likewise.
> (cmp_internal2): Likewise.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #05

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:39 PM, Michael Meissner
 wrote:
> This patch prevents the compiler from calling the IEEE 128-bit emulation
> functions with the vector value in both GPRs and vector registers due to the
> fact that the library function did not have a prototype.
>
> I have built the compiler with this patch and the previous subpatches (1-4).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.c (init_cumulative_args): Initialize
> libcall field in CUMULATIVE_ARGS.
> (rs6000_function_arg): Treat library functions as if they had
> prototypes to prevent IEEE 128-bit support functions from passing
> arguments in both GPRs and vector registers.
> (rs6000_arg_partial_bytes): Likewise.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #02

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:30 PM, Michael Meissner
 wrote:
> This patch changes the switch from -mfloat128-software and -mfloat128-none to
> be a binary switch, -mfloat128 and -mno-float128.  It also provides some of 
> the
> basic setup for IEEE types.  It also removes code I had put in a previous 
> patch
> that doesn't allow IFmode/KFmode to go in any register if -mno-float128 (this
> causes some reload problems).
>
> I have built the compiler with this patch and subpatch #1 installed.  I have
> built the compiler with all 16 subpatches and had no regressions.  Is this
> patch ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.opt (-mfloat128-*): Delete -mfloat128-none
> and -mfloat128-software switches.  Replace them with a binary
> -mfloat128 switch.
> (-mfloat128): Likewise.
>
> * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): Allow
> 128-bit floating point types in GPRs, even if the appropriate
> option enabling the type was not used.
> (rs6000_debug_reg_global): Remove -mfloat128-{software,none}
> debugging.
> (rs6000_setup_reg_addr_masks): Do not allow pre-increment and
> pre-decrement on IEEE 128-bit floating point values.
> (rs6000_init_hard_regno_mode_ok): Change test for whether TFmode
> is IEEE 128-bit floating point.
> (rs6000_init_hard_regno_mode_ok): Add reload handlers for IEEE
> 128-bit floating point types that can go in vector registers.
> (rs6000_option_override_internal): Change -mfloat128-none and
> -mfloat128-software to -mfloat128, and move code to be near other
> VSX option handling.
> (rs6000_option_override_internal): Disable -mfloat128 if we don't
> have the Altivec ABI.
> (rs6000_init_builtins): Don't make TFmode use either IFmode or
> KFmode floating point nodes. Instead, have three separate nodes.
> (rs6000_scalar_mode_supported_p): Add support for IFmode to allow
> eventually moving the long double default to IEEE 128-bit floating
> point.
> (rs6000_opt_masks): Add -mfloat128.
> (struct rs6000_opt_var): Fix typo in comment.
>
> * config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add -mfloat128 as
> an option that can be turned on via -mcpu=.
>
> * config/rs6000/rs6000-opts.h (enum float128_type_t): Delete, no
> longer used.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #01

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:26 PM, Michael Meissner
 wrote:
> This patch is the rs6000.h changes. It makes the IEEE 128-bit floating point
> type that can go in vector registers a 'vector' type, so that the address code
> in rs6000.c that determines whether to use VSX addressing works. In addition, 
> I
> made IEEE 128-bit floating point tie with vectors and not with other scalar
> floats.
>
> I have built the compiler with this patch applied, and run bootstrap and
> regression tests with all of the patches installed.  Is it ok to install on 
> the
> trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.h (ALTIVEC_VECTOR_MODE): Add IEEE 128-bit
> floating point modes that can go in vector registers.
> (MODES_TIEABLE_P): Move tests for vector modes before tests for
> scalar floating point, so that IEEE 128-bit floating point that
> can go in vector registers bind with vectors and not FP.
> (struct rs6000_args): Add libcall field.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #11

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:52 PM, Michael Meissner
 wrote:
> This patch changes the mangling for __float128.  I came to the conclusion that
> the current code is so tangled, that it would be better to use U10__float128
> rather than "e".  However, if it is felt that we should go with "e", I can go
> that way as well.
>
> I have built the compiler with this patch and the previous subpatches (1-10).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.c (rs6000_mangle_type): Use U10__float128
> for IEEE 128-bit floating point.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #13

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:58 PM, Michael Meissner
 wrote:
> This patch is the second part to allow TFmode to be IBM extended double or 
> IEEE
> 128-bit floating point depending on switches.
>
> I have built the compiler with this patch and the previous subpatches (1-12).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.md (FP iterator): Allow TFmode to be IEEE
> 128-bit floating point.
> (extenddftf2): Rework 128-bit floating point conversions to
> properly handle -mabi=ieeelongdouble. Merge IFmode, TFmode, and
> KFmode expanders into one function.
> (extenddf2): Likewise.
> (extenddftf2_fprs): Likewise.
> (extenddf2_fprs): Likewise.
> (extenddftf2_vsx): Likewise.
> (extenddf2_vsx): Likewise.
> (extendsftf2): Likewise.
> (extendsf2): Likewise.
> (trunctfdf2): Likewise.
> (truncdf2): Likewise.
> (trunctfdf2_internal1): Likewise.
> (truncdf2_internal1): Likewise.
> (trunctfdf2_internal2): Likewise.
> (truncdf2_internal2): Likewise.
> (trunctfsf2): Likewise.
> (truncsf2): Likewise.
> (trunctfsf2_fprs): Likewise.
> (truncsf2_fprs): Likewise.
> (floatsit2f): Likewise.
> (floatsi2): Likewise.
> (fix_trunc_helper): Likewise.
> (fix_trunc_helper): Likewise.
> (fix_trunctfsi2): Likewise.
> (fix_truncsi2): Likewise.
> (fix_trunctfsi2_fprs): Likewise.
> (fix_truncsi2_fprs): Likewise.
> (fix_trunctfsi2_internal): Likewise.
> (fix_truncsi2_internal): Likewise.
> (fix_trunctfdi2): Likewise.
> (fix_truncdi2): Likewise.
> (fixuns_trunctf2): Likewise.
> (fixuns_trunc2): Likewise.
> (floatditf2): Likewise.
> (floatdi2): Likewise.
> (floatunstf2): Likewise.
> (floatuns): Likewise.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #12

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:57 PM, Michael Meissner
 wrote:
> This patch is the first of two rs6000.md patches to straighten out the IFmode,
> KFmode, and TFmode support.  Part of the change is to change the iterator 
> names
> to be easier to understand, using IEEE128, IBM128, and FLOAT128 as the
> iterators.  This change, and the next change go through and have parallel 
> insns
> for handling IFmode and TFmode (when -mabi=ibmlongdouble) for IBM extended
> double, and for handling KFmode and TFmode (when -mabi=ieeelongdouble).  The
> idea is to prepare the way in GCC 7.0 to change the default for long double.
>
> I have built the compiler with this patch and the previous subpatches (1-11).
> I have bootstrapped the compiler with all 16 subpatches installed, and there
> were no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.md (FLOAT128_SFDFTF): Delete iterator,
> rework IEEE 128-bit floating point insns to deal with TFmode being
> either IBM extended double or IEEE 128-bit floating point.
> (IFKF): Likewise.
> (IBM128): Update iterator to add condition that the mode is IBM
> extended double.
> (IEEE128): New iterator for IEEE 128-bit floating point.
> (TFIFKF): Rename TFIFKF iterator to FLOAT128.
> (FLOAT128): Likewise.
> (signbit2): FLOAT128_IBM_P condition test moved into IBM128
> iterator.
> (neg2): Replace TFIFKF iterator with FLOAT128. Add support
> for TFmode being IEEE 128-bit floating point. Use IEEE128 iterator
> instead of hard coding TFmode or KFmode.
> (negtf2_internal): Likewise.
> (neg2_internal): Likewise.
> (abs2): Likewise.
> (abstf2_internal): Likewise.
> (abs2_internal): Likewise.
> (ieee_128bit_neg2): Likewise.
> (ieee_128bit_neg2_internal): Likewise.
> (ieee_128bit_abs2): Likewise.
> (ieee_128bit_abs2_internal): Likewise.
> (ieee_128bit_nabs2): Likewise.
> (ieee_128bit_nabs2_internal): Likewise.
> (extendiftf2): Add explicit conversions between 128-bit floating
> point types. Drop the old conversions that had become unwieldy.
> (extend2): Likewise.
> (extendifkf2): Likewise.
> (trunc2): Likewise.
> (extendtfkf2): Likewise.
> (fix_trunc2): Likewise.
> (trunciftf2): Likewise.
> (fixuns_trunc2): Likewise.
> (truncifkf2): Likewise.
> (float2): Likewise.
> (trunckftf2): Likewise.
> (floatuns2): Likewise.
> (trunctfif2): Likewise.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #03

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:33 PM, Michael Meissner
 wrote:
> This patch defines 3 macros to tell the user whether -mfloat128 is enabled or
> not, and whether long double is IBM extended double or IEEE 128-bit floating
> point.
>
> I have built the compiler with this patch and the previous subpatches (1 and
> 2).  I have bootstrapped the compiler with all 16 subpatches installed, and
> there were no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define
> __FLOAT128__ if -mfloat128. Define __LONG_DOUBLE_IEEE128__ if long
> double is IEEE 128-bit. Define __LONG_DOUBLE_IBM128__ if long
> double is IBM extended double.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #10

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:49 PM, Michael Meissner
 wrote:
> This patch is part of the support needed to properly swap IEEE 128-bit 
> floating
> point on little endian systems.  Note, you will need the rs6000.md changes for
> this to become effective.
>
> I have built the compiler with this patch and the previous subpatches (1-9).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.c (rs6000_gen_le_vsx_permute): On little
> endian systems generate a ROTATE insn instead of VEC_SELECT for
> IEEE 128-bit floating point types that can go in vector
> registers.
> (chain_contains_only_swaps): Properly swap IEEE 128-bit floating
> point types that can go in vector registers on little endian
> PowerPC systems.
> (mark_swaps_for_removal): Likewise.
> (rs6000_analyze_swaps): Likewise.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #08

[David Edelsohn]

On Fri, Oct 23, 2015 at 1:45 PM, Michael Meissner
 wrote:
> This patch adds support for using 'q' or 'Q' as a suffix for __float128
> constants, which is compatible with the existing x86_64 implmenetation of 
> their
> __float128 support.
>
> I have built the compiler with this patch and the previous subpatches (1-7).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
>
> 2015-10-22  Michael Meissner  
>
> * config/rs6000/rs6000.c (TARGET_C_MODE_FOR_SUFFIX): Define 'q'
> and 'Q' as the suffix to use for IEEE 128-bit floating point
> constants with -mfloat128.
> (rs6000_c_mode_for_suffix): Likewise.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #06

[Michael Meissner]

On Thu, Oct 29, 2015 at 10:33:48AM -0400, David Edelsohn wrote:
> On Fri, Oct 23, 2015 at 1:40 PM, Michael Meissner
>  wrote:
> > This patch sets up all of the emulation functions.
> >
> > I have built the compiler with this patch and the previous subpatches 
> > (1-4).  I
> > have bootstrapped the compiler with all 16 subpatches installed, and there 
> > were
> > no regressions.  Is it ok to install in the trunk?
> >
> > 2015-10-22  Michael Meissner  
> >
> > * config/rs6000/rs6000.c (rs6000_init_libfuncs): Split libfunc
> > setup into 3 functions: init_float128_ibm, init_float128_ieee, and
> > rs6000_init_libfuncs. If -mfloat128, add IFmode functions for all
> > of the traditional names that TFmode uses for handling IEEE
> > extended double. If -mfloat128, add KFmode functions for all of
> > the emulation functions. If -mabi=ieeelongdouble and -mfloat128,
> > make TFmode use the same emulation functions as KFmode.
> > (init_float128_ibm): Likewise.
> > (init_float128_ieee): Likewise.
> 
> This seems to change the logic for initializing Darwin and AIX
> libfuncs.  It may not be wrong, but I am a little concerned.  I
> believe that they were defined unconditionally before and now they
> only are defined if TARGET_LONG_DOUBLE_128.
> 
> Am I misunderstanding something?

No really, I just assumed if -mlong-double-64 you wouldn't be using TFmode.  I
can remove the test if you prefer.  BTW, Darwin has 128-bit long double (using
IBM extended double).

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #17

[Michael Meissner]

This patch adds a test to make sure __float128 and __ibm128 are not allowed to
be combined in binary operations.  I re-ran the test suite on power8 little
endian, and this test passed. Once the preceeding 16 patches are applied to the
tree, is this patch ok to commit into trunk?

2015-10-27  Michael Meissner  

* gcc.target/powerpc/float128-mix.c: New test for IEEE 128-bit
floating point.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/testsuite/gcc.target/powerpc/float128-mix.c
===
--- gcc/testsuite/gcc.target/powerpc/float128-mix.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/float128-mix.c (revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile { target { powerpc*-*-linux* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
+/* { dg-options "-O2 -mcpu=power7 -mfloat128" } */
+
+
+/* Test to make sure that __float128 and __ibm128 cannot be combined together. 
 */
+__float128 add (__float128 a, __ibm128 b)
+{
+  return a+b;  /* { dg-error "__float128 and __ibm128 cannot be used in the 
same expression" "" } */
+}
+
+__ibm128 sub (__ibm128 a, __float128 b)
+{
+  return a-b;  /* { dg-error "__float128 and __ibm128 cannot be used in the 
same expression" "" } */
+}

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #14

[Michael Meissner]

This patch makes TFmode be fully switchable for comparisons.

I have built the compiler with this patch and the previous subpatches (1-13).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.md (cmptf_internal1): Use a mode iterator
to add support for both types (IFmode, TFmode) that support IBM
extended double.
(cmp_internal1): Likewise.
(cmptf_internal2): Likewise.
(cmp_internal2): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 229200)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -10576,20 +10576,20 @@ (define_split
(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 4)))])
 
 ;; Only need to compare second words if first words equal
-(define_insn "*cmptf_internal1"
+(define_insn "*cmp_internal1"
   [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
-   (compare:CCFP (match_operand:TF 1 "gpc_reg_operand" "d")
- (match_operand:TF 2 "gpc_reg_operand" "d")))]
-  "!TARGET_IEEEQUAD && !TARGET_XL_COMPAT
+   (compare:CCFP (match_operand:IBM128 1 "gpc_reg_operand" "d")
+ (match_operand:IBM128 2 "gpc_reg_operand" "d")))]
+  "!TARGET_XL_COMPAT && FLOAT128_IBM_P (mode)
&& TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT && 
TARGET_LONG_DOUBLE_128"
   "fcmpu %0,%1,%2\;bne %0,$+8\;fcmpu %0,%L1,%L2"
   [(set_attr "type" "fpcompare")
(set_attr "length" "12")])
 
-(define_insn_and_split "*cmptf_internal2"
+(define_insn_and_split "*cmp_internal2"
   [(set (match_operand:CCFP 0 "cc_reg_operand" "=y")
-   (compare:CCFP (match_operand:TF 1 "gpc_reg_operand" "d")
- (match_operand:TF 2 "gpc_reg_operand" "d")))
+   (compare:CCFP (match_operand:IBM128 1 "gpc_reg_operand" "d")
+ (match_operand:IBM128 2 "gpc_reg_operand" "d")))
 (clobber (match_scratch:DF 3 "=d"))
 (clobber (match_scratch:DF 4 "=d"))
 (clobber (match_scratch:DF 5 "=d"))
@@ -10599,7 +10599,7 @@ (define_insn_and_split "*cmptf_internal2
 (clobber (match_scratch:DF 9 "=d"))
 (clobber (match_scratch:DF 10 "=d"))
 (clobber (match_scratch:GPR 11 "=b"))]
-  "!TARGET_IEEEQUAD && TARGET_XL_COMPAT
+  "TARGET_XL_COMPAT && FLOAT128_IBM_P (mode)
&& TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT && 
TARGET_LONG_DOUBLE_128"
   "#"
   "&& reload_completed"
@@ -10623,10 +10623,10 @@ (define_insn_and_split "*cmptf_internal2
   const int lo_word = LONG_DOUBLE_LARGE_FIRST ? GET_MODE_SIZE (DFmode) : 0;
   const int hi_word = LONG_DOUBLE_LARGE_FIRST ? 0 : GET_MODE_SIZE (DFmode);
 
-  operands[5] = simplify_gen_subreg (DFmode, operands[1], TFmode, hi_word);
-  operands[6] = simplify_gen_subreg (DFmode, operands[1], TFmode, lo_word);
-  operands[7] = simplify_gen_subreg (DFmode, operands[2], TFmode, hi_word);
-  operands[8] = simplify_gen_subreg (DFmode, operands[2], TFmode, lo_word);
+  operands[5] = simplify_gen_subreg (DFmode, operands[1], mode, hi_word);
+  operands[6] = simplify_gen_subreg (DFmode, operands[1], mode, lo_word);
+  operands[7] = simplify_gen_subreg (DFmode, operands[2], mode, hi_word);
+  operands[8] = simplify_gen_subreg (DFmode, operands[2], mode, lo_word);
   operands[12] = gen_label_rtx ();
   operands[13] = gen_label_rtx ();
   real_inf ();

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #05 (patch included)

[Michael Meissner]

On Fri, Oct 23, 2015 at 01:39:36PM -0400, Michael Meissner wrote:
> This patch prevents the compiler from calling the IEEE 128-bit emulation
> functions with the vector value in both GPRs and vector registers due to the
> fact that the library function did not have a prototype.
> 
> I have built the compiler with this patch and the previous subpatches (1-4).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
> 
> 2015-10-22  Michael Meissner  
> 
>   * config/rs6000/rs6000.c (init_cumulative_args): Initialize
>   libcall field in CUMULATIVE_ARGS.
>   (rs6000_function_arg): Treat library functions as if they had
>   prototypes to prevent IEEE 128-bit support functions from passing
>   arguments in both GPRs and vector registers.
>   (rs6000_arg_partial_bytes): Likewise.

I forgot to attach the patch.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229187)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -9441,6 +9441,7 @@ init_cumulative_args (CUMULATIVE_ARGS *c
  ? CALL_LIBCALL : CALL_NORMAL);
   cum->sysv_gregno = GP_ARG_MIN_REG;
   cum->stdarg = stdarg_p (fntype);
+  cum->libcall = libcall;
 
   cum->nargs_prototype = 0;
   if (incoming || cum->prototype)
@@ -10613,9 +10614,11 @@ rs6000_function_arg (cumulative_args_t c
   rtx r, off;
   int i, k = 0;
 
-  /* Do we also need to pass this argument in the parameter
-save area?  */
-  if (TARGET_64BIT && ! cum->prototype)
+  /* Do we also need to pass this argument in the parameter save area?
+Library support functions for IEEE 128-bit are assumed to not need the
+value passed both in GPRs and in vector registers.  */
+  if (TARGET_64BIT && !cum->prototype
+ && (!cum->libcall || !FLOAT128_VECTOR_P (elt_mode)))
{
  int align_words = ROUND_UP (cum->words, 2);
  k = rs6000_psave_function_arg (mode, type, align_words, rvec);
@@ -10846,11 +10849,14 @@ rs6000_arg_partial_bytes (cumulative_arg
 
   if (USE_ALTIVEC_FOR_ARG_P (cum, elt_mode, named))
 {
-  /* If we are passing this arg in the fixed parameter save area
- (gprs or memory) as well as VRs, we do not use the partial
-bytes mechanism; instead, rs6000_function_arg will return a
-PARALLEL including a memory element as necessary.  */
-  if (TARGET_64BIT && ! cum->prototype)
+  /* If we are passing this arg in the fixed parameter save area (gprs or
+ memory) as well as VRs, we do not use the partial bytes mechanism;
+ instead, rs6000_function_arg will return a PARALLEL including a memory
+ element as necessary.  Library support functions for IEEE 128-bit are
+ assumed to not need the value passed both in GPRs and in vector
+ registers.  */
+  if (TARGET_64BIT && !cum->prototype
+ && (!cum->libcall || !FLOAT128_VECTOR_P (elt_mode)))
return 0;
 
   /* Otherwise, we pass in VRs only.  Check for partial copies.  */

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #16

[Michael Meissner]

This patch adds a test to make sure __float128 are passed and returned like
vector objects, and not as IBM extended double did.

This is the last subpatch of patch #7.  I have bootstrapped the compiler with
all 16 subpatches installed, and there were no regressions.  Is it ok to
install in the trunk?

2015-10-22  Michael Meissner  

* gcc.target/powerpc/float128-call.c: New test for -mfloat128 on
PowerPC.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/testsuite/gcc.target/powerpc/float128-call.c
===
--- gcc/testsuite/gcc.target/powerpc/float128-call.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/float128-call.c(revision 0)
@@ -0,0 +1,27 @@
+/* { dg-do compile { target { powerpc*-*-linux* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
+/* { dg-options "-O2 -mcpu=power7 -mfloat128 -mno-regnames" } */
+
+#ifndef __FLOAT128__
+#error "-mfloat128 is not supported."
+#endif
+
+#ifdef __LONG_DOUBLE_IEEE128__
+#define TYPE long double
+#define ONE  1.0L
+
+#else
+#define TYPE __float128
+#define ONE  1.0Q
+#endif
+
+/* Test to make sure vector registers are used for passing IEEE 128-bit
+   floating point values and returning them. Also make sure the 'q' suffix is
+   handled.  */
+TYPE one (void) { return ONE; }
+void store (TYPE a, TYPE *p) { *p = a; }
+
+/* { dg-final { scan-assembler "lxvd2x 34"  } } */
+/* { dg-final { scan-assembler "stxvd2x 34" } } */

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #13

[Michael Meissner]

This patch is the second part to allow TFmode to be IBM extended double or IEEE
128-bit floating point depending on switches.

I have built the compiler with this patch and the previous subpatches (1-12).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.md (FP iterator): Allow TFmode to be IEEE
128-bit floating point.
(extenddftf2): Rework 128-bit floating point conversions to
properly handle -mabi=ieeelongdouble. Merge IFmode, TFmode, and
KFmode expanders into one function.
(extenddf2): Likewise.
(extenddftf2_fprs): Likewise.
(extenddf2_fprs): Likewise.
(extenddftf2_vsx): Likewise.
(extenddf2_vsx): Likewise.
(extendsftf2): Likewise.
(extendsf2): Likewise.
(trunctfdf2): Likewise.
(truncdf2): Likewise.
(trunctfdf2_internal1): Likewise.
(truncdf2_internal1): Likewise.
(trunctfdf2_internal2): Likewise.
(truncdf2_internal2): Likewise.
(trunctfsf2): Likewise.
(truncsf2): Likewise.
(trunctfsf2_fprs): Likewise.
(truncsf2_fprs): Likewise.
(floatsit2f): Likewise.
(floatsi2): Likewise.
(fix_trunc_helper): Likewise.
(fix_trunc_helper): Likewise.
(fix_trunctfsi2): Likewise.
(fix_truncsi2): Likewise.
(fix_trunctfsi2_fprs): Likewise.
(fix_truncsi2_fprs): Likewise.
(fix_trunctfsi2_internal): Likewise.
(fix_truncsi2_internal): Likewise.
(fix_trunctfdi2): Likewise.
(fix_truncdi2): Likewise.
(fixuns_trunctf2): Likewise.
(fixuns_trunc2): Likewise.
(floatditf2): Likewise.
(floatdi2): Likewise.
(floatunstf2): Likewise.
(floatuns): Likewise.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 229198)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -347,8 +347,7 @@ (define_mode_iterator FP [
&& ((TARGET_FPRS && TARGET_SINGLE_FLOAT) || TARGET_E500_SINGLE)")
   (DF "TARGET_HARD_FLOAT 
&& ((TARGET_FPRS && TARGET_DOUBLE_FLOAT) || TARGET_E500_DOUBLE)")
-  (TF "!TARGET_IEEEQUAD
-   && TARGET_HARD_FLOAT
+  (TF "TARGET_HARD_FLOAT
&& (TARGET_FPRS || TARGET_E500_DOUBLE)
&& TARGET_LONG_DOUBLE_128")
   (IF "TARGET_FLOAT128")
@@ -6463,34 +6462,51 @@ (define_insn_and_split "*mov_softf
 { rs6000_split_multireg_move (operands[0], operands[1]); DONE; }
   [(set_attr "length" "20,20,16")])
 
-(define_expand "extenddftf2"
-  [(set (match_operand:TF 0 "gpc_reg_operand" "")
-   (float_extend:TF (match_operand:DF 1 "gpc_reg_operand" "")))]
+(define_expand "extenddf2"
+  [(set (match_operand:FLOAT128 0 "gpc_reg_operand" "")
+   (float_extend:FLOAT128 (match_operand:DF 1 "gpc_reg_operand" "")))]
   "TARGET_HARD_FLOAT && (TARGET_FPRS || TARGET_E500_DOUBLE)
&& TARGET_LONG_DOUBLE_128"
 {
-  if (TARGET_IEEEQUAD)
+  if (FLOAT128_IEEE_P (mode))
 rs6000_expand_float128_convert (operands[0], operands[1], false);
   else if (TARGET_E500_DOUBLE)
-emit_insn (gen_spe_extenddftf2 (operands[0], operands[1]));
+{
+  gcc_assert (mode == TFmode);
+  emit_insn (gen_spe_extenddftf2 (operands[0], operands[1]));
+}
   else if (TARGET_VSX)
-emit_insn (gen_extenddftf2_vsx (operands[0], operands[1]));
-  else
+{
+  if (mode == TFmode)
+   emit_insn (gen_extenddftf2_vsx (operands[0], operands[1]));
+  else if (mode == IFmode)
+   emit_insn (gen_extenddfif2_vsx (operands[0], operands[1]));
+  else
+   gcc_unreachable ();
+}
+   else
 {
   rtx zero = gen_reg_rtx (DFmode);
   rs6000_emit_move (zero, CONST0_RTX (DFmode), DFmode);
-  emit_insn (gen_extenddftf2_fprs (operands[0], operands[1], zero));
+
+  if (mode == TFmode)
+   emit_insn (gen_extenddftf2_fprs (operands[0], operands[1], zero));
+  else if (mode == IFmode)
+   emit_insn (gen_extenddfif2_fprs (operands[0], operands[1], zero));
+  else
+   gcc_unreachable ();
 }
   DONE;
 })
 
 ;; Allow memory operands for the source to be created by the combiner.
-(define_insn_and_split "extenddftf2_fprs"
-  [(set (match_operand:TF 0 "gpc_reg_operand" "=d,d,")
-   (float_extend:TF (match_operand:DF 1 "nonimmediate_operand" "d,m,d")))
+(define_insn_and_split "extenddf2_fprs"
+  [(set (match_operand:IBM128 0 "gpc_reg_operand" "=d,d,")
+   (float_extend:IBM128
+(match_operand:DF 1 "nonimmediate_operand" "d,m,d")))
(use (match_operand:DF 2 "nonimmediate_operand" "m,m,d"))]
   "!TARGET_VSX && TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT
-   && 

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #02

[Michael Meissner]

This patch changes the switch from -mfloat128-software and -mfloat128-none to
be a binary switch, -mfloat128 and -mno-float128.  It also provides some of the
basic setup for IEEE types.  It also removes code I had put in a previous patch
that doesn't allow IFmode/KFmode to go in any register if -mno-float128 (this
causes some reload problems).

I have built the compiler with this patch and subpatch #1 installed.  I have
built the compiler with all 16 subpatches and had no regressions.  Is this
patch ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.opt (-mfloat128-*): Delete -mfloat128-none
and -mfloat128-software switches.  Replace them with a binary
-mfloat128 switch.
(-mfloat128): Likewise.

* config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): Allow
128-bit floating point types in GPRs, even if the appropriate
option enabling the type was not used.
(rs6000_debug_reg_global): Remove -mfloat128-{software,none}
debugging.
(rs6000_setup_reg_addr_masks): Do not allow pre-increment and
pre-decrement on IEEE 128-bit floating point values.
(rs6000_init_hard_regno_mode_ok): Change test for whether TFmode
is IEEE 128-bit floating point.
(rs6000_init_hard_regno_mode_ok): Add reload handlers for IEEE
128-bit floating point types that can go in vector registers.
(rs6000_option_override_internal): Change -mfloat128-none and
-mfloat128-software to -mfloat128, and move code to be near other
VSX option handling.
(rs6000_option_override_internal): Disable -mfloat128 if we don't
have the Altivec ABI.
(rs6000_init_builtins): Don't make TFmode use either IFmode or
KFmode floating point nodes. Instead, have three separate nodes.
(rs6000_scalar_mode_supported_p): Add support for IFmode to allow
eventually moving the long double default to IEEE 128-bit floating
point.
(rs6000_opt_masks): Add -mfloat128.
(struct rs6000_opt_var): Fix typo in comment.

* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add -mfloat128 as
an option that can be turned on via -mcpu=.

* config/rs6000/rs6000-opts.h (enum float128_type_t): Delete, no
longer used.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.opt
===
--- gcc/config/rs6000/rs6000.opt(revision 229182)
+++ gcc/config/rs6000/rs6000.opt(working copy)
@@ -601,18 +601,6 @@ moptimize-swaps
 Target Undocumented Var(rs6000_optimize_swaps) Init(1) Save
 Analyze and remove doubleword swaps from VSX computations.
 
-mfloat128-
-Target RejectNegative Joined Enum(float128_type_t) Var(TARGET_FLOAT128) 
Init(FLOAT128_UNSET) Save
--mfloat128-{software,none} - Specify how IEEE 128-bit floating point is used.
-
-Enum
-Name(float128_type_t) Type(enum float128_type_t)
-
-EnumValue
-Enum(float128_type_t) String(none) Value(FLOAT128_NONE)
-
-EnumValue
-Enum(float128_type_t) String(software) Value(FLOAT128_SW)
-
-EnumValue
-Enum(float128_type_t) String(sw) Value(FLOAT128_SW)
+mfloat128
+Target Report Mask(FLOAT128) Var(rs6000_isa_flags)
+Enable/disable IEEE 128-bit floating point via the __float128 keyword.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229182)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1772,16 +1772,6 @@ rs6000_hard_regno_mode_ok (int regno, ma
&& IN_RANGE (last_regno, FIRST_GPR_REGNO, LAST_GPR_REGNO)
&& ((regno & 1) == 0));
 
-  /* If we don't allow 128-bit binary floating point, disallow the 128-bit
- types from going in any registers.  Similarly if __float128 is not
- supported, don't allow __float128/__ibm128 types.  */
-  if (!TARGET_LONG_DOUBLE_128
-  && (mode == TFmode || mode == KFmode || mode == IFmode))
-return false;
-
-  if (!TARGET_FLOAT128 && (mode == KFmode || mode == IFmode))
-return false;
-
   /* VSX registers that overlap the FPR registers are larger than for non-VSX
  implementations.  Don't allow an item to be split between a FP register
  and an Altivec register.  Allow TImode in all VSX registers if the user
@@ -2055,7 +2045,6 @@ rs6000_debug_reg_global (void)
   const char *trace_str;
   const char *abi_str;
   const char *cmodel_str;
-  const char *float128_str;
   struct cl_target_option cl_opts;
 
   /* Modes we want tieable information on.  */
@@ -2421,15 +2410,6 @@ rs6000_debug_reg_global (void)
   fprintf (stderr, DEBUG_FMT_S, "e500_double",
   (TARGET_E500_DOUBLE ? "true" : "false"));
 
-  switch (TARGET_FLOAT128)
-{
-case FLOAT128_NONE:float128_str = "none"; 

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #03

[Michael Meissner]

This patch defines 3 macros to tell the user whether -mfloat128 is enabled or
not, and whether long double is IBM extended double or IEEE 128-bit floating
point.

I have built the compiler with this patch and the previous subpatches (1 and
2).  I have bootstrapped the compiler with all 16 subpatches installed, and
there were no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define
__FLOAT128__ if -mfloat128. Define __LONG_DOUBLE_IEEE128__ if long
double is IEEE 128-bit. Define __LONG_DOUBLE_IBM128__ if long
double is IBM extended double.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 229182)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -408,6 +408,8 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfi
 builtin_define ("__RSQRTE__");
   if (TARGET_FRSQRTES)
 builtin_define ("__RSQRTEF__");
+  if (TARGET_FLOAT128)
+builtin_define ("__FLOAT128__");
 
   if (TARGET_EXTRA_BUILTINS && cpp_get_options (pfile)->lang != CLK_ASM)
 {
@@ -481,6 +483,11 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfi
 {
   builtin_define ("__LONG_DOUBLE_128__");
   builtin_define ("__LONGDOUBLE128");
+
+  if (TARGET_IEEEQUAD)
+   builtin_define ("__LONG_DOUBLE_IEEE128__");
+  else
+   builtin_define ("__LONG_DOUBLE_IBM128__");
 }
 
   switch (TARGET_CMODEL)

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #05

[Michael Meissner]

This patch prevents the compiler from calling the IEEE 128-bit emulation
functions with the vector value in both GPRs and vector registers due to the
fact that the library function did not have a prototype.

I have built the compiler with this patch and the previous subpatches (1-4).  I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.c (init_cumulative_args): Initialize
libcall field in CUMULATIVE_ARGS.
(rs6000_function_arg): Treat library functions as if they had
prototypes to prevent IEEE 128-bit support functions from passing
arguments in both GPRs and vector registers.
(rs6000_arg_partial_bytes): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #10

[Michael Meissner]

This patch is part of the support needed to properly swap IEEE 128-bit floating
point on little endian systems.  Note, you will need the rs6000.md changes for
this to become effective.

I have built the compiler with this patch and the previous subpatches (1-9).  I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_gen_le_vsx_permute): On little
endian systems generate a ROTATE insn instead of VEC_SELECT for
IEEE 128-bit floating point types that can go in vector
registers.
(chain_contains_only_swaps): Properly swap IEEE 128-bit floating
point types that can go in vector registers on little endian
PowerPC systems.
(mark_swaps_for_removal): Likewise.
(rs6000_analyze_swaps): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229194)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -8467,8 +8467,14 @@ rs6000_const_vec (machine_mode mode)
 rtx
 rs6000_gen_le_vsx_permute (rtx source, machine_mode mode)
 {
-  rtx par = gen_rtx_PARALLEL (VOIDmode, rs6000_const_vec (mode));
-  return gen_rtx_VEC_SELECT (mode, source, par);
+  /* Use ROTATE instead of VEC_SELECT on IEEE 128-bit floating point.  */
+  if (FLOAT128_VECTOR_P (mode))
+return gen_rtx_ROTATE (mode, source, GEN_INT (64));
+  else
+{
+  rtx par = gen_rtx_PARALLEL (VOIDmode, rs6000_const_vec (mode));
+  return gen_rtx_VEC_SELECT (mode, source, par);
+}
 }
 
 /* Emit a little-endian load from vector memory location SOURCE to VSX
@@ -35844,7 +35850,7 @@ chain_contains_only_swaps (swap_web_entr
 
   for (; link; link = link->next)
 {
-  if (!VECTOR_MODE_P (GET_MODE (DF_REF_REG (link->ref
+  if (!ALTIVEC_OR_VSX_VECTOR_MODE (GET_MODE (DF_REF_REG (link->ref
continue;
 
   if (DF_REF_IS_ARTIFICIAL (link->ref))
@@ -35943,7 +35949,7 @@ mark_swaps_for_removal (swap_web_entry *
{
  /* Ignore uses for addressability.  */
  machine_mode mode = GET_MODE (DF_REF_REG (use));
- if (!VECTOR_MODE_P (mode))
+ if (!ALTIVEC_OR_VSX_VECTOR_MODE (mode))
continue;
 
  struct df_link *link = DF_REF_CHAIN (use);
@@ -36457,10 +36463,11 @@ rs6000_analyze_swaps (function *fun)
mode = V4SImode;
}
 
- if (VECTOR_MODE_P (mode) || mode == TImode)
+ if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
{
  insn_entry[uid].is_relevant = 1;
- if (mode == TImode || mode == V1TImode)
+ if (mode == TImode || mode == V1TImode
+ || FLOAT128_VECTOR_P (mode))
insn_entry[uid].is_128_int = 1;
  if (DF_REF_INSN_INFO (mention))
insn_entry[uid].contains_subreg
@@ -36481,13 +36488,14 @@ rs6000_analyze_swaps (function *fun)
 isn't sufficient to ensure we union the call into the
 web with the parameter setup code.  */
  if (mode == DImode && GET_CODE (insn) == SET
- && VECTOR_MODE_P (GET_MODE (SET_DEST (insn
+ && ALTIVEC_OR_VSX_VECTOR_MODE (GET_MODE (SET_DEST (insn
mode = GET_MODE (SET_DEST (insn));
 
- if (VECTOR_MODE_P (mode) || mode == TImode)
+ if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
{
  insn_entry[uid].is_relevant = 1;
- if (mode == TImode || mode == V1TImode)
+ if (mode == TImode || mode == V1TImode
+ || FLOAT128_VECTOR_P (mode))
insn_entry[uid].is_128_int = 1;
  if (DF_REF_INSN_INFO (mention))
insn_entry[uid].contains_subreg

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2)

[Michael Meissner]

David asked me to try and break patch #7 into smaller bite sized chunks. I have
broken this into roughly 16 parts. These are the same patches that I submitted
for patch #7 (revised), just broken up.  There is one additional patch in this
selection, to restrict __float128 and IBM extended double from being combined
in an expression.

I have done bootstraps with no regressions on both a little endian power8
system and a big endian power7 system.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #12

[Michael Meissner]

This patch is the first of two rs6000.md patches to straighten out the IFmode,
KFmode, and TFmode support.  Part of the change is to change the iterator names
to be easier to understand, using IEEE128, IBM128, and FLOAT128 as the
iterators.  This change, and the next change go through and have parallel insns
for handling IFmode and TFmode (when -mabi=ibmlongdouble) for IBM extended
double, and for handling KFmode and TFmode (when -mabi=ieeelongdouble).  The
idea is to prepare the way in GCC 7.0 to change the default for long double.

I have built the compiler with this patch and the previous subpatches (1-11).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.md (FLOAT128_SFDFTF): Delete iterator,
rework IEEE 128-bit floating point insns to deal with TFmode being
either IBM extended double or IEEE 128-bit floating point.
(IFKF): Likewise.
(IBM128): Update iterator to add condition that the mode is IBM
extended double.
(IEEE128): New iterator for IEEE 128-bit floating point.
(TFIFKF): Rename TFIFKF iterator to FLOAT128.
(FLOAT128): Likewise.
(signbit2): FLOAT128_IBM_P condition test moved into IBM128
iterator.
(neg2): Replace TFIFKF iterator with FLOAT128. Add support
for TFmode being IEEE 128-bit floating point. Use IEEE128 iterator
instead of hard coding TFmode or KFmode.
(negtf2_internal): Likewise.
(neg2_internal): Likewise.
(abs2): Likewise.
(abstf2_internal): Likewise.
(abs2_internal): Likewise.
(ieee_128bit_neg2): Likewise.
(ieee_128bit_neg2_internal): Likewise.
(ieee_128bit_abs2): Likewise.
(ieee_128bit_abs2_internal): Likewise.
(ieee_128bit_nabs2): Likewise.
(ieee_128bit_nabs2_internal): Likewise.
(extendiftf2): Add explicit conversions between 128-bit floating
point types. Drop the old conversions that had become unwieldy.
(extend2): Likewise.
(extendifkf2): Likewise.
(trunc2): Likewise.
(extendtfkf2): Likewise.
(fix_trunc2): Likewise.
(trunciftf2): Likewise.
(fixuns_trunc2): Likewise.
(truncifkf2): Likewise.
(float2): Likewise.
(trunckftf2): Likewise.
(floatuns2): Likewise.
(trunctfif2): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 229182)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -448,24 +448,18 @@ (define_mode_iterator RECIPF [SF DF V4SF
 ; Iterator for just SF/DF
 (define_mode_iterator SFDF [SF DF])
 
-; Iterator for float128 floating conversions
-(define_mode_iterator FLOAT128_SFDFTF [
-(SF "TARGET_FLOAT128")
-(DF "TARGET_FLOAT128")
-(TF "FLOAT128_IBM_P (TFmode)")
-(IF "TARGET_FLOAT128")])
-
-; Iterator for special 128-bit floating point.  This is for non-default
-; conversions, so TFmode is not used here.
-(define_mode_iterator IFKF [IF KF])
-
 ; Iterator for 128-bit floating point that uses the IBM double-double format
-(define_mode_iterator IBM128 [IF TF])
+(define_mode_iterator IBM128 [(IF "FLOAT128_IBM_P (IFmode)")
+ (TF "FLOAT128_IBM_P (TFmode)")])
+
+; Iterator for 128-bit floating point that uses IEEE 128-bit float
+(define_mode_iterator IEEE128 [(KF "FLOAT128_IEEE_P (KFmode)")
+  (TF "FLOAT128_IEEE_P (TFmode)")])
 
 ; Iterator for 128-bit floating point
-(define_mode_iterator TFIFKF [(KF "TARGET_FLOAT128")
- (IF "TARGET_FLOAT128")
- (TF "TARGET_LONG_DOUBLE_128")])
+(define_mode_iterator FLOAT128 [(KF "TARGET_FLOAT128")
+   (IF "TARGET_FLOAT128")
+   (TF "TARGET_LONG_DOUBLE_128")])
 
 ; SF/DF suffix for traditional floating instructions
 (define_mode_attr Ftrad[(SF "s") (DF "")])
@@ -4248,8 +4242,7 @@ (define_expand "signbit2"
(match_dup 5))
(set (match_operand:SI 0 "gpc_reg_operand" "")
(match_dup 6))]
-  "FLOAT128_IBM_P (mode)
-   && TARGET_HARD_FLOAT
+  "TARGET_HARD_FLOAT
&& (TARGET_FPRS || TARGET_E500_DOUBLE)"
 {
   operands[2] = gen_reg_rtx (DFmode);
@@ -6735,8 +6728,8 @@ (define_expand "floatunstf2"
 })
 
 (define_expand "neg2"
-  [(set (match_operand:TFIFKF 0 "gpc_reg_operand" "")
-   (neg:TFIFKF (match_operand:TFIFKF 1 "gpc_reg_operand" "")))]
+  [(set (match_operand:FLOAT128 0 "gpc_reg_operand" "")
+   (neg:FLOAT128 (match_operand:FLOAT128 1 "gpc_reg_operand" "")))]
   "FLOAT128_IEEE_P (mode)
|| 

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #01

[Michael Meissner]

This patch is the rs6000.h changes. It makes the IEEE 128-bit floating point
type that can go in vector registers a 'vector' type, so that the address code
in rs6000.c that determines whether to use VSX addressing works. In addition, I
made IEEE 128-bit floating point tie with vectors and not with other scalar
floats.

I have built the compiler with this patch applied, and run bootstrap and
regression tests with all of the patches installed.  Is it ok to install on the
trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.h (ALTIVEC_VECTOR_MODE): Add IEEE 128-bit
floating point modes that can go in vector registers.
(MODES_TIEABLE_P): Move tests for vector modes before tests for
scalar floating point, so that IEEE 128-bit floating point that
can go in vector registers bind with vectors and not FP.
(struct rs6000_args): Add libcall field.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 229182)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -1217,11 +1217,16 @@ enum data_align { align_abi, align_opt, 
 ((MODE) == V4SFmode\
  || (MODE) == V2DFmode)\
 
-#define ALTIVEC_VECTOR_MODE(MODE)  \
-((MODE) == V16QImode   \
- || (MODE) == V8HImode \
- || (MODE) == V4SFmode \
- || (MODE) == V4SImode)
+/* Note KFmode and possibly TFmode (i.e. IEEE 128-bit floating point) are not
+   really a vector, but we want to treat it as a vector for moves, and
+   such.  */
+
+#define ALTIVEC_VECTOR_MODE(MODE)  \
+  ((MODE) == V16QImode \
+   || (MODE) == V8HImode   \
+   || (MODE) == V4SFmode   \
+   || (MODE) == V4SImode   \
+   || FLOAT128_VECTOR_P (MODE))
 
 #define ALTIVEC_OR_VSX_VECTOR_MODE(MODE)   \
   (ALTIVEC_VECTOR_MODE (MODE) || VSX_VECTOR_MODE (MODE)
\
@@ -1248,12 +1253,19 @@ enum data_align { align_abi, align_opt, 
 
PTImode cannot tie with other modes because PTImode is restricted to even
GPR registers, and TImode can go in any GPR as well as VSX registers (PR
-   57744).  */
+   57744).
+
+   Altivec/VSX vector tests were moved ahead of scalar float mode, so that IEEE
+   128-bit floating point on VSX systems ties with other vectors.  */
 #define MODES_TIEABLE_P(MODE1, MODE2)  \
   ((MODE1) == PTImode  \
? (MODE2) == PTImode\
: (MODE2) == PTImode\
? 0 \
+   : ALTIVEC_OR_VSX_VECTOR_MODE (MODE1)\
+   ? ALTIVEC_OR_VSX_VECTOR_MODE (MODE2)\
+   : ALTIVEC_OR_VSX_VECTOR_MODE (MODE2)\
+   ? 0 \
: SCALAR_FLOAT_MODE_P (MODE1)   \
? SCALAR_FLOAT_MODE_P (MODE2)   \
: SCALAR_FLOAT_MODE_P (MODE2)   \
@@ -1266,10 +1278,6 @@ enum data_align { align_abi, align_opt, 
? SPE_VECTOR_MODE (MODE2)   \
: SPE_VECTOR_MODE (MODE2)   \
? 0 \
-   : ALTIVEC_OR_VSX_VECTOR_MODE (MODE1)\
-   ? ALTIVEC_OR_VSX_VECTOR_MODE (MODE2)\
-   : ALTIVEC_OR_VSX_VECTOR_MODE (MODE2)\
-   ? 0 \
: 1)
 
 /* Post-reload, we can't use any new AltiVec registers, as we already
@@ -1801,6 +1809,7 @@ typedef struct rs6000_args
   GPR space (darwin64) */
   int named;   /* false for varargs params */
   int escapes; /* if function visible outside tu */
+  int libcall; /* If this is a compiler generated call.  */
 } CUMULATIVE_ARGS;
 
 /* Initialize a variable CUM of type CUMULATIVE_ARGS

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #04

[Michael Meissner]

This patch allows SUBREG's for the reg_or_indexed_operand, which is used when
you have an integral value in a float/vector register, and you want to move the
value (either via direct move on power8, or via store).

I have built the compiler with this patch and the previous subpatches (1-3).  I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/predicates.md (reg_or_indexed_operand): Allow
SUBREGs.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #06

[Michael Meissner]

This patch sets up all of the emulation functions.

I have built the compiler with this patch and the previous subpatches (1-4).  I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_init_libfuncs): Split libfunc
setup into 3 functions: init_float128_ibm, init_float128_ieee, and
rs6000_init_libfuncs. If -mfloat128, add IFmode functions for all
of the traditional names that TFmode uses for handling IEEE
extended double. If -mfloat128, add KFmode functions for all of
the emulation functions. If -mabi=ieeelongdouble and -mfloat128,
make TFmode use the same emulation functions as KFmode.
(init_float128_ibm): Likewise.
(init_float128_ieee): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229190)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -16036,75 +16036,184 @@ rs6000_common_init_builtins (void)
 }
 }
 
+/* Set up AIX/Darwin/64-bit Linux quad floating point routines.  */
 static void
-rs6000_init_libfuncs (void)
+init_float128_ibm (machine_mode mode)
 {
-  if (!TARGET_IEEEQUAD)
-  /* AIX/Darwin/64-bit Linux quad floating point routines.  */
-if (!TARGET_XL_COMPAT)
-  {
-   set_optab_libfunc (add_optab, TFmode, "__gcc_qadd");
-   set_optab_libfunc (sub_optab, TFmode, "__gcc_qsub");
-   set_optab_libfunc (smul_optab, TFmode, "__gcc_qmul");
-   set_optab_libfunc (sdiv_optab, TFmode, "__gcc_qdiv");
+  if (!TARGET_XL_COMPAT)
+{
+  set_optab_libfunc (add_optab, mode, "__gcc_qadd");
+  set_optab_libfunc (sub_optab, mode, "__gcc_qsub");
+  set_optab_libfunc (smul_optab, mode, "__gcc_qmul");
+  set_optab_libfunc (sdiv_optab, mode, "__gcc_qdiv");
 
-   if (!(TARGET_HARD_FLOAT && (TARGET_FPRS || TARGET_E500_DOUBLE)))
- {
-   set_optab_libfunc (neg_optab, TFmode, "__gcc_qneg");
-   set_optab_libfunc (eq_optab, TFmode, "__gcc_qeq");
-   set_optab_libfunc (ne_optab, TFmode, "__gcc_qne");
-   set_optab_libfunc (gt_optab, TFmode, "__gcc_qgt");
-   set_optab_libfunc (ge_optab, TFmode, "__gcc_qge");
-   set_optab_libfunc (lt_optab, TFmode, "__gcc_qlt");
-   set_optab_libfunc (le_optab, TFmode, "__gcc_qle");
-
-   set_conv_libfunc (sext_optab, TFmode, SFmode, "__gcc_stoq");
-   set_conv_libfunc (sext_optab, TFmode, DFmode, "__gcc_dtoq");
-   set_conv_libfunc (trunc_optab, SFmode, TFmode, "__gcc_qtos");
-   set_conv_libfunc (trunc_optab, DFmode, TFmode, "__gcc_qtod");
-   set_conv_libfunc (sfix_optab, SImode, TFmode, "__gcc_qtoi");
-   set_conv_libfunc (ufix_optab, SImode, TFmode, "__gcc_qtou");
-   set_conv_libfunc (sfloat_optab, TFmode, SImode, "__gcc_itoq");
-   set_conv_libfunc (ufloat_optab, TFmode, SImode, "__gcc_utoq");
- }
+  if (!(TARGET_HARD_FLOAT && (TARGET_FPRS || TARGET_E500_DOUBLE)))
+   {
+ set_optab_libfunc (neg_optab, mode, "__gcc_qneg");
+ set_optab_libfunc (eq_optab, mode, "__gcc_qeq");
+ set_optab_libfunc (ne_optab, mode, "__gcc_qne");
+ set_optab_libfunc (gt_optab, mode, "__gcc_qgt");
+ set_optab_libfunc (ge_optab, mode, "__gcc_qge");
+ set_optab_libfunc (lt_optab, mode, "__gcc_qlt");
+ set_optab_libfunc (le_optab, mode, "__gcc_qle");
 
-   if (!(TARGET_HARD_FLOAT && TARGET_FPRS))
- set_optab_libfunc (unord_optab, TFmode, "__gcc_qunord");
-  }
-else
-  {
-   set_optab_libfunc (add_optab, TFmode, "_xlqadd");
-   set_optab_libfunc (sub_optab, TFmode, "_xlqsub");
-   set_optab_libfunc (smul_optab, TFmode, "_xlqmul");
-   set_optab_libfunc (sdiv_optab, TFmode, "_xlqdiv");
-  }
+ set_conv_libfunc (sext_optab, mode, SFmode, "__gcc_stoq");
+ set_conv_libfunc (sext_optab, mode, DFmode, "__gcc_dtoq");
+ set_conv_libfunc (trunc_optab, SFmode, mode, "__gcc_qtos");
+ set_conv_libfunc (trunc_optab, DFmode, mode, "__gcc_qtod");
+ set_conv_libfunc (sfix_optab, SImode, mode, "__gcc_qtoi");
+ set_conv_libfunc (ufix_optab, SImode, mode, "__gcc_qtou");
+ set_conv_libfunc (sfloat_optab, mode, SImode, "__gcc_itoq");
+ set_conv_libfunc (ufloat_optab, mode, SImode, "__gcc_utoq");
+   }
+
+  if (!(TARGET_HARD_FLOAT && TARGET_FPRS))
+   set_optab_libfunc (unord_optab, mode, "__gcc_qunord");
+}
   else
 {
-  /* 32-bit SVR4 quad floating point routines.  */
+  set_optab_libfunc (add_optab, mode, "_xlqadd");
+  set_optab_libfunc (sub_optab, mode, 

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #07

[Michael Meissner]

This patch updates to use the unordered comparison function for IEEE 128-bit
floating point to mimic the behaviour of SFmode/DFmode using the fcmpu
instruction.

It also restructures the code to allow a future change to drop in easier.

I have built the compiler with this patch and the previous subpatches (1-6).  I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_generate_compare): For IEEE
128-bit floating point comparisons, call the unordered comparison
function instead of the ordered comparison function.
(rs6000_expand_float128_convert): Deal with operands that are
memory operands. Restructure the code to use a switch statement on
the mode. Add support for TFmode defaulting to either IBM extended
double or IEEE 128-bit floating point. If the underlying types are
the same, use a move instead of a conversion function.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229191)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -20098,17 +20098,18 @@ rs6000_generate_compare (rtx cmp, machin
   emit_insn (cmp);
 }
 
-  /* IEEE 128-bit support in VSX registers.  The comparison function (__cmpkf2)
- returns 0..15 that is laid out the same way as the PowerPC CR register
- would for a normal floating point comparison.  */
+  /* IEEE 128-bit support in VSX registers.  The comparison functions
+ (__cmpokf2 and __cmpukf2) returns 0..15 that is laid out the same way as
+ the PowerPC CR register would for a normal floating point comparison from
+ the fcmpo and fcmpu instructions.  */
   else if (FLOAT128_IEEE_P (mode))
 {
   rtx and_reg = gen_reg_rtx (SImode);
   rtx dest = gen_reg_rtx (SImode);
-  rtx libfunc = optab_libfunc (cmp_optab, mode);
+  rtx libfunc = optab_libfunc (ucmp_optab, mode);
   HOST_WIDE_INT mask_value = 0;
 
-  /* Values that __cmpkf2 returns.  */
+  /* Values that __cmpokf2/__cmpukf2 returns.  */
 #define PPC_CMP_UNORDERED  0x1 /* isnan (a) || isnan (b).  */
 #define PPC_CMP_EQUAL  0x2 /* a == b.  */
 #define PPC_CMP_GREATER_THEN   0x4 /* a > b.  */
@@ -20280,6 +20281,7 @@ rs6000_generate_compare (rtx cmp, machin
 }
 
 
+
 /* Expand floating point conversion to/from __float128 and __ibm128.  */
 
 void
@@ -20288,60 +20290,121 @@ rs6000_expand_float128_convert (rtx dest
   machine_mode dest_mode = GET_MODE (dest);
   machine_mode src_mode = GET_MODE (src);
   convert_optab cvt = unknown_optab;
+  bool do_move = false;
   rtx libfunc = NULL_RTX;
   rtx dest2;
 
   if (dest_mode == src_mode)
 gcc_unreachable ();
 
+  /* Eliminate memory operations.  */
+  if (MEM_P (src))
+src = force_reg (src_mode, src);
+
+  if (MEM_P (dest))
+{
+  rtx tmp = gen_reg_rtx (dest_mode);
+  rs6000_expand_float128_convert (tmp, src, unsigned_p);
+  rs6000_emit_move (dest, tmp, dest_mode);
+  return;
+}
+
+  /* Convert to IEEE 128-bit floating point.  */
   if (FLOAT128_IEEE_P (dest_mode))
 {
-  if (src_mode == SFmode
- || src_mode == DFmode
- || FLOAT128_IBM_P (src_mode))
-   cvt = sext_optab;
+  switch (src_mode)
+   {
+   case DFmode:
+ cvt = sext_optab;
+ break;
 
-  else if (GET_MODE_CLASS (src_mode) == MODE_INT)
-   cvt = (unsigned_p) ? ufloat_optab : sfloat_optab;
+   case SFmode:
+ cvt = sext_optab;
+ break;
 
-  else if (FLOAT128_IEEE_P (src_mode))
-   emit_move_insn (dest, gen_lowpart (dest_mode, src));
+   case KFmode:
+   case IFmode:
+   case TFmode:
+ if (FLOAT128_IBM_P (src_mode))
+   cvt = sext_optab;
+ else
+   do_move = true;
+ break;
 
-  else
-   gcc_unreachable ();
+   case SImode:
+   case DImode:
+ cvt = (unsigned_p) ? ufloat_optab : sfloat_optab;
+ break;
+
+   default:
+ gcc_unreachable ();
+   }
 }
 
+  /* Convert from IEEE 128-bit floating point.  */
   else if (FLOAT128_IEEE_P (src_mode))
 {
-  if (dest_mode == SFmode
- || dest_mode == DFmode
- || FLOAT128_IBM_P (dest_mode))
-   cvt = trunc_optab;
+  switch (dest_mode)
+   {
+   case DFmode:
+ cvt = trunc_optab;
+ break;
 
-  else if (GET_MODE_CLASS (dest_mode) == MODE_INT)
-   cvt = (unsigned_p) ? ufix_optab : sfix_optab;
+   case SFmode:
+ cvt = trunc_optab;
+ break;
 
-  else
-   gcc_unreachable ();
+   case KFmode:
+   case IFmode:
+  

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #09

[Michael Meissner]

This patch is the new patch from the last submission. It sets up a hook so that
the compiler will not allow IBM extended double and IEEE 128-bit floating point
to intermix in a binary expression without using an explicit conversion.

I have built the compiler with this patch and the previous subpatches (1-8).  I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.c (TARGET_INVALID_BINARY_OP): Do not allow
inter-mixing of IEEE 128-bit floating point with IBM extended
double floating point.
(rs6000_invalid_binary_op): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229193)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1677,6 +1677,9 @@ static const struct attribute_spec rs600
 
 #undef TARGET_C_MODE_FOR_SUFFIX
 #define TARGET_C_MODE_FOR_SUFFIX rs6000_c_mode_for_suffix
+
+#undef TARGET_INVALID_BINARY_OP
+#define TARGET_INVALID_BINARY_OP rs6000_invalid_binary_op
 
 
 /* Processor table.  */
@@ -20283,6 +20286,47 @@ rs6000_generate_compare (rtx cmp, machin
   return gen_rtx_fmt_ee (code, VOIDmode, compare_result, const0_rtx);
 }
 
+
+/* Return the diagnostic message string if the binary operation OP is
+   not permitted on TYPE1 and TYPE2, NULL otherwise.  */
+
+static const char*
+rs6000_invalid_binary_op (int op ATTRIBUTE_UNUSED,
+ const_tree type1,
+ const_tree type2)
+{
+  enum machine_mode mode1 = TYPE_MODE (type1);
+  enum machine_mode mode2 = TYPE_MODE (type2);
+
+  /* For complex modes, use the inner type.  */
+  if (COMPLEX_MODE_P (mode1))
+mode1 = GET_MODE_INNER (mode1);
+
+  if (COMPLEX_MODE_P (mode2))
+mode2 = GET_MODE_INNER (mode2);
+
+  /* Don't allow IEEE 754R 128-bit binary floating point and IBM extended
+ double to intermix.  */
+  if (mode1 == mode2)
+return NULL;
+
+  if ((mode1 == KFmode && mode2 == IFmode)
+  || (mode1 == IFmode && mode2 == KFmode))
+return N_("__float128 and __ibm128 cannot be used in the same expression");
+
+  if (TARGET_IEEEQUAD
+  && ((mode1 == IFmode && mode2 == TFmode)
+ || (mode1 == TFmode && mode2 == IFmode)))
+return N_("__ibm128 and long double cannot be used in the same 
expression");
+
+  if (!TARGET_IEEEQUAD
+  && ((mode1 == KFmode && mode2 == TFmode)
+ || (mode1 == TFmode && mode2 == KFmode)))
+return N_("__float128 and long double cannot be used in the same "
+ "expression");
+
+  return NULL;
+}
 
 
 /* Expand floating point conversion to/from __float128 and __ibm128.  */

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #11

[Michael Meissner]

This patch changes the mangling for __float128.  I came to the conclusion that
the current code is so tangled, that it would be better to use U10__float128
rather than "e".  However, if it is felt that we should go with "e", I can go
that way as well.

I have built the compiler with this patch and the previous subpatches (1-10).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_mangle_type): Use U10__float128
for IEEE 128-bit floating point.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229196)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -30052,6 +30052,21 @@ rs6000_mangle_type (const_tree type)
   if (type == bool_int_type_node) return "U6__booli";
   if (type == bool_long_type_node) return "U6__booll";
 
+  /* Use a unique name for __float128 rather than trying to use "e" or "g". Use
+ "g" for IBM extended double, no matter whether it is long double (using
+ -mabi=ibmlongdouble) or the distinct __ibm128 type.  */
+  if (TARGET_FLOAT128)
+{
+  if (type == ieee128_float_type_node)
+   return "U10__float128";
+
+  if (type == ibm128_float_type_node)
+   return "g";
+
+  if (type == long_double_type_node && TARGET_LONG_DOUBLE_128)
+   return (TARGET_IEEEQUAD) ? "U10__float128" : "g";
+}
+
   /* Mangle IBM extended float long double as `g' (__float128) on
  powerpc*-linux where long-double-64 previously was the default.  */
   if (TYPE_MAIN_VARIANT (type) == long_double_type_node

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #08

[Michael Meissner]

This patch adds support for using 'q' or 'Q' as a suffix for __float128
constants, which is compatible with the existing x86_64 implmenetation of their
__float128 support.

I have built the compiler with this patch and the previous subpatches (1-7).  I
have bootstrapped the compiler with all 16 subpatches installed, and there were
no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* config/rs6000/rs6000.c (TARGET_C_MODE_FOR_SUFFIX): Define 'q'
and 'Q' as the suffix to use for IEEE 128-bit floating point
constants with -mfloat128.
(rs6000_c_mode_for_suffix): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 229192)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1674,6 +1674,9 @@ static const struct attribute_spec rs600
 
 #undef TARGET_OFFLOAD_OPTIONS
 #define TARGET_OFFLOAD_OPTIONS rs6000_offload_options
+
+#undef TARGET_C_MODE_FOR_SUFFIX
+#define TARGET_C_MODE_FOR_SUFFIX rs6000_c_mode_for_suffix
 
 
 /* Processor table.  */
@@ -33308,6 +33311,26 @@ rs6000_vector_mode_supported_p (machine_
 return false;
 }
 
+/* Target hook for c_mode_for_suffix.  */
+static machine_mode
+rs6000_c_mode_for_suffix (char suffix)
+{
+  if (TARGET_FLOAT128)
+{
+  if (suffix == 'q' || suffix == 'Q')
+   return (FLOAT128_IEEE_P (TFmode)) ? TFmode : KFmode;
+
+  /* At the moment, we are not defining a suffix for IBM extended double.
+If/when the default for -mabi=ieeelongdouble is changed, and we want
+to support __ibm128 constants in legacy library code, we may need to
+re-evalaute this decision.  Currently, c-lex.c only supports 'w' and
+'q' as machine dependent suffixes.  The x86_64 port uses 'w' for
+__float80 constants.  */
+}
+
+  return VOIDmode;
+}
+
 /* Target hook for invalid_arg_for_unprototyped_fn. */
 static const char *
 invalid_arg_for_unprototyped_fn (const_tree typelist, const_tree funcdecl, 
const_tree val)

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #09

[Michael Meissner]

On Fri, Oct 23, 2015 at 08:05:58PM +, Joseph Myers wrote:
> On Fri, 23 Oct 2015, Michael Meissner wrote:
> 
> > This patch is the new patch from the last submission. It sets up a hook so 
> > that
> > the compiler will not allow IBM extended double and IEEE 128-bit floating 
> > point
> > to intermix in a binary expression without using an explicit conversion.
> 
> I don't see a testcase that this mixing is rejected.  And I'd have 
> expected you to need a C/C++ front-end patch to cause rejection in 
> conditional expressions, which don't seem currently to have such a hook, 
> but didn't see that in this series - is it intended for a patch after #7?

I am planning on writing the test cases, but I couldn't write them until all
of the sub-patches for patch #7 are in place.

I am planning on looking at a new hook for ?: next week.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #04

[Michael Meissner]

On Fri, Oct 23, 2015 at 01:36:25PM -0400, Michael Meissner wrote:
> This patch allows SUBREG's for the reg_or_indexed_operand, which is used when
> you have an integral value in a float/vector register, and you want to move 
> the
> value (either via direct move on power8, or via store).
> 
> I have built the compiler with this patch and the previous subpatches (1-3).  
> I
> have bootstrapped the compiler with all 16 subpatches installed, and there 
> were
> no regressions.  Is it ok to install in the trunk?
> 
> 2015-10-22  Michael Meissner  
> 
>   * config/rs6000/predicates.md (reg_or_indexed_operand): Allow
>   SUBREGs.

I forgot to attach the patch.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 229188)
+++ gcc/config/rs6000/predicates.md (revision 229189)
@@ -684,7 +684,7 @@ (define_predicate "indexed_or_indirect_o
 ;; Like indexed_or_indirect_operand, but also allow a GPR register if direct
 ;; moves are supported.
 (define_predicate "reg_or_indexed_operand"
-  (match_code "mem,reg")
+  (match_code "mem,reg,subreg")
 {
   if (MEM_P (op))
 return indexed_or_indirect_operand (op, mode);

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2)

[Segher Boessenkool]

On Fri, Oct 23, 2015 at 01:22:11PM -0400, Michael Meissner wrote:
> David asked me to try and break patch #7 into smaller bite sized chunks. I 
> have
> broken this into roughly 16 parts. These are the same patches that I submitted
> for patch #7 (revised), just broken up.  There is one additional patch in this
> selection, to restrict __float128 and IBM extended double from being combined
> in an expression.

#04, #05 are missing the patch.


Segher

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #09

[Joseph Myers]

On Fri, 23 Oct 2015, Michael Meissner wrote:

> This patch is the new patch from the last submission. It sets up a hook so 
> that
> the compiler will not allow IBM extended double and IEEE 128-bit floating 
> point
> to intermix in a binary expression without using an explicit conversion.

I don't see a testcase that this mixing is rejected.  And I'd have 
expected you to need a C/C++ front-end patch to cause rejection in 
conditional expressions, which don't seem currently to have such a hook, 
but didn't see that in this series - is it intended for a patch after #7?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2)

[Michael Meissner]

On Fri, Oct 23, 2015 at 02:47:16PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2015 at 01:22:11PM -0400, Michael Meissner wrote:
> > David asked me to try and break patch #7 into smaller bite sized chunks. I 
> > have
> > broken this into roughly 16 parts. These are the same patches that I 
> > submitted
> > for patch #7 (revised), just broken up.  There is one additional patch in 
> > this
> > selection, to restrict __float128 and IBM extended double from being 
> > combined
> > in an expression.
> 
> #04, #05 are missing the patch.

I had caught #05 was missing a patch, but I missed #04. I have re-submitted
subpatches #4 and #5.  Thanks.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #15

[Michael Meissner]

This patch adds the documentation.

I have built the compiler with this patch and the previous subpatches (1-14).
I have bootstrapped the compiler with all 16 subpatches installed, and there
were no regressions.  Is it ok to install in the trunk?

2015-10-22  Michael Meissner  

* doc/extend.texi (Floating Types): Document __ibm128 and
__float128 on PowerPC.

* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mfloat128 and -mno-float128.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 229182)
+++ gcc/doc/extend.texi (working copy)
@@ -929,6 +929,7 @@ examine and set these two fictitious var
 @cindex additional floating types
 @cindex @code{__float80} data type
 @cindex @code{__float128} data type
+@cindex @code{__ibm128} data type
 @cindex @code{w} floating point suffix
 @cindex @code{q} floating point suffix
 @cindex @code{W} floating point suffix
@@ -941,19 +942,39 @@ Support for additional types includes th
 add, subtract, multiply, divide; unary arithmetic operators;
 relational operators; equality operators; and conversions to and from
 integer and other floating types.  Use a suffix @samp{w} or @samp{W}
-in a literal constant of type @code{__float80} and @samp{q} or @samp{Q}
-for @code{_float128}.  You can declare complex types using the
-corresponding internal complex type, @code{XCmode} for @code{__float80}
-type and @code{TCmode} for @code{__float128} type:
+in a literal constant of type @code{__float80} or type
+@code{__ibm128}.  Use a suffix @samp{q} or @samp{Q} for @code{_float128}.
+
+On the i386, x86_64, IA-64, and HP-UX targets, you can declare complex
+types using the corresponding internal complex type, @code{XCmode} for
+@code{__float80} type and @code{TCmode} for @code{__float128} type:
 
 @smallexample
 typedef _Complex float __attribute__((mode(TC))) _Complex128;
 typedef _Complex float __attribute__((mode(XC))) _Complex80;
 @end smallexample
 
+On PowerPC Linux, Freebsd and Darwin systems, the default for
+@code{long double} is to use the IBM extended floating point format
+that uses a pair of @code{double} values to extend the precision.
+This means that the mode @code{TCmode} was already used by the
+traditional IBM long double format, and you would need to use the mode
+@code{KCmode}:
+
+@smallexample
+typedef _Complex float __attribute__((mode(KC))) _Complex128;
+@end smallexample
+
 Not all targets support additional floating-point types.  @code{__float80}
 and @code{__float128} types are supported on x86 and IA-64 targets.
-The @code{__float128} type is supported on hppa HP-UX targets.
+The @code{__float128} type is supported on hppa HP-UX.
+The @code{__float128} type is supported on PowerPC systems by default
+if the vector scalar instruction set (VSX) is enabled.
+
+On the PowerPC, @code{__ibm128} provides access to the IBM extended
+double format, and it is intended to be used by the library functions
+that handle conversions if/when long double is changed to be IEEE
+128-bit floating point.
 
 @node Half-Precision
 @section Half-Precision Floating Point
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 229182)
+++ gcc/doc/invoke.texi (working copy)
@@ -946,7 +946,8 @@ See RS/6000 and PowerPC Options.
 -mquad-memory-atomic -mno-quad-memory-atomic @gol
 -mcompat-align-parm -mno-compat-align-parm @gol
 -mupper-regs-df -mno-upper-regs-df -mupper-regs-sf -mno-upper-regs-sf @gol
--mupper-regs -mno-upper-regs}
+-mupper-regs -mno-upper-regs @gol
+-mfloat128 -mno-float128}
 
 @emph{RX Options}
 @gccoptlist{-m64bit-doubles  -m32bit-doubles  -fpu  -nofpu@gol
@@ -19519,6 +19520,17 @@ floating point register set, depending o
 If the @option{-mno-upper-regs} option is used, it turns off both
 @option{-mupper-regs-sf} and @option{-mupper-regs-df} options.
 
+@item -mfloat128
+@itemx -mno-float128
+@opindex mfloat128
+@opindex mno-float128
+Enable/disable the @var{__float128} keyword for IEEE 128-bit floating point
+and use software emulation for IEEE 128-bit floating point.
+
+The VSX instruction set (@option{-mvsx}, @option{-mcpu=power7}, or
+@option{-mcpu=power8}) must be enabled to use the @option{-mfloat128}
+option.
+
 @item -mfloat-gprs=@var{yes/single/double/no}
 @itemx -mfloat-gprs
 @opindex mfloat-gprs

Re: [Patch] PowerPC IEEE 128-bit patch #7 (revised #2)

[Michael Meissner]

On Thu, Oct 08, 2015 at 09:30:45PM +, Joseph Myers wrote:
> Question: what happens if you mix __float128 and __ibm128 in an arithmetic 
> or conditional expression?
> 
> __float128 a;
> __ibm128 b;
> int x;
> /* ... */
> a + b;
> x ? a : b;
> 
> (And likewise if one or both are the corresponding complex types.)  As I 
> suggested in  I think 
> this would best be rejected for both C and C++ (with testcases).  That 
> accords with TS 18661-3 (just published) making floating-point conversions 
> undefined where neither type's set of values is a subset of the other's.
> 
> The invalid_binary_op target hook should be usable to cover the case where 
> a binary operation would cause implicit conversions, but I don't see an 
> existing hook that would deal with ? : expressions.

Good points. I hadn't delved into error conditions, but I will code up a target
hook not allowing inter-mixing different formats.

I believe every non-NaN value that IBM extended double supports is
representable in IEEE 754R 128-bit floating point, since IEEE has 112 bits of
mantissa plus the hidden bit, while IBM extended double has 106 bits (52 bits
of mantissa for each part plus 2 hidden bits). Even with all of the extra bits
that you can hand craft into silent/signalling NaNs, you should be able
represent those values in IEEE 128-bit floating point as similar NaNs.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [Patch] PowerPC IEEE 128-bit patch #7 (revised #2)

[Joseph Myers]

On Tue, 13 Oct 2015, Michael Meissner wrote:

> I believe every non-NaN value that IBM extended double supports is
> representable in IEEE 754R 128-bit floating point, since IEEE has 112 bits of
> mantissa plus the hidden bit, while IBM extended double has 106 bits (52 bits
> of mantissa for each part plus 2 hidden bits). Even with all of the extra bits

No, because IBM long double can represent values with discontiguous 
mantissa bits (these are the values that 
libgcc/config/rs6000/ibm-ldouble-format describes as denormal but not 
subnormal).

> that you can hand craft into silent/signalling NaNs, you should be able
> represent those values in IEEE 128-bit floating point as similar NaNs.

The low part of a NaN in IBM long double is documented as don't-care (so 
all IBM long double NaNs are correctly converted to binary128 simply by 
converting the high part - as is also the case with zeroes).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [Patch] PowerPC IEEE 128-bit patch #7 (revised #2)

[Joseph Myers]

Question: what happens if you mix __float128 and __ibm128 in an arithmetic 
or conditional expression?

__float128 a;
__ibm128 b;
int x;
/* ... */
a + b;
x ? a : b;

(And likewise if one or both are the corresponding complex types.)  As I 
suggested in  I think 
this would best be rejected for both C and C++ (with testcases).  That 
accords with TS 18661-3 (just published) making floating-point conversions 
undefined where neither type's set of values is a subset of the other's.

The invalid_binary_op target hook should be usable to cover the case where 
a binary operation would cause implicit conversions, but I don't see an 
existing hook that would deal with ? : expressions.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised)

[Michael Meissner]

A heads up. I just found some places in the IEEE 128-bit floating point code
where it doesn't handle conversions to/from __ibm128.  Nor does it generate the
same names for -mabi=ieeelongdouble.  I will submit a revised patch when it is
ready.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797