Re: [PATCH, fortran, v4] Use Levenshtein spelling suggestions in Fortran FE

[forgot to CC gcc-patches] On Sat, Jun 18, 2016 at 09:58:47PM +0200, Bernhard Reutner-Fischer wrote: > Hi, > > Ok for trunk? This was ACKed about a year ago by Janne and Jerry and since there were no objections in the meantime i've installed this first step towards providing spelling

[committed] Fix ICE with F2008 BLOCK inside of !$OMP PARALLEL (PR fortran/82568)

Hi! As OpenMP 4.5 supports only F2003 and earlier, this is strictly speaking code with unspecified behavior, but we shouldn't ICE on it, so if we find a sequential loop iterator inside of BLOCK inside of parallel or task generating construct, and the loop iterator is explicitly or implicitly

Re: [PATCH] Do not instrument use-after-scope for vars with large alignment (PR sanitizer/82517).

On Thu, Oct 19, 2017 at 09:21:47AM +0200, Martin Liška wrote: > Hi. > > As discussed with Jakub, use-after-scope sanitization should not be done for > variables that have bigger > alignment than MAX_SUPPORTED_STACK_ALIGNMENT. In this case, we can't put a > variable to fixed stack slot. > >

[PATCH] Do not instrument use-after-scope for vars with large alignment (PR sanitizer/82517).

Hi. As discussed with Jakub, use-after-scope sanitization should not be done for variables that have bigger alignment than MAX_SUPPORTED_STACK_ALIGNMENT. In this case, we can't put a variable to fixed stack slot. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready

Re: [RFA] Zen tuning part 9: Add support for scatter/gather in vectorizer costmodel

Hi, this is proof of concept patch for vectorizer costs to use costs used for rtx_cost and register_move_cost which are readily available in ix86_costs instead of using its own set of random values. At least until we have proof of evidence that vectroizer costs needs to differ, I do not think

Re: [PATCH PR/82546] tree node size

> On 18 Oct 2017, at 15:59, Eric Botcazou wrote: > >> I'd think so. LANG_TYPE is treated specially in several >> places and Ada debug types are pretty sensitive so this would >> require caution but I don't see/know-of obvious reasons why this >> couldn't be done. > >

<    1   2