Re: [PATCH] Add _Float/_FloatX rounding built-ins & improve gimple optimization of _Float/_FloatX built-in functions

On Thu, Dec 21, 2017 at 01:03:26PM -0600, Segher Boessenkool wrote: > On Thu, Dec 21, 2017 at 06:16:16PM +, Joseph Myers wrote: > > On Fri, 17 Nov 2017, Michael Meissner wrote: > > The architecture-independent changes are OK. However, I have a comment on > > the target parts: > > > > >

Re: [nvptx, committed] Disable -gstatement-frontiers for nvptx

On Dec 27, 2017, Tom de Vries wrote: > .loc file_index line_number column_position > so this causes ptxas errors when compiling something for nvptx with > -g, which breaks the nvptx build. What do the errors look like? I ask because the patches that actually change the

Re: [patch, lingfortran] Bug 83560 - list-directed formatting of INTEGER is missing plus on output

On 12/25/2017 12:06 PM, Jerry DeLisle wrote: > On 12/25/2017 05:10 AM, Dominique d'Humières wrote: >> Dear Jerry, >> >> The lines >> >> +a=12.3456 >> >> and >> >> +open(unit=10,sign='plus') >> >> in gfortran.dg/integer_plus.f90 could probably be removed. >> > > Yes, left over from some other

Re: [PATCH] Add _Float/_FloatX rounding built-ins & improve gimple optimization of _Float/_FloatX built-in functions

On Thu, Dec 21, 2017 at 06:16:16PM +, Joseph Myers wrote: > On Fri, 17 Nov 2017, Michael Meissner wrote: > > > Here is the fixed patch. It fixes the btrunc2 insn to use the correct > > XSRPQI variant for truncf128. I added the float128-hw11.c test as a runtime > > test to make sure round,

[4/4] Make CONST_VECTOR_ELT handle implicitly-encoded elements

This patch makes CONST_VECTOR_ELT handle implicitly-encoded elements, in a similar way to VECTOR_CST_ELT. 2017-12-28 Richard Sandiford gcc/ * rtl.h (CONST_VECTOR_ELT): Redefine to const_vector_elt. (const_vector_encoded_nelts): New function.

[3/4] Make more use of rtx_vector_builder

This patch makes various bits of CONST_VECTOR-building code use rtx_vector_builder, operating directly on a specific encoding. 2017-12-28 Richard Sandiford gcc/ * expr.c: Include rtx-vector-builder.h. (const_vector_mask_from_tree): Use

[2/4] New CONST_VECTOR layout

This patch makes CONST_VECTOR use the same encoding as VECTOR_CST. One problem that occurs in RTL but not at the tree level is that a fair amount of code uses XVEC and XVECEXP directly on CONST_VECTORs (which is valid, just with looser checking). This is complicated by the fact that vectors are

[1/4] Use CONST_VECTOR_ELT instead of XVECEXP

This patch replaces target-independent uses of XVECEXP with uses of CONST_VECTOR_ELT. This kind of replacement isn't necessary for code specific to targets other than AArch64. 2017-12-28 Richard Sandiford gcc/ * simplify-rtx.c

[0/4] Use new vector constant encoding for CONST_VECTOR

This series of patches converts CONST_VECTOR to use the same encoding scheme as VECTOR_CST. I'd originally being holding it back until the vec_perm series had been processed, but that was probably a mistake. The main difference from VECTOR_CST is that we still include all the elements for

[committed] [rs6000] Use gen_int_mode in ieee_128bit_negative_zero

Previously we'd generate a non-canonical zero-extended CONST_INT instead of a sign-extended one, which tripped the assert for canonical CONST_INTs after a later patch. Tested on powerpc64le-linux-gnu and installed as obvious. Richard 2017-12-28 Richard Sandiford

[committed] Use valid_for_const_vector_p instead of CONSTANT_P

This patch makes the VEC_SERIES code use valid_for_const_vector_p instead of CONSTANT_P, to match what we already do for VEC_DUPLICATE. This showed up as a failure in gcc.c-torture/execute/pr28982b.c for -m32 on x86_64-linux-gnu after later patches. Tested on aarch64-linux-gnu, x86_64-linux-gnu

RFA: Fix REG_ARGS_SIZE handling when pushing TLS addresses

Andreas Schwab writes: > On Dez 23 2017, Richard Sandiford wrote: >> gcc/ >> * expr.c (fixup_args_size_notes): Check that any existing >> REG_ARGS_SIZE notes are correct, and don't try to re-add them. >>

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

I applied the patch the trunk and confirmed that it doesn’t break any previously passing OpenCoarrays tests.  Is that sufficient or should I also try applying the  patch to the 7 branch? Damian

Re: [PATCH] PR fortran/83344 Don't set bogus constant value

On Thu, Dec 28, 2017 at 07:37:44PM +0200, Janne Blomqvist wrote: > This patch does not fix PR 83344, but merely fixes an error where we > used to set a constant character length value from a non-constant > expression, and thus set it to some bogus value. > > As a result of this, I have commented

[PATCH] PR fortran/83344 Don't set bogus constant value

This patch does not fix PR 83344, but merely fixes an error where we used to set a constant character length value from a non-constant expression, and thus set it to some bogus value. As a result of this, I have commented out part of the associate_22.f90 test which otherwise generates a warning

m68k: clear cc_status in ashrdi3_const1, lshrdi3_const1

The ashrdi3_const1 and lshrdi3_const1 insns don't produce a useful CC status. This fixes the 20_util/to_chars/1.cc test in the libstdc++ testsuite. Andreas. * config/m68k/m68k.md (ashrdi3_const1, lshrdi3_const1): Add CC_STATUS_INIT. diff --git a/gcc/config/m68k/m68k.md

Re: [libgomp, openacc, openmp, PR83046] Prune removed funcs from offload table

On Thu, Dec 28, 2017 at 05:06:57PM +0100, Jakub Jelinek wrote: > This has O(n^2) complexity for n == vec_safe_length (offload_funcs). > Can't you instead just have 2 IVs, one for where we read the vector elt and > one for where we write it if the 2 are different, then truncate the vector > if

Re: [libgomp, openacc, openmp, PR83046] Prune removed funcs from offload table

On Thu, Dec 28, 2017 at 04:53:29PM +0100, Tom de Vries wrote: > --- a/gcc/lto-cgraph.c > +++ b/gcc/lto-cgraph.c > @@ -,6 +,16 @@ output_offload_tables (void) >struct lto_simple_output_block *ob > = lto_create_simple_output_block (LTO_section_offload_table); > > + for (unsigned

[libgomp, openacc, openmp, PR83046] Prune removed funcs from offload table

Hi, Consider this openmp example: ... /* { dg-do link } */ #define N 100 int main () { int a[N]; int i, x; int c; c = 1; #pragma omp target for (i = 0; i < 100; i++) a[i] = 0; if (c) __builtin_unreachable (); #pragma omp target for (i = 0; i < 100; i++) a[i] = 1;

[PATCH] Fix gcc.target/i386/avx512vpopcntdqvl-vpopcnt*-1.c FAILs

Hi! Binutils had vpopcnt[dq] support since ~ January, but only for the 512-bit instructions, only in ~ October further support for the AVX512VPOPCNTDQ | AVX512VL instructions has been added. So, if one is using gas in between those two, these two tests FAIL to assemble. Fixed thusly (tests will

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

Hi all, as long as the computation where the token can be found is adapted in the same way, i.e. the token's offset in the derived type monitors the changed position, everything is fine. When I remember correctly, then this is done automatically by the routines setting up the caf_ref-chain for

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

Hi All, OK - I'll hold back until I hear from Damian & Zaak. Cheers Paul On 27 December 2017 at 21:06, Damian Rouson wrote: > > Thanks for the additional information Thomas. It sounds like I should test > Paul’s patch. I should be able to do so today and will

[PATCH] GFNI and misc other fixes (PR target/83604)

Hi! Martin reported sse-13.c ICEs without all the options it has in dg-options. The problem is that the GFNI builtins used incorrect ISA masks and the headers too. GFNI has one SSE encoded instruction (but that really needs SSE2 rather than SSE, because it uses V16QImode which is not enabled

[PATCH] Fix a vbmi2 ICE (PR target/83604)

Hi! These insns don't really need AVX512BW in any way themselves, only their masked variants might need it for reloading of the mask register, but that should be covered in builtins.def, doesn't need duplication in sse.md. For non-masked it causes ICEs, because the builtins properly aren't

[PATCH] Misc sse.md formatting fixes

Hi! I've noticed various formatting issues in the recently added ISA support patterns. No functional changes, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OT, wonder why we have any of the maskz and maskz_1 patterns, can't it be done in the intrinsic header by using the