OK.
On Tue, Jan 24, 2017 at 1:53 PM, Nathan Sidwell wrote:
> On 01/24/2017 01:41 PM, Jason Merrill wrote:
>>
>> On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell wrote:
>>>
>>> On 01/23/2017 04:06 PM, Jason Merrill wrote:
>>>
> In this particular case we've also made the base object the contai
On 01/24/2017 01:41 PM, Jason Merrill wrote:
On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell wrote:
On 01/23/2017 04:06 PM, Jason Merrill wrote:
In this particular case we've also made the base object the containing
class, not the unnamed struct member. That means we're looking in the
wrong
On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell wrote:
> On 01/23/2017 04:06 PM, Jason Merrill wrote:
>
>>> In this particular case we've also made the base object the containing
>>> class, not the unnamed struct member. That means we're looking in the
>>> wrong
>>> CONSTRUCTOR and see CONSTRUCTO
On 01/23/2017 04:06 PM, Jason Merrill wrote:
In this particular case we've also made the base object the containing
class, not the unnamed struct member. That means we're looking in the wrong
CONSTRUCTOR and see CONSTRUCTOR_NO_IMPLICIT_ZERO is true. Whereas for the
subobj's CONSTRUCTOR it is f
On Tue, Jan 24, 2017 at 07:01:45AM -0500, Nathan Sidwell wrote:
> On 01/24/2017 05:49 AM, Jakub Jelinek wrote:
>
> > ((BIT_FIELD_REF ^ BIT_FIELD_REF ) & 110) == 0
> > out of that. So unless we DTRT (i.e. save constexpr bodies before
> > cp_fold for constexpr evaluation purposes), the workaround
On 01/24/2017 05:49 AM, Jakub Jelinek wrote:
((BIT_FIELD_REF ^ BIT_FIELD_REF ) & 110) == 0
out of that. So unless we DTRT (i.e. save constexpr bodies before
cp_fold for constexpr evaluation purposes), the workaround would need
to handle this properly (basically pattern recognize whatever the
On Tue, Jan 24, 2017 at 11:54:09AM +0100, Richard Biener wrote:
> > Please note that say for:
> > struct S { int : 1; int a : 3; int : 1; int b : 2; };
> >
> > int
> > foo (S a, S b)
> > {
> > return a.a == b.a && a.b == b.b;
> > }
> >
> > (haven't tried to turn that into a constexpr testcase, bu
On Tue, Jan 24, 2017 at 11:49 AM, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 08:49:43AM -0500, Nathan Sidwell wrote:
>> This patch addresses 79118, where we ICE on a constexpr involving bitfields
>> in an unnamed struct (unnamed struct members are a g++ extension).
>>
>> This is really a band-
On Mon, Jan 23, 2017 at 08:49:43AM -0500, Nathan Sidwell wrote:
> This patch addresses 79118, where we ICE on a constexpr involving bitfields
> in an unnamed struct (unnamed struct members are a g++ extension).
>
> This is really a band-aid, because our internal representation BITFIELD_REF
> and t
On Mon, Jan 23, 2017 at 4:13 PM, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 04:06:22PM -0500, Jason Merrill wrote:
>> > The right solution is to fix the IR. In the C++ FE have BITFIELD_REF (or a
>> > new node) look much more like COMPONENT_REF (or even be COMPONENT_REF, but
>> > I
>> > suspe
On Mon, Jan 23, 2017 at 04:06:22PM -0500, Jason Merrill wrote:
> > The right solution is to fix the IR. In the C++ FE have BITFIELD_REF (or a
> > new node) look much more like COMPONENT_REF (or even be COMPONENT_REF, but I
> > suspect lots of places think ADDR (COMPONENT_REF (...)) is legit). And
On Mon, Jan 23, 2017 at 8:49 AM, Nathan Sidwell wrote:
> This patch addresses 79118, where we ICE on a constexpr involving bitfields
> in an unnamed struct (unnamed struct members are a g++ extension).
>
> This is really a band-aid, because our internal representation BITFIELD_REF
> and the (prema
This patch addresses 79118, where we ICE on a constexpr involving
bitfields in an unnamed struct (unnamed struct members are a g++ extension).
This is really a band-aid, because our internal representation
BITFIELD_REF and the (premature) optimizations it encourages is
incompatible with conste
13 matches
Mail list logo
