Re: [patch, fortran] PR66461 ICE on missing end program in fixed source

On 05/22/2016 04:53 AM, Andre Vehreschild wrote: > Hi Jerry, > > I have tested your patch and gave it a review and the only thing I like > to have is a testcase. Can you provide one from the PR? With a testcase > I say the patch is ok for trunk and thanks for the patch. > > Please note, I don't

Re: [RFC] Type promotion pass and elimination of zext/sext

Hi Richard, > So what does this mean for this pass? It means that we need to think > about the immediate goal we want to fulfil - which might be to just > promote things that we can fully promote, avoiding the necessity to > prevent passes from undoing our work. That said - we need a set of >

Re: [RFC] Type promotion pass and elimination of zext/sext

Hi Jeff, On 20 May 2016 at 04:17, Jeff Law wrote: > On 05/15/2016 06:45 PM, Kugan Vivekanandarajah wrote: >> >> Hi Richard, >> >> Now that stage1 is open, I would like to get the type promotion passes >> reviewed again. I have tested the patches on aarch64, x86-64, and >>

Re: [PATCH] Fix ICE with x87 asm operands (PR inline-asm/68843)

On Sun, May 22, 2016 at 9:00 AM, Bernd Edlinger wrote: > Hi! > > as described in the PR there are several non-intuitive rules that > one has to follow to avoid ICEs with x87 asm operands. > > This patch adds an explicit rule, that avoids ICE in the first test case and >

[C++ Patch] PR 69095

Hi, finally sending a patch for this issue. As noticed by submitter himself, it appears to boil down to a rather straightforward case of not rejecting unexpanded parameter packs in default arguments. In order to handle all the combinations (in/out of class, template parameter/function

match.pd: Relax some tree_nop_conversion_p

Hello, this patch replaces some tree_nop_conversion_p tests with less restrictive conditions. In some cases I checked the transformation automatically (of course I could have messed up the checker, or the translation). I didn't always put the laxest possible check. For instance the

Re: [PATCH] Fix up a few i386 tests

On Sat, May 21, 2016 at 7:16 PM, Jakub Jelinek wrote: > Hi! > > While trying to look for bugs using the > https://sourceware.org/ml/binutils/2016-05/msg00328.html > hacks, in order to achive more testing I've also turned all > dg-do compile tests into dg-do assemble, so that

Re: [PATCH] Use flag_general_regs_only with -mgeneral-regs-only

On Sat, May 21, 2016 at 9:48 AM, Uros Bizjak wrote: > On Fri, May 20, 2016 at 7:49 PM, H.J. Lu wrote: >> On Fri, May 20, 2016 at 10:15 AM, Rainer Orth >> wrote: >>> "H.J. Lu" writes: >>> On Thu,

[fortran, patch, pr69659, v1] [6/7 Regression] ICE on using option -frepack-arrays, in gfc_conv_descriptor_data_get

Hi all, attached patch fixes a regression that occurred on some testcases when doing a validation run with -frepack-arrays. The issue here was that for class arrays the array descriptor is in the _data component and not directly at the address of the class_array. The patch fixes this issue for

[C++ Patch] Improve check_for_bare_parameter_packs location

Hi, I'm finally completing a candidate fix for c++/69095 and I noticed that in order to get function parameters (not just template parameters, as originally reported) right it's important that the location used by check_for_bare_parameter_packs is (more) accurate. But the below seems

Debug iterator cleanup

Hi I just want to make sure that you agree that I can remove the @todo by implementing operator-> this way. * include/debug/safe_iterator.h (_Safe_iterator<>::operator->()): Implement using underlying iterator operator ->. * include/debug/safe_local_iterator.h

PR 71181 Avoid rehash after reserve

Hi To fix 71181 problem I propose to change how we deal with reserve called with pivot values that is to say prime numbers. Now _M_next_bkt always return a value higher than the input value. This way when reverse(97) is called we end up with 199 buckets and so enough space to store 97

Re: [patch, fortran] PR66461 ICE on missing end program in fixed source

Hi Jerry, I have tested your patch and gave it a review and the only thing I like to have is a testcase. Can you provide one from the PR? With a testcase I say the patch is ok for trunk and thanks for the patch. Please note, I don't have review rights in the area the patch addresses, although I

Re: [PATCH] Make basic asm implicitly clobber memory

On 05/20/2016 07:50 AM, David Wohlferd wrote: > At a minimum, suddenly forcing an unexpected/unneeded memory clobber > can adversely impact the optimization of surrounding code. This can > be particularly annoying if the reason for the asm was to improve > performance. And adding a memory

Re: [PATCH] Fix up vec_set_* for -mavx512vl -mno-avx512dq

Hello, On 18 May 23:03, Jakub Jelinek wrote: > Hi! > > The vinsert[if]64x2 instructions are AVX512VL & AVX512DQ, so > if only AVX512VL is on, we should emit the other insns - 32x4, > which without masking do the same thing. > With masking, we have to require TARGET_AVX512DQ. > >

Re: [PATCH] Improve XMM16+ handling in vec_set*

Hello, On 18 May 23:01, Jakub Jelinek wrote: > Hi! > > vinserti32x4 is in AVX512VL. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. > > 2016-05-18 Jakub Jelinek > > * config/i386/sse.md (vec_set_lo_v16hi, vec_set_hi_v16hi, >

Re: [PATCH] Improve 128-bit to 256-bit broadcasts

Hi Jakub, On 18 May 23:00, Jakub Jelinek wrote: > Hi! > > vbroadcast[fi]32x4 and vinsert[fi]32x4 are in AVX512VL, > vbroadcast[fi]64x2 and vinsert[fi]64x2 are in AVX512VL & AVX512DQ. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. > > 2016-05-18 Jakub Jelinek

Re: [PATCH] Improve XMM16-31 handling in various *vec_dup* patterns

Hello Jakub, On 18 May 22:58, Jakub Jelinek wrote: > Hi! > > These instructions are available in AVX512VL, so we can use > XMM16+ in there. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. > > 2016-05-18 Jakub Jelinek > > *

[PATCH] Fix ICE with x87 asm operands (PR inline-asm/68843)

Hi! as described in the PR there are several non-intuitive rules that one has to follow to avoid ICEs with x87 asm operands. This patch adds an explicit rule, that avoids ICE in the first test case and removes an unnecessary error message in the second test case. Boot-strapped and