On Apr 3, 2018, Jason Merrill wrote:
> On Tue, Apr 3, 2018 at 11:47 AM, Jason Merrill wrote:
>> On Tue, Apr 3, 2018 at 3:44 AM, Alexandre Oliva wrote:
>>> + if ((complain & tf_conv))
>>> +return false;
>> I think we want to return true.
Yeah, it doesn't work at all returning false.
>
On Tue, Apr 3, 2018 at 11:47 AM, Jason Merrill wrote:
> On Tue, Apr 3, 2018 at 3:44 AM, Alexandre Oliva wrote:
>> On Apr 2, 2018, Jason Merrill wrote:
>>
>>> On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
On Mar 30, 2018, Jason Merrill wrote:
> I don't think we need thi
On Tue, Apr 3, 2018 at 3:44 AM, Alexandre Oliva wrote:
> On Apr 2, 2018, Jason Merrill wrote:
>
>> On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
>>> 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
On Apr 2, 2018, Jason Merrill wrote:
> On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
>> 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 singl
On Sat, Mar 31, 2018 at 2:24 AM, Alexandre Oliva wrote:
> 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
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 got there.
As a bo
On Fri, Mar 30, 2018 at 3:48 AM, Alexandre Oliva wrote:
> On Mar 29, 2018, Alexandre Oliva wrote:
>
>> Here's a patch that should take care of the marking a namespace-scoped
>> or static member function as used when taking its address, thus working
>> around (fixing?) the reported problem.
>
>> R
On Mar 29, 2018, Alexandre Oliva wrote:
> Here's a patch that should take care of the marking a namespace-scoped
> or static member function as used when taking its address, thus working
> around (fixing?) the reported problem.
> Regstrapping now. Ok to install if it passes?
It regressed overl
On Mar 29, 2018, Alexandre Oliva wrote:
> On Mar 28, 2018, Jason Merrill wrote:
>> It looks like cp_build_addr_expr_1 already calls mark_used for single
>> static member functions, it should probably do the same for single
>> non-member functions.
> ultimately select, *if* we marked anything.
On Mar 28, 2018, Jason Merrill wrote:
> It looks like cp_build_addr_expr_1 already calls mark_used for single
> static member functions, it should probably do the same for single
> non-member functions.
Hmm... That existing call is suspicious, now that you point it out.
There's a switch before
On Wed, Mar 28, 2018 at 2:18 AM, Alexandre Oliva wrote:
> On Mar 23, 2018, Jason Merrill wrote:
>
>> On Fri, Mar 23, 2018 at 4:55 PM, Jason Merrill wrote:
>>> On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote:
Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null.
>>>
On Mar 23, 2018, Jason Merrill wrote:
> On Fri, Mar 23, 2018 at 4:55 PM, Jason Merrill wrote:
>> On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote:
>>> Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null.
>>
>> Did you try this? That should avoid it being ADDR_EXPR of
On Fri, Mar 23, 2018 at 4:55 PM, Jason Merrill wrote:
> On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote:
>> Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null.
>
> Did you try this? That should avoid it being ADDR_EXPR of a decl.
Oh, I was assuming the ICE was in the
On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote:
> Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null.
Did you try this? That should avoid it being ADDR_EXPR of a decl.
Jason
On Mar 23, 2018, Jason Merrill wrote:
> On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
>> fn[0]() ICEs because we end up with addr_expr of a decl, and that
>> should only happen for artificial or otherwise special internal
>> functions. For anything else, we should find the decl earlie
On Fri, Mar 23, 2018 at 12:17 PM, Alexandre Oliva wrote:
> On Mar 23, 2018, Jason Merrill wrote:
>
>> On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
>>> fn[0]() ICEs because we end up with addr_expr of a decl, and that
>>> should only happen for artificial or otherwise special internal
On Mar 23, 2018, Jason Merrill wrote:
> On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
>> fn[0]() ICEs because we end up with addr_expr of a decl, and that
>> should only happen for artificial or otherwise special internal
>> functions. For anything else, we should find the decl earlie
On Thu, Mar 22, 2018 at 7:00 PM, Alexandre Oliva wrote:
> fn[0]() ICEs because we end up with addr_expr of a decl, and that
> should only happen for artificial or otherwise special internal
> functions. For anything else, we should find the decl earlier, but we
> don't because we build an indirec
fn[0]() ICEs because we end up with addr_expr of a decl, and that
should only happen for artificial or otherwise special internal
functions. For anything else, we should find the decl earlier, but we
don't because we build an indirect_ref or an addr_expr and don't
cancel them out. Let fold do its
19 matches
Mail list logo
