Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-12 13:55:50 -0600, Martin Sebor wrote: > On 03/12/2015 03:10 AM, Vincent Lefevre wrote: > >Well, this depends on the interpretation of effective types in the > >case of a union. For instance, when writing > > > > union { char a[16]; int b; } u; > > u.b = 1; > > > >you don't set the m

Re: Undefined behavior due to 6.5.16.1p3

On 03/12/2015 03:10 AM, Vincent Lefevre wrote: On 2015-03-12 00:19:55 +0100, Robbert Krebbers wrote: On 03/11/2015 05:31 PM, Vincent Lefevre wrote: I disagree that it is an extension. The standard does not say that "one union member can be active at any time". The interpretation under which th

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-12 01:05:42 +, Joseph Myers wrote: > On Wed, 11 Mar 2015, Vincent Lefevre wrote: > > > BTW, the following is forbidden (and makes no sense), but is accepted > > by GCC without a warning: > > > > int foo (void) > > { > > union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 }; > >

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-12 00:19:55 +0100, Robbert Krebbers wrote: > On 03/11/2015 05:31 PM, Vincent Lefevre wrote: > >I disagree that it is an extension. The standard does not say > >that "one union member can be active at any time". > > > >The interpretation under which this is allowed in confirmed by > >Note

Re: Undefined behavior due to 6.5.16.1p3

BTW, the following is forbidden (and makes no sense), but is accepted by GCC without a warning: int foo (void) { union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 }; return u.b; } -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-11 17:39:31 +0100, Jakub Jelinek wrote: > On Wed, Mar 11, 2015 at 05:31:01PM +0100, Vincent Lefevre wrote: > > > (in C only one union member can be active at any time, > > > we as extension allow type punning through unions etc.) > > > > I disagree that it is an extension. The standard

Re: Undefined behavior due to 6.5.16.1p3

On Wed, Mar 11, 2015 at 05:08:16PM +0100, Vincent Lefevre wrote: > On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote: > > But what about "long long" on 32 bits machines. For example: > > > > union { > > long long a; > > struct { char b1; long long b2; } b; > > } u; > > > > Will GCC perform

Re: Undefined behavior due to 6.5.16.1p3

On Wed, 11 Mar 2015, Vincent Lefevre wrote: > BTW, the following is forbidden (and makes no sense), but is accepted > by GCC without a warning: > > int foo (void) > { > union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 }; > return u.b; > } What constraint do you think forbids it? It look

Re: Undefined behavior due to 6.5.16.1p3

On 03/11/2015 05:31 PM, Vincent Lefevre wrote: I disagree that it is an extension. The standard does not say that "one union member can be active at any time". The interpretation under which this is allowed in confirmed by Note 95 of 6.5.2.3p3. Effective types disallow to access a union member o

Re: Undefined behavior due to 6.5.16.1p3

On Wed, Mar 11, 2015 at 05:31:01PM +0100, Vincent Lefevre wrote: > > (in C only one union member can be active at any time, > > we as extension allow type punning through unions etc.) > > I disagree that it is an extension. The standard does not say > that "one union member can be active at any ti

Re: Undefined behavior due to 6.5.16.1p3

On 11 March 2015 at 16:11, Jakub Jelinek wrote: > There is some PR about it in our bugzilla, and the conclusion is that > it is both invalid (in C only one union member can be active at any time, > we as extension allow type punning through unions etc.) > and we really don't want to support it. I

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-11 17:11:55 +0100, Jakub Jelinek wrote: > On Wed, Mar 11, 2015 at 05:08:16PM +0100, Vincent Lefevre wrote: > > On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote: > > > But what about "long long" on 32 bits machines. For example: > > > > > > union { > > > long long a; > > > struct

Re: Undefined behavior due to 6.5.16.1p3

On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote: > But what about "long long" on 32 bits machines. For example: > > union { > long long a; > struct { char b1; long long b2; } b; > } u; > > Will GCC perform similar optimizations as for the case of big structs? I > tried to play around wit

Re: Undefined behavior due to 6.5.16.1p3

On 03/11/2015 07:27 AM, Robbert Krebbers wrote: Dear Joseph, On 03/10/2015 11:01 PM, Joseph Myers wrote: and did "u.b.b2 = f (u.a);" instead of "u.b.b2 = u.a;", that would not be undefined (see 6.8.6.4 and GCC PR 43784). Thanks for the references, those are useful! But what about "long long"

Re: Undefined behavior due to 6.5.16.1p3

Dear Joseph, On 03/10/2015 11:01 PM, Joseph Myers wrote: and did "u.b.b2 = f (u.a);" instead of "u.b.b2 = u.a;", that would not be undefined (see 6.8.6.4 and GCC PR 43784). Thanks for the references, those are useful! But what about "long long" on 32 bits machines. For example: union { long

Re: Undefined behavior due to 6.5.16.1p3

On Tue, 10 Mar 2015, Robbert Krebbers wrote: > On 03/10/2015 05:44 PM, Robbert Krebbers wrote: > > On 03/10/2015 05:18 PM, Martin Sebor wrote: > > > I suspect every compiler relies on this requirement in certain > > > cases otherwise copying would require making use of temporary > > > storage. Her

Re: Undefined behavior due to 6.5.16.1p3

On 03/10/2015 05:44 PM, Robbert Krebbers wrote: On 03/10/2015 05:18 PM, Martin Sebor wrote: I suspect every compiler relies on this requirement in certain cases otherwise copying would require making use of temporary storage. Here's an example: Thanks, this example is indeed not already undefin

Re: Undefined behavior due to 6.5.16.1p3

On 03/10/2015 05:18 PM, Martin Sebor wrote: I suspect every compiler relies on this requirement in certain cases otherwise copying would require making use of temporary storage. Here's an example: Thanks, this example is indeed not already undefined by effective types, nor 6.2.6.1p6. An entire

Re: Undefined behavior due to 6.5.16.1p3

On 03/09/2015 01:26 PM, Robbert Krebbers wrote: I was wondering whether GCC uses 6.5.16.1p3 of the C11 standard as a license to perform certain optimizations. If so, could anyone provide me an example program. In particular, I am interested about the "then the overlap shall be exact" part of 6.5

Re: Undefined behavior due to 6.5.16.1p3

On Tue, Mar 10, 2015 at 10:11 AM, Robbert Krebbers wrote: > Dear Richard, > > On 03/10/2015 09:51 AM, Richard Biener wrote: >> >> struct X { int i; int j; }; >> >> int foo (struct X *p, struct X *q) >> { >>q->j = 1; >>p->i = 0; >>return q->j; >> } >> >> will optimize to return 1. If *

Re: Undefined behavior due to 6.5.16.1p3

Dear Richard, On 03/10/2015 09:51 AM, Richard Biener wrote: struct X { int i; int j; }; int foo (struct X *p, struct X *q) { q->j = 1; p->i = 0; return q->j; } will optimize to return 1. If *p and *q were allowed to overlap (&p->i == &q->j) this would invoke undefined behavior. Than

Re: Undefined behavior due to 6.5.16.1p3

On Mon, Mar 9, 2015 at 8:26 PM, Robbert Krebbers wrote: > I was wondering whether GCC uses 6.5.16.1p3 of the C11 standard as a license > to perform certain optimizations. If so, could anyone provide me an example > program. > > In particular, I am interested about the "then the overlap shall be ex