[Committed 2/2] S/390: Fix zvector vec_double builtin

The (unsigned) long int to double vector conversion instructions expect 2 immediate parameters. One for the inexact suppression control and another one for the rounding mode. However, the vec_double builtin has just the vector source operand. The 2 addtional operands need to be added with an

[libgomp, nvptx] Fix libgomp.c/target-5.c compilation

[ was: Re: [libgomp, nvptx] Disable OMP_{DISPLAY_AFFINITY,AFFINITY_FORMAT} support ] On 12-12-18 14:15, Jakub Jelinek wrote: > On Wed, Dec 12, 2018 at 02:02:20PM +0100, Tom de Vries wrote: >> This RFC patch implements that approach for getpid and gethostname (I >> wonder though whether it's not

Re: [PATCH][PR84877]Dynamically align the address for local parameter copy on the stack when required alignment is larger than MAX_SUPPORTED_STACK_ALIGNMENT

> 2018-03-22 Renlin Li > > PR middle-end/84877 > * explow.h (get_dynamic_stack_size): Declare it as external. > * explow.c (record_new_stack_level): Remove function static attribute. > * function.c (assign_stack_local_1): Dynamically align the stack slot > addr

Re: [PATCH, rs6000] Allow libitm to use HTM on newer hw and kernels

On Wed, Dec 12, 2018 at 06:55:14PM -0600, Peter Bergner wrote: > On 12/12/18 2:52 PM, Segher Boessenkool wrote: > >> +/* This is a fairly new feature bit, so handle it not being defined. */ > >> +#ifndef PPC_FEATURE2_HTM_NO_SUSPEND > >> +# define PPC_FEATURE2_HTM_NO_SUSPEND 0 > >> +#endif > > >

Re: [PATCH] PR libstdc++/80762 avoid ambiguous __constructible_from

On 13/12/18 08:56 +0100, Christophe Lyon wrote: On Wed, 12 Dec 2018 at 17:13, Jonathan Wakely wrote: Ensure we don't try to instantiate __is_constructible_from, because there are two partial specializations that are equally good matches. PR libstdc++/80762 *

Re: [PATCH][AArch64][doc] Clarify -msve-vector-bits=128 behaviour

On Thu, Dec 13, 2018 at 10:15 AM Richard Sandiford wrote: > > Thanks for doing this. > > "Kyrill Tkachov" writes: > > @@ -15716,16 +15716,19 @@ an effect when SVE is enabled. > > > > GCC supports two forms of SVE code generation: ``vector-length > > agnostic'' output that works with any size

Re: [PATCH] OpenACC 2.6 manual deep copy support (attach/detach)

On Mon, Dec 10, 2018 at 07:41:37PM +, Julian Brown wrote: > @@ -11870,7 +11874,8 @@ c_parser_oacc_wait_list (c_parser *parser, location_t > clause_loc, tree list) > static tree > c_parser_omp_variable_list (c_parser *parser, > location_t clause_loc, > -

Re: [RS6000] Don't pass -many to the assembler

On Wed, Nov 14, 2018 at 01:43:57PM +1030, Alan Modra wrote: > On Tue, Nov 13, 2018 at 05:17:41AM -0600, Segher Boessenkool wrote: > > On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote: > > > OK, fair enough. Another option is to just disable -many when gcc is > > > in development, like

Re: [PATCH 4/6, OpenACC, libgomp] Async re-work, libgomp/target.c changes (revised, v2)

On Tue, Dec 11, 2018 at 09:47:10PM +0800, Chung-Lin Tang wrote: > I have revised the patch to make both gomp_[un]map_vars and > gomp_[un]map_vars_async > point to gomp_[un]map_vars_internal, which is static always_inline. This > should > alleviate that part of the concerns. > @@ -263,8 +279,9

Re: [PATCH][AArch64][doc] Clarify -msve-vector-bits=128 behaviour

Thanks for doing this. "Kyrill Tkachov" writes: > @@ -15716,16 +15716,19 @@ an effect when SVE is enabled. > > GCC supports two forms of SVE code generation: ``vector-length > agnostic'' output that works with any size of vector register and > -``vector-length specific'' output that only

Re: [PATCH v2 6/7] Remaining support for clobber high

On Thu, Jul 26, 2018 at 10:13:28AM +0100, Alan Hayward wrote: > --- a/gcc/rtl.c > +++ b/gcc/rtl.c > @@ -304,6 +304,10 @@ copy_rtx (rtx orig) > return orig; >break; > > +case CLOBBER_HIGH: > + gcc_assert (REG_P (XEXP (orig, 0))); > + return orig; Wrong formatting

Re: [testsuite] Include gdc.test prefix in test names (PR testsuite/88041)

On Thu, 13 Dec 2018 at 10:16, Rainer Orth wrote: > > As reported in the PR, the test names of DejaGnu tests should be the > path relative to the respective testsuite directory, a convention the > gdc.test tests currently don't follow. > > The patch below fixes this. After a few false starts

Re: RFA: libiberty: Add a limit on demangling qualifiers (PR 87241)

Hi Jason, > This issue also will be resolved by disabling or removing the old > demangling code, which I haven't seen anyone argue against. Doh - of course. I withdraw my patch and I hope that yours will go in soon. Cheers Nick

Re: RFA: libiberty: Add a limit on demangling qualifiers (PR 87241) (version 2)

Hi Ian, > I thought we were removing the old demangling schemes? Doh! yes, I totally forgot. So I will withdraw this patch in favour of Jason's. Cheers Nick

[PATCH][AArch64][doc] Clarify -msve-vector-bits=128 behaviour

Hi all, We've received reports about the -msve-vector-bits=128 bits being somewhat ambiguous. It isn't clear whether -msve-vector-bits=128 forces vector-length-agnostic code or whether -msve-vector-bits=scalable forces 128-bit vector-lengh-specific code. The latter is a, perhaps unintuitive,

[testsuite] Include gdc.test prefix in test names (PR testsuite/88041)

As reported in the PR, the test names of DejaGnu tests should be the path relative to the respective testsuite directory, a convention the gdc.test tests currently don't follow. The patch below fixes this. After a few false starts (some described in the PR and several more) I came up with the

Re: [PATCH] Allow direct 0 and -1 moves to mask registers (PR target/88465)

On Wed, Dec 12, 2018 at 11:38 PM Jakub Jelinek wrote: > > Hi! > > As mentioned in the PR, we can use kxor? %kN, %kN, %kN or > kxnor? %kN, %kN, %kN to set %kN to 0 or -1, instead of > setting a GPR to that and moving to the mask register. > > Bootstrapped/regtested on x86_64-linux and i686-linux,

<    1   2