On Aug 26, 2014, at 1:35 AM, Richard Biener wrote:
>
>> 8 The implicitly-defined copy constructor for class X performs a member-
>> wise copy of its subobjects. The order of copying is the same as the
>> order of initialization of bases and members in a user-defined con-
>> structor (see
On Fri, Aug 22, 2014 at 1:47 AM, Mike Stump wrote:
> On Aug 21, 2014, at 4:22 AM, Richard Biener
> wrote:
>> I still say we need to solve the issue at language level - that is,
>> try to figure out what the language standard says about
>>
>> volatile struct X x, y;
>
>> x = y;
>
> The definition
On Aug 22, 2014, at 8:42 AM, Joseph S. Myers wrote:
> On Thu, 21 Aug 2014, Mike Stump wrote:
>> 1 - I use n843 for C99, which is slightly different from the standard, but
>> in this case I suspect it is the same.
>
> Use N1256 (C99+TC1+TC2+TC3) instead.
Thanks. I had the C99.pdf to quote from,
On Thu, 21 Aug 2014, Mike Stump wrote:
> 1 - I use n843 for C99, which is slightly different from the standard, but in
> this case I suspect it is the same.
Use N1256 (C99+TC1+TC2+TC3) instead.
--
Joseph S. Myers
jos...@codesourcery.com
On Aug 21, 2014, at 4:22 AM, Richard Biener wrote:
> I still say we need to solve the issue at language level - that is,
> try to figure out what the language standard says about
>
> volatile struct X x, y;
> x = y;
The definition of x = y doesn’t change wrt volatile above. See below for the
On Thu, Aug 21, 2014 at 12:34 PM, James Greenhalgh
wrote:
>
> Hi,
>
> Andrew is quite right, we break the contract for volatile struct copies
> if we start double copying bytes.
>
> But, the generic code will call memcpy - at which point anything could
> happen. So, we must not put out a call to m
Hi,
Andrew is quite right, we break the contract for volatile struct copies
if we start double copying bytes.
But, the generic code will call memcpy - at which point anything could
happen. So, we must not put out a call to memcpy if either our source or
destination operands are volatile. The sam
