[PATCH] improve -Wrestrict for struct members (PR 85753)

The attached patch extends -Wrestrict to constrain valid offset ranges into objects of struct types to the bounds of the object type, the same way the warning already handles arrays. This makes it possible to detect overlapping accesses in cases like the second call to memcpy below: char

C++ PATCH to oversized array handling

We weren't checking for arrays being too large in tsubst, which meant that we don't catch that problem as early as we would like. Fixed by calling valid_array_size_p from tsubst. Tested x86_64-pc-linux-gnu, applying to trunk. commit eba9af072d35ec8cc0840622e30a096401d306fb Author: Jason Merrill

[Committed] PR fortran/85542 -- Avoid NULL dereference

I've committed the attached patch. It checks for a valid pointer before using it. 2018-05-11 Steven G. Kargl PR fortran/85542 * expr.c (check_inquiry): Avoid NULL pointer dereference. 2018-05-11 Steven G. Kargl PR

Re: Replace FMA_EXPR with one internal fn per optab

On Fri, May 11, 2018 at 11:04 AM, Richard Sandiford wrote: > Andrew Pinski writes: >> On Fri, May 11, 2018 at 10:15 AM, Richard Sandiford >> wrote: >>> There are four optabs for various forms of fused multiply-add:

Re: Replace FMA_EXPR with one internal fn per optab

Andrew Pinski writes: > On Fri, May 11, 2018 at 10:15 AM, Richard Sandiford > wrote: >> There are four optabs for various forms of fused multiply-add: >> fma, fms, fnma and fnms. Of these, only fma had a direct gimple >> representation. For the

Re: Replace FMA_EXPR with one internal fn per optab

On Fri, May 11, 2018 at 10:15 AM, Richard Sandiford wrote: > There are four optabs for various forms of fused multiply-add: > fma, fms, fnma and fnms. Of these, only fma had a direct gimple > representation. For the other three we relied on special pattern- >

Replace FMA_EXPR with one internal fn per optab

There are four optabs for various forms of fused multiply-add: fma, fms, fnma and fnms. Of these, only fma had a direct gimple representation. For the other three we relied on special pattern- matching during expand, although tree-ssa-math-opts.c did have some code to try to second-guess what

Re: [libstdc++, PATCH] PR libstdc++/83140 - assoc_legendre returns negated value when m is odd.

which always causes a failure: +FAIL: tr1/5_numerical_facilities/special_functions/02_assoc_legendre/check_value.cc (test for excess errors) Excess errors: Undefined first referenced symbol in file main

Re: [Patch / RFC] Rename POINTER_TYPE_P to INDIRECT_TYPE_P ?

Hi, On 11/05/2018 17:06, Jakub Jelinek wrote: On Fri, May 11, 2018 at 10:42:13AM -0400, Jason Merrill wrote: On Fri, May 11, 2018 at 8:48 AM, Paolo Carlini wrote: we got this very old comment in tree.h: /* Nonzero if TYPE represents a pointer or reference type.

Re: [PATCH 0/2] Introduce gcc_qsort

> I meant "anti-commutativity"; sorry about the mixup. symmetry/antisymmetry is more appropriate for binary relations (commutativity is for binary operations). -- Eric Botcazou

[PATCH] consider offsets when handling nonstrings in -Wstringop-truncation (PR 85643)

The attached tweak suppresses some -Wstringop-truncation false positives when a pointer into an array declared nonstring is passed to a function that expects a string argument such as in: char a[8] __attribute__ ((nonstring)); strncpy (a + 1, s, sizeof a - 1); I'd like to commit this fix to

Re: [Patch / RFC] Rename POINTER_TYPE_P to INDIRECT_TYPE_P ?

On Fri, May 11, 2018 at 10:42:13AM -0400, Jason Merrill wrote: > On Fri, May 11, 2018 at 8:48 AM, Paolo Carlini > wrote: > > we got this very old comment in tree.h: > > > > /* Nonzero if TYPE represents a pointer or reference type. > >(It should be renamed to

Re: [Patch / RFC] Rename POINTER_TYPE_P to INDIRECT_TYPE_P ?

Hi, On 11/05/2018 16:42, Jason Merrill wrote: On Fri, May 11, 2018 at 8:48 AM, Paolo Carlini wrote: we got this very old comment in tree.h: /* Nonzero if TYPE represents a pointer or reference type. (It should be renamed to INDIRECT_TYPE_P.) Keep these checks

Re: [Patch / RFC] Rename POINTER_TYPE_P to INDIRECT_TYPE_P ?

On Fri, May 11, 2018 at 8:48 AM, Paolo Carlini wrote: > we got this very old comment in tree.h: > > /* Nonzero if TYPE represents a pointer or reference type. >(It should be renamed to INDIRECT_TYPE_P.) Keep these checks in >ascending code order. */ > > #define

Re: [libstdc++, PATCH] PR libstdc++/83140 - assoc_legendre returns negated value when m is odd.

Hi Ed, > On 05/10/2018 01:44 PM, Rainer Orth wrote: >> Hi Ed, >> > 2018-05-07  Edward Smith-Rowland  <3dw...@verizon.net> > > PR libstdc++/83140 - assoc_legendre returns negated value when m is > odd > * include/tr1/legendre_function.tcc (__assoc_legendre_p): Add

[arm] PR target/85733 Restore be8 linking behaviour for ARMv6-M and products deriving from its capabilities

My patch last year to automate passing the be8 flag to the linker had a nasty flaw in that I forgot entirely that the ARMv6-M architecture did not derive its capabilities directly from the ARMv6 capability list, but was a new group of capabilities (since it needs to leave out the ARM -- notm --

[PATCH][AArch64] Add combine pattern to fuse AESE/AESMC instructions

Hi all, When the AESE,AESD and AESMC, AESMC instructions are generated through the appropriate arm_neon.h intrinsics we really want to keep them together when the AESE feeds into an AESMC and fusion is supported by the target CPU. We have macro-fusion hooks and scheduling model forwarding

Re: [PATCH] Do not ICE for incomplete types in ICF (PR ipa/85607).

On 05/11/2018 11:35 AM, Richard Biener wrote: > On Thu, May 10, 2018 at 9:58 AM, Martin Liška wrote: >> Hi. >> >> It's removal of an assert at place where we calculate hash of a type. >> For incomplete types, let's skip it. >> >> Patch can bootstrap on x86_64-linux-gnu and

Re: [PATCH 1/2] gcc_qsort: source code changes

On Fri, 11 May 2018, Richard Biener wrote: > Looks good to me. As additional enhancement we might want to provide > (even unconditionally?) > the glibc qsort_r() interface. I remember adding various globals to > pass down state to the comparator... Thanks. I have no plans w.r.t qsort_r, but

Re: [PATCH GCC][4/6]Support regional coalesce and live range computation

On Fri, May 4, 2018 at 6:23 PM, Bin Cheng wrote: > Hi, > Following Jeff's suggestion, I am now using existing tree-ssa-live.c and > tree-ssa-coalesce.c to compute register pressure, rather than inventing > another live range solver. > > The major change is to record region's

[Patch / RFC] Rename POINTER_TYPE_P to INDIRECT_TYPE_P ?

Hi, we got this very old comment in tree.h: /* Nonzero if TYPE represents a pointer or reference type.    (It should be renamed to INDIRECT_TYPE_P.)  Keep these checks in    ascending code order.  */ #define POINTER_TYPE_P(TYPE) \   (TREE_CODE (TYPE) == POINTER_TYPE || TREE_CODE (TYPE) ==

Re: [PATCH 0/2] Introduce gcc_qsort

On Fri, May 11, 2018 at 03:03:09PM +0300, Alexander Monakov wrote: > On Fri, 11 May 2018, Segher Boessenkool wrote: > > > In general such address-based comparisons steps are invalid; they lack > > > anti-reflexivity. So comparators are not actually allowed to do that. > > > > I don't know what

Re: [PATCH GCC][3/6]Delete unnecessary function live_merge_and_clear

On Fri, May 4, 2018 at 6:22 PM, Bin Cheng wrote: > HI, > This is an obvious patch removing the unnecessary function. > > Bootstrap and test on x86_64 and AArch64 ongoing. Is it OK? OK. Richard. > Thanks, > bin > 2018-04-27 Bin Cheng > > *

Re: Fix PR85726 (div-div suboptimization) and a rant on match.pd :s-flag

On Fri, May 11, 2018 at 2:17 PM, Richard Biener wrote: > On Thu, May 10, 2018 at 1:41 AM, Hans-Peter Nilsson > wrote: > > [...] > > With all the followups this generated I'm still going to reply here. > >> Now a rant on the match.pd ":s"

Re: Fix PR85726 (div-div suboptimization) and a rant on match.pd :s-flag

On Thu, May 10, 2018 at 1:41 AM, Hans-Peter Nilsson wrote: [...] With all the followups this generated I'm still going to reply here. > Now a rant on the match.pd ":s" flag, which reasonable people > may reasonably suggest I should have used in the patch instead >

Re: Rb_tree constructor optimization

On 06/05/18 16:06 +0200, François Dumont wrote: Here is the rework of this patch. On 02/05/2018 13:49, Jonathan Wakely wrote: There's no changelog entry with the patch, so to recap, the changes are: - noexcept specifications are automatically deduced instead of being  stated explicitly. I

Re: [PATCH 0/2] Introduce gcc_qsort

On Fri, 11 May 2018, Segher Boessenkool wrote: > > In general such address-based comparisons steps are invalid; they lack > > anti-reflexivity. So comparators are not actually allowed to do that. > > I don't know what you mean here? Every comparator is required to be > *reflexive*! Subtracting

Re: [PATCH 1/2] gcc_qsort: source code changes

On Thu, May 10, 2018 at 5:56 PM, Alexander Monakov wrote: > * sort.cc: New file. > * system.h [!CHECKING_P] (qsort): Redirect to gcc_qsort. > * vec.c (qsort_chk): Use gcc_qsort. Looks good to me. As additional enhancement we might want to provide

Re: [PATCH 0/2] Introduce gcc_qsort

On Fri, May 11, 2018 at 01:35:00PM +0300, Alexander Monakov wrote: > On Fri, 11 May 2018, Segher Boessenkool wrote: > > For example from reload1.c: > > No, this example is not relevant, because ... > > > static int > > reload_reg_class_lower (const void *r1p, const void *r2p) > > { > > int r1

Re: [PATCH 0/2] Introduce gcc_qsort

On Fri, May 11, 2018 at 05:29:05AM -0500, Segher Boessenkool wrote: > Such a comparator will still work with temporary arrays if both elements > are always in the same temp array (in deterministic order, etc.) array; but > it won't work if the comparator did e.g. > > return (r1 - reload_order)

Re: [PATCH 0/2] Introduce gcc_qsort

On Fri, 11 May 2018, Segher Boessenkool wrote: > For example from reload1.c: No, this example is not relevant, because ... > static int > reload_reg_class_lower (const void *r1p, const void *r2p) > { > int r1 = *(const short *) r1p, r2 = *(const short *) r2p; > > // ... > > return r1 - r2;

Re: [PATCH 0/2] Introduce gcc_qsort

On Thu, May 10, 2018 at 07:40:57PM +0200, Richard Biener wrote: > On May 10, 2018 5:56:39 PM GMT+02:00, Alexander Monakov > wrote: > >/* This implements a sort function suitable for GCC use cases: > > - signature-compatible to C qsort, but relaxed contract: > > - may

Re: [PATCH, v2] Recognize a missed usage of a sbfiz instruction

Hi Luis, On 10/05/18 11:31, Luis Machado wrote: On 05/09/2018 10:44 AM, Kyrill Tkachov wrote: On 09/05/18 13:30, Luis Machado wrote: Hi Kyrill, On 05/08/2018 11:09 AM, Kyrill Tkachov wrote: Hi Luis, On 07/05/18 15:28, Luis Machado wrote: Hi, On 02/08/2018 10:45 AM, Luis Machado wrote:

Re: [PATCH] Do not ICE for incomplete types in ICF (PR ipa/85607).

On Thu, May 10, 2018 at 9:58 AM, Martin Liška wrote: > Hi. > > It's removal of an assert at place where we calculate hash of a type. > For incomplete types, let's skip it. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? Seems

[arm] PR target/85606 prefer armv6s-m for armv6-m parts

When Arm introduced ARMv6-M there were two variants, ARMv6-M and ARMv6S-M. The two differed only in support for the SVC instruction. Later on SVC was then made a mandatory part of ARMv6-M and the ARMv6S-M name was dropped. GCC and GAS, however still recognize both names and at least some

Re: [PATCH][arm] PR target/83687: Fix invalid combination of VSUB + VABS into VABD

On 17/01/18 11:51, Kyrill Tkachov wrote: Hi all, On 15/01/18 11:23, Kyrill Tkachov wrote: Hi all, In this wrong-code bug we combine a VSUB.I8 and a VABS.S8 into a VABD.S8 instruction . This combination is not valid for integer operands because in the VABD instruction the semantics are that

Re: [PATCH 2/2] gcc_qsort: build system changes

On Thu, May 10, 2018 at 5:56 PM, Alexander Monakov wrote: > * Makefile.in (OBJS-libcommon): Add sort.o. > (build/sort.o): New target. Use it... > (BUILD_RTL): ... here, and... > (build/gencfn-macros): ... here, and... >

Re: [PR 85655] Check is_single_const in intersect_with_plats

On Thu, May 10, 2018 at 3:59 PM, Martin Jambor wrote: > Hi, > > bug 85655 happens because intersect_with_plats encounters a BOTTOM > lattice and does not check for it. On closer inspection, the real check > that should be performed is is_single_const, so this patch adds it. > >

[PATCH] Constant fold even masked shift builtins

Hi! On top of the earlier 3 pending patches, this patch adds constant folding of the shifts even when the mask is not all ones (as long as the orig value argument is VECTOR_CST too). Then we can just do the blend according to the constant mask. Bootstrapped/regtested on x86_64-linux and

[committed] Fix OpenMP C/C++ default(none) handling (PR c/85696)

Hi! While we explicitly firstprivatize temporaries used in VLA size computations, if the VLAs are indirect (pointer to VLA) or struct element pointer to VLA etc., the temporaries are just handled using the default sharing. For C/C++ that works fine as long as default(none) isn't used, at which

Re: [PATCH] Use two source permute for vector initialization (PR 85692, take 2)

On Thu, 10 May 2018, Jakub Jelinek wrote: > On Wed, May 09, 2018 at 04:53:19PM +0200, Allan Sandfeld Jensen wrote: > > > > @@ -2022,8 +2022,9 @@ simplify_vector_constructor (gimple_stmt_iterator > > > > *gsi)> > > > >elem_type = TREE_TYPE (type); > > > >elem_size = TREE_INT_CST_LOW

[PATCH] PR gcc/84923 - gcc.dg/attr-weakref-1.c failed on aarch64

From: Vladimir Mezentsev When weakref_targets is not empty a target cannot be removed from the weak list. A small example is below when 'wv12' is removed from the weak list on aarch64: static vtype Wv12 __attribute__((weakref ("wv12"))); extern vtype wv12

Re: [PATCH 1/3] Add PTWRITE builtins for x86

On Fri, May 11, 2018 at 2:44 AM, Andi Kleen wrote: >> @@ -31325,7 +31329,21 @@ ix86_init_mmx_sse_builtins (void) >> continue; >> >>ftype = (enum ix86_builtin_func_type) d->flag; >> - def_builtin2 (d->mask, d->name, ftype, d->code); >> + decl =