> 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,
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
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:
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
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
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