On Tue, Apr 24, 2018 at 12:31 PM, Nathan Sidwell wrote:
> On 04/23/2018 01:19 PM, Jason Merrill wrote:
>>
>> On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell
>
>> I have to change convert_ptrmem to always
>> expand the constant (into an OFFSET_TYPE) so that
>> initializer_constant_valid_
Now with added patchy goodness.
On 04/24/2018 12:31 PM, Nathan Sidwell wrote:
On 04/23/2018 01:19 PM, Jason Merrill wrote:
On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell
I have to change convert_ptrmem to always
expand the constant (into an OFFSET_TYPE) so that
initializer_constant
On 04/23/2018 01:19 PM, Jason Merrill wrote:
On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell
I have to change convert_ptrmem to always
expand the constant (into an OFFSET_TYPE) so that
initializer_constant_valid_p (used by reduced_constant_expression_p)
doesn't get confused by a z
On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell wrote:
> On 04/20/2018 01:44 PM, Jason Merrill wrote:
>
> > Any time we need an actual adjustment, there will be a PLUS_EXPR. The
> > issue is somehow distinguishing between a reinterpret_cast and one of
> > the many other sources of NOP_EXPR.
>
> yea
On Fri, Apr 20, 2018 at 02:52:32PM -0400, Nathan Sidwell wrote:
> On 04/20/2018 01:44 PM, Jason Merrill wrote:
>
> > Any time we need an actual adjustment, there will be a PLUS_EXPR. The
> > issue is somehow distinguishing between a reinterpret_cast and one of
> > the many other sources of NOP_EXP
On 04/20/2018 01:44 PM, Jason Merrill wrote:
Any time we need an actual adjustment, there will be a PLUS_EXPR. The
issue is somehow distinguishing between a reinterpret_cast and one of
the many other sources of NOP_EXPR.
yeah, I see that now. Perhaps VIEW_CONVERT_EXPR is more appropriate for
On Fri, Apr 20, 2018, 8:28 AM Nathan Sidwell wrote:
> On 04/18/2018 01:07 AM, Jason Merrill wrote:
> > I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
>
> That's kind of the wrong way round, isn't it? NOP_EXPRs are for things
> that don't generate code, which a reinterpret_ca
On 04/18/2018 01:07 AM, Jason Merrill wrote:
I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
That's kind of the wrong way round, isn't it? NOP_EXPRs are for things
that don't generate code, which a reinterpret_cast is. static_cast adds
a constant, which is only zero for
On Wed, Apr 18, 2018 at 09:32:53PM +0200, Jakub Jelinek wrote:
> In any case, this reinterpret_cast constexpr pedantic stuff looks too
> large/risky at this point to me, I wonder if we accept-invalid even the
> simple constexpr int a = reinterpret_cast (1); whether it is not ok for
> GCC8 to not er
On Wed, Apr 18, 2018 at 03:14:19PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 02:59:34PM +0200, Jakub Jelinek wrote:
> > On Wed, Apr 18, 2018 at 05:07:33AM +, Jason Merrill wrote:
> > > I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
>
> As for reinterpret_cast,
On Wed, Apr 18, 2018 at 02:59:34PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 05:07:33AM +, Jason Merrill wrote:
> > I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
As for reinterpret_cast, we e.g. accept
constexpr int a = reinterpret_cast (1);
which clang++ reje
On Wed, Apr 18, 2018 at 05:07:33AM +, Jason Merrill wrote:
> I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
I have tried following (still need Alex' expr.c changes, otherwise it ICEs),
on the bright side it fixes the new pr85437-4.C testcase,
but it causes Excess errors:
/
I wonder if it would work to use CONVERT_EXPR for reinterpret_cast.
On Tue, Apr 17, 2018, 9:45 PM Alexandre Oliva wrote:
>
> A static_cast of a pointer to data member used to wrap the PTRMEM_CST
> in a NOP_EXPR, but the NOP_EXPR is taken, in constexpr, as evidence
> that there was a reinterpret_
A static_cast of a pointer to data member used to wrap the PTRMEM_CST
in a NOP_EXPR, but the NOP_EXPR is taken, in constexpr, as evidence
that there was a reinterpret_cast in the expression. While
reinterpret_casts are to be rejected in constexprs, static_casts are
ok.
Thus, avoid introducing th
14 matches
Mail list logo
