[Patches] Add variant constexpr support for visit, comparisons and get

This 4-patch series contains the following in order: a.diff: Remove uses-allocator ctors. They are going away, and removing it reduces the maintenance burden from now on. b.diff: Add constexpr support for get<> and comparisons. This patch also involves small refactoring of _Variant_storage.

Re: [PATCH] avoid calling alloca(0)

On 11/25/2016 12:51 PM, Jeff Law wrote: On 11/23/2016 06:15 PM, Martin Sebor wrote: gcc_assert works only in some instances (e.g., in c-ada-spec.c:191) but not in others because some actually do make the alloca(0) call at runtime: at a minimum, lto.c:3285, reg-stack.c:2008, and

Re: [PATCH] improve folding of expressions that move a single bit around

On Sat, Nov 26, 2016 at 11:22:44PM +0100, Paolo Bonzini wrote: > The combine.c hunk instead is needed to simplify cases that do not use the > ternary operator (the "h" and "i" functions in the testcases) like this: > > return ((x >> 9) & 1) << 7; > > Normally this is simplified just fine

[PATCH] Partial solution to LWG 523

Also see discussions from libstdc++/71500. Bootstrapped and tested on x86_64-linux-gnu. Thanks! -- Regards, Tim Shen commit 6c862a2b84578a651d458b09572551c8391082e4 Author: Tim Shen Date: Sat Nov 26 12:36:20 2016 -0800 2016-11-26 Tim Shen

Re: [PATCH] improve folding of expressions that move a single bit around

On Sat, 26 Nov 2016, Paolo Bonzini wrote: --- match.pd(revision 242742) +++ match.pd(working copy) @@ -2554,6 +2554,19 @@ (cmp (bit_and@2 @0 integer_pow2p@1) @1) (icmp @2 { build_zero_cst (TREE_TYPE (@0)); }))) +/* If we have (A & C) != 0 ? D : 0 where C and D are powers of 2, +

[PATCH] simplify-rtx: Handle truncate of extract

simplify_truncation changes the truncation of many operations into the operation on the truncation. This patch makes this code also handle extracts. Tested on powerpc64-linux. With this patch the rlwimi testcases work. Is this okay for trunk? Segher --- gcc/simplify-rtx.c | 30

Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

On Sat, 26 Nov 2016, Allan Sandfeld Jensen wrote: Use the recently introduced unaligned variant of __m128i and add a similar __m64 and use those to make it clear these two intrinsics require neither 128- bit nor 64-bit alignment. Thanks for doing this. You'll want Uros or Kirill to review

[PATCH] combine: Tweak change_zero_ext

change_zero_ext handles (zero_extend:M1 (subreg:M2 (reg:M1) ...)) already; this patch extends it to also deal with any (zero_extend:M1 (subreg:M2 (reg:M3) ...)) where the subreg is not paradoxical. Tested on powerpc64-linux. This is needed for some of the rlwimi testcases to be optimised

[PATCH] improve folding of expressions that move a single bit around

In code like the following from KVM: /* it is a read fault? */ error_code = (exit_qualification << 2) & PFERR_FETCH_MASK; it would be nicer to write /* it is a read fault? */ error_code = (exit_qualification & VMX_EPT_READ_FAULT_MASK) ? PFERR_FETCH_MASK : 0;

[Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64

Use the recently introduced unaligned variant of __m128i and add a similar __m64 and use those to make it clear these two intrinsics require neither 128- bit nor 64-bit alignment. `Allan Index: gcc/config/i386/emmintrin.h === ---

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On Sat, Nov 26, 2016 at 09:15:48AM -0700, Jeff Law wrote: > On 11/26/2016 04:11 AM, Eric Botcazou wrote: > >> From my investigations on the m68k, the effects on the IL are minimal > >>with a slight bias towards better code (by suppressing if-conversions of > >>some now more costly blocks). *But*

[PATCHv3] [AARCH64] Add variant support to -m="native"and add thunderxt88p1.

On Tue, Nov 1, 2016 at 11:08 AM, Andrew Pinski wrote: > On Tue, Nov 17, 2015 at 2:10 PM, Andrew Pinski wrote: >> Since ThunderX T88 pass 1 (variant 0) is a ARMv8 part while pass 2 (variant >> 1) >> is an ARMv8.1 part, I needed to add detecting of the

Re: Documentation of LTIME

>> If not, we definitely need to fix the documentation of LTIME, since >> the current version simply does not work with TIME8(), unless one uses >> -fdefault-integer-8 (which is not mentioned in the docu). > > What about the attached patch Yes, looks good to me. Ok to commit! One minor nit

Re: Documentation of LTIME

> Still, since we internally already have both implementations for > kind=4 and kind=8, we could as well make use of them, I guess. I let this for people understanding what to do. > If not, we definitely need to fix the documentation of LTIME, since > the current version simply does not work

Re: [PATCH] Fix a couple of issues in gimple-ssa-sprintf.c

On 11/25/2016 10:20 AM, Jakub Jelinek wrote: Hi! Here is an attempt to fix a couple of bugs in gimple-ssa-sprintf.c. First of all, it assumes size_t is always the same as uintmax_t, which is not necessarily the case. Second, it uses static tree {,u}intmax_type_node; variables for caching those

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

2016-11-26 17:37 GMT+01:00 Dominique d'Humières : > >> Le 26 nov. 2016 à 10:45, Janus Weil a écrit : >> >> ping! >> > The patch is working has expected. Note the removed block has been introduced > by Daniel Franke at r126826. Right, thanks for the

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On Sat, Nov 26, 2016 at 03:44:22AM -0700, Jeff Law wrote: > On 11/24/2016 03:32 PM, Segher Boessenkool wrote: > >On Thu, Nov 24, 2016 at 10:14:24AM -0600, Segher Boessenkool wrote: > >>On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote: > >>>On 11/24/2016 07:53 AM, Segher Boessenkool wrote:

Re: Documentation of LTIME

Well LTIME cannot accept both kind(4) and kind(8) arguments. The reference to TIME8 looks like a mistake, isn’t it? >>> >>> Huh, in libgfortran I see two versions with different kinds (ltime_i4 >>> and ltime_i8), but in my tests I never get LTIME to work with kind=8 >>> arguments. I

Re: Documentation of LTIME

On Sat, Nov 26, 2016 at 7:03 PM, Janus Weil wrote: > 2016-11-26 17:58 GMT+01:00 Janus Weil : * possibly add some more cross-links to intrinsic.texi >>> >>> Could you please elaborate? >> >> I just mean it might be useful to add some more links from LTIME

Re: Documentation of LTIME

2016-11-26 17:58 GMT+01:00 Janus Weil : >>> * possibly add some more cross-links to intrinsic.texi >> >> Could you please elaborate? > > I just mean it might be useful to add some more links from LTIME to > ITIME, IDATE and DATE_AND_DATE (and back?). They are are all very >

Re: Documentation of LTIME

>> * possibly add some more cross-links to intrinsic.texi > > Could you please elaborate? I just mean it might be useful to add some more links from LTIME to ITIME, IDATE and DATE_AND_DATE (and back?). They are are all very similar. >> And one last point: The description of LTIME mentions

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

> Le 26 nov. 2016 à 10:45, Janus Weil a écrit : > > ping! > The patch is working has expected. Note the removed block has been introduced by Daniel Franke at r126826. Dominique.

Re: Documentation of LTIME

> Le 26 nov. 2016 à 17:00, Janus Weil a écrit : > > And one last point: The description of LTIME mentions TIME8, but if I try > this: > > call ltime(time8(), values) > > I get: > > Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4 Well LTIME cannot

Re: Documentation of LTIME

> Le 26 nov. 2016 à 16:54, Janus Weil a écrit : > > 2016-11-26 16:49 GMT+01:00 Dominique d'Humières : >> If there is no objection, I’ll commit the following patch > > Looks good to me! > > If you want, you could also fix the remaining items I mentioned

Re: Documentation of LTIME

Dominique, your patch sounds good to me. 2016-11-26 16:49 GMT+01:00 Dominique d'Humières : > If there is no objection, I’ll commit the following patch > > --- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0 > +0100 > +++ gcc/fortran/intrinsic.texi

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On 11/26/2016 04:11 AM, Eric Botcazou wrote: From my investigations on the m68k, the effects on the IL are minimal with a slight bias towards better code (by suppressing if-conversions of some now more costly blocks). *But* the size of the resulting code was all over the place -- sometimes it

Re: Documentation of LTIME

And one last point: The description of LTIME mentions TIME8, but if I try this: call ltime(time8(), values) I get: Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4 So maybe the reference to TIME8 should be replaced by TIME? Cheers, Janus 2016-11-26 16:54 GMT+01:00

Re: Documentation of LTIME

2016-11-26 16:49 GMT+01:00 Dominique d'Humières : > If there is no objection, I’ll commit the following patch Looks good to me! If you want, you could also fix the remaining items I mentioned in comment 1 in the PR: * apply the same fix to GMTIME * fix it in the libgfortran

Re: Documentation of LTIME

If there is no objection, I’ll commit the following patch --- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0 +0100 +++ gcc/fortran/intrinsic.texi 2016-11-26 16:47:12.0 +0100 @@ -9663,11 +9663,11 @@ The elements of @var{VALUES} are assigne seconds @item

Re: [v3 PATCH] LWG 2766, LWG 2749

On 22 November 2016 at 17:06, Jonathan Wakely wrote: >> so I can certainly change all these swaps to use operator! rather than >> __not_. Is the >> patch otherwise ok for trunk? What about the tuple part? > > > Yes, OK changing the top-level __not_s to operator! > I haven't

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

> From my investigations on the m68k, the effects on the IL are minimal > with a slight bias towards better code (by suppressing if-conversions of > some now more costly blocks). *But* the size of the resulting code was > all over the place -- sometimes it was better, others worse. From >

Re: change initialization of ptrdiff_type_node

On 25 November 2016 at 14:48, Richard Biener wrote: > On Fri, 25 Nov 2016, Prathamesh Kulkarni wrote: > >> On 25 November 2016 at 13:43, Richard Biener wrote: >> > On Fri, 25 Nov 2016, Jakub Jelinek wrote: >> > >> >> On Fri, Nov 25, 2016 at 01:28:06PM +0530,

Re: [0/3] Fix PR78120, in ifcvt/rtlanal/i386.

On 11/24/2016 03:32 PM, Segher Boessenkool wrote: On Thu, Nov 24, 2016 at 10:14:24AM -0600, Segher Boessenkool wrote: On Thu, Nov 24, 2016 at 08:48:04AM -0700, Jeff Law wrote: On 11/24/2016 07:53 AM, Segher Boessenkool wrote: That we compare different kinds of costs (which really has no

Re: [Patch, Fortran] PR 78392: ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:5979

ping! 2016-11-19 10:12 GMT+01:00 Janus Weil : > Hi all, > >> I previously assumed that the test case for this PR would be legal, >> but by now I think that's wrong. The test case should be rejected, and >> we already have checking mechanisms for this (see >>

[PATCH v2] libgcc/mkmap-symver: support skip_underscore (PR74748)

Hi, Some platforms, such as Blackfin, have a special prefix for assembly symbols as opposed to C symbols. For this reason, a function named "foo()" in C will in fact be visible as a symbol called "_foo" in the ELF binary. The current linker version script logic in libgcc doesn't take into