Re: [PATCH] Improve avx512{f,bw} vec_set (PR middle-end/85090)

2018-03-31 Thread Kirill Yukhin
> On 31 Mar 2018, at 01:50, Jakub Jelinek wrote: > Hi! > > The code we emit on the following testcases is really terrible, with both > -mavx512f -mno-avx512bw as well as -mavx512bw, rather than doing e.g. >vpinsrw $0, %edi, %xmm0, %xmm1 >vinserti32x4$0,

Re: [PATCH, committed] Update my MAINTAINERS entries

2018-03-31 Thread Gerald Pfeifer
On Fri, 30 Mar 2018, Bill Schmidt wrote: > Just updating my email address and making it a little clearer which > is which between Will Schmidt and me. Committed. Actually you can (should) remove your entry from Write after Approval since you are now listed in one of the previous sections

Re: [patch, fortran] Simplify constants which come from parameter arrays

2018-03-31 Thread Thomas König
Hi Dominique, If I am not mistaken, the patch causes: FAIL: gfortran.dg/pr71935.f90 -O (test for excess errors) FAIL: gfortran.dg/substr_6.f90 -O0 execution test FAIL: gfortran.dg/substr_6.f90 -O1 execution test FAIL: gfortran.dg/substr_6.f90 -O2 execution test FAIL:

Re: [PATCH] [PR c++/85039] no type definitions in builtin offsetof

2018-03-31 Thread Alexandre Oliva
On Mar 30, 2018, Jason Merrill wrote: > On Fri, Mar 30, 2018 at 3:55 AM, Alexandre Oliva wrote: >> Types defined within a __builtin_offsetof argument don't always get >> properly recorded as members of their context types >> I suppose this means I should

Re: [PATCH] [PR c++/84979] improve auto handling in explicit tmpl args for concepts

2018-03-31 Thread Alexandre Oliva
On Mar 30, 2018, Jason Merrill wrote: > True, it looks like sometimes we build a TEMPLATE_ID_EXPR with an > IDENTIFIER_NODE. Looking at tsubst_copy_and_build, I see that we > don't call finish_id_expression when substituting such a > TEMPLATE_ID_EXPR. So maybe

Re: [PATCH] [PR c++/84943] allow folding of array indexing indirect_ref

2018-03-31 Thread Alexandre Oliva
On Mar 30, 2018, Jason Merrill wrote: > I don't think we need this; if arg is overloaded, we take the > type_unknown_p early exit, so the code lower down is always dealing > with a single function. Aah, that's why it seemed to me that we had already resolved overloads when we