Re: [PATCH], PowerPC, add ISA 3.0 xxperm (power9 patch #12)

[David Edelsohn]

On Thu, Dec 31, 2015 at 1:30 PM, Michael Meissner
 wrote:
> This patch adds support for the ISA 3.0 XXPERM instruction, which is like
> VPERM, except it can operate on any VSX register.  Since the instruction is a 
> 3
> operand instruction (RT and RA must be the same), I made it so VPERM was
> preferred.  I also added XXPERM fusion support where a XXLOR move instruction
> immediately before the XXPERM instruction is fused together.
>
> I have bootstrapped and done make check on a big endian power7 and a little
> endian power8 system.  In addition, I built all of Spec 2006 with power9
> support enabled, and all of the tests that previously built now build with
> XXPERM being generated (the OMNETPP benchmark currently does not build on
> little endian for either power8 or power9).  Are these patches ok to check in?
>
> [gcc]
> 2015-12-31  Michael Meissner  
>
> * config/rs6000/constraints.md (wo constraint): New constraint for
> ISA 3.0 (power9).
>
> * config/rs6000/rs6000.c (rs6000_debug_reg_global): Add support
> for wo constraint.
> (rs6000_init_hard_regno_mode_ok): Likewise.
>
> * config/rs6000/rs6000.h (r6000_reg_class_enum): Add support for
> wo constraint.
>
> * config/rs6000/altivec.md (altivec_vperm_): Clean up vperm
> expanders not to have constraints.  Add support for ISA 3.0 xxperm
> instruction.  Add support for fusing xxlor with xxperm.
> (altivec_vperm__internal): Likewise.
> (altivec_vperm_v8hiv16qi): Likewise.
> (altivec_vperm_v16q): Likewise.
> (altivec_vperm__uns): Likewise.
> (vperm_v8hiv4si): Likewise.
> (vperm_v16qiv8hi): Likewise.
>
> * doc/md.texi (RS/6000 constraints): Document wo constraint.
>
> [gcc/testsuite]
> 2015-12-31  Michael Meissner  
>
> * gcc.target/powerpc/p9-permute.c: New test for xxperm code
> generation.

This is okay.

Thanks, David

Re: [PATCH], PowerPC, Add -mpower9-dform to switches turned on with -mcpu=power9

[David Edelsohn]

On Thu, Dec 31, 2015 at 3:41 PM, Michael Meissner
 wrote:
> When I did the inital d-form support for ISA 3.0 (power9) for loading scalar
> SF/DF values into Altivec registers, I did not enable -mpower9-dform with the
> other ISA 3.0 switches when you used -mcpu=power9.  This was during the 
> initial
> development, I had some bugs.  I fixed the bugs, but I forgot to enable the
> d-form addressing support.  This patch enables that default.
>
> I have built all of Spec 2006 with this option, and there were no failures.  I
> did not do the full bootstrap/make check right now, but I have done it in the
> past with no regressions.  Is it ok to install this patch?
>
> 2015-12-31  Michael Meissner  
>
> * config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Add
> OPTION_MASK_P9_DFORM.
>
> (Note, at some point there will be patches to enable using d-form addressing
> with 128-bit vector types, but those patches aren't ready yet).

This is okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit fp, patch #10 (comparison, documentation, conversion, debug)

[David Edelsohn]

On Tue, Dec 29, 2015 at 10:43 AM, Michael Meissner
 wrote:
> This is a clean-up patch for IEEE 128-bit floating point support on the
> PowerPC.
>
> The main change is to change the way comparisons are done when IEEE 128-bit
> floating is emulated.  Previously, I had added special __cmpkf2 and __cmpukf2
> functions that were modeled on the CR bits that the XSCMPUQP instruction sets.
> I have changed this to use the standard EQ, GE, LE, and UNORD functions
> provided by glibc/libgcc's software floating point emulation functions.
>
> I've done some debugging on issues with _Complex __float128, and I think at 
> the
> moment it is just not feasible to support _Complex __float128 in GCC 6.x.  The
> main problem is the way the IFmode/KFmode types are added as fractional 
> floating
> point types which prevents them from being default types for conversion.  I
> think in order to support this, the machine independent type system is going 
> to
> have to be tinkered with.  However, since we are now coming to the end of
> stage3 it is not the time to be making these changes.
>
> I added documentation to state that right now -mfloat128 is only enabled on
> 64-bit PowerPC Linux systems.  There is some desire for this to be eventually
> supported on other systems like FreeBSD, but I wanted to set expectations for
> users interested in the this.  I also documented that complex __float128
> currently does not work.
>
> I added an undocumented debug switch (-mfloat128-convert) that enables default
> conversions between IBM extended double and IEEE 128-bit floating point, to
> enable further debugging of the complex __float128 support in the future.
>
> Finally, I noticed if you use -mabi=ieeelongdouble, that it generated calls to
> convert between long double and explicit __float128, even though they are the
> same representation, and fixed that.
>
> Going forward, patch #11 will enable the software emulation library.  At the
> moment, there is no support for converting between decimal types and
> __float128, nor for the complex __float128 support.  These are being worked 
> on,
> and should be done in the GCC 7.x time frame.  However, it is important to add
> the software emulation support in GCC 6.x so that most users that want to use
> IEEE 128-bit floating point can use it, and that we can work on the glibc
> issues to fully support __float128 in the GCC 7.x time frame.
>
> 2015-12-29  Michael Meissner  
>
> * config/rs6000/rs6000.c (init_float128_ieee): Remove IEEE 128-bit
> comparison functions in cmp_optab and ucmp_optab.
> (rs6000_generate_compare): Rewrite IEEE 128-bit floating point
> software emulation comparisons to only use __eqkf2, __gekf2,
> __lekf2, and __unordkf2 functions.
> (rs6000_invalid_binary_op): Add support for -mfloat128-convert.
>
> * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define
> __FLOAT128_HARDWARE__ if hardware IEEE 128-bit support is
> available.
>
> * config/rs6000/rs6000.opt (-mfloat128-convert): Add debug switch
> to allow IBM extended double and IEEE 128-bit floating point to be
> converted with default conversions.
>
> * config/rs6000/rs6000.md (extendkftf2): Add converters between
> KFmode and TFmode if -mabi=ieeelongdouble.
> (trunctfkf2): Likewise.
> (ieee128_mfvsrd): Split 64-bit integer conversions into 32-bit and
> 64-bit insns.
> (ieee128_mfvsrd_64bit): Likewise.
> (ieee128_mfvsrd_32bit): Likewise.
> (ieee128_mtvsrd): Likewise.
> (ieee128_mtvsrd_64bit): Likewise.
> (ieee128_mtvsrd_32bit): Likewise.
>
> * doc/extend.texi (Floating Types): Document that complex
> __float128 does not work currently.
>
> * doc/invoke.texi (RS/6000 and PowerPC Options): Document that
> -mfloat128 is only supported on PowerPC 64-bit Linux systems.

Okay.

Thanks, David

Re: [PATCH], PowerPC IEEE 128-bit fp, #11 (enable libgcc conversions)

[David Edelsohn]

On Tue, Dec 29, 2015 at 11:38 AM, Michael Meissner
 wrote:
> This patch enables support of the __float128 software emulation functions in
> libgcc.  The patch is reworked from previous versions of this patch (listed as
> patch #8).
>
> This patch adds support for declaring emulation functions that either use the
> software emulation functions from the soft-fp subdirectory converted for
> PowerPC __float128 via sed, or by using the hardware instructions that will be
> present in ISA 3.0 (power9).  Thus if you compile code for power7/power8 and
> run it on a power9 system, it use the hardware support when running on power9.
>
> I removed the old comparison functions that was in previous versions of this
> patch, and instead went with the standard EQ, GE, LE, and UNORD software
> emulation support (patch #10 changes the compiler to use these functions).
>
> This patch adds support to use the hardware rounding modes and exceptions for
> software emulation that was done by Steven Munroe and Tulio Magno.
>
> The __float128 support is only enabled on 64-bit PowerPC Linux systems, where
> the base compler targets at least power7.  On big endian systems, you can use
> __float128 in 32-bit mode, but the support functions are not built on a purely
> 32-bit system.
>
> At the moment, there is no support for converting between decimal types and
> __float128, nor for the complex __float128 support.  These are being worked 
> on,
> and should be done in the GCC 7.x time frame.  However, it is important to add
> the software emulation support in GCC 6.x now so that most users that want to
> use IEEE 128-bit floating point can use it, and that we can work on the glibc
> issues to fully support __float128 in the GCC 7.x time frame.  There might be
> problems that need to be fixed, but without the libgcc changes, nobody can use
> __float128.
>
> I have done bootstraps on a big-endian power7 system and little-endian power8
> system with no regressions.  I have also built a compiler on a SLES 11.3 
> system
> to make sure that it builds on systems without the ISA 3.0 instructions (in
> this case, the ifunc resolver always returns the software emulation function).
> Is this ok to install in the tree along with IEEE patch #10?
>
> 2015-12-29  Michael Meissner  
> Steven Munroe (munro...@linux.vnet.ibm.com)
> Tulio Magno Quites Machado Filho 
>
> * config/rs6000/floattikf-sw.c: New file to convert signed 128-bit
> integers to IEEE 128-bit floating point.
>
> * config/rs6000/float128-hw.c: New file for ISA 3.0 IEEE 128-bit
> floating point hardware support.
>
> * config/rs6000/fixkfti-sw.c: New file to convert IEEE 128-bit
> floating point to signed 128-bit integer.
>
> * config/rs6000/float128-ifunc.c: New file to pick either IEEE
> 128-bit floating point software emulation or use ISA 3.0 hardware
> support if it is available.
>
> * config/rs6000/fixunskfti-sw.c: New file to convert IEEE 128-bit
> floating point to unsigned 128-bit integer.
>
> * config/rs6000/extendkftf2-sw.c: New file to convert IBM extended
> double to IEEE 128-bit floating point.
>
> * config/rs6000/floatuntikf-sw.c: New file to convert unsigned
> 128-bit integer to IEEE 128-bit floating point.
>
> * config/rs6000/trunctfkf2-sw.c: New file to convert IEEE 128-bit
> floating point to IBM extended double.
>
> * config/rs6000/t-float128: New file to build IEEE 128-bit
> floating point emulator functions.
>
> * config/rs6000/t-float128-hw: New file to build IEEE 128-bit
> floating point emulator functions using ISA 3.0 hardware
> instructions.
>
> * config/rs6000/sfp-exceptions.c: New file to provide exception
> support for IEEE 128-bit floating point.
>
> * config/rs6000/quad-float128.h: New file to support IEEE 128-bit
> floating point.
>
> * config/rs6000/float128-sed: New file to convert TF names to KF
> names for PowerPC IEEE 128-bit floating point support.
>
> * config/rs6000/sfp-machine.h (_FP_W_TYPE_SIZE): Use 64-bit types
> when building on 64-bit systems, or when VSX is enabled.
> (_FP_W_TYPE): Likewise.
> (_FP_WS_TYPE): Likewise.
> (_FP_I_TYPE): Likewise.
> (TItype): Define on 64-bit systems.
> (UTItype): Likewise.
> (TI_BITS): Likewise.
> (_FP_MUL_MEAT_D): Add support for using 64-bit types.
> (_FP_MUL_MEAT_Q): Likewise.
> (_FP_DIV_MEAT_D): Likewise.
> (_FP_DIV_MEAT_Q): Likewise.
> (_FP_NANFRAC_D): Likewise.
> (_FP_NANFRAC_Q): Likewise.
> (ISA_BIT): Add exception support.
> (FP_EX_INVALID): Likewise.
> (FP_EX_OVERFLOW): Likewise.
> (FP_EX_UNDERFLOW): Likewise.
> (FP_EX_DIVZERO): 

Re: [PATCH, rs6000] Add support for lxvx and stxvx P9 instructions

[David Edelsohn]

On Sun, Dec 27, 2015 at 6:00 PM, Bill Schmidt
 wrote:
> Hi,
>
> POWER9 adds endian-neutral load and store vector instructions that
> support unaligned accesses. This allows more efficient code generation
> than POWER8.  With these new instructions, we no longer generate the
> load-swap and swap-store sequences, and we no longer need to perform
> swap optimization to get rid of unnecessary swaps.  We also need to make
> sure that we don't perform P8-specific vector load fusion sequences when
> the new instructions are available.
>
> This patch includes two tests that verify the correct instructions are
> generated with -mcpu=power9.  One of these generates a pattern that
> causes P8-specific vector load fusion with -mcpu=power8, and verifies we
> don't generate it with -mcpu=power9.
>
> Besides these tests, I hand-tested all the swaps-p8* tests to verify
> correct generation of lxvx and stxvx rather than the old P8 sequences.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  Ok for trunk, and then for backport to GCC 5?
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2015-12-27  Bill Schmidt  
>
> * config/rs6000/rs6000.c (rs6000_emit_le_vsx_move): Verify that
> this is never called when lxvx/stxvx are available.
> (pass_analyze_swaps::gate): Don't perform swap optimization when
> lxvx/stxvx are available.
> * config/rs6000/vector.md (mov): Don't call
> rs6000_emit_le_vsx_move when lxvx/stxvx are available.
> * config/rs6000/vsx.md (*p9_vecload_): New define_insn.
> (*p9_vecstore_): Likewise.
> (*vsx_le_perm_load_:VSX_LE): Disable when lxvx/stxvx are
> available.
> (*vsx_le_perm_load_:VSX_W): Likewise.
> (*vsx_le_perm_load_v8hi): Likewise.
> (*vsx_le_perm_load_v16qi): Likewise.
> (*vsx_le_perm_store_:VSX_LE): Likewise.
> ([related define_splits]): Likewise.
> (*vsx_le_perm_store_:VSX_W): Likewise.
> ([related define_splits]): Likewise.
> (*vsx_le_perm_store_v8hi): Likewise.
> ([related define_splits]): Likewise.
> (*vsx_le_perm_store_v16qi): Likewise.
> ([related define_splits]): Likewise.
> (*vsx_lxvd2x2_le_): Likewise.
> (*vsx_lxvd2x4_le_): Likewise.
> (*vsx_lxvd2x8_le_V8HI): Likewise.
> (*vsx_lvxd2x16_le_V16QI): Likewise.
> (*vsx_stxvd2x2_le_): Likewise.
> (*vsx_stxvd2x4_le_): Likewise.
> (*vsx_stxvd2x8_le_V8HI): Likewise.
> (*vsx_stxvdx16_le_V16QI): Likewise.
>
> [gcc/testsuite]
>
> 2015-12-27  Bill Schmidt  
>
> * gcc.target/powerpc/p9-lxvx-stxvx-1.c: New.
> * gcc.target/powerpc/p9-lxvx-stxvx-2.c: New.

Okay for trunk.  This isn't a bug fix, so GCC 5 will require more consideration.

Thanks, David

Re: [PATCH, rs6000] Fix PR target/68872, make -mcpu=powerpc64le pass correct assembler option

[David Edelsohn]

On Tue, Dec 22, 2015 at 2:30 PM, Peter Bergner <berg...@vnet.ibm.com> wrote:
> On Tue, 2015-12-22 at 13:36 -0500, David Edelsohn wrote:
>> On Tue, Dec 22, 2015 at 12:13 PM, Peter Bergner <berg...@vnet.ibm.com> wrote:

>> Ultimately rs6000_file_start ".machine" directive support should be
>> strengthened to handle -mcpu=.
>
> I'm not sure there is anything to do there.  The code that emits the
> .machine assembler directive uses rs6000_isa_flags which should be
> set correctly, regardless of whether we use -mcpu= with power8 or
> powerpc64le.  ...although, the code as is never outputs a .machine
> on LE, since the code that guards the emitting of .machine doesn't
> ever seem to be true on LE.  At least I can't seem to get a .machine
> generated with my LE build.

Currently, the .machine directive only is emitted if -mcpu= is not
used.  We should avoid -mcpu= setting assembler command line options
and instead switch to use .machine.  The .machine path needs to be
tested more thoroughly in the presence of -mcpu options.

Thanks, David

Re: [PATCH, rs6000] Fix PR target/68872, make -mcpu=powerpc64le pass correct assembler option

[David Edelsohn]

On Tue, Dec 22, 2015 at 12:13 PM, Peter Bergner  wrote:
> Currently, -mcpu=powerpc64le correctly sets the TARGET_* flags for an
> LE compile, meaning it mimics a -mcpu=power8 compile, but it doesn't
> pass the correct -mpower8/-mpwr8 option to the assembler, so we die
> with lots of assembler errors on POWER8 instructions.  This patch
> fixes things so we pass the correct assembler option when using
> -mcpu=powerpc64le.
>
> This passes bootstrap/regtesting on powerpc64le-linux.  Ok for mainline?
> Ok for the release branches too after testing?
>
> Peter
>
>
> gcc/
> PR target/68772
> * config/rs6000/rs6000.h (ASM_CPU_SPEC): For -mcpu=powerpc64le,
> pass %(asm_cpu_power8)/-mpwr8.
> * config/rs6000/aix53.h: Likewise.
> * config/rs6000/aix61.h: Likewise.
> * config/rs6000/aix71.h: Likewise.
>
> gcc/testsuite/
> PR target/68772
> * gcc.target/powerpc/pr68872.c: New test.

AIX does not support PPC64LE, so the aix53.h, aix61.h and aix71.h
changes should not be applied.

Ultimately rs6000_file_start ".machine" directive support should be
strengthened to handle -mcpu=.

Okay with just the rs6000.h change and new testcase.

Thanks, David

Re: [PATCH 4/4] Un-XFAIL ssa-dom-cse-2.c for most platforms

[David Edelsohn]

On Mon, Dec 21, 2015 at 8:13 AM, Alan Lawrence  wrote:
> ...the test passes with --param sra-max-scalarization-size-Ospeed.
>
> Verified on aarch64 and with stage1 compiler for hppa, powerpc, sparc, s390.
>
> On alpha, tree-optimized is:
>
>   MEM[(int[8] *)] = { 0, 1 };
>   MEM[(int[8] *) + 8B] = { 2, 3 };
>   MEM[(int[8] *) + 16B] = { 4, 5 };
>   MEM[(int[8] *) + 24B] = { 6, 7 };
>   _23 = a[0];
>   _29 = a[1];
>   sum_30 = _23 + _29;
>   _36 = a[2];
>   sum_37 = sum_30 + _36;
>
> Which is beyond the scope of these changes to DOM to optimize.
>
> On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized as a
> reduction); however, without that, similar code is generated to Alpha (the
> vectorizer decides the reduction is not worthwhile without SIMD support), and
> the test fails; hence, I've XFAILed for powerpc, but I think I could condition
> the XFAIL on powerpc64 && !check_p8vector_hw_available, if preferred?

Fun.

Does it work with -mcpu=power7?

Bill: What GCC DejaGNU incantation would you like to see?

- David

Re: [PATCH] Pr 68805, Fix PowerPC little endian -mvsx-timode

[David Edelsohn]

On Wed, Dec 16, 2015 at 6:20 PM, Michael Meissner
 wrote:
> My first mail did not seem to be delivered, so I'm trying again.
>
> This fixes a bug with the debug switch -mvsx-timode that we would eventually
> like to enable by default on PowerPC little endian server systems.  The bug is
> that the load with rotate or rotate with store instructions needed on power8
> little endian systems used VEC_SELECT to swap the 64-bit words.  This patch
> uses ROTATE for TImode, just like I did for KFmode.
>
> Without this patch, 10 of the 30 spec 2006 benchmarks fail to compile on a
> little endian PowerPC system with -mvsx-timode.  With the patch, all 30
> benchmarks compile and do the spec verification.
>
> In developing the patch, I noticed that the generic swap optimizations that 
> are
> done for vector types are not done for TImode, since we don't split the 
> TImoves
> until after register allocation when we discover a vector register was used
> instead of a GPR register.  So, I added a peephole2 to catch the common case 
> of
> store followed by load, eliminating the pair of ROTATE insns.
>
> I bootstrapped it on both a big endian power7 and a little endian power8 
> system
> with no regressions.  Is it ok to install on the trunk?
>
> At the current time, I don't see the need to back port it to GCC 5 (though the
> backport is fairly simple), because it isn't on by default in GCC 5, and we
> don't plan to eventually have -mvsx-timode and -mlra on by default in that
> branch.
>
> [gcc]
> 2015-12-15  Michael Meissner  
>
> PR target/68805
> * config/rs6000/rs6000.c (rs6000_gen_le_vsx_permute): Use ROTATE
> instead of VEC_SELECT for TImode.
>
> * config/rs6000/vsx.md (VSX_LE): Move TImode from VSX_LE to
> VSX_LE_128, so that we use ROTATE to swap the 64-bit words instead
> of using VEC_SELECT.
> (VSX_LE_128): Likewise.
> (define_peephole2): Add peephole to eliminate double xxpermdi when
> copying TImode.
>
> [gcc/testsuite]
> 2015-12-15  Michael Meissner  
>
> PR target/68805
> * gcc.target/powerpc/pr68805.c: New test.

Okay.

Thanks, David

Re: [PATCH] rs6000: Fix a mistake in cstore_si_as_di (PR68865, PR68879)

[David Edelsohn]

On Mon, Dec 14, 2015 at 2:04 AM, Segher Boessenkool
 wrote:
> convert_move does not know how to zero-extend a constant integer to the
> target mode -- simply because it does not know the target mode.  As a
> result, 32-bit SImode with the high bit set would be effectively sign-
> extended instead of zero-extended.
>
> This patch fixes it.  Is this okay for trunk?  (bootstrap+regtest in
> progress, on powerpc64-linux).
>
>
> Segher
>
>
> 2015-12-14  Segher Boessenkool  
>
> PR target/68865
> PR target/68879
> * rs6000.md (cstore_si_as_di): Force all operands into registers.

Okay.

Thanks, David

[PATCH] g++.dg/cpp1y/pr58708.C testcase fix for AIX

[David Edelsohn]

I previously updated the assignment to correct the compile-time error,
but the runtime check of values also needs to be updated for 16 bit
wchar_t.

Tested on powerpc-ibm-aix7.1.0.0.

Committed.

Thanks, David

* g++.dg/cpp17/pr58708.C: Test appropriate value for size of wchar_t.

Index: pr58708.C
===
--- pr58708.C   (revision 231582)
+++ pr58708.C   (working copy)
@@ -50,8 +50,13 @@
 #endif
   if (is_same::value != true)
__builtin_abort();
   if (sizeof(wfoo.chars)/sizeof(wchar_t) != 2) __builtin_abort();
+#if __SIZEOF_WCHAR_T__ == 2
+  if (wfoo.chars[0] != 258) __builtin_abort();
+  if (wfoo.chars[1] != 772) __builtin_abort();
+#else
   if (wfoo.chars[0] != 16909060) __builtin_abort();
   if (wfoo.chars[1] != 84281096) __builtin_abort();
+#endif

   auto foou = u"\x0102\x0304\x0506\x0708"_foo;
   if (is_same::value != true)
__builtin_abort();

Re: Request permission to delete gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c

[David Edelsohn]

On Thu, Dec 10, 2015 at 2:23 PM, Bill Schmidt
 wrote:
> Hi,
>
> The subject test case has been failing as follows:
>
> FAIL: gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c 
> scan-tree-dump-times vect "vectorization not profitable" 1
>
> The test has been failing since r223528, which is:
>
> 2015-05-22  Richard Biener  
>
> PR tree-optimization/65701
> * tree-vect-data-refs.c (vect_enhance_data_refs_alignment):
> Move peeling cost models into one place.  Peel for alignment
> for single loads only if an aligned load is cheaper than
> an unaligned load.
>
> Thus with that modification, gcc now vectorizes the loop that was
> previously deemed unprofitable to vectorize.  As a result, the test case
> no longer has any reason to exist, and I would like to delete it.
>
> Ok for trunk?
>
> Thanks,
> Bill
>
>
> [gcc/testsuite]
>
> 2015-12-10  Bill Schmidt  
>
> * gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c:
> Delete.

Okay with me.

Thanks, David

Re: [PATCH 1/2] rs6000: Implement cstore for signed Pmode register compares

[David Edelsohn]

On Fri, Dec 4, 2015 at 9:34 AM, Segher Boessenkool
 wrote:
> This implements cstore for the last case we do not yet handle, using
> the superopt algo from the venerable CWG.  The only integer cases we
> do still not handle after this are for -m32 -mpowerpc64.  Those case
> now generate a branch sequence, which is better than what we had
> before.
>
> Tested on powerpc64-linux; okay for mainline?
>
>
> Segher
>
>
> 2015-12-04  Segher Boessenkool  
>
> * (cstore4_signed): New expander.
> (cstore4): Call it.  FAIL instead of calling rs6000_emit_sCOND.

The new expander is okay as well as calling it.

Please do not remove the fallback to sCOND without performance testing.

Thanks, David

Re: [PATCH 2/2] rs6000: Clean up the cstore code a bit

[David Edelsohn]

On Fri, Dec 4, 2015 at 9:34 AM, Segher Boessenkool
 wrote:
> "register_operand" was a bit confusing.  Also some other minor cleanups.
>
> Tested on powerpc64-linux; okay for mainline?
>
>
> Segher
>
>
> 2015-12-04  Segher Boessenkool  
>
> * (cstore4_unsigned): Use gpc_reg_operand instead of
> register_operand.  Remove empty constraints.  Use std::swap.
> (cstore_si_as_di, cstore4_signed_imm,
> cstore4_unsigned_imm, cstore4 for GPR): Use
> gpc_reg_operand instead of register_operand.
> (cstore4 for FP): Use gpc_reg_operand instead of
> register_operand.  Remove empty constraints.

Okay.

Thanks, David

[PATCH] PPC sqrtf using rsqrtes (PR 68609)

[David Edelsohn]

The PowerPC port provides reciprocal sqrt but doesn't implement the
extra incantation to utilize it for sqrtf.

The current implementation re-associates terms in the N-R iteration to
utilize one constant instead of two, but does not provide a
pre-computed estimate multiplied by the source, which requires an
extra multiply at the end.  The cost of the extra load of an FP
constant through the LSU and a register to hold it seems to balance
against the cost of the extra multiply in the VSU, so it's not clear
that re-arranging the computation is beneficial.

Thanks, David

PR target/68609
* config/rs6000/rs6000-protos.h (rs6000_emit_swsqrt): Rename and add
bool arguement.
* config/rs6000/rs6000.c (rs6000_emit_swsqrt): Rename. Add non-reciporcal path.
* config/rs6000/rs6000.md (rsqrt2): Call new function name.
(sqrt2): Replace define_insn with define_expand that can call
rs6000_emit_swsqrt.

Index: rs6000-protos.h
===
--- rs6000-protos.h (revision 231169)
+++ rs6000-protos.h (working copy)
@@ -137,7 +137,7 @@
 extern void rs6000_expand_atomic_exchange (rtx op[]);
 extern void rs6000_expand_atomic_op (enum rtx_code, rtx, rtx, rtx, rtx, rtx);
 extern void rs6000_emit_swdiv (rtx, rtx, rtx, bool);
-extern void rs6000_emit_swrsqrt (rtx, rtx);
+extern void rs6000_emit_swsqrt (rtx, rtx, bool);
 extern void output_toc (FILE *, rtx, int, machine_mode);
 extern rtx rs6000_longcall_ref (rtx);
 extern void rs6000_fatal_bad_address (rtx);
Index: rs6000.c
===
--- rs6000.c(revision 231169)
+++ rs6000.c(working copy)
@@ -32889,7 +32889,7 @@ rs6000_emit_swdiv (rtx dst, rtx n, rtx d, bool not
rsqrt.  Assumes no trapping math and finite arguments.  */

 void
-rs6000_emit_swrsqrt (rtx dst, rtx src)
+rs6000_emit_swsqrt (rtx dst, rtx src, bool recip)
 {
   machine_mode mode = GET_MODE (src);
   rtx x0 = gen_reg_rtx (mode);
@@ -32922,6 +32922,16 @@ void
   emit_insn (gen_rtx_SET (x0, gen_rtx_UNSPEC (mode, gen_rtvec (1, src),
  UNSPEC_RSQRT)));

+  /* If (src == 0.0) filter infinity to prevent NaN for sqrt(0.0).  */
+  if (!recip)
+{
+  rtx zero = force_reg (mode, CONST0_RTX (mode));
+  rtx target = emit_conditional_move (x0, GT, src, zero, mode,
+ x0, zero, mode, 0);
+  if (target != x0)
+   emit_move_insn (x0, target);
+}
+
   /* y = 0.5 * src = 1.5 * src - src -> fewer constants */
   rs6000_emit_msub (y, src, halfthree, src);

@@ -32938,7 +32948,11 @@ void
   x0 = x1;
 }

-  emit_move_insn (dst, x0);
+  if (!recip)
+emit_insn (gen_mul (dst, src, x0));
+  else
+emit_move_insn (dst, x0);
+
   return;
 }
Index: rs6000.md
===
--- rs6000.md   (revision 231169)
+++ rs6000.md   (working copy)
@@ -4301,7 +4301,7 @@
(match_operand:RECIPF 1 "gpc_reg_operand" "")]
   "RS6000_RECIP_HAVE_RSQRTE_P (mode)"
 {
-  rs6000_emit_swrsqrt (operands[0], operands[1]);
+  rs6000_emit_swsqrt (operands[0], operands[1], 1);
   DONE;
 })
 ^L
@@ -4426,7 +4426,7 @@
   [(set_attr "type" "div")
(set_attr "fp_type" "fp_div_")])

-(define_insn "sqrt2"
+(define_insn "*sqrt2_internal"
   [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,")
(sqrt:SFDF (match_operand:SFDF 1 "gpc_reg_operand" ",")))]
   "TARGET__FPR && !TARGET_SIMPLE_FPU
@@ -4437,6 +4437,23 @@
   [(set_attr "type" "sqrt")
(set_attr "fp_type" "fp_sqrt_")])

+(define_expand "sqrt2"
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "")
+   (sqrt:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "")))]
+  "TARGET__FPR && !TARGET_SIMPLE_FPU
+   && (TARGET_PPC_GPOPT || (mode == SFmode && TARGET_XILINX_FPU))"
+{
+  if (mode == SFmode
+  && RS6000_RECIP_HAVE_RSQRTE_P (mode)
+  && !optimize_function_for_size_p (cfun)
+  && flag_finite_math_only && !flag_trapping_math
+  && flag_unsafe_math_optimizations)
+{
+  rs6000_emit_swsqrt (operands[0], operands[1], 0);
+  DONE;
+}
+})
+
 ;; Floating point reciprocal approximation
 (define_insn "fre"
   [(set (match_operand:SFDF 0 "gpc_reg_operand" "=,")

Re: [PATCH] Fix large code model with the ELFv2 ABI

[David Edelsohn]

On Wed, Dec 2, 2015 at 2:44 PM, Ulrich Weigand  wrote:
> Hello,
>
> this patch fixes support for the large code model with the ELFv2 ABI.
>
> The global entry point prologue currently assumes that the TOC associated
> with a function is less than 2GB away from the function entry point.  This
> is always true when using the medium or small code model, but may not be
> the case when using the large code model.
>
> This patch adds a new variant of the ELFv2 global entry point prologue that
> lifts the 2GB restriction when building with -mcmodel=large.  This works by
> emitting a quadword containing the distance from the function entry point
> to its associated TOC immediately before the entry point (this is done in
> rs6000_elf_declare_function_name), and then using a prologue like:
>
> ld r2,-8(r12)
> add r2,r2,r12
>
> In addition, if assembler support for this new relocation is detected,
> the compiler emits a R_PPC64_ENTRY reloc on the first instruction of
> this new prologue.  This will allow the linker to rewrite the prologue
> to the original form if it turns out at link time that the distance
> between entry point and TOC actually happens to be less than 2GB.
>
> The patch also introduces a new function rs6000_global_entry_point_needed_p,
> which is used instead of directly checking cfun->machine->r2_setup_needed.
> This allows handling global entry point prologues for C++ thunks.  This was
> previously done by having rs6000_output_mi_thunk set the r2_setup_needed
> flag, but this no longer works, since we now need to check whether we need
> a global entry point prologue in rs6000_elf_declare_function_name, which
> is already called *before* rs6000_output_mi_thunk.
>
> Finally, the patch removes use of the GNU local label extension ("0b")
> in favour of compiler-emitted internal labels.  This seems clearer now
> that the entry point code may be split across two different functions
> (rs6000_output_function_prologue vs. rs6000_elf_declare_function_name)
> and makes it simpler to move the location of the TOC delta quadword
> at some future time.  Also, it removes the implicit assumption that
> the system assembler supports this GNU extension, which I understand
> we don't assume anywhere else.
>
> Tested on powerp64le-linux.  Also tested bootstrap/regtest with an
> extra patch to switch the default code model to CMODEL_LARGE.  Tested
> both with an assembler supporting R_PPC64_ENTRY and with an assembler
> that doesn't support it.
>
> OK for mainline?
>
> Bye,
> Ulrich
>
> ChangeLog:
>
> * configure.ac: Check assembler support for R_PPC64_ENTRY relocation.
> * configure: Regenerate.
> * config.in: Regenerate.
> * config/rs6000/rs6000.c (rs6000_global_entry_point_needed_p): New
> function.
> (rs6000_output_function_prologue): Use it instead of checking
> cfun->machine->r2_setup_needed.  Use internal labels instead of
> GNU as local label extension.  Handle ELFv2 large code model.
> (rs6000_output_mi_thunk): Do not set cfun->machine->r2_setup_needed.
> (rs6000_elf_declare_function_name): Handle ELFv2 large code model.

Okay.

Thanks, David

Re: [PATCH] rs6000: Optimise SImode cstore on 64-bit

[David Edelsohn]

On Tue, Dec 1, 2015 at 8:55 PM, Segher Boessenkool
 wrote:
> On 64-bit we can do comparisons of 32-bit values by extending those
> values to 64-bit, subtracting them, and then getting the high bit of
> the result.  For registers this is always cheaper than using the carry
> bit sequence; and if the comparison involves a constant, this is cheaper
> than the sequence we previously generated in half of the cases (and the
> same cost in the other cases).
>
> After this, the only sequence left that is using the mfcr insn is the
> one doing signed comparison of Pmode registers.
>
> Testing in progress.  Okay for trunk if that succeeds?

Okay.

Thanks, David

Re: [PATCH, rs6000] Fix analyze_swaps to handle vperm for large and small code models

[David Edelsohn]

> Uli Weigand discovered that the gcc.target/powerpc/swaps-p8-21.c test
case fails when large and small code models are used, rather than the
default medium code model.  This is because analyze_swaps is determining
whether the mask used for a vperm insn is loaded from the constant pool,
and there is an extra indirection for such loads when the large or small
code model is used.  This patch changes analyze_swaps to handle the
extra indirection correctly.  A new test case variant is added to check
for it.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Ok for trunk?

Thanks,
Bill


[gcc]

2015-12-01  Bill Schmidt  

* config/rs6000/rs6000.c (const_load_sequence_p): Handle extra
indirection for large and small code models.
(adjust_vperm): Likewise.

[gcc/testsuite]

2015-12-01  Bill Schmidt  

* gcc.target/powerpc/swaps-p8-22.c: New.

Okay.

Thanks, David

Re: PING: [PATCH] PR target/67215: -fno-plt needs improvements for x86

[David Edelsohn]

On Wed, 28 Oct 2015 at 18:14 PM, H.J. Lu wrote:
> On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt  wrote:
>> On 10/29/2015 02:10 AM, H.J. Lu wrote:
>>>
>>> On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law  wrote:


 So I'll ask again, why did you commit a patch which you clearly knew did
 not
 meet the conditions Bernd set forth for approval?
>>>
>>>
>>> I believed that aarch64 backend didn't properly handle -fno-plt,
>>> which shouldn't block my patch.
>>
>>
>> This really isn't how the rules work, and you've been around long enough to
>> know it.
>>
>
> Sometimes It seems that it is the only way to get attention from the
> community.  BTW, my patch was submitted in August.

H.J.:

Because you have committed unapproved patches on several occasions,
contrary to specific requests from GCC reviewers, the GCC Steering
Committee has voted to suspend your committer privileges to the GCC
Repository for two weeks. Future unapproved commits will lead to
longer suspensions.

- The GCC Steering Committee

Re: [PATCH] rs6000_adjust_cost old thinko

[David Edelsohn]

On Mon, Nov 30, 2015 at 4:44 AM, Eric Botcazou  wrote:
>> Note this also is wrong on PA and one of the SPARC adjust_cost macros.
>
> Thanks for the heads up, fixed thusly, applied on the mainline
>
>
> PR target/28115
> * config/sparc/sparc.c (supersparc_adjust_cost): Fix thinko.
> (sparc_adjust_cost): Add missing space.

Eric,

FYI, the function should test recog_memoized (dep_insn) also.

- David

[PATCH] rs6000_adjust_cost old thinko

[David Edelsohn]

When rs6000_adjust_cost originally was written, the return value from
recog_memoized() was handled incorrectly.

Note this also is wrong on PA and one of the SPARC adjust_cost macros.

Bootstrapped on powrepc-ibm-aix7.1.0.0.

PR target/28115
* config/rs6000/rs6000.c (rs6000_adjust_cost): Correct recog_memoized
test for insn and check recog_memoized for dep_insn.

Index: rs6000.c
===
--- rs6000.c(revision 231044)
+++ rs6000.c(working copy)
@@ -28544,8 +28544,8 @@ rs6000_adjust_cost (rtx_insn *insn, rtx link, rtx_
 {
   enum attr_type attr_type;

-  if (! recog_memoized (insn))
-return 0;
+  if (recog_memoized (insn) < 0 || recog_memoized (dep_insn) < 0)
+return cost;

   switch (REG_NOTE_KIND (link))
 {

Re: [PATCH] GCC system.h and Graphite header order

[David Edelsohn]

On Fri, Nov 27, 2015 at 11:24 AM, Thomas Schwinge
 wrote:
> Hi!
>
> On Tue, 24 Nov 2015 10:32:12 +, Alan Lawrence  
> wrote:
>> I note doc/install.texi says that gcc uses "ISL Library version 0.15,
>> 0.14, 0.13, or 0.12.2". This patch breaks the build with 0.12.2 (a
>> subset of errors below)
>
>  has been filed.  I set you guys on CC.
>
>> but seems fine with 0.14. I haven't tested
>> 0.13. Do we want to update install.texi ?
>
> I have a slight preference to keep ISL 0.12.2 supported, but can adapt to
> a newer version, if necessary.

I updated the install document yesterday.

I don't object to support for ISL 0.12.2, but someone has to implement
an appropriate header file incantation for the Graphite source files
WITHOUT reordering it again nor including ISL header files first --
before system.h.  Some GCC header files must be included first in GCC
source files.

Thanks, David

Re: GCC 5.3 Status Report (2015-11-20)

[David Edelsohn]

On Wed, Nov 25, 2015 at 11:57 AM, Paolo Bonzini  wrote:

> Patch committed to upstream libtool, thanks for your understanding.

Great!

How can I have the patch backported to GCC trunk and 5-branch libtool,
and then rebuild configure with the appropriate versions of autoconf?
I have not been able to install the correct versions of autoconf to
produce configure without gratuitous changes.

Thanks, David

[PATCH] AIX declare aliases

[David Edelsohn]

The initial rs6000_declare_alais support fort handle AIX function
descriptors was no complete.  For function descriptors, both the
undecorated symbols (the function descriptor) and the "dot" symbol
(the function entry point address) must be globalized and renamed.

Thanks, David

* config/rs6000/rs6000.c (rs6000_declare_alias): Rename and globalize
both the symbol and the "dot" symbol for function descriptors.  Fix
inversion for rename of symbols with dollar sign.

Index: rs6000.c
===
--- rs6000.c(revision 230866)
+++ rs6000.c(working copy)
@@ -31888,13 +31888,15 @@ rs6000_declare_alias (struct symtab_node *n, void
   if (dollar_inside) {
  if (data->function_descriptor)
 fprintf(data->file, "\t.rename .%s,\".%s\"\n", buffer, name);
- else
-fprintf(data->file, "\t.rename %s,\"%s\"\n", buffer, name);
+ fprintf(data->file, "\t.rename %s,\"%s\"\n", buffer, name);
}
  if (data->function_descriptor)
-   fputs ("\t.globl .", data->file);
- else
-   fputs ("\t.globl ", data->file);
+   {
+ fputs ("\t.globl .", data->file);
+ RS6000_OUTPUT_BASENAME (data->file, buffer);
+ putc ('\n', data->file);
+   }
+ fputs ("\t.globl ", data->file);
  RS6000_OUTPUT_BASENAME (data->file, buffer);
  putc ('\n', data->file);
}
@@ -31908,14 +31910,16 @@ rs6000_declare_alias (struct symtab_node *n, void
   if (dollar_inside)
{
  if (data->function_descriptor)
-fprintf(data->file, "\t.rename %s,\"%s\"\n", buffer, name);
- else
 fprintf(data->file, "\t.rename .%s,\".%s\"\n", buffer, name);
+ fprintf(data->file, "\t.rename %s,\"%s\"\n", buffer, name);
}
   if (data->function_descriptor)
-   fputs ("\t.lglobl .", data->file);
-  else
-   fputs ("\t.lglobl ", data->file);
+   {
+ fputs ("\t.lglobl .", data->file);
+ RS6000_OUTPUT_BASENAME (data->file, buffer);
+ putc ('\n', data->file);
+   }
+  fputs ("\t.lglobl ", data->file);
   RS6000_OUTPUT_BASENAME (data->file, buffer);
   putc ('\n', data->file);
}

Re: [PATCH], Add power9 support to GCC, patch #10 (SFmode/DFmode d-form addressing)

[David Edelsohn]

On Tue, Nov 10, 2015 at 4:56 PM, Michael Meissner
 wrote:
> This patch d-form addressing to float/double scalars for the PowerPC that was
> added in ISA 3.0 (power9).  This patch does not yet turn on D-form addressing
> as default.  It is likely that patch #11, which will add limited d-form
> addressing to vector registers will enable it by default.
>
> I have bootstrapped the compiler with these changes, and there were no
> regressions to the testsuite.
>
> In addition, I built all of the Spec 2006 benchmark with my normal options
> (-ffast-math -O3 -mveclibabi=mass -mcpu=power9 -mpower9-dform -mrecip=rsqrt
> -fpeel-loops -funroll-loops -fvect-cost-model -msave-toc-indirect
> -fno-aggressive-loop-optimizations -mno-pointers-to-nested-functions) and 
> there
> were no compiler failures (and various power9 instructions were generated,
> including d-form addressing).
>
> Are these patches ok to check in?
>
> [gcc]
> 2015-11-10  Michael Meissner  
>
> 
> * config/rs6000/constraints.md (wb constraint): New constraint for
> ISA 3.0 d-form scalar addressing.
>
> * config/rs6000/rs6000.c (mode_supports_vmx_dform): Add support
> for ISA 3.0 D-form addressing to load SFmode/DFmode scalars into
> Altivec registers.  Add wb constraint for Altivec registers with
> D-form addressing.  If we have ISA 3.0 d-form support, undo
> secondary reload support for using FPR registers if we want to do
> D-form addressing.
> (rs6000_debug_reg_global): Likewise.
> (rs6000_setup_reg_addr_masks): Likewise.
> (rs6000_init_hard_regno_mode_ok): Likewise.
> (rs6000_secondary_reload): Likewise.
> (rs6000_preferred_reload_class): Likewise.
> (rs6000_secondary_reload_class): Likewise.
>
> * config/rs6000/rs6000.h (enum r6000_reg_class_enum): Add wb
> constraint.
>
> * config/rs6000/rs6000.md (f32_lr2 mode attribute): Add support
> for ISA 3.0 SFmode/DFmode d-form addressing to Altivec registers.
> (f32_lm2): Likewise.
> (f32_li2): Likewise.
> (f32_sr2): Likewise.
> (f32_sm2): Likewise.
> (f32_si2): Likewise.
> (f64_p9): Likewise.
> (extendsfdf2_fpr): Likewise.
> (mov_hardfloat): Likewise.
> (mov_hardfloat32): Likewise.
> (mov_hardfloat64): Likewise.
>
> * doc/md.texi (RS/6000 constraints): Document wb constraint.
> Fixup we constraint documentation.
>
> [gcc/testsuite]
> 2015-11-10  Michael Meissner  
>
> * gcc.target/powerpc/dform-1.c: New test.
> * gcc.target/powerpc/dform-2.c: Likewise.

This is okay.

I don't know if you want to apply it now or wait until after the
holidays in case there is any fallout.

Thanks, David

Re: [PATCH] lround for PowerPC

[David Edelsohn]

On Tue, Nov 24, 2015 at 1:55 PM, Michael Meissner
<meiss...@linux.vnet.ibm.com> wrote:
> Whoops, I forgot to update the ChangeLog after reversing Fv and Fv2.
>
> 2015-11-24  David Edelsohn  <dje@gmail.com>
> Michael Meissner  <meiss...@linux.vnet.ibm.com>
>
> * config/rs6000/rs6000.md (UNSPEC_XSRDPI): New unspec.
> (Fv2): New mode attribute to be used when ISA 2.07 instructions
> are used on SF values, and ISA 2.06 instructions on DF values.
> (add3_fpr): Use  instead of .
> (sub3_fpr): Use  instead of .
> (mul3_fpr): Use  instead of .
> (div3_fpr): Use  instead of .
> (sqrt2): Use  instead of .
> (fre): Use  instead of .
> (rsqrt2): Use  instead of .

Why are the above instructions converted to Fv2?  xsadd, xssub, xsmul,
xsdiv, xsre, and xsrsqrte are Power7 instructions.

xssqrt and the ones below are Power8.

> (cmp_fpr): Use  instead of .
> (xsrdpi): Add support for the lround function.
> (lrounddi2): Likewise.
> (fma4_fpr): Use  instead of .
> (fms4_fpr): Use  instead of .
> (nfma4_fpr): Use  instead of .
> (nfms4_fpr): Use  instead of .

Thanks, David

Re: [PATCH] rs6000: Fix for and_operand oversight (PR68332, PR67677)

[David Edelsohn]

On Tue, Nov 24, 2015 at 2:13 AM, Segher Boessenkool
 wrote:
> Calling rs6000_is_valid_and_mask on a reg instead of on a const_int is
> not a good idea, as PR68332 and PR67677 as well as testing with
> --enable-checking=yes,rtl show.  Fix this.
>
> Bootstrapped and tested on powerpc64-linux.  Is this okay for trunk?
>
>
> Segher
>
>
> 2015-11-24  Segher Boessenkool  
>
> PR target/66217
> PR target/67677
> PR target/68332
> * config/rs6000/predicates.md (and_operand): Check that the operand
> is a const_int before calling rs6000_is_valid_and_mask.

Okay.

Thanks, David

Re: GCC 5.3 Status Report (2015-11-20)

[David Edelsohn]

On Sun, Nov 22, 2015 at 8:38 AM, Paolo Bonzini <bonz...@gnu.org> wrote:
>
>
> On 20/11/2015 14:14, David Edelsohn wrote:
>> On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener <rguent...@suse.de> wrote:
>>>
>>> Status
>>> ==
>>>
>>> We plan to do a GCC 5.3 release candidate at the end of next week
>>> followed by the actual release a week after that.
>>>
>>> So now is the time to look at your regression bugs in bugzilla and
>>> do some backporting for things already fixed on trunk.
>>
>> I'm still waiting for approval of the libtool change to support AIX
>> TLS symbols (PR 68192).  There has been no response on Libtool patches
>> mailing list.
>>
>> I again request permission to apply the patches to GCC trunk and 5-branch.
>
> Let me look around for a libtool committer tomorrow, I'll get back to you.

Any progress?

Thanks, David

Re: [PATCH] lround for PowerPC

[David Edelsohn]

On Mon, Nov 23, 2015 at 4:56 PM, Michael Meissner
<meiss...@linux.vnet.ibm.com> wrote:
> David ping'ed me on internal IRC, and I had a thinko in terms of the use of 
> the
>  mode attribute.  In some of the uses (such as abs, smax, etc.) we want to
> use ISA 2.06 instructions on SFmode, while in other uses (add, mul, etc.) we
> want to use it only if we have the ISA 2.07 instrucitons.
>
> I have split these mode attributes into Fv and Fv2 and gone through all of the
> uses in the compiler to use the appropriate attribute.  I have built a cross
> compiler on x86, but it blew up on a big endian power7 with a segmentation
> violation that I need to look into.  I'm also building on a little endian
> power8 right now, and it has gotten further.
>
> 2015-11-23  David Edelsohn  <dje@gmail.com>
> Michael Meissner  <meiss...@linux.vnet.ibm.com>
>
> * config/rs6000/rs6000.md (UNSPEC_XSRDPI): New unspec.
> (Fv2): New mode attribute to be used when ISA 2.06 instructions
> are used on SF/DF values.
> (abs2_fpr): Use  instead of .
> (nabs2_fpr): Likewise.
> (neg2_fpr): Likewise.
> (copysign3_fcpsgn): Likewise.
> (smax3_vsx): Likewise.
> (smin3_vsx): Likewise.
> (floatsi2_lfiwax): Likewise.
> (floatunssi2_lfiwz): Likewise.
> (fctiwz_): Likewise.
> (fctiwuz_): Likewise.
> (btrunc2): Likewise.
> (ceil2): Likewise.
> (floor2): Likewise.
> (xsrdpi): Add support for the lround function.
> (lround2): Likewise.

I would prefer that you reverse the meaning of "Fv" and "Fv2".  "Fv"
corresponds to VSX2 and "Fv2" corresponds to VSX, which is confusing
for anyone trying to make sense of this in the future.

Also, the lrounddi2 pattern should use "Fv" not "wa" from my
original patch.  And the ChangeLog entry should list lrounddi2.

Okay with those changes, after the cause of the SEGV is diagnosed and fixed.

Thanks, David

Re: [PATCH] lround for PowerPC

[David Edelsohn]

On Sun, Nov 22, 2015 at 2:34 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On November 22, 2015 2:52:53 AM GMT+01:00, David Edelsohn <dje@gmail.com> 
> wrote:
>>PowerPC was missing a definition of the lroundMN pattern, which can be
>>implemented with  VSX instructions available in Power7.  Below is a
>>first draft.

> Why unsafe-math?

It's a first draft.  I want to re-confirm that the combined
instructions set all of the correct flags.

The patterns should work in SF and DF modes, but currently trigger a
reload failure in SFmode.

Thanks, David

Re: [PATCH] lround for PowerPC

[David Edelsohn]

v2 of the patch.  Seems to pass the GCC testsuite, although the
testsuite doesn't stress FP.

There is something wrong with current VSX SFmode constraints.

Index: rs6000.md
===
--- rs6000.md (revision 230723)
+++ rs6000.md (working copy)
@@ -77,6 +77,7 @@
UNSPEC_FRIN
UNSPEC_FRIP
UNSPEC_FRIZ
+   UNSPEC_XSRDPI
UNSPEC_LD_MPIC ; load_macho_picbase
UNSPEC_RELD_MPIC ; re-load_macho_picbase
UNSPEC_MPIC_CORRECT ; macho_correct_pic
@@ -5500,6 +5501,27 @@
   [(set_attr "type" "fp")
(set_attr "fp_type" "fp_addsub_")])

+(define_insn "*xsrdpi2"
+  [(set (match_operand:SFDF 0 "gpc_reg_operand" "=wa")
+   (unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" "wa")]
+UNSPEC_XSRDPI))]
+  "TARGET__FPR && TARGET_POPCNTD"
+  "xsrdpi %x0,%x1"
+  [(set_attr "type" "fp")
+   (set_attr "fp_type" "fp_addsub_")])
+
+(define_expand "lrounddi2"
+  [(set (match_dup 2)
+   (unspec:SFDF [(match_operand:SFDF 1 "gpc_reg_operand" "wa")]
+UNSPEC_XSRDPI))
+   (set (match_operand:DI 0 "gpc_reg_operand" "=d")
+   (unspec:DI [(match_dup 2)]
+  UNSPEC_FCTID))]
+  "TARGET__FPR && TARGET_POPCNTD"
+{
+  operands[2] = gen_reg_rtx (mode);
+})
+
 ; An UNSPEC is used so we don't have to support SImode in FP registers.
 (define_insn "stfiwx"
   [(set (match_operand:SI 0 "memory_operand" "=Z")

Re: [PATCH, rs6000, gcc 5 backport] Fix PR target/67808, LRA ICE on double to long double conversion

[David Edelsohn]

On Fri, Nov 20, 2015 at 6:47 PM, Michael Meissner
 wrote:
> On Fri, Oct 02, 2015 at 02:04:48PM -0500, Peter Bergner wrote:
>> PR67808 exposes a problem with the constraints in the *extenddftf2_internal
>> pattern, in that it allows TFmode operands to occupy Altivec registers
>> which they are not allowed to do.  Reload was able to work around the
>> problem, but LRA is more pedantic and it caused it to go into an infinite
>> spill loop until it ICEd.  The following patch from Mike changes the TFmode
>> output operand to use the "d" constraint instead of "ws".  It also allows
>> using the "ws" constraint for the two input operands, since that is allowed
>> for DFmode operands.
>>
>> This passed bootstraps (with reload on by default and lra on by default)
>> and shows no testsuite regressions.  Is this ok for trunk?
>>
>> The bug is also present in the FSF 5 branch (4.9 is ok), is this ok for
>> that too, assuming my bootstrap/regtesting there are clean?
>
> The following patch backports the fix to GCC 5.x.  There were no regressions 
> in
> doing the bootstrap/make check on both a big endian power7 system and a little
> endian power8 system.  Is it ok to apply the patch to the gcc-5 branch?
>
> 2015-10-20  Michael Meissner  
>
> Back port from trunk:
> 2015-10-05  Michael Meissner  
> Peter Bergner  
>
> PR target/67808
> * config/rs6000/rs6000.md (extenddftf2): In the expander, only
> allow registers, but provide insns for the combiner to create for
> loads from memory. Separate VSX code from non-VSX code. For
> non-VSX code, combine extenddftf2_fprs into extenddftf2 and rename
> externaldftf2_internal to externaldftf2_fprs. Reorder constraints
> so that registers come before memory operations. Drop support from
> converting DFmode to TFmode, if the DFmode value is in a GPR
> register.
> (extenddftf2_fprs): Likewise.
> (extenddftf2_internal): Likewise.
> (extenddftf2_vsx): Likewise.
> (extendsftf2): In the expander, only allow registers, but provide
> insns for the combiner to create for stores and loads.

Okay.

Thanks, David

Re: [PATCH] Fix uninitialized src_range within c_expr (Re: libcpp/C FE source range patch committed (r230331))

[David Edelsohn]

On Tue, Nov 17, 2015 at 3:12 PM, David Malcolm  wrote:
> On Tue, 2015-11-17 at 16:24 +0100, Bernd Schmidt wrote:
>> On 11/17/2015 04:13 PM, David Malcolm wrote:
>> > On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote:
>> >>
>> >> Should c_expr perhaps acquire a constructor so that this problem is
>> >> avoided in the future? The whole thing seems somewhat error-prone.
>> >
>> > I agree that it's error prone, and the ctor approach is what I've been
>> > trying for the C++ FE [1] but I suspect that touching that in the C FE
>> > would be a much more invasive patch (unless we simply give it a default
>> > ctor that makes the src_range be a pair of UNKNOWN_LOCATIONS?).
>>
>> The UNKNOWN_LOCATIONS pair would have been my approach, yes.
>>
>> > This case gains a pair of locals: start_loc and end_loc (so that we can
>> > track the spelling range whilst retaining the "loc" used for the caret),
>> > and I preferred to confine their scope to within the case, hence the
>> > extra braced block.  Omitting the braced block leads to:
>> > ../../src/gcc/c/c-parser.c:7494:7: error: jump to case label [-fpermissive]
>> >case RID_OFFSETOF:
>> > ^
>> > ../../src/gcc/c/c-parser.c:7472:17: error:   crosses initialization of 
>> > ‘location_t end_loc’
>> >location_t end_loc = c_parser_peek_token (parser)->get_finish ();
>> >   ^
>> > etc.
>>
>> Hmm, odd, I tried placing just the location_t start_loc line into the
>> switch and that appeared to compile fine. But I guess this is not a huge
>> problem.
>> >
>> > Is the combination of the 3 patches OK for trunk? (assuming
>> > bootstrap it's only the braced-init tweak that hasn't been).
>>
>> Yes.
>
> Thanks.  I've committed the 3 patches to trunk as r230497, which should
> fix the worst of the regressions caused by r230331 seen on AIX.  I'll
> continue to investigate as per the discussion above.

Hi, David

The new stret-1.m Objective C failure on AIX shows the same symptoms.
Is there another fix needed for Objective C?

#1  0x10016794 in _Z14linemap_lookupP9line_mapsj (set=0x7000, line=991)
at /nasfarm/edelsohn/src/src/libcpp/line-map.c:991
991   linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));


Thanks, David

[PATCH] lround for PowerPC

[David Edelsohn]

PowerPC was missing a definition of the lroundMN pattern, which can be
implemented with  VSX instructions available in Power7.  Below is a
first draft.

- David

* config/rs6000/rs6000.md (*xsrdpidf2): New define_insn.
(lrounddfdi2): New define_expand.

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 8c53c40..eadbe1d 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -77,6 +77,7 @@
UNSPEC_FRIN
UNSPEC_FRIP
UNSPEC_FRIZ
+   UNSPEC_XSRDPI
UNSPEC_LD_MPIC  ; load_macho_picbase
UNSPEC_RELD_MPIC; re-load_macho_picbase
UNSPEC_MPIC_CORRECT ; macho_correct_pic
@@ -5245,6 +5246,27 @@
   [(set_attr "type" "fp")
(set_attr "fp_type" "fp_addsub_")])

+(define_insn "*xsrdpidf2"
+  [(set (match_operand:DF 0 "gpc_reg_operand" "=")
+   (unspec:DF [(match_operand:DF 1 "gpc_reg_operand" "")]
+  UNSPEC_XSRDPI))]
+  "TARGET_DF_FPR && TARGET_POPCNTD"
+  "xsrdpi %0,%1"
+  [(set_attr "type" "fp")])
+
+(define_expand "lrounddfdi2"
+  [(set (match_dup 2)
+   (unspec:DF [(match_operand:DF 1 "gpc_reg_operand" "")]
+  UNSPEC_XSRDPI))
+   (set (match_operand:DI 0 "gpc_reg_operand" "=d")
+   (unspec:DI [(match_dup 2)]
+  UNSPEC_FCTID))]
+  "TARGET_DF_FPR && TARGET_POPCNTD
+   && flag_unsafe_math_optimizations && !flag_trapping_math"
+{
+  operands[2] = gen_reg_rtx (DFmode);
+})
+
 ; An UNSPEC is used so we don't have to support SImode in FP registers.
 (define_insn "stfiwx"
   [(set (match_operand:SI 0 "memory_operand" "=Z")

Re: [PATCH] Fix uninitialized src_range within c_expr (Re: libcpp/C FE source range patch committed (r230331))

[David Edelsohn]

On Sat, Nov 21, 2015 at 3:00 PM, David Malcolm <dmalc...@redhat.com> wrote:
> On Sat, 2015-11-21 at 13:54 -0500, David Edelsohn wrote:
>> On Tue, Nov 17, 2015 at 3:12 PM, David Malcolm <dmalc...@redhat.com> wrote:
>> > On Tue, 2015-11-17 at 16:24 +0100, Bernd Schmidt wrote:
>> >> On 11/17/2015 04:13 PM, David Malcolm wrote:
>> >> > On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote:
>> >> >>
>> >> >> Should c_expr perhaps acquire a constructor so that this problem is
>> >> >> avoided in the future? The whole thing seems somewhat error-prone.
>> >> >
>> >> > I agree that it's error prone, and the ctor approach is what I've been
>> >> > trying for the C++ FE [1] but I suspect that touching that in the C FE
>> >> > would be a much more invasive patch (unless we simply give it a default
>> >> > ctor that makes the src_range be a pair of UNKNOWN_LOCATIONS?).
>> >>
>> >> The UNKNOWN_LOCATIONS pair would have been my approach, yes.
>> >>
>> >> > This case gains a pair of locals: start_loc and end_loc (so that we can
>> >> > track the spelling range whilst retaining the "loc" used for the caret),
>> >> > and I preferred to confine their scope to within the case, hence the
>> >> > extra braced block.  Omitting the braced block leads to:
>> >> > ../../src/gcc/c/c-parser.c:7494:7: error: jump to case label 
>> >> > [-fpermissive]
>> >> >case RID_OFFSETOF:
>> >> > ^
>> >> > ../../src/gcc/c/c-parser.c:7472:17: error:   crosses initialization of 
>> >> > ‘location_t end_loc’
>> >> >location_t end_loc = c_parser_peek_token (parser)->get_finish ();
>> >> >   ^
>> >> > etc.
>> >>
>> >> Hmm, odd, I tried placing just the location_t start_loc line into the
>> >> switch and that appeared to compile fine. But I guess this is not a huge
>> >> problem.
>> >> >
>> >> > Is the combination of the 3 patches OK for trunk? (assuming
>> >> > bootstrap it's only the braced-init tweak that hasn't been).
>> >>
>> >> Yes.
>> >
>> > Thanks.  I've committed the 3 patches to trunk as r230497, which should
>> > fix the worst of the regressions caused by r230331 seen on AIX.  I'll
>> > continue to investigate as per the discussion above.
>>
>> Hi, David
>>
>> The new stret-1.m Objective C failure on AIX shows the same symptoms.
>> Is there another fix needed for Objective C?
>>
>> #1  0x10016794 in _Z14linemap_lookupP9line_mapsj (set=0x7000, line=991)
>> at /nasfarm/edelsohn/src/src/libcpp/line-map.c:991
>> 991   linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
>
> I believe this one is fixed by the patch I posted here:
>  "[PATCH] Fix PR objc/68438 (uninitialized source ranges)"
>https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02536.html
>
> (it runs cleanly under valgrind on x86_64 with that patch applied)

Yep, thanks.  I missed the follow-on patch.

Thanks, David

[PATCH] GCC system.h and Graphite header order

[David Edelsohn]

Graphite relies on the ISL library and includes multiple ISL headers.
The ISL headers refer to identifiers that are poisoned for use in GCC.
The source files for Graphite were organized to include the ISL
headers first, to avoid the identifier poisoning, which breaks some
platforms because GCC header features are disabled.

This patch reorganizes the graphite*.c header file inclusion order to
list ISL header files near the end, just before the graphite header
files on which they rely.  A new macro, USES_ISL, is defined, which
skips the relevant identifier poisoning, similar to logic for Flex and
Bison.

This patch also removes early inclusion of stddef.h for ISL because it
now should be provided by GCC system.h

This has been bootstrapped on powerpc-ibm-aix7.1.0.0

Okay for trunk?

Thanks, David

* system.h: Don't poison calloc and strdup if USES_ISL is defined.
* graphite-dependences.c: Define USES_ISL.  Include ISL header files
after GCC header files and before graphite header files.
* graphite-dependences.c: Same.
* graphite-isl-ast-to-gimple.c: Same.
* graphite-optimize-isl.c: Same.
* graphite-poly.c: Same.
* graphite-scop-detection.c: Same.
* graphite-sese-to-poly.c: Same.
* graphite.c: Same.


GG
Description: Binary data

Re: GCC 5.3 Status Report (2015-11-20)

[David Edelsohn]

On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener  wrote:
>
> Status
> ==
>
> We plan to do a GCC 5.3 release candidate at the end of next week
> followed by the actual release a week after that.
>
> So now is the time to look at your regression bugs in bugzilla and
> do some backporting for things already fixed on trunk.

I'm still waiting for approval of the libtool change to support AIX
TLS symbols (PR 68192).  There has been no response on Libtool patches
mailing list.

I again request permission to apply the patches to GCC trunk and 5-branch.

Thanks, David

[PATCH] 23_containers/vector/profile/vector.cc

[David Edelsohn]

The testcase allocates so much memory that it requires an additional
option to enabled higher memory limit on AIX.

Bootstrapped on powerpc-ibm-aix7.1.0.0

Thanks, David

* testsuite/23_containers/vector/profile/vector.cc: Add maxdata option on AIX.

Index: 23_containers/vector/profile/vector.cc
===
--- 23_containers/vector/profile/vector.cc  (revision 230674)
+++ 23_containers/vector/profile/vector.cc  (working copy)
@@ -2,6 +2,8 @@
 // Advice: set tmp as 1

 // { dg-options "-DITERATIONS=20" { target simulator } }
+// AIX requires higher memory limit
+// { dg-additional-options "-Wl,-bmaxdata:0x2000" { target {
powerpc-ibm-aix* } } }

 #ifndef ITERATIONS
 #define ITERATIONS 2000

Re: [PATCH 1/2] [graphite] Move codegen related functions to graphite-isl-ast-to-gimple.c

[David Edelsohn]

The patch fixed the bootstrap failure.

Thanks, David

On Thu, Nov 19, 2015 at 3:37 PM, Sebastian Pop  wrote:
> Fixed in r230625.
>
> David, please test on your systems, we were not able to reproduce the fails on
> x86_64-linux: the linker does optimize away the functions that are not used.
>
> Thanks,
> Sebastian
>
> Aditya K wrote:
>> Thanks for the update. I'll fix that asap.
>>
>>
>> -Aditya
>>
>>
>> 
>> > Date: Thu, 19 Nov 2015 08:36:58 -0500
>> > Subject: Re: [PATCH 1/2] [graphite] Move codegen related functions to 
>> > graphite-isl-ast-to-gimple.c
>> > From: dje@gmail.com
>> > To: hiradi...@msn.com; aditya...@samsung.com; s@samsung.com
>> > CC: gcc-patches@gcc.gnu.org
>> >
>> > This patch broke bootstrap when ISL is not enabled.
>> >
>> > graphite-isl-ast-to-gimple.c is protected by HAVE_isl but
>> > get_false_edge_from_guard_bb() is used outside of Graphite, including
>> > sese.c, which is not restricted to HAVE_isl.
>> >
>> > Please fix.
>> >
>> > Thanks, David
>>

Re: [PATCH 1/2] [graphite] Move codegen related functions to graphite-isl-ast-to-gimple.c

[David Edelsohn]

This patch broke bootstrap when ISL is not enabled.

graphite-isl-ast-to-gimple.c is protected by HAVE_isl but
get_false_edge_from_guard_bb() is used outside of Graphite, including
sese.c, which is not restricted to HAVE_isl.

Please fix.

Thanks, David

Re: POWERPC64_TOC_POINTER_ALIGNMENT

[David Edelsohn]

On Tue, Nov 17, 2015 at 9:32 PM, Alan Modra  wrote:
> On Tue, Nov 17, 2015 at 07:53:18PM -0500, Michael Meissner wrote:
>> Here is the temporary patch I'm using to get past rs6000.c.  But I suspect 
>> the
>> TOC alignment should never be 256.
>
> Yes, it should be.  Recent GNU ld aligns .TOC. to a 256 byte boundary.
> I have this patch in my tree.
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index abc8eaa..e3ec042 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -8059,12 +8059,17 @@ rs6000_cannot_force_const_mem (machine_mode mode 
> ATTRIBUTE_UNUSED, rtx x)
>  static bool
>  use_toc_relative_ref (rtx sym, machine_mode mode)
>  {
> +  /* Silence complaint that the POWERPC64_TOC_POINTER_ALIGNMENT test
> + is always true.  */
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wtype-limits"
>return ((constant_pool_expr_p (sym)
>&& ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (sym),
>get_pool_mode (sym)))
>   || (TARGET_CMODEL == CMODEL_MEDIUM
>   && SYMBOL_REF_LOCAL_P (sym)
>   && GET_MODE_SIZE (mode) <= POWERPC64_TOC_POINTER_ALIGNMENT));
> +#pragma GCC diagnostic pop
>  }
>
>  /* Our implementation of LEGITIMIZE_RELOAD_ADDRESS.  Returns a value to

I have applied Alan's work-around for now until there is a more robust solution.

Thanks, David

PPC bootstrap failure builtin clz

[David Edelsohn]

Richard,

One of the patches in your recent series caused bootstrap failure on PPC:

In file included from /nasfarm/edelsohn/src/src/libgcc/libgcov-driver.c:49:0:
/nasfarm/edelsohn/src/src/libgcc/../gcc/gcov-io.c: In function 'gcov_do_dump':
/nasfarm/edelsohn/src/src/libgcc/../gcc/gcov-io.c:731:51: internal
compiler error: in convert_move, at expr.c:286
   r = sizeof (long long) * __CHAR_BIT__ - 1 - __builtin_clzll (v);


 ^~~~


David

Re: PATCH to shorten_compare -Wtype-limits handling

[David Edelsohn]

On Wed, Nov 18, 2015 at 11:26 PM, Jason Merrill  wrote:
> The rs6000 target was hitting a bootstrap failure due to
> -Werror=type-limits.  Since warn_tautological_cmp and other warnings avoid
> warning if one of the operands comes from a macro, I thought it would make
> sense to do that here as well.
>
> Tested that this allows rs6000 bootstrap to proceed, regression tested on
> x86_64-pc-linux-gnu, applying to trunk.  David, do you want to revert the
> #pragma GCC diagnostic change?

Thanks for the patch.

Yes, I will revert the #pragma GCC diagnostic patch.  It was meant as
a temporary hack to fix bootstrap while a long-term solution was
developed.

Thanks, David

Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

[David Edelsohn]

Kirill,

* c-c++-common/attr-simd.c
and
* c-c++-common/attr-simd-3.c

fail on 32 bit systems, e.g., see powerpc64-linux tested in 32 bit mode.

- David

[PATCH] g++.dg/cpp1y/pr58708.C wchar_t size

[David Edelsohn]

The testcase in the GCC testsuite assumes that wchar_t is 32 bits,
which is not correct on AIX.  32 bit AIX maintains 16 bit wchar_t for
backward compatibility (64 bit AIX uses 32 bit wchar_t).

What is the preferred method to make the testcase safe for smaller wchar_t?

The following patch works for me.  I wasn't sure what header file and
what macro test would be considered portable.  I could include
stdint.h and compare

WCHAR_MAX == UINT16_MAX

or

WCHAR_MAX < UINT32_MAX

Thanks, David

Index: pr58708.C
===
--- pr58708.C   (revision 230463)
+++ pr58708.C   (working copy)
@@ -1,5 +1,7 @@
 // { dg-do run { target c++14 } }

+#include 
+
 template
   struct is_same
   {
@@ -43,7 +45,11 @@
   if (foo.chars[1] != 98) __builtin_abort();
   if (foo.chars[2] != 99) __builtin_abort();

-  auto wfoo = L"\x01020304\x05060708"_foo;
+#if WCHAR_MAX == 65535
+auto wfoo = L"\x0102\x0304"_foo;
+#else
+auto wfoo = L"\x01020304\x05060708"_foo;
+#endif
   if (is_same::value != true)
__builtin_abort();
   if (sizeof(wfoo.chars)/sizeof(wchar_t) != 2) __builtin_abort();
   if (wfoo.chars[0] != 16909060) __builtin_abort();

Re: C++ PATCH to integrate c++-delayed-folding branch

[David Edelsohn]

On Mon, Nov 16, 2015 at 10:47 PM, Jason Merrill <ja...@redhat.com> wrote:
> On 11/16/2015 09:39 PM, David Edelsohn wrote:
>>
>> The PPC port seems to be bootstrapping again, but I'm not sure why.
>> Mike Meissner's patch only should have affected long double.
>
>
>> It's hard to know if there is a latent bug that has gone back into hiding.
>
>
> The problem was twofold:
>
> 1) VSX_L included IFmode, but VSa didn't, so expanding various patterns over
> VSX_L generated an IFmode insn that still had  scattered around.
> Mike's patch fixed this.
>
> 2) The delayed folding merge changed
>
>   __builtin_constant_p (non-constant-expr && false)
>
> to be false because the operand is not a C++ constant expression. Previously
> we had seen that the IFmode insn was inactive because its test was known to
> be false, but with this change we needed to evaluate its test at runtime, so
> we had to parse the insn itself, so we ran into problem #1.
>
> I have a patch to fix the __builtin_constant_p regression which I will be
> checking in shortly.

Thanks for debugging and fixing this!

- David

Re: [PATCH] g++.dg/cpp1y/pr58708.C wchar_t size

[David Edelsohn]

On Tue, Nov 17, 2015 at 11:22 AM, Jonathan Wakely <jwakely@gmail.com> wrote:
> On 17 November 2015 at 16:04, David Edelsohn wrote:
>> The testcase in the GCC testsuite assumes that wchar_t is 32 bits,
>> which is not correct on AIX.  32 bit AIX maintains 16 bit wchar_t for
>> backward compatibility (64 bit AIX uses 32 bit wchar_t).
>>
>> What is the preferred method to make the testcase safe for smaller wchar_t?
>>
>> The following patch works for me.  I wasn't sure what header file and
>> what macro test would be considered portable.  I could include
>> stdint.h and compare
>>
>> WCHAR_MAX == UINT16_MAX
>>
>> or
>>
>> WCHAR_MAX < UINT32_MAX
>
> __SIZEOF_WCHAR_T__ is always pre-defined  by the compiler, so that
> could be used.

Thanks for the pointer.  How about the following?

Thanks, David


Index: pr58708.C
===
--- pr58708.C   (revision 230463)
+++ pr58708.C   (working copy)
@@ -43,7 +43,11 @@
   if (foo.chars[1] != 98) __builtin_abort();
   if (foo.chars[2] != 99) __builtin_abort();

-  auto wfoo = L"\x01020304\x05060708"_foo;
+#if __SIZEOF_WCHAR_T__ == 2
+auto wfoo = L"\x0102\x0304"_foo;
+#else
+auto wfoo = L"\x01020304\x05060708"_foo;
+#endif
   if (is_same<decltype(wfoo)::char_type, wchar_t>::value != true)
__builtin_abort();
   if (sizeof(wfoo.chars)/sizeof(wchar_t) != 2) __builtin_abort();
   if (wfoo.chars[0] != 16909060) __builtin_abort();

Re: [PATCH] g++.dg/init/vbase1.C and g++.dg/cpp/ucn-1.C

[David Edelsohn]

On Mon, Nov 16, 2015 at 4:15 AM, Eric Botcazou  wrote:
>> No RISC architecture can store directly to MEM, so the expected RTL in
>> g++.dg/init/vbase1.C is wrong.  I am adding XFAIL for PowerPC.  This
>> probably should be disabled for ARM and other RISC architectures.
>
> Some of them can store 0 directly to MEM though, for example SPARC.

As Mike said, this testcase isn't portable and needs to be limited to
the targets that support the particular idiom used in this testcase.

Thanks, David

Re: C++ PATCH to integrate c++-delayed-folding branch

[David Edelsohn]

The PPC port seems to be bootstrapping again, but I'm not sure why.
Mike Meissner's patch only should have affected long double.

It's hard to know if there is a latent bug that has gone back into hiding.

- David


On Sat, Nov 14, 2015 at 1:47 AM, Jason Merrill <ja...@redhat.com> wrote:
> On 11/13/2015 11:46 PM, David Edelsohn wrote:
>>
>> This seems to have broken bootstrap on PowerPC.  I originally saw it
>> on AIX, but duplicated it on PPC64LE Linux.
>
>
> Was this a clean build?  The gtfiles change doesn't propagate to the
> Makefile unless config.status is regenerated.
>
> Jason
>

Re: [PATCH] PR 68192 Export AIX TLS symbols

[David Edelsohn]

On Thu, Nov 5, 2015 at 10:53 PM, Alexandre Oliva <aol...@redhat.com> wrote:
> On Nov  5, 2015, Paolo Bonzini <bonz...@gnu.org> wrote:
>
>> On 05/11/2015 17:28, David Edelsohn wrote:
>>> [Explicitly copying build maintainers.]
>>>
>>> Paolo and Alexandre,
>>>
>>> Could you review and help with this patch?
>>>
>>> TLS symbols in AIX display a new, different symbol type in nm output.
>>> Libtool explicitly creates a list of exported symbols for shared
>>> libraries using nm and does not recognize the new TLS symbols, so
>>> those symbols are not exported.
>>>
>>> This is a regression for TLS support on AIX.
>>>
>>> This patch updates libtool.m4 in GCC and configure for libstdc++-v3,
>>> libgfortran, and libgomp.  I would like to apply the patch to GCC
>>> while I simultaneously work with the Libtool community to correct the
>>> bug upstream.  I also would like to backport this to GCC 5.2 and GCC
>>> 4.9.x.
>
>> I think it's okay to wait for the patch to be upstream.
>
> *nod*.  The reason we want it upstream first is that we don't want a
> regression when someone updates the libtool version in GCC, now or in
> the future.
>
> It's such a simple patch that it should be really easy to get it into
> libtool upstream.

Ten days and still waiting for a response on libtool-patches.

- David

Re: [PATCH] g++.dg/init/vbase1.C and g++.dg/cpp/ucn-1.C

[David Edelsohn]

On Sat, Nov 14, 2015 at 8:30 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Sat, Nov 14, 2015 at 08:09:44AM -0500, David Edelsohn wrote:
>> On Sat, Nov 14, 2015 at 5:16 AM, Andreas Schwab <sch...@linux-m68k.org> 
>> wrote:
>> > David Edelsohn <dje@gmail.com> writes:
>> >
>> >> +  int c\u0024c;// { dg-error "not valid in an identifier" {
>> >> target { powerpc-ibm-aix* } } }
>> >
>> > FAIL: g++.dg/cpp/ucn-1.C  -std=gnu++11  target { powerpc-ibm-aix* }  (test 
>> > for errors, line 12)
>>
>> Argh.  So why isn't it limited to the specified target as the
>> documentation implies?
>
> Because there needs to be "" or some other string in between the regexp
> and { target ... }.

Fixed.  Sorry.

Thanks, David

Re: [PATCH] g++.dg/init/vbase1.C and g++.dg/cpp/ucn-1.C

[David Edelsohn]

On Sat, Nov 14, 2015 at 8:41 AM, Andreas Schwab <sch...@linux-m68k.org> wrote:
> David Edelsohn <dje@gmail.com> writes:
>
>> On Sat, Nov 14, 2015 at 5:16 AM, Andreas Schwab <sch...@linux-m68k.org> 
>> wrote:
>>> David Edelsohn <dje@gmail.com> writes:
>>>
>>>> +  int c\u0024c;// { dg-error "not valid in an identifier" {
>>>> target { powerpc-ibm-aix* } } }
>>>
>>> FAIL: g++.dg/cpp/ucn-1.C  -std=gnu++11  target { powerpc-ibm-aix* }  (test 
>>> for errors, line 12)
>>
>> Argh.  So why isn't it limited to the specified target as the
>> documentation implies?
>
> Where does it imply that?
>
> # dg-error regexp comment [{ target/xfail selector } [{.|0|linenum}]]

That's not right either.

I incorrectly read it as

dg-error regexp [comment] [{ target/xfail selector} [line] }]

- David

[PATCH] testsuite/experimental/random/randint.cc

[David Edelsohn]

Testcases that use TLS need additional options on some targets
(normall -pthread).  This fixes the testcase on AIX and Solaris.

Committed as obvious.

* testsuite/experimental/random/randint.cc: Add dg-add-options tls.

Index: testsuite/experimental/random/randint.cc
===
--- testsuite/experimental/random/randint.cc(revision 230347)
+++ testsuite/experimental/random/randint.cc(working copy)
@@ -1,5 +1,6 @@
 // { dg-options "-std=gnu++14" }
 // { dg-require-effective-target tls_runtime }
+// { dg-add-options tls }

 // Copyright (C) 2015 Free Software Foundation, Inc.
 //

Thanks, David

Re: [PATCH] g++.dg/init/vbase1.C and g++.dg/cpp/ucn-1.C

[David Edelsohn]

On Sat, Nov 14, 2015 at 5:16 AM, Andreas Schwab <sch...@linux-m68k.org> wrote:
> David Edelsohn <dje@gmail.com> writes:
>
>> +  int c\u0024c;// { dg-error "not valid in an identifier" {
>> target { powerpc-ibm-aix* } } }
>
> FAIL: g++.dg/cpp/ucn-1.C  -std=gnu++11  target { powerpc-ibm-aix* }  (test 
> for errors, line 12)

Argh.  So why isn't it limited to the specified target as the
documentation implies?

Thanks, David

Re: [patch] GSoC: Implement std::experimental::shared_ptr

[David Edelsohn]

The copy_ctor_neg testcase fails on AIX.

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:
In function 'void test02()':
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:50:44:
error: no matching function for call to 'st
d::experimental::fundamentals_v2::shared_ptr::shared_ptr(std::experimental::fundamentals_v2::shared_ptr&)'
In file included from
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/memory:46:0,
 from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:23:
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:772:7:
note: candidate: std::experimental::fundamentals_v2::sha
red_ptr<_Tp>::shared_ptr(const
std::experimental::fundamentals_v2::weak_ptr<_Tp>&, std::nothrow_t)
[with _Tp = A [2]]
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:772:7:
note:   candidate expects 2 arguments, 1 provided
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:763:7:
note: candidate: template
 
std::experimental::fundamentals_v2::shared_ptr<_Tp>::shared_ptr(std::_Sp_make_shared_tag,
const _Alloc&, _Args&& ...)
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:763:7:
note:   template argument deduction/substitution failed:
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:50:44:
note:   candidate expects at least 2 argume
nts, 1 provided
In file included from
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/memory:46:0,
 from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:23:
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:706:17:
note: candidate: constexpr std::experimental::fundament
als_v2::shared_ptr<_Tp>::shared_ptr(std::nullptr_t) [with _Tp = A [2];
std::nullptr_t = std::nullptr_t]
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:706:17:
note:   no known conversion for argument 1 from 'std::e
xperimental::fundamentals_v2::shared_ptr' to 'std::nullptr_t'
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:703:2:
note: candidate: template
 
std::experimental::fundamentals_v2::shared_ptr<_Tp>::shared_ptr(std::unique_ptr<_Up,
_Ep>&&)
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:703:2:
note:   template argument deduction/substitution failed:
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:50:44:
note:   'std::experimental::fundamentals_v2
::shared_ptr' is not derived from 'std::unique_ptr<_Tp, _Dp>'
In file included from
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/memory:46:0,
 from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:23:
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:696:2:
note: candidate: template std::experimental:
:fundamentals_v2::shared_ptr<_Tp>::shared_ptr(std::auto_ptr<_Up>&&)
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:696:2:
note:   template argument deduction/substitution failed:
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:50:44:
note:   'std::experimental::fundamentals_v2
::shared_ptr' is not derived from 'std::auto_ptr<_Up>'
In file included from
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/memory:46:0,
 from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:23:
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:691:11:
note: candidate: template std::experimental
::fundamentals_v2::shared_ptr<_Tp>::shared_ptr(const
std::experimental::fundamentals_v2::weak_ptr<_Tp1>&)
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:691:11:
note:   template argument deduction/substitution failed
:
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:50:44:
note:   'std::experimental::fundamentals_v2
::shared_ptr' is not derived from 'const
std::experimental::fundamentals_v2::weak_ptr<_Tp>'
In file included from
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/memory:46:0,
 from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/copy_ctor_neg.cc:23:
/tmp/20151113/powerpc-ibm-aix7.1.0.0/libstdc++-v3/include/experimental/bits/shared_ptr.h:687:2:
note: candidate: template std::experi

Re: libcpp/C FE source range patch committed (r230331).

[David Edelsohn]

This patch causes numerous new testsuite failure on AIX caused by the
compiler crashing during compilation, e.g.

gcc.c-torture/execute/20020206-1.c

in GCC libcpp

991   linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));

(gdb) where
#0  _Z11fancy_abortPKciS0_ (
file=0x11296dc0
<_GLOBAL__F__ZN9text_info9set_rangeEj12source_rangeb+3056>
"/nasfarm/edelsohn/src/src/libcpp/line-map.c", line=991,
function=0x11296f30
<_GLOBAL__F__ZN9text_info9set_rangeEj12source_rangeb+3424>
"linemap_macro_map_lookup")
at /nasfarm/edelsohn/src/src/gcc/diagnostic.c:1332
#1  0x100169b4 in _Z14linemap_lookupP9line_mapsj (set=0x7000, line=991)
at /nasfarm/edelsohn/src/src/libcpp/line-map.c:991
#2  0x100188f8 in
_Z40linemap_unwind_to_first_non_reserved_locP9line_mapsjPPK8line_map
(set=0x7000, loc=991, map=0x0)
at /nasfarm/edelsohn/src/src/libcpp/line-map.c:1629
#3  0x100753c8 in _ZL17expand_location_1jb (loc=889323520,
expansion_point_p=false) at /nasfarm/edelsohn/src/src/gcc/input.c:158
#4  0x10076488 in _Z48linemap_client_expand_location_to_spelling_pointj (
loc=991) at /nasfarm/edelsohn/src/src/gcc/input.c:751
#5  0x10019928 in _ZN13rich_location9add_rangeEjjb (this=0x2ff21cd8,
start=991, finish=889323520, show_caret_p=true)
at /nasfarm/edelsohn/src/src/libcpp/line-map.c:2012
#6  0x10019a54 in _ZN13rich_locationC2EP9line_mapsj (this=0x2ff21cd8,
set=0x3df, loc=287928112)
at /nasfarm/edelsohn/src/src/libcpp/line-map.c:2024
#7  0x1000ed84 in _Z7warningiPKcz (opt=164,
gmsgid=0x11488d18
<_GLOBAL__F__Z20prepare_call_addressP9tree_nodeP7rtx_defS2-
_PS2_ii+3752> "function call has aggregate value")
at /nasfarm/edelsohn/src/src/gcc/diagnostic.c:1003
#8  0x1067ebac in _Z11expand_callP9tree_nodeP7rtx_defi (exp=0x700dcf20,
target=0x700ec080, ignore=0) at /nasfarm/edelsohn/src/src/gcc/calls.c:2476
#9  0x10406858 in
_Z18expand_expr_real_1P9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_b
(exp=0x700dcf20, target=0x700ec080, tmode=BLKmode,
modifier=EXPAND_NORMAL, alt_rtl=0x17, inner_reference_p=false)
at /nasfarm/edelsohn/src/src/gcc/expr.c:10581
#10 0x104158c0 in _Z22store_expr_with_boundsP9tree_nodeP7rtx_defibbS0_ (
exp=0x700dcf20, target=0x700ec080, call_param_p=0, nontemporal=false,
reverse=false, btarget=0x700df058)
at /nasfarm/edelsohn/src/src/gcc/expr.c:5405
#11 0x104178fc in _Z17expand_assignmentP9tree_nodeS0_b (to=0x700df058,
from=0x700dcf20, nontemporal=false)
at /nasfarm/edelsohn/src/src/gcc/expr.c:5174
#12 0x106f67b4 in _ZL18expand_gimple_stmtP6gimple (stmt=0x7000e240)
at /nasfarm/edelsohn/src/src/gcc/cfgexpand.c:6278
#13 0x106f87d8 in _ZL25expand_gimple_basic_blockP15basic_block_defb (
bb=0x700c7740, disable_tail_calls=false)
at /nasfarm/edelsohn/src/src/gcc/cfgexpand.c:5679
#14 0x106ffbf4 in _ZN12_GLOBAL__N_111pass_expand7executeEP8function (
this=0x11296dc0
<_GLOBAL__F__ZN9text_info9set_rangeEj12source_rangeb+3056>,
fun=0x70009138) at /nasfarm/edelsohn/src/src/gcc/cfgexpand.c:6291

[PATCH] 21_strings/basic_string/capacity/wchar_t/18654.cc

[David Edelsohn]

http://www.cplusplus.com/reference/string/basic_string/reserve/

"Note that the resulting string capacity may be equal or greater than n."

The current testcase verifies that the capacity is exactly equal to
the length of the string or reserve value, but the standard allows the
capacity to be larger.  On AIX, the capacity is larger and the
testcase incorrectly fails.

Linux x86-64:
i: 4
str.length: 4
str.capacity: 4
str.capacity: 12
str.capacity: 8
str.capacity: 4

AIX:
i: 4
str.length: 4
str.capacity: 7   <-- i
str.capacity: 14  <-- i*3
str.capacity: 8   <-- i*2
str.capacity: 7   <-- default

* 21_strings/basic_string/capacity/wchar_t/18654.cc: Verify the
capacity is greater than or equal to the requested amount.

Index: 18654.cc
===
--- 18654.cc(revision 230322)
+++ 18654.cc(working copy)
@@ -50,10 +50,10 @@
   str.reserve(3 * i);

   str.reserve(2 * i);
-  VERIFY( str.capacity() == 2 * i );
+  VERIFY( str.capacity() >= 2 * i );

   str.reserve();
-  VERIFY( str.capacity() == i );
+  VERIFY( str.capacity() >= i );
 }
 }

Thanks, David

[PATCH] g++.dg/init/vbase1.C and g++.dg/cpp/ucn-1.C

[David Edelsohn]

No RISC architecture can store directly to MEM, so the expected RTL in
g++.dg/init/vbase1.C is wrong.  I am adding XFAIL for PowerPC.  This
probably should be disabled for ARM and other RISC architectures.

Dollar sign is not a valid identifier on AIX, so g++.dg/cpp/ucn-1.C
will produce an additional error on AIX.

* g++.dg/init/vbase1.C: XFAIL powerpc*-*-*.
* g++.dg/cpp/ucn-1.C: Expect error for dollar sign identifier on AIX.

Thanks, David

Index: init/vbase1.C
===
--- init/vbase1.C   (revision 230366)
+++ init/vbase1.C   (working copy)
@@ -42,4 +42,4 @@
 // Verify that the SubB() mem-initializer is storing 0 directly into
 // this->D.whatever rather than into a stack temp that is then copied into the
 // base field.
-// { dg-final { scan-rtl-dump "set
\[^\n\]*\n\[^\n\]*this\[^\n\]*\n\[^\n\]*const_int 0" "expand" } }
+// { dg-final { scan-rtl-dump "set
\[^\n\]*\n\[^\n\]*this\[^\n\]*\n\[^\n\]*const_int 0" "expand" { xfail
{ powerpc*-*-* } } } }
Index: cpp/ucn-1.C
===
--- cpp/ucn-1.C (revision 230366)
+++ cpp/ucn-1.C (working copy)
@@ -7,8 +7,9 @@
   "\u0041";// 'A' UCN is OK in string literal
   '\u0041';// also OK in character literal

-  int c\u0041c;  // { dg-error "not valid in an
identifier" }
-  int c\u0024c;  // $ is OK; not part of basic
source char set
+  int c\u0041c;// { dg-error "not valid in an identifier" }
+   // $ is OK on most targets; not part of basic source char set
+  int c\u0024c;// { dg-error "not valid in an identifier" {
target { powerpc-ibm-aix* } } }

   U"\uD800"; // { dg-error "not a valid universal character" }
 }

Re: C++ PATCH to integrate c++-delayed-folding branch

[David Edelsohn]

This seems to have broken bootstrap on PowerPC.  I originally saw it
on AIX, but duplicated it on PPC64LE Linux.

The failure is genoutput seems to be miscompiled by stage1 and
produces error messages implying that it did not parse rs6000/vsx.md
correctly.  I don't know if the miscompilation is genoutput sources or
libstdc++.

/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,?"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 3
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1299: note:  in operand 3
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,?"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 0
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 1
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 2
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sr>,"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 3
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: error: undefined
machine-specific constraint at this point: "Sa>"
/home/dje/src/src/gcc/config/rs6000/vsx.md:1310: note:  in operand 3

Thanks, David

Re: [PATCH] 21_strings/basic_string/capacity/wchar_t/18654.cc

[David Edelsohn]

On Fri, Nov 13, 2015 at 1:40 PM, David Edelsohn <dje@gmail.com> wrote:
> http://www.cplusplus.com/reference/string/basic_string/reserve/
>
> "Note that the resulting string capacity may be equal or greater than n."
>
> The current testcase verifies that the capacity is exactly equal to
> the length of the string or reserve value, but the standard allows the
> capacity to be larger.  On AIX, the capacity is larger and the
> testcase incorrectly fails.
>
> Linux x86-64:
> i: 4
> str.length: 4
> str.capacity: 4
> str.capacity: 12
> str.capacity: 8
> str.capacity: 4
>
> AIX:
> i: 4
> str.length: 4
> str.capacity: 7   <-- i
> str.capacity: 14  <-- i*3
> str.capacity: 8   <-- i*2
> str.capacity: 7   <-- default
>
> * 21_strings/basic_string/capacity/wchar_t/18654.cc: Verify the

Jonathan,

AIX has 2-byte wchar_t in 32 bit mode, which seems to be the cause of
all of the libstdc++ testsuite wchar_t failures.  If GCC libstdc++ is
suppose to shrink-to-fit, how should the testcases be fixed?

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #8 (add integer multiply/add)

[David Edelsohn]

On Tue, Nov 10, 2015 at 1:39 PM, Michael Meissner
 wrote:
> This patch adds support for the MADDLD instruciton, which is a fused
> multiply/add instruction for integers.  At this time, it is for 64-bit
> multiplies only.  Eventually, we will restructure 128-bit multiply so that we
> can use the 64x64 + 64 high bit varients.
>
> I have bootstrapped a compiler with this change in and there were no
> regressions.  Is it ok to apply to the trunk?
>
> [gcc]
> 2015-11-10  Michael Meissner  
>
> * config/rs6000/rs6000.h (TARGET_MADDLD): Add support for the ISA
> 3.0 integer multiply-add instruction.
> * config/rs6000/rs6000.md (mul3): Likewise.
>
> [gcc/testsuite]
> 2015-11-10  Michael Meissner  
>
> * gcc.target/powerpc/maddld.c: New test.

Okay.

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #7 (direct move enhancements)

[David Edelsohn]

On Sun, Nov 8, 2015 at 7:48 PM, Michael Meissner
 wrote:
> This patch adds support for the new direct move instructions (MFVSRLD and
> MTVSRDD) that simplify moving 128-bit data between GPRs and vector registers.
>
> I have built previous versions of this patch with no regressions.  At the
> moment, I have built a non-bootstrap build and ran the PowerPC tests, with no
> regressions.  Assuming the bootstrap build that I've started has no
> regressions, is it ok to install in the trunk?
>
> [gcc]
> 2015-11-08  Michael Meissner  
>
> * config/rs6000/constraints.md (we constraint): New constraint for
> 64-bit power9 vector support.
> (wL constraint): New constraint for the element in a vector that
> can be addressed by the MFVSRLD instruction.
>
> * config/rs6000/rs6000.c (rs6000_debug_reg_global): Add ISA 3.0
> debugging.
> (rs6000_init_hard_regno_mode_ok): If ISA 3.0 and 64-bit, enable we
> constraint.  Disable the VSX<->GPR direct move helpers if we have
> the MFVSRLD and MTVSRDD instructions.
> (rs6000_secondary_reload_simple_move): Add support for doing
> vector direct moves directly without additional scratch registers
> if we have ISA 3.0 instructions.
> (rs6000_secondary_reload_direct_move): Update comments.
> (rs6000_output_move_128bit): Add support for ISA 3.0 vector
> instructions.
>
> * config/rs6000/vsx.md (vsx_mov): Add support for ISA 3.0
> direct move instructions.
> (vsx_movti_64bit): Likewise.
> (vsx_extract_): Likewise.
>
> * config/rs6000/rs6000.h (VECTOR_ELEMENT_MFVSRLD_64BIT): New
> macros for ISA 3.0 direct move instructions.
> (TARGET_DIRECT_MOVE_128): Likewise.
>
> * config/rs6000/rs6000.md (128-bit GPR splitters): Don't split a
> 128-bit move that is a direct move between GPR and vector
> registers using ISA 3.0 direct move instructions.
>
> * doc/md.texi (RS/6000 constraints): Document we, wF, wG, wL
> constraints.  Update wa documentation to say not to use %x on
> instructions that only take Altivec registers.
>
> [gcc/testsuite]
> 2015-11-08  Michael Meissner  
>
> * gcc.target/powerpc/direct-move-vector.c: New test for 128-bit
> vector direct move instructions.

This is okay.

Thanks, David

Re: open acc default data attribute

[David Edelsohn]

Nathan,

The ChangeLog was placed in the wrong files.

gcc/
* gimplify.c (oacc_default_clause): New.
(omp_notice_variable): Call it.

Should go in gcc/ChangeLog without "gcc/"

gcc/testsuite/
* c-c++-common/goacc/data-default-1.c: New.

should go in gcc/testsuite/ChangeLog

libgomp/
* testsuite/libgomp.oacc-c-c++-common/default-1.c: New.

should go in libgomp/ChangeLog

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #6 (IEEE 128-bit hardware support)

[David Edelsohn]

On Sun, Nov 8, 2015 at 7:44 PM, Michael Meissner
 wrote:
> This patch adds support for the IEEE 128-bit hardware instructions that are
> being added to the PowerPC ISA 3.0 (power9).  With this patch, users on power7
> and power8 will use the software emulation functions that are committed, but
> still need some enhancment.  On ISA 3.0/power9, they would be able to use the
> direct instructions.
>
> I have built this patch with a bootstrap build on a power8 little endian
> system.  There were no regressions in the test suite.  Is this patch ok to
> install in the trunk?
>
> [gcc]
> 2015-11-08  Michael Meissner  
>
> * config/rs6000/rs6000-protos.h (convert_float128_to_int): Add
> declaration.
> (convert_int_to_float128): Likewise.
> (rs6000_generate_compare): Add support for ISA 3.0 (power9)
> hardware support for IEEE 128-bit floating point.
> (rs6000_expand_float128_convert): Likewise.
> (convert_float128_to_int): Likewise.
> (convert_int_to_float128): Likewise.
>
> * config/rs6000/rs6000.md (UNSPEC_ROUND_TO_ODD): New unspecs for
> ISA 3.0 hardware IEEE 128-bit floating point.
> (UNSPEC_IEEE128_MOVE): Likewise.
> (UNSPEC_IEEE128_CONVERT): Likewise.
> (FMA_F): Add support for IEEE 128-bit floating point hardware
> support.
> (Ff): Add support for DImode.
> (Fv): Likewise.
> (any_fix code iterator): New and updated iterators for IEEE
> 128-bit floating point hardware support.
> (any_float code iterator): Likewise.
> (s code attribute): Likewise.
> (su code attribute): Likewise.
> (az code attribute): Likewise.
> (neg2, FLOAT128 iterator): Add support for IEEE 128-bit
> floating point hardware support.
> (abs2, FLOAT128 iterator): Likewise.
> (add3, IEEE128 iterator): New insns for IEEE 128-bit
> floating point hardware.
> (sub3, IEEE128 iterator): Likewise.
> (mul3, IEEE128 iterator): Likewise.
> (div3, IEEE128 iterator): Likewise.
> (copysign3, IEEE128 iterator): Likewise.
> (sqrt2, IEEE128 iterator): Likewise.
> (neg2, IEEE128 iterator): Likewise.
> (abs2, IEEE128 iterator): Likewise.
> (nabs2, IEEE128 iterator): Likewise.
> (fma4_hw, IEEE128 iterator): Likewise.
> (fms4_hw, IEEE128 iterator): Likewise.
> (nfma4_hw, IEEE128 iterator): Likewise.
> (nfms4_hw, IEEE128 iterator): Likewise.
> (extend2_hw): Likewise.
> (truncdf2_hw, IEEE128 iterator): Likewise.
> (truncsf2_hw, IEEE128 iterator): Likewise.
> (fix_fixuns code attribute): Likewise.
> (float_floatuns code attribute): Likewise.
> (_si2_hw): Likewise.
> (_di2_hw): Likewise.
> (_si2_hw): Likewise.
> (_di2_hw): Likewise.
> (xscvqpwz_): Likewise.
> (xscvqpdz_): Likewise.
> (xscvdqp_ (ieee128_mfvsrd): Likewise.
> (ieee128_mfvsrwz): Likewise.
> (ieee128_mtvsrw): Likewise.
> (ieee128_mtvsrd): Likewise.
> (truncdf2_odd): Likewise.
> (cmp_h): Likewise.
>
> [gcc/testsuite]
> 2015-11-08  Michael Meissner  
>
> * gcc.target/powerpc/float128-hw.c: New test for IEEE 128-bit
> hardware floating point support.

Please change the attribute to "uns" as suggested by Segher.

> +(define_code_attr fix_fixuns  [(fix   "fix")   (unsigned_fix
"fixuns")])
> +(define_code_attr float_floatuns [(float "float")
(unsigned_float "floatuns")])

You could instead do an "uns" attribute so you would write fix etc.

Okay with that change.

We need to think more about ieee128_mtvsw pattern.

Thanks, David

Re: [rs6000] Rotate stack checking loop

[David Edelsohn]

On Thu, Nov 12, 2015 at 4:51 PM, Eric Botcazou  wrote:
> Hi,
>
> this patch rotates the loop generated in the prologue to do stack checking
> when -fstack-check is specified, thereby saving one branch instruction.  It
> was initially implemented as a WHILE loop to match the generic implementation
> but can be turned into a DO-WHILE loop because the amount of stack to be
> checked is known at compile time (since it's the static part of the frame).
>
> Tested on PowerPC/Linux, OK for the mainline?
>
>
> 2015-11-12  Eric Botcazou  
>
> * config/rs6000/rs6000.c (rs6000_emit_probe_stack_rang): Adjust.
> (output_probe_stack_range): Rotate the loop and simplify.

Okay.

Thanks, David

[PATCH] AIX asserts

[David Edelsohn]

This patch adds some asserts of cpu and machine to fix an assert
testcase and makes the defines consistent with PPC64 Linux.

boottrapped on powerpc-ibm-aix7.1.0.0

* config/rs6000/aix.h (TARGET_OS_AIX_CPP_BUILTINS): Add cpu and
machine asserts.  Update defines for 64 bit.

Thanks, David

Index: aix.h
===
--- aix.h   (revision 230144)
+++ aix.h   (working copy)
@@ -101,8 +101,6 @@
 {  \
   builtin_define ("_IBMR2");   \
   builtin_define ("_POWER");   \
-  builtin_define ("__powerpc__");   \
-  builtin_define ("__PPC__");   \
   builtin_define ("__unix__");  \
   builtin_define ("_AIX"); \
   builtin_define ("_AIX32");   \
@@ -112,6 +110,22 @@
 builtin_define ("__LONGDOUBLE128");\
   builtin_assert ("system=unix");  \
   builtin_assert ("system=aix");   \
+  if (TARGET_64BIT)\
+   {   \
+ builtin_define ("__PPC__");   \
+ builtin_define ("__PPC64__"); \
+ builtin_define ("__powerpc__");   \
+ builtin_define ("__powerpc64__"); \
+ builtin_assert ("cpu=powerpc64"); \
+ builtin_assert ("machine=powerpc64"); \
+   }   \
+  else \
+   {   \
+ builtin_define ("__PPC__");   \
+ builtin_define ("__powerpc__");   \
+ builtin_assert ("cpu=powerpc");   \
+ builtin_assert ("machine=powerpc");   \
+   }   \
 }  \
   while (0)

Re: [PATCH], Add power9 support to GCC, patch #5 (ISA 3.0 fusion)

[David Edelsohn]

On Mon, Nov 9, 2015 at 11:57 AM, Segher Boessenkool
 wrote:
> On Mon, Nov 09, 2015 at 12:34:20PM -0500, Michael Meissner wrote:
>> > > +(define_insn "*toc_fusionload_"
>> > > +  [(set (match_operand:QHSI 0 "int_reg_operand" "=,??r")
>> > > + (match_operand:QHSI 1 "toc_fusion_mem_wrapped" "wG,wG"))
>> > > +   (unspec [(const_int 0)] UNSPEC_FUSION_ADDIS)
>> > > +   (use (match_operand:DI 2 "base_reg_operand" "r,r"))
>> > > +   (clobber (match_scratch:DI 3 "=X,"))]
>> > > +  "TARGET_TOC_FUSION_INT"
>> >
>> > Do you need that "??r" alternative?  Same for the next define_insn.
>>
>> Yes unfortunately.  The ??r catches the case where r0 is chosen.  R0 is not a
>> base register, and it can't be used for power8 gpr fusion (where you use the
>> value being loaded for the ADDIS instruction), but it can be used for power9
>> fusion (where the ADDIS must be adjancent, but it no longer has to be the
>> register being loaded).
>
> If you have only "b", r0 will not be chosen.  Does that help?  Or are
> you generating this pattern from somewhere else where you put in r0?

Mike,

What happens if you leave out the "r" alternative?  Does other code
explicitly generate that pattern with r0?

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #3 (scalar count trailing zeros)

[David Edelsohn]

On Sun, Nov 8, 2015 at 4:37 PM, Michael Meissner
 wrote:
> This patch adds support for scalar count trailing zeros instruction that is
> being added to ISA 3.0 (power9).
>
> I have built this patch (along with patches #2 and #4) with a bootstrap build
> on a power8 little endian system.  There were no regressions in the test
> suite.  Is this patch ok to install in the trunk once patch #1 has been
> installed.
>
> [gcc]
> 2015-11-08  Michael Meissner  
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Update costs for
> count trailing zero instruction if we have hardware support.
>
> * config/rs6000/rs6000.h (TARGET_CTZ): Add support for count
> trailing zero instruction in ISA 3.0.
> * config/rs6000/rs6000.c (ctz2): Likewise.
> (ctz2_h): Likewise.
>
> [gcc/testsuite]
> 2015-11-08  Michael Meissner  
>
> * gcc.target/powerpc/ctz-1.c: Add test for count trailing zero
> instruciton support.
> * gcc.target/powerpc/ctz-2.c: Likewise.

This is okay.  We can address the attribute at a later time if necessary.

Please re-check CTZ_DEFINED_VALUE_AT_ZERO.

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #5 (ISA 3.0 fusion)

[David Edelsohn]

On Sun, Nov 8, 2015 at 4:42 PM, Michael Meissner
 wrote:
> This patch adds support for new fusion forms in ISA 3.0 (power9).  In
> particular, ISA 3.0 can fuse GPR loads of R0, FPR loads, GPR stores, FPR
> stores, and some constant generation that ISA 2.07 (power8) could not
> generate.
>
> I have built this patch with a bootstrap build on a power8 little endian
> system.  There were no regressions in the test suite.  Is this patch ok to
> install in the trunk once patch #1 has been installed.
>
> [gcc]
> 2015-11-08  Michael Meissner  
>
> * config/rs6000/constraints.md (wF constraint): New constraints
> for power9/toc fusion.
> (wG constraint): Likewise.
>
> * config/rs6000/predicates.md (upper16_cint_operand): New
> predicate for power9 and toc fusion.
> (fpr_reg_operand): Likewise.
> (toc_fusion_or_p9_reg_operand): Likewise.
> (toc_fusion_mem_raw): Likewise.
> (toc_fusion_mem_wrapped): Likewise.
> (fusion_gpr_addis): If power9 fusion, allow fusion for a larger
> address range.
> (fusion_gpr_mem_combo): Delete, use fusion_addis_mem_combo_load
> instead.
> (fusion_addis_mem_combo_load): Add support for power9 fusion of
> floating point loads, floating point stores, and gpr stores.
> (fusion_addis_mem_combo_store): Likewise.
> (fusion_offsettable_mem_operand): Likewise.
>
> * config/rs6000/rs6000-protos.h (emit_fusion_addis): Add
> declarations.
> (emit_fusion_load_store): Likewise.
> (fusion_p9_p): Likewise.
> (expand_fusion_p9_load): Likewise.
> (expand_fusion_p9_store): Likewise.
> (emit_fusion_p9_load): Likewise.
> (emit_fusion_p9_store): Likewise.
> (fusion_wrap_memory_address): Likewise.
>
> * config/rs6000/rs6000.c (struct rs6000_reg_addr): Add new
> elements for power9 fusion.
> (rs6000_debug_print_mode): Rework debug information to print more
> information about fusion.
> (rs6000_init_hard_regno_mode_ok): Setup for power9 fusion
> support.
> (rs6000_legitimate_address_p): Recognize toc fusion as a valid
> offsettable memory address.
> (emit_fusion_gpr_load): Move most of the code from
> emit_fusion_gpr_load into emit_fusion-addis that handles both
> power8 and power9 fusion.
> (emit_fusion_addis): Likewise.
> (emit_fusion_load_store): Likewise.
> (fusion_wrap_memory_address): Add support for TOC fusion.
> (fusion_split_address): Likewise.
> (fusion_p9_p): Add support for power9 fusion.
> (expand_fusion_p9_load): Likewise.
> (expand_fusion_p9_store): Likewise.
> (emit_fusion_p9_load): Likewise.
> (emit_fusion_p9_store): Likewise.
>
> * config/rs6000/rs6000.h (TARGET_TOC_FUSION_INT): New macros for
> power9 fusion support.
> (TARGET_TOC_FUSION_FP): Likewise.
>
> * config/rs6000/rs6000.md (UNSPEC_FUSION_P9): New power9/toc
> fusion unspecs.
> (UNSPEC_FUSION_ADDIS): Likewise.
> (QHSI mode iterator): New iterator for power9 fusion.
> (GPR_FUSION): Likewise.
> (FPR_FUSION): Likewise.
> (power9 fusion splitter): New power9/toc fusion support.
> (toc_fusionload_): Likewise.
> (toc_fusionload_di): Likewise.
> (fusion_gpr_load_): Update predicate function.
> (power9 fusion peephole2s): New power9/toc fusion support.
> (fusion_gpr___load): Likewise.
> (fusion_gpr___store): Likewise.
> (fusion_fpr___load): Likewise.
> (fusion_fpr___store): Likewise.
> (fusion_p9__constant): Likewise.
>
> [gcc/testsuite]
> 2015-11-08  Michael Meissner  
>
> * gcc.target/powerpc/fusion.c (fusion_vector): Move to fusion2.c
> and allow the test on PowerPC LE.
> * gcc.target/powerpc/fusion2.c (fusion_vector): Likewise.
>
> * gcc.target/powerpc/fusion3.c: New file, test power9 fusion.

Okay, with the changes that you and Segher discussed.

Thanks, David

Re: [PATCH 5/6] Simplify rs6000_builtin_vectorized_function

[David Edelsohn]

On Mon, Nov 9, 2015 at 8:30 AM, Richard Sandiford
 wrote:
> After the previous patches it's no longer necessary for
> TARGET_BUILTIN_VECTORIZED_FUNCTION to return functions that
> map to the vector optab of the original operation.  We'll use
> a vector form of the internal function instead.
>
>
> gcc/
> * config/rs6000/rs6000.c (rs6000_builtin_vectorized_function): Remove
> entries that map directly to optabs.

Okay.

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #4

[David Edelsohn]

On Sun, Nov 8, 2015 at 4:39 PM, Michael Meissner
 wrote:
> This patch adds support for the EXTSWSLI instruction that is being added to
> PowerPC ISA 3.0 (power9).
>
> I have built this patch (along with patches #2 and #3) with a bootstrap build
> on a power8 little endian system.  There were no regressions in the test
> suite.  Is this patch ok to install in the trunk once patch #1 has been
> installed.
>
> [gcc]
> 2015-11-08  Michael Meissner  
>
> * config/rs6000/predicates.md (u6bit_cint_operand): New
> predicate, recognize 0..63.
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Adjust the costs if
> the EXTSWSLI instruction is generated.
>
> * config/rs6000/rs6000.h (TARGET_EXTSWSLI): Add support for ISA
> 3.0 EXTSWSLI instruction.
> * config/rs6000/rs6000.md (ashdi3_extswsli): Likewise.
> (ashdi3_extswsli_dot): Likewise.
> (ashdi3_extswsli_dot2): Likewise.
>
> [gcc/testsuite]
> 2015-11-08  Michael Meissner  
>
> * gcc.target/powerpc/extswsli-1.c: New file to test EXTSWSLI
> instruction generation.
> * gcc.target/powerpc/extswsli-2.c: Likewise.
> * gcc.target/powerpc/extswsli-3.c: Likewise.

Okay.

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #1 (revised)

[David Edelsohn]

On Sun, Nov 8, 2015 at 4:33 PM, Michael Meissner
 wrote:
> This is patch #1 that I revised.  I changed -mfusion-toc to -mtoc-fusion.  I
> changed the references to ISA 2.08 to 3.0.  I added two new debug switches for
> code in future patches that in undergoing development and is not ready to be 
> on
> by default.
>
> I have done a bootstrap build on a little endian power8 system and there were
> no regressions in this patch.  Is it ok to install in the trunk?
>
> 2015-11-08  Michael Meissner  
>
> * config/rs6000/rs6000.opt (-mpower9-fusion): Add new switches for
> ISA 3.0 (power9).
> (-mpower9-vector): Likewise.
> (-mpower9-dform): Likewise.
> (-mpower9-minmax): Likewise.
> (-mtoc-fusion): Likewise.
> (-mmodulo): Likewise.
> (-mfloat128-hardware): Likewise.
>
> * config/rs6000/rs6000-cpus.def (ISA_3_0_MASKS_SERVER): Add option
> mask for ISA 3.0 (power9).
> (POWERPC_MASKS): Add new ISA 3.0 switches.
> (power9 cpu): Add power9 cpu.
>
> * config/rs6000/rs6000.h (ASM_CPU_POWER9_SPEC): Add support for
> power9.
> (ASM_CPU_SPEC): Likewise.
> (EXTRA_SPECS): Likewise.
>
> * config/rs6000/rs6000-opts.h (enum processor_type): Add
> PROCESSOR_POWER9.
>
> * config/rs6000/rs6000.c (power9_cost): Initial cost setup for
> power9.
> (rs6000_debug_reg_global): Add support for power9 fusion.
> (rs6000_setup_reg_addr_masks): Cache mode size.
> (rs6000_option_override_internal): Until real power9 tuning is
> added, use -mtune=power8 for -mcpu=power9.
> (rs6000_setup_reg_addr_masks): Do not allow pre-increment,
> pre-decrement, or pre-modify on SFmode/DFmode if we allow the use
> of Altivec registers.
> (rs6000_option_override_internal): Add support for ISA 3.0
> switches.
> (rs6000_loop_align): Add support for power9 cpu.
> (rs6000_file_start): Likewise.
> (rs6000_adjust_cost): Likewise.
> (rs6000_issue_rate): Likewise.
> (insn_must_be_first_in_group): Likewise.
> (insn_must_be_last_in_group): Likewise.
> (force_new_group): Likewise.
> (rs6000_register_move_cost): Likewise.
> (rs6000_opt_masks): Likewise.
>
> * config/rs6000/rs6000.md (cpu attribute): Add power9.
> * config/rs6000/rs6000-tables.opt: Regenerate.
>
> * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
> _ARCH_PWR9 if power9 support is available.
>
> * config/rs6000/aix61.h (ASM_CPU_SPEC): Add power9.
> * config/rs6000/aix53.h (ASM_CPU_SPEC): Likewise.
>
> * configure.ac: Determine if the assembler supports the ISA 3.0
> instructions.
> * config.in (HAVE_AS_POWER9): Likewise.
> * configure: Regenerate.
>
> * doc/invoke.texi (RS/6000 and PowerPC Options): Document ISA 3.0
> switches.

Okay.

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #2 (add modulus instructions)

[David Edelsohn]

On Sun, Nov 8, 2015 at 4:36 PM, Michael Meissner
 wrote:
> This is patch #2.  It adds support for the new modulus instructions that are
> being added in ISA 3.0 (power9):
>
> I have built this patch (along with patches #3 and #4) with a bootstrap build
> on a power8 little endian system.  There were no regressions in the test
> suite.  Is this patch ok to install in the trunk once patch #1 has been
> installed.
>
> [gcc]
> 2015-11-08  Michael Meissner  
>
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Update costs for
> modulus instructions if we have hardware support.
>
> * config/rs6000/rs6000.md (mod3): Add support for ISA 3.0
> modulus instructions.
> (umod3): Likewise.
> (divmod peephole): Likewise.
> (udivmod peephole): Likewise.
>
> [gcc/testsuite]
> 2015-11-08  Michael Meissner  
>
> * lib/target-supports.exp (check_p9vector_hw_available): Add
> checks for power9 availability.
> (check_effective_target_powerpc_p9vector_ok): Likewise.
> (check_vect_support_and_set_flags): Likewise.
>
> * gcc.target/powerpc/mod-1.c: New test.
> * gcc.target/powerpc/mod-2.c: Likewise.

This is okay, but let's wait for revised #3 since you tested 2, 3, 4 together.

Thanks, David

Re: [PATCH 2/2] rs6000: Extend 20050603-3.c testcase to 64-bit

[David Edelsohn]

On Sun, Nov 8, 2015 at 11:33 PM, Segher Boessenkool
 wrote:
> The testcase used to fail on 64-bit, but it was disabled there.
> This patch makes it run there, and beefs up the checking of the
> generated code a bit.
>
> Tested on powerpc64-linux *-m32,-m32/-mpowerpc64,-m64).
> Is this okay for trunk?
>
>
> Segher
>
>
> 2015-11-09  Segher Boessenkool  
>
> gcc/testsuite/
> * gcc.target/powerpc/20050603-3.c: Don't restrict to ilp32.  Do more
> tests for the expected generated code.

This is okay when the simplify-rtx.c patch is approved.

Thanks, David

Re: [PATCH], Add power9 support to GCC, patch #5 (ISA 3.0 fusion)

[David Edelsohn]

On Mon, Nov 9, 2015 at 2:17 PM, Michael Meissner
<meiss...@linux.vnet.ibm.com> wrote:
> On Mon, Nov 09, 2015 at 01:11:41PM -0800, David Edelsohn wrote:
>> On Mon, Nov 9, 2015 at 11:57 AM, Segher Boessenkool
>> <seg...@kernel.crashing.org> wrote:
>> > On Mon, Nov 09, 2015 at 12:34:20PM -0500, Michael Meissner wrote:
>> >> > > +(define_insn "*toc_fusionload_"
>> >> > > +  [(set (match_operand:QHSI 0 "int_reg_operand" "=,??r")
>> >> > > + (match_operand:QHSI 1 "toc_fusion_mem_wrapped" "wG,wG"))
>> >> > > +   (unspec [(const_int 0)] UNSPEC_FUSION_ADDIS)
>> >> > > +   (use (match_operand:DI 2 "base_reg_operand" "r,r"))
>> >> > > +   (clobber (match_scratch:DI 3 "=X,"))]
>> >> > > +  "TARGET_TOC_FUSION_INT"
>> >> >
>> >> > Do you need that "??r" alternative?  Same for the next define_insn.
>> >>
>> >> Yes unfortunately.  The ??r catches the case where r0 is chosen.  R0 is 
>> >> not a
>> >> base register, and it can't be used for power8 gpr fusion (where you use 
>> >> the
>> >> value being loaded for the ADDIS instruction), but it can be used for 
>> >> power9
>> >> fusion (where the ADDIS must be adjancent, but it no longer has to be the
>> >> register being loaded).
>> >
>> > If you have only "b", r0 will not be chosen.  Does that help?  Or are
>> > you generating this pattern from somewhere else where you put in r0?
>>
>> Mike,
>>
>> What happens if you leave out the "r" alternative?  Does other code
>> explicitly generate that pattern with r0?
>
> Sometimes, one of the passes after reload (usually -fgcse-after-reload) 
> decides
> to redo the register allocation, and I would see a failure in building things
> like Spec 2006.  I have tried not putting the "r" in there, or using
> base_reg_operand instead of gpc_reg_operand, but I still got failures.

This seems like a bug in those other passes that should be tracked down.

Thanks, David

[PATCH] Complete cxa_atexit for AIX

[David Edelsohn]

IBM xlC++ compiler provides its own implementation of atexit() to
provide correct interaction between atexit() and destructors.  GCC
needs to provide the same through libgcc.

I previously added partial support based on the implementation in
GLIBC (copied with FSF permission) and confirmed that destructors
continued to function properly.  This patch completes the support with
the matching definition of atexit().

With this patch, cxa_atexit tests in the testsuite function correctly.

I plan to backport this patch to the GCC 5 branch, in which cxa_atexit
is not enabled by default.

Bootstrapped on powerpc-ibm-aix7.1.0.0 and powerpc-ibm-aix7.1.3.0.

Thanks, David

* config/rs6000/atexit.c: New file.
* config/rs6000/t-aix-cxa (LIB2ADDEH): Build atexit.c.
* config/rs6000/libgcc-aix-cxa.ver (atexit): Add symbol to exports.
* config/rs6000/cxa_finalize.c
(catomic_compare_and_exchange_bool_acq): Negate return value.


AA
Description: Binary data

Re: [PATCH] gcc/config.gcc: fix typo for powerpc e6500 cpu_is_64bit

[David Edelsohn]

2015-11-06  Arnout Vandecappelle  
 * gcc/config.gcc: fix typo for powerpc e6500 cpu_is_64bit

For GCC, please don't send ChangeLog entries as diffs.

Applied.  Thanks.

- David

Re: [PATCH] PR 68192 Export AIX TLS symbols

[David Edelsohn]

[Explicitly copying build maintainers.]

Paolo and Alexandre,

Could you review and help with this patch?

TLS symbols in AIX display a new, different symbol type in nm output.
Libtool explicitly creates a list of exported symbols for shared
libraries using nm and does not recognize the new TLS symbols, so
those symbols are not exported.

This is a regression for TLS support on AIX.

This patch updates libtool.m4 in GCC and configure for libstdc++-v3,
libgfortran, and libgomp.  I would like to apply the patch to GCC
while I simultaneously work with the Libtool community to correct the
bug upstream.  I also would like to backport this to GCC 5.2 and GCC
4.9.x.

I have not been able to run the correct versions of autoconf to
regenerate configure directly.  I either can edit the files directly
or I would appreciate someone helping me to regenerate configure in
all library directories.

Bootstrapped on powerpc-ibm-aix7.1.0.0.

* libtool.m4 (export_symbols_cmds) [AIX]: Add global TLS "L" symbols.
* libstdc++-v3/configure: Regenerate.
* libgfortran/configure: Regenerate.
* libgomp/configure: Regenerate.

Thanks, David


ZZ
Description: Binary data

Re: [PATCH] PR 68192 Export AIX TLS symbols

[David Edelsohn]

Hi, Richi

You mentioned GCC 5.3 release around the time of stage 1 ending in the
GCC 5 status report:

https://gcc.gnu.org/ml/gcc/2015-07/msg00197.html

If the timeframe is later, we have more time to address the AIX libtool problem.

Thanks, David

On Thu, Nov 5, 2015 at 9:13 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On November 5, 2015 5:38:45 PM GMT+01:00, David Edelsohn <dje@gmail.com> 
> wrote:
>>On Thu, Nov 5, 2015 at 8:34 AM, Paolo Bonzini <bonz...@gnu.org> wrote:
>>>
>>>
>>> On 05/11/2015 17:28, David Edelsohn wrote:
>>>> [Explicitly copying build maintainers.]
>>>>
>>>> Paolo and Alexandre,
>>>>
>>>> Could you review and help with this patch?
>>>>
>>>> TLS symbols in AIX display a new, different symbol type in nm
>>output.
>>>> Libtool explicitly creates a list of exported symbols for shared
>>>> libraries using nm and does not recognize the new TLS symbols, so
>>>> those symbols are not exported.
>>>>
>>>> This is a regression for TLS support on AIX.
>>>>
>>>> This patch updates libtool.m4 in GCC and configure for libstdc++-v3,
>>>> libgfortran, and libgomp.  I would like to apply the patch to GCC
>>>> while I simultaneously work with the Libtool community to correct
>>the
>>>> bug upstream.  I also would like to backport this to GCC 5.2 and GCC
>>>> 4.9.x.
>>>
>>> I think it's okay to wait for the patch to be upstream.
>>>
>>> I can help committing the patch once it is.
>>
>>Paolo,
>>
>>The patch MUST go into GCC 5.3 release, which Richi has announced that
>>he wants to release around the beginning of Stage 3.  The patch should
>>not go into GCC 5 branch without going into trunk.  This patch cannot
>>wait unless you want to block GCC 5.3.
>
> I don't remember announcing this timeframe but I won't be able to dedicate 
> the required resources until the end of November.
>
> Richard.
>
>>Thanks, David
>
>

Re: [PATCH] PR 68192 Export AIX TLS symbols

[David Edelsohn]

On Thu, Nov 5, 2015 at 8:34 AM, Paolo Bonzini <bonz...@gnu.org> wrote:
>
>
> On 05/11/2015 17:28, David Edelsohn wrote:
>> [Explicitly copying build maintainers.]
>>
>> Paolo and Alexandre,
>>
>> Could you review and help with this patch?
>>
>> TLS symbols in AIX display a new, different symbol type in nm output.
>> Libtool explicitly creates a list of exported symbols for shared
>> libraries using nm and does not recognize the new TLS symbols, so
>> those symbols are not exported.
>>
>> This is a regression for TLS support on AIX.
>>
>> This patch updates libtool.m4 in GCC and configure for libstdc++-v3,
>> libgfortran, and libgomp.  I would like to apply the patch to GCC
>> while I simultaneously work with the Libtool community to correct the
>> bug upstream.  I also would like to backport this to GCC 5.2 and GCC
>> 4.9.x.
>
> I think it's okay to wait for the patch to be upstream.
>
> I can help committing the patch once it is.

Paolo,

The patch MUST go into GCC 5.3 release, which Richi has announced that
he wants to release around the beginning of Stage 3.  The patch should
not go into GCC 5 branch without going into trunk.  This patch cannot
wait unless you want to block GCC 5.3.

Thanks, David

[PATCH] Merge from gomp-4_5-branch to trunk

[David Edelsohn]

This patch broke bootstrap on AIX.

/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/ios_init.cc: In
static member function 'static  bool
std::ios_base::sync_with_stdio(bool)':
/nasfarm/edelsohn/src/src/libstdc++-v3/src/c++98/ios_init.cc:181:59:
internal compiler error: in tree_to_shwi, at tree.c:7297
  new (_cout) stdio_filebuf(stdout, ios_base::out);

   ^

- David

Re: [PATCH] Merge from gomp-4_5-branch to trunk

[David Edelsohn]

Sorry for the incorrect blame.  I thought the failure was due to GOMP
changes, but it appears to be due to the placement new size changes.
I am re-testing after Martin's fix.

By the way, Martin, the ChangeLog entry is wrong

2015-11-05  Martin Sebor  

PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
* gcc/testsuite/g++.dg/warn/Wplacement-new-size.C: New test.

The invoke.texi change should list doc/invoke.texi and the testsuite
change should go in testsuite/ChangeLog.

Thanks, David

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] PR 68192 Export AIX TLS symbols

[David Edelsohn]

On Tue, Nov 3, 2015 at 9:47 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Tue, Nov 3, 2015 at 3:23 PM, David Edelsohn <dje@gmail.com> wrote:
>> TLS symbols in AIX display a new, different symbol type in nm output.
>> Libtool explicitly creates a list of exported symbols for shared
>> libraries using nm and does not recognize the new TLS symbols, so
>> those symbols are not exported.
>>
>> This is a regression for TLS support on AIX.
>>
>> This patch updates libtool.m4 in GCC and configure for libstdc++-v3,
>> libgfortran, and libgomp.  I would like to apply the patch to GCC
>> while I simultaneously work with the Libtool community to correct the
>> bug upstream.  I also would like to backport this to GCC 5.2 and GCC
>> 4.9.x.
>
> What does this do to the set of exported symbols esp. on branches.
> Does AIX have library versions?

The patch restores symbols that were omitted by the "nm" change.  The
symbols are a superset of the current symbols and were present before,
which is why this is a regression.

Thanks, David

[PATCH] PR 68192 Export AIX TLS symbols

[David Edelsohn]

TLS symbols in AIX display a new, different symbol type in nm output.
Libtool explicitly creates a list of exported symbols for shared
libraries using nm and does not recognize the new TLS symbols, so
those symbols are not exported.

This is a regression for TLS support on AIX.

This patch updates libtool.m4 in GCC and configure for libstdc++-v3,
libgfortran, and libgomp.  I would like to apply the patch to GCC
while I simultaneously work with the Libtool community to correct the
bug upstream.  I also would like to backport this to GCC 5.2 and GCC
4.9.x.

I have not been able to run the correct versions of autoconf to
regenerate configure directly.  I either can edit the files directly
or I would appreciate someone helping me to regenerate configure in
all library directories.

Bootstrapped on powerpc-ibm-aix7.1.0.0.

* libtool.m4 (export_symbols_cmds) [AIX]: Add global TLS "L" symbols.
* libstdc++-v3/configure: Regenerate.
* libgfortran/configure: Regenerate.
* libgomp/configure: Regenerate.

Thanks, David


ZZ
Description: Binary data

Re: [PATCH 2/2] rs6000: Rewrite rs6000_reg_live_or_pic_offset_p

[David Edelsohn]

On Sat, Oct 31, 2015 at 1:39 PM, Segher Boessenkool
 wrote:
> This function is quite a puzzle; untangle it.  No functional change.
>
> Tested etc.; okay for trunk?
>
>
> Segher
>
>
> 2015-10-31  Segher Boessenkool  
>
> * config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p): Rewrite.

Okay.

Thanks, David

Re: [PATCH 1/2] rs6000: Another PIC LRA fix

[David Edelsohn]

On Sat, Oct 31, 2015 at 1:39 PM, Segher Boessenkool
 wrote:
> This one for TARGET_TOC && TARGET_MINIMAL_TOC.  Without it, r30 is not
> saved in the prologue for functions that do not use r30, but the register
> is set later in the prologue anyhow.  This made all java tests fail.
>
> Tested on powerpc64-linux, --enable-languages=all,ada,go,obj-c++ and test
> variants {-m32/-mno-lra,-m32/-mlra,-m32/-mpowerpc64,-m64/-mno-lra,-m64/-mlra};
> and on powerpc64le-linux, everything default.  Both also with bootstrapping
> with LRA defaulted on.
>
> Okay for trunk?
>
>
> Segher
>
>
> 2015-10-31  Segher Boessenkool  
>
> * config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p): Use the
> same condition for testing whether RS6000_PIC_OFFSET_TABLE_REGNUM is
> live as for using it elsewhere, for TARGET_MINIMAL_TOC.

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