Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #44630 > unrolled thread
| Started by | Melzzzzz <mel@zzzzz.com> |
|---|---|
| First post | 2016-08-31 14:59 +0200 |
| Last post | 2016-09-05 21:25 +0100 |
| Articles | 20 on this page of 123 — 25 participants |
Back to article view | Back to comp.lang.c++
This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-08-31 14:59 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 15:20 +0200
Re: This will work or not? mark <mark@invalid.invalid> - 2016-08-31 16:05 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 16:19 +0200
Re: This will work or not? scott@slp53.sl.home (Scott Lurndal) - 2016-08-31 14:20 +0000
Re: This will work or not? Bo Persson <bop@gmb.dk> - 2016-08-31 18:53 +0200
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 09:03 -0700
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 22:45 +0200
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 18:08 -0700
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 09:24 +0200
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 06:31 -0700
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-04 20:19 +0200
Re: This will work or not? Manfred <noname@invalid.add> - 2016-08-31 15:45 +0200
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-08-31 15:59 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 16:22 +0200
Re: This will work or not? Manfred <noname@invalid.add> - 2016-08-31 17:06 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 19:29 +0200
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-08-31 21:52 +0100
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 09:07 +0200
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-01 12:30 +0100
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 09:01 -0700
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-01 18:16 +0100
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 18:37 -0700
Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-02 10:42 +0100
Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 06:59 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 23:17 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 09:35 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 15:34 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-01 13:50 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 21:01 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-01 19:02 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 22:17 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 08:19 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:39 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 12:26 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:38 -0400
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 13:51 -0700
Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 14:16 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 19:58 -0400
Re: This will work or not? Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-02 23:56 +0300
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-03 17:58 +0200
Re: This will work or not? Manfred <noname@invalid.add> - 2016-09-02 11:41 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 12:27 +0200
Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 12:37 +0100
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:39 +0200
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-02 17:40 +0200
Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 16:54 +0100
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 20:22 +0200
Re: This will work or not? Richard Damon <Richard@Damon-Family.org> - 2016-09-02 08:04 -0400
Re: This will work or not? BartC <bc@freeuk.com> - 2016-09-02 13:51 +0100
Re: This will work or not? Richard Damon <Richard@Damon-Family.org> - 2016-09-02 21:48 -0400
Re: This will work or not? Manfred <noname@invalid.add> - 2016-09-02 15:17 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:46 +0200
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 23:14 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 21:02 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 09:35 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 08:50 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:59 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:49 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 20:36 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:32 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-03 18:08 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 18:25 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-03 23:51 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 21:48 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 03:48 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 23:05 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 05:02 +0100
Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-04 10:57 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 09:40 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 16:39 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 12:46 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 17:51 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:07 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 18:37 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:16 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 22:23 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 18:54 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 09:58 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:08 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 10:21 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:18 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 22:24 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 18:56 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 00:27 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:53 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 18:18 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 15:27 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 20:32 +0100
Re: This will work or not? woodbrian77@gmail.com - 2016-09-05 14:07 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 18:15 -0400
Re: This will work or not? Ike Naar <ike@iceland.freeshell.org> - 2016-09-05 20:12 +0000
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 22:05 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 18:16 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-06 08:47 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-06 09:12 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-06 16:31 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-06 11:20 -0400
Re: This will work or not? bighe.trole@gmail.com - 2016-09-04 18:55 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:55 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 17:17 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:57 -0400
Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-05 11:20 -0700
Re: This will work or not? Luuk <luuk@invalid.lan> - 2016-09-04 18:54 +0200
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 17:59 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:08 -0400
Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-04 20:25 +0200
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:20 -0400
Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-04 02:36 -0700
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 09:41 -0400
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 21:49 -0400
Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 03:49 +0100
Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 23:06 -0400
Re: This will work or not? woodbrian77@gmail.com - 2016-09-03 21:16 -0700
Re: This will work or not? Vir Campestris <vir.campestris@invalid.invalid> - 2016-08-31 21:08 +0100
Re: This will work or not? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-01 02:28 +0200
Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-01 01:28 -0700
Re: This will work or not? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-02 12:06 -0700
Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-05 02:21 -0700
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-05 13:38 +0200
Re: This will work or not? Juha Nieminen <nospam@thanks.invalid> - 2016-09-05 11:34 +0000
Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-05 13:36 +0200
Re: This will work or not? Vir Campestris <vir.campestris@invalid.invalid> - 2016-09-05 21:25 +0100
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-03 17:58 +0200 |
| Message-ID | <nqeruq$747$1@dont-email.me> |
| In reply to | #44765 |
On 02/09/16 22:56, Paavo Helde wrote: > On 2.09.2016 22:26, me wrote: >> But 1.9.1 (plus footnote 5) says that if there is _no_ affect >> on observable behaviour (as in my programs above), the implementation >> can do any darn thing it pleases with struct layout. > > I have got an impression that the most common thing which might happen > with a struct is that the compiler decides to place it into registers > altogether and there is no layout to speak of (what is the padding > between EAX and EBX?). > Certainly when you have small structs declared locally, you can expect that some or all of the parts will be placed in registers. Other bits might go onto the stack, or be removed entirely if they are not actually needed. > In regard of unions this becomes quite interesting. I imagine the > compiler might easily place the different union members in different > registers (except for the common initial sequence, if any). Using > different registers might make a lot of sense if one member is holding > integers and the other floating-point numbers, for example. Yes, that sounds reasonable. > I guess the > only thing which might hold the compiler developers back here is that > the union has a long tradition of being illegally abused for type-punning. > Note that this is only "illegal abuse" for C++ compilers that don't allow it as an implementation-dependent feature. C compilers (from C99 onwards) have it as part of the standards, and C++ compilers such as gcc allow it as implementation-dependent behaviour. Since all, or at least almost all, C++ compilers are also C compilers, it would surprise me if such type-punning unions work did not work correctly - at least in simple cases. (Relying on this behaviour, unless it is documented by your compiler, is of course a bad idea.)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-09-02 11:41 +0200 |
| Message-ID | <nqbhfb$12q1$1@gioia.aioe.org> |
| In reply to | #44721 |
On 9/2/2016 4:02 AM, me wrote: > > I did. > > The standard also says that the as-if rule over-rides everything else in > the standard, and that only observable behaviour of the program need be > considered. So again, why is structure member layout _different_ in this > respect? > It is different because of the presence of the union. When you access the struct memory area through the array you are accessing data in a well-specified order, and the struct members must therefore follow the order specified by the standard. As long as memory access is legal, and it is in this case, if optimization could reorder the struct members, the "as-if" rule would be violated because the optimized and non-optimized code results would be different. I may think the union+array trick also solves the problem of interleaving of data members with different access control, and "space for managing virtual functions and virtual base classes" (also from the same clause of the standard), because the union becomes its own data item within "struct Problem", encapsulated with no other data and no virtual members or bases. But someone else may be more specific than I can be on this.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-02 12:27 +0200 |
| Message-ID | <nqbk65$bmh$1@dont-email.me> |
| In reply to | #44727 |
On 02/09/16 11:41, Manfred wrote:
> On 9/2/2016 4:02 AM, me wrote:
>>
>> I did.
>>
>> The standard also says that the as-if rule over-rides everything else in
>> the standard, and that only observable behaviour of the program need be
>> considered. So again, why is structure member layout _different_ in this
>> respect?
>>
> It is different because of the presence of the union.
> When you access the struct memory area through the array you are
> accessing data in a well-specified order, and the struct members must
> therefore follow the order specified by the standard.
> As long as memory access is legal, and it is in this case, if
> optimization could reorder the struct members, the "as-if" rule would be
> violated because the optimized and non-optimized code results would be
> different.
The as-if rule still applies. If we stick to C, where you /are/ allowed
to access data in different ways with a union, we could have this:
union {
struct {
uint32_t a;
uint32_t b;
uint64_t c;
uint32_t d;
};
uint32_t as_array[5];
} u;
When you write:
uint32_t foo(void) {
u.d = 123;
u.b = u.as_array[4];
return u.as_array[1];
}
The compiler will have to return 123. It must /behave/ in this way.
But it does /not/ have to keep the struct in the order you have given -
it is allowed to transform that program into this:
union {
struct {
uint64_t c; // <- Note the change
uint32_t a;
uint32_t b;
uint32_t d;
};
uint32_t as_array[5];
} u;
uint32_t foo(void) {
u.d = 123;
u.b = u.as_array[4];
return u.as_array[3]; // <- Note the change
}
Would a compiler actually do this? No, it is highly unlikely - it's
just too much effort to get it all correct, and too little gain. But it
/is/ legal, by the "as-if" rule.
And there /are/ compilers that re-arrange structs - they might be
reducing padding, improving cache line hits, separating "hot" and "cold"
parts, removing unused fields, etc. When the structs are used in a
simple manner, that will be fine - when they are used in other ways
(such as with a union, or memcpy'ing, or taking addresses of members),
there quickly becomes a point where it is too difficult to track for
correctness if the struct is re-arranged.
>
> I may think the union+array trick also solves the problem of
> interleaving of data members with different access control, and "space
> for managing virtual functions and virtual base classes" (also from the
> same clause of the standard), because the union becomes its own data
> item within "struct Problem", encapsulated with no other data and no
> virtual members or bases.
> But someone else may be more specific than I can be on this.
>
Maybe it is precisely to avoid that sort of access control cheating that
C++ makes such union+array tricks undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-02 12:37 +0100 |
| Message-ID | <87wpiu4jny.fsf@bsb.me.uk> |
| In reply to | #44729 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/09/16 11:41, Manfred wrote:
>> On 9/2/2016 4:02 AM, me wrote:
<snip>
>>> The standard also says that the as-if rule over-rides everything else in
>>> the standard, and that only observable behaviour of the program need be
>>> considered. So again, why is structure member layout _different_ in this
>>> respect?
>>>
>> It is different because of the presence of the union.
>> When you access the struct memory area through the array you are
>> accessing data in a well-specified order, and the struct members must
>> therefore follow the order specified by the standard.
>> As long as memory access is legal, and it is in this case, if
>> optimization could reorder the struct members, the "as-if" rule would be
>> violated because the optimized and non-optimized code results would be
>> different.
>
> The as-if rule still applies. If we stick to C, where you /are/ allowed
> to access data in different ways with a union, we could have this:
>
> union {
> struct {
> uint32_t a;
> uint32_t b;
> uint64_t c;
> uint32_t d;
> };
> uint32_t as_array[5];
> } u;
Is the 5 a typo?
> When you write:
>
> uint32_t foo(void) {
> u.d = 123;
> u.b = u.as_array[4];
> return u.as_array[1];
> }
Is the 4 a typo?
> The compiler will have to return 123. It must /behave/ in this way.
I've not been following the details, so maybe there are some assumptions
in play here, but if the struct has unknown padding the only thing you
can rely on is that u.a and u.as_array[0] overlap.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-02 17:39 +0200 |
| Message-ID | <nqc6f9$amb$1@dont-email.me> |
| In reply to | #44730 |
On 02/09/16 13:37, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 02/09/16 11:41, Manfred wrote:
>>> On 9/2/2016 4:02 AM, me wrote:
> <snip>
>>>> The standard also says that the as-if rule over-rides everything else in
>>>> the standard, and that only observable behaviour of the program need be
>>>> considered. So again, why is structure member layout _different_ in this
>>>> respect?
>>>>
>>> It is different because of the presence of the union.
>>> When you access the struct memory area through the array you are
>>> accessing data in a well-specified order, and the struct members must
>>> therefore follow the order specified by the standard.
>>> As long as memory access is legal, and it is in this case, if
>>> optimization could reorder the struct members, the "as-if" rule would be
>>> violated because the optimized and non-optimized code results would be
>>> different.
>>
>> The as-if rule still applies. If we stick to C, where you /are/ allowed
>> to access data in different ways with a union, we could have this:
>>
>> union {
>> struct {
>> uint32_t a;
>> uint32_t b;
>> uint64_t c;
>> uint32_t d;
>> };
>> uint32_t as_array[5];
>> } u;
>
> Is the 5 a typo?
No - "c" is a uint64_t, while the others are uint32_t. I don't know if
that was a typo in the OP's first post, but I've followed it.
>
>> When you write:
>>
>> uint32_t foo(void) {
>> u.d = 123;
>> u.b = u.as_array[4];
>> return u.as_array[1];
>> }
>
> Is the 4 a typo?
>
>> The compiler will have to return 123. It must /behave/ in this way.
>
> I've not been following the details, so maybe there are some assumptions
> in play here, but if the struct has unknown padding the only thing you
> can rely on is that u.a and u.as_array[0] overlap.
>
It's true that there could be padding here - my assumption is that there
is no padding.
But the point still stands - /if/ the first code is allowed (depending
on implementation-dependent padding), then the second code is an
allowable transformation by the compiler.
> <snip>
>
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-09-02 17:40 +0200 |
| Message-ID | <20160902174014.0ff8a90a@maxa-pc> |
| In reply to | #44740 |
On Fri, 02 Sep 2016 17:39:21 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 02/09/16 13:37, Ben Bacarisse wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >
> >> On 02/09/16 11:41, Manfred wrote:
> >>> On 9/2/2016 4:02 AM, me wrote:
> > <snip>
> >>>> The standard also says that the as-if rule over-rides everything
> >>>> else in the standard, and that only observable behaviour of the
> >>>> program need be considered. So again, why is structure member
> >>>> layout _different_ in this respect?
> >>>>
> >>> It is different because of the presence of the union.
> >>> When you access the struct memory area through the array you are
> >>> accessing data in a well-specified order, and the struct members
> >>> must therefore follow the order specified by the standard.
> >>> As long as memory access is legal, and it is in this case, if
> >>> optimization could reorder the struct members, the "as-if" rule
> >>> would be violated because the optimized and non-optimized code
> >>> results would be different.
> >>
> >> The as-if rule still applies. If we stick to C, where you /are/
> >> allowed to access data in different ways with a union, we could
> >> have this:
> >>
> >> union {
> >> struct {
> >> uint32_t a;
> >> uint32_t b;
> >> uint64_t c;
> >> uint32_t d;
> >> };
> >> uint32_t as_array[5];
> >> } u;
> >
> > Is the 5 a typo?
>
> No - "c" is a uint64_t, while the others are uint32_t. I don't know
> if that was a typo in the OP's first post, but I've followed it.
It was not typo. I only missed to say that struct has packed attribute.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-02 16:54 +0100 |
| Message-ID | <87r3922t7m.fsf@bsb.me.uk> |
| In reply to | #44740 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/09/16 13:37, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 02/09/16 11:41, Manfred wrote:
>>>> On 9/2/2016 4:02 AM, me wrote:
>> <snip>
>>>>> The standard also says that the as-if rule over-rides everything else in
>>>>> the standard, and that only observable behaviour of the program need be
>>>>> considered. So again, why is structure member layout _different_ in this
>>>>> respect?
>>>>>
>>>> It is different because of the presence of the union.
>>>> When you access the struct memory area through the array you are
>>>> accessing data in a well-specified order, and the struct members must
>>>> therefore follow the order specified by the standard.
>>>> As long as memory access is legal, and it is in this case, if
>>>> optimization could reorder the struct members, the "as-if" rule would be
>>>> violated because the optimized and non-optimized code results would be
>>>> different.
>>>
>>> The as-if rule still applies. If we stick to C, where you /are/ allowed
>>> to access data in different ways with a union, we could have this:
>>>
>>> union {
>>> struct {
>>> uint32_t a;
>>> uint32_t b;
>>> uint64_t c;
>>> uint32_t d;
>>> };
>>> uint32_t as_array[5];
>>> } u;
>>
>> Is the 5 a typo?
>
> No - "c" is a uint64_t, while the others are uint32_t. I don't know if
> that was a typo in the OP's first post, but I've followed it.
Ah, right. I missed that.
<snip>
>> I've not been following the details, so maybe there are some assumptions
>> in play here, but if the struct has unknown padding the only thing you
>> can rely on is that u.a and u.as_array[0] overlap.
>>
>
> It's true that there could be padding here - my assumption is that there
> is no padding.
I'd missed that too.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-02 20:22 +0200 |
| Message-ID | <nqcg0q$ek9$1@dont-email.me> |
| In reply to | #44743 |
On 02/09/16 17:54, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 02/09/16 13:37, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 02/09/16 11:41, Manfred wrote:
>>>>> On 9/2/2016 4:02 AM, me wrote:
>>> <snip>
>>>>>> The standard also says that the as-if rule over-rides everything else in
>>>>>> the standard, and that only observable behaviour of the program need be
>>>>>> considered. So again, why is structure member layout _different_ in this
>>>>>> respect?
>>>>>>
>>>>> It is different because of the presence of the union.
>>>>> When you access the struct memory area through the array you are
>>>>> accessing data in a well-specified order, and the struct members must
>>>>> therefore follow the order specified by the standard.
>>>>> As long as memory access is legal, and it is in this case, if
>>>>> optimization could reorder the struct members, the "as-if" rule would be
>>>>> violated because the optimized and non-optimized code results would be
>>>>> different.
>>>>
>>>> The as-if rule still applies. If we stick to C, where you /are/ allowed
>>>> to access data in different ways with a union, we could have this:
>>>>
>>>> union {
>>>> struct {
>>>> uint32_t a;
>>>> uint32_t b;
>>>> uint64_t c;
>>>> uint32_t d;
>>>> };
>>>> uint32_t as_array[5];
>>>> } u;
>>>
>>> Is the 5 a typo?
>>
>> No - "c" is a uint64_t, while the others are uint32_t. I don't know if
>> that was a typo in the OP's first post, but I've followed it.
>
> Ah, right. I missed that.
>
> <snip>
>>> I've not been following the details, so maybe there are some assumptions
>>> in play here, but if the struct has unknown padding the only thing you
>>> can rely on is that u.a and u.as_array[0] overlap.
>>>
>>
>> It's true that there could be padding here - my assumption is that there
>> is no padding.
>
> I'd missed that too.
>
I can't really blame you for not noticing my unstated assumptions -
especially as they were based on the OP's omitted "packed" attribute :-)
I'd be surprised if there are any implementations of C that would put
padding in this struct even without a "packed" attribute - it would
almost have to be an architecture with 64-bit int and 32-bit short for
packing to make much sense. But it was still an assumption, and should
have been stated.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-09-02 08:04 -0400 |
| Message-ID | <RUdyz.14073$yi7.3443@fx42.iad> |
| In reply to | #44729 |
On 9/2/16 6:27 AM, David Brown wrote:
> On 02/09/16 11:41, Manfred wrote:
>> On 9/2/2016 4:02 AM, me wrote:
>>>
>>> I did.
>>>
>>> The standard also says that the as-if rule over-rides everything else in
>>> the standard, and that only observable behaviour of the program need be
>>> considered. So again, why is structure member layout _different_ in this
>>> respect?
>>>
>> It is different because of the presence of the union.
>> When you access the struct memory area through the array you are
>> accessing data in a well-specified order, and the struct members must
>> therefore follow the order specified by the standard.
>> As long as memory access is legal, and it is in this case, if
>> optimization could reorder the struct members, the "as-if" rule would be
>> violated because the optimized and non-optimized code results would be
>> different.
>
> The as-if rule still applies. If we stick to C, where you /are/ allowed
> to access data in different ways with a union, we could have this:
>
> union {
> struct {
> uint32_t a;
> uint32_t b;
> uint64_t c;
> uint32_t d;
> };
> uint32_t as_array[5];
> } u;
>
> When you write:
>
> uint32_t foo(void) {
> u.d = 123;
> u.b = u.as_array[4];
> return u.as_array[1];
> }
>
> The compiler will have to return 123. It must /behave/ in this way.
> But it does /not/ have to keep the struct in the order you have given -
> it is allowed to transform that program into this:
>
No it does not. a must match as_array[0] but the compiler is allowed to
insert padding between a and b. (Yes, for most machines it is unlikely
to, but it can). One motivation would be if you had a machine that was
naturally faster accessing 64 bit aligned objects than 32, but could
access 32 bit objects (perhaps with multiple instructions). An example
would be a 64 bit word based machine that natively only could access at
at 64 bit level, but to look like a more conventional machine the
compiler simulated smaller accesses (to avoid having CHAR_BIT == 64 and
sizeof(long long) == 1 which would give many programs problems, not
unlike the 16 bit access machine of yesteryear). On such a machine, b
would be at as_array[2], not [1] as expected, and [1] would map to a
padding word.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-02 13:51 +0100 |
| Message-ID | <nqbslm$7qn$1@dont-email.me> |
| In reply to | #44732 |
On 02/09/2016 13:04, Richard Damon wrote:
> On 9/2/16 6:27 AM, David Brown wrote:
>> On 02/09/16 11:41, Manfred wrote:
>>> On 9/2/2016 4:02 AM, me wrote:
>>>>
>>>> I did.
>>>>
>>>> The standard also says that the as-if rule over-rides everything
>>>> else in
>>>> the standard, and that only observable behaviour of the program need be
>>>> considered. So again, why is structure member layout _different_ in
>>>> this
>>>> respect?
>>>>
>>> It is different because of the presence of the union.
>>> When you access the struct memory area through the array you are
>>> accessing data in a well-specified order, and the struct members must
>>> therefore follow the order specified by the standard.
>>> As long as memory access is legal, and it is in this case, if
>>> optimization could reorder the struct members, the "as-if" rule would be
>>> violated because the optimized and non-optimized code results would be
>>> different.
>>
>> The as-if rule still applies. If we stick to C, where you /are/ allowed
>> to access data in different ways with a union, we could have this:
>>
>> union {
>> struct {
>> uint32_t a;
>> uint32_t b;
>> uint64_t c;
>> uint32_t d;
>> };
>> uint32_t as_array[5];
>> } u;
>>
>> When you write:
>>
>> uint32_t foo(void) {
>> u.d = 123;
>> u.b = u.as_array[4];
>> return u.as_array[1];
>> }
>>
>> The compiler will have to return 123. It must /behave/ in this way.
>> But it does /not/ have to keep the struct in the order you have given -
>> it is allowed to transform that program into this:
>>
>
> No it does not. a must match as_array[0] but the compiler is allowed to
> insert padding between a and b. (Yes, for most machines it is unlikely
> to, but it can). One motivation would be if you had a machine that was
> naturally faster accessing 64 bit aligned objects than 32, but could
> access 32 bit objects (perhaps with multiple instructions). An example
> would be a 64 bit word based machine that natively only could access at
> at 64 bit level, but to look like a more conventional machine the
> compiler simulated smaller accesses (to avoid having CHAR_BIT == 64 and
> sizeof(long long) == 1 which would give many programs problems, not
> unlike the 16 bit access machine of yesteryear). On such a machine, b
> would be at as_array[2], not [1] as expected, and [1] would map to a
> padding word.
>
Easy to fix:
#pragma pack(1) // or better, push then later pop
union {
struct {
uint32_t a;
uint32_t b;
etc.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-09-02 21:48 -0400 |
| Message-ID | <2_pyz.47258$M27.22464@fx33.iad> |
| In reply to | #44734 |
On 9/2/16 8:51 AM, BartC wrote:
> On 02/09/2016 13:04, Richard Damon wrote:
>>
>> No it does not. a must match as_array[0] but the compiler is allowed to
>> insert padding between a and b. (Yes, for most machines it is unlikely
>> to, but it can). One motivation would be if you had a machine that was
>> naturally faster accessing 64 bit aligned objects than 32, but could
>> access 32 bit objects (perhaps with multiple instructions). An example
>> would be a 64 bit word based machine that natively only could access at
>> at 64 bit level, but to look like a more conventional machine the
>> compiler simulated smaller accesses (to avoid having CHAR_BIT == 64 and
>> sizeof(long long) == 1 which would give many programs problems, not
>> unlike the 16 bit access machine of yesteryear). On such a machine, b
>> would be at as_array[2], not [1] as expected, and [1] would map to a
>> padding word.
>>
>
> Easy to fix:
>
> #pragma pack(1) // or better, push then later pop
>
> union {
> struct {
> uint32_t a;
> uint32_t b;
> etc.
>
Since the pragma doesn't begin with STDC it is implementation defined,
so does nothing as far as what the standard says must happen. Once you
are willing to depend on implementation defined behavior,you don't need
the pragma, as the implementation can document their padding rules and
define that padding won't be added in this case (the standard doesn't
require this to be documented, but it can be).
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-09-02 15:17 +0200 |
| Message-ID | <nqbu5g$1oe5$1@gioia.aioe.org> |
| In reply to | #44729 |
On 09/02/2016 12:27 PM, David Brown wrote:
>> It is different because of the presence of the union.
>> When you access the struct memory area through the array you are
>> accessing data in a well-specified order, and the struct members must
>> therefore follow the order specified by the standard.
>> As long as memory access is legal, and it is in this case, if
>> optimization could reorder the struct members, the "as-if" rule would be
>> violated because the optimized and non-optimized code results would be
>> different.
>
> The as-if rule still applies. If we stick to C, where you /are/ allowed
> to access data in different ways with a union, we could have this:
>
> union {
> struct {
> uint32_t a;
> uint32_t b;
> uint64_t c;
> uint32_t d;
> };
> uint32_t as_array[5];
> } u;
>
> When you write:
>
> uint32_t foo(void) {
> u.d = 123;
> u.b = u.as_array[4];
> return u.as_array[1];
> }
>
> The compiler will have to return 123. It must /behave/ in this way.
> But it does /not/ have to keep the struct in the order you have given -
> it is allowed to transform that program into this:
>
> union {
> struct {
> uint64_t c; // <- Note the change
> uint32_t a;
> uint32_t b;
> uint32_t d;
> };
> uint32_t as_array[5];
> } u;
>
> uint32_t foo(void) {
> u.d = 123;
> u.b = u.as_array[4];
> return u.as_array[3]; // <- Note the change
> }
>
You mean that the compiler would be allowed to rearrange the entire
address space (variables /and/ addresses: the programmer asks for
u.as_array[1] and gets u.as_array[3]) so that they appear to be in order
while physically they are not. I strongly doubt this, simply because it
would be almost impossible to guarantee the expected results for any
generic input code (and it would often provide no performance change or
even a degradation). Note that in your example the compiler designer
would have to build in the knowledge that the return value of foo is u.b
instead of u.as_array[1], which is true for your specific example only.
On the other hand, even if such obscure behaviour occurred, it would be
completely transparent to the programmer, so that it could be ignored
anyway.
To put it more simple:
#include <cstdio>
#include <cstdint>
union {
struct __attribute__ ((__packed__)) {
uint32_t a;
uint32_t b;
uint64_t c;
uint32_t d;
};
uint32_t as_array[5];
} u;
void foo(void) {
u.a = 1;
u.b = 2;
u.c = 3;
u.d = 4;
}
void bar(void) {
for(uint32_t* p = u.as_array; p < u.as_array+5; ++p) {
printf("%u\n", *p);
}
}
int main(void) {
foo();
bar();
}
The output must be
1
2
3
0
4
(assuming little endian), and since we are scanning the memory area
sequentially, variables must be ordered as coded. Again, even if obscure
things would be allowed to happen, they would be transparent to the
programmer, so that they could be ignored.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-02 17:46 +0200 |
| Message-ID | <nqc6sr$bum$1@dont-email.me> |
| In reply to | #44735 |
On 02/09/16 15:17, Manfred wrote:
> On 09/02/2016 12:27 PM, David Brown wrote:
>>> It is different because of the presence of the union.
>>> When you access the struct memory area through the array you are
>>> accessing data in a well-specified order, and the struct members must
>>> therefore follow the order specified by the standard.
>>> As long as memory access is legal, and it is in this case, if
>>> optimization could reorder the struct members, the "as-if" rule would be
>>> violated because the optimized and non-optimized code results would be
>>> different.
>>
>> The as-if rule still applies. If we stick to C, where you /are/ allowed
>> to access data in different ways with a union, we could have this:
>>
>> union {
>> struct {
>> uint32_t a;
>> uint32_t b;
>> uint64_t c;
>> uint32_t d;
>> };
>> uint32_t as_array[5];
>> } u;
>>
>> When you write:
>>
>> uint32_t foo(void) {
>> u.d = 123;
>> u.b = u.as_array[4];
>> return u.as_array[1];
>> }
>>
>> The compiler will have to return 123. It must /behave/ in this way.
>> But it does /not/ have to keep the struct in the order you have given -
>> it is allowed to transform that program into this:
>>
>> union {
>> struct {
>> uint64_t c; // <- Note the change
>> uint32_t a;
>> uint32_t b;
>> uint32_t d;
>> };
>> uint32_t as_array[5];
>> } u;
>>
>> uint32_t foo(void) {
>> u.d = 123;
>> u.b = u.as_array[4];
>> return u.as_array[3]; // <- Note the change
>> }
>>
>
> You mean that the compiler would be allowed to rearrange the entire
> address space (variables /and/ addresses: the programmer asks for
> u.as_array[1] and gets u.as_array[3]) so that they appear to be in order
> while physically they are not. I strongly doubt this, simply because it
> would be almost impossible to guarantee the expected results for any
> generic input code (and it would often provide no performance change or
> even a degradation). Note that in your example the compiler designer
> would have to build in the knowledge that the return value of foo is u.b
> instead of u.as_array[1], which is true for your specific example only.
>
>
>
> On the other hand, even if such obscure behaviour occurred, it would be
> completely transparent to the programmer, so that it could be ignored
> anyway.
>
>
>
> To put it more simple:
>
>
>
> #include <cstdio>
> #include <cstdint>
>
> union {
> struct __attribute__ ((__packed__)) {
> uint32_t a;
> uint32_t b;
> uint64_t c;
> uint32_t d;
> };
> uint32_t as_array[5];
> } u;
>
> void foo(void) {
> u.a = 1;
> u.b = 2;
> u.c = 3;
> u.d = 4;
> }
>
> void bar(void) {
> for(uint32_t* p = u.as_array; p < u.as_array+5; ++p) {
> printf("%u\n", *p);
> }
> }
>
> int main(void) {
> foo();
> bar();
> }
>
> The output must be
> 1
> 2
> 3
> 0
> 4
> (assuming little endian), and since we are scanning the memory area
> sequentially, variables must be ordered as coded. Again, even if obscure
> things would be allowed to happen, they would be transparent to the
> programmer, so that they could be ignored.
>
>
The point is that the output you have shown here is observable
behaviour. In this case, it is the /only/ observable behaviour. And
the compiler is free to make whatever transformations it wants, as long
as the observable behaviour matches. The compiler is therefore free to
re-arrange the structs as it wants - just as it is free to turn main() into
int main(void) {
puts("1\n2\n3\n0\n4\n");
}
Of course, that would only be legal if the compiler knew that the code
would not be statically linked with other code that called foo, bar, or
main, or used u. When gcc had an option for re-ordering structs, it
could only be enabled along with the "-fwhole-program" flag for
precisely that reason. But if the relevant structs and functions had
been locals or file static (with no "escapes"), then the compiler could
freely transform it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-01 23:14 +0200 |
| Message-ID | <nqa5n8$g2f$1@dont-email.me> |
| In reply to | #44698 |
On 01/09/16 21:34, Jerry Stuckle wrote: > On 9/1/2016 3:35 AM, David Brown wrote: >> On 01/09/16 05:17, Jerry Stuckle wrote: >>> >>> Incorrect. Order of data members in the struct must be as they are >>> declared in the struct. There may be padding between the members, but >>> the order cannot change. >>> >>> Compilers cannot "generate anything they want as long as the runs as >>> if". They are bound by other rules. >> >> No, to a very large extent they /can/ generate anything they want - as >> long as the code runs "as if" it followed the rules strictly. This is >> one of the key points for an optimising compiler. >> > > They can "to a very large extent". But this does NOT include reordering > members of a struct. The most they can do is add padding between > members. That is not reordering. > Read up a bit about the "as if" rule. You might also want to look up the "-fipa-struct-reorg" flag to gcc, which existed between versions 4.4 and 4.8. Here's a link so that you don't have to google: <http://stackoverflow.com/questions/14671253/is-there-a-gcc-keyword-to-allow-structure-reordering> And here's a paper discussing it on the Pathscale compiler: <http://www.capsl.udel.edu/conferences/open64/2008/Papers/111.pdf> Of course, it is conceivable that /you/ understand C and C++ far better than the people writing these compilers - but I think it is unlikely.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-01 21:02 -0400 |
| Message-ID | <nqaj3f$mv2$2@jstuckle.eternal-september.org> |
| In reply to | #44709 |
On 9/1/2016 5:14 PM, David Brown wrote: > On 01/09/16 21:34, Jerry Stuckle wrote: >> On 9/1/2016 3:35 AM, David Brown wrote: >>> On 01/09/16 05:17, Jerry Stuckle wrote: > >>>> >>>> Incorrect. Order of data members in the struct must be as they are >>>> declared in the struct. There may be padding between the members, but >>>> the order cannot change. >>>> >>>> Compilers cannot "generate anything they want as long as the runs as >>>> if". They are bound by other rules. >>> >>> No, to a very large extent they /can/ generate anything they want - as >>> long as the code runs "as if" it followed the rules strictly. This is >>> one of the key points for an optimising compiler. >>> >> >> They can "to a very large extent". But this does NOT include reordering >> members of a struct. The most they can do is add padding between >> members. That is not reordering. >> > > Read up a bit about the "as if" rule. > > You might also want to look up the "-fipa-struct-reorg" flag to gcc, > which existed between versions 4.4 and 4.8. > > Here's a link so that you don't have to google: > > <http://stackoverflow.com/questions/14671253/is-there-a-gcc-keyword-to-allow-structure-reordering> > > > And here's a paper discussing it on the Pathscale compiler: > > <http://www.capsl.udel.edu/conferences/open64/2008/Papers/111.pdf> > > Of course, it is conceivable that /you/ understand C and C++ far better > than the people writing these compilers - but I think it is unlikely. > > And it is conceivable the quote I got from the standard shows how wrong you are. But you never read that quote, did you? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-02 09:35 +0200 |
| Message-ID | <nqba4f$cp8$1@dont-email.me> |
| In reply to | #44716 |
On 02/09/16 03:02, Jerry Stuckle wrote: > On 9/1/2016 5:14 PM, David Brown wrote: >> On 01/09/16 21:34, Jerry Stuckle wrote: >>> On 9/1/2016 3:35 AM, David Brown wrote: >>>> On 01/09/16 05:17, Jerry Stuckle wrote: >> >>>>> >>>>> Incorrect. Order of data members in the struct must be as they are >>>>> declared in the struct. There may be padding between the members, but >>>>> the order cannot change. >>>>> >>>>> Compilers cannot "generate anything they want as long as the runs as >>>>> if". They are bound by other rules. >>>> >>>> No, to a very large extent they /can/ generate anything they want - as >>>> long as the code runs "as if" it followed the rules strictly. This is >>>> one of the key points for an optimising compiler. >>>> >>> >>> They can "to a very large extent". But this does NOT include reordering >>> members of a struct. The most they can do is add padding between >>> members. That is not reordering. >>> >> >> Read up a bit about the "as if" rule. >> >> You might also want to look up the "-fipa-struct-reorg" flag to gcc, >> which existed between versions 4.4 and 4.8. >> >> Here's a link so that you don't have to google: >> >> <http://stackoverflow.com/questions/14671253/is-there-a-gcc-keyword-to-allow-structure-reordering> >> >> >> And here's a paper discussing it on the Pathscale compiler: >> >> <http://www.capsl.udel.edu/conferences/open64/2008/Papers/111.pdf> >> >> Of course, it is conceivable that /you/ understand C and C++ far better >> than the people writing these compilers - but I think it is unlikely. >> >> > > And it is conceivable the quote I got from the standard shows how wrong > you are. But you never read that quote, did you? > Yes, I read the quotation. And note here that I referenced compiler writers opinions on applying the as-if rule to struct layout - not just my own. Are you telling me that you know better than they do? And I see from your other posts that you believe "the as-if rule applies to execution, not memory layout". If that belief were true, then you would be correct that struct layout is exempt from as-if optimisation. However, it is /not/ true. There are two reasons for me saying this. First, there is nowhere in the standards (C standards at least - I haven't read as much of the C++ standards) that makes this distinction. Secondly, as long as we are talking about memory that can only be seen from within the program (while following the rules of C), memory layout is nothing more than an effect of execution. The way a struct is laid out is not observable behaviour in itself, and thus the compiler is free to change it. It is /not/ free to change struct layout when that data is passed to external functions, written to files, or has volatile behaviour - those are observable effects. But if the data stays within the program as known to the compiler, the compiler is free to do as it wants.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-02 08:50 -0400 |
| Message-ID | <nqbsho$7cs$1@jstuckle.eternal-september.org> |
| In reply to | #44726 |
On 9/2/2016 3:35 AM, David Brown wrote: > On 02/09/16 03:02, Jerry Stuckle wrote: >> On 9/1/2016 5:14 PM, David Brown wrote: >>> On 01/09/16 21:34, Jerry Stuckle wrote: >>>> On 9/1/2016 3:35 AM, David Brown wrote: >>>>> On 01/09/16 05:17, Jerry Stuckle wrote: >>> >>>>>> >>>>>> Incorrect. Order of data members in the struct must be as they are >>>>>> declared in the struct. There may be padding between the members, but >>>>>> the order cannot change. >>>>>> >>>>>> Compilers cannot "generate anything they want as long as the runs as >>>>>> if". They are bound by other rules. >>>>> >>>>> No, to a very large extent they /can/ generate anything they want - as >>>>> long as the code runs "as if" it followed the rules strictly. This is >>>>> one of the key points for an optimising compiler. >>>>> >>>> >>>> They can "to a very large extent". But this does NOT include reordering >>>> members of a struct. The most they can do is add padding between >>>> members. That is not reordering. >>>> >>> >>> Read up a bit about the "as if" rule. >>> >>> You might also want to look up the "-fipa-struct-reorg" flag to gcc, >>> which existed between versions 4.4 and 4.8. >>> >>> Here's a link so that you don't have to google: >>> >>> <http://stackoverflow.com/questions/14671253/is-there-a-gcc-keyword-to-allow-structure-reordering> >>> >>> >>> And here's a paper discussing it on the Pathscale compiler: >>> >>> <http://www.capsl.udel.edu/conferences/open64/2008/Papers/111.pdf> >>> >>> Of course, it is conceivable that /you/ understand C and C++ far better >>> than the people writing these compilers - but I think it is unlikely. >>> >>> >> >> And it is conceivable the quote I got from the standard shows how wrong >> you are. But you never read that quote, did you? >> > > Yes, I read the quotation. And note here that I referenced compiler > writers opinions on applying the as-if rule to struct layout - not just > my own. Are you telling me that you know better than they do? > The as-if rule applies to execution. If it applied here, 9.2.13 would be meaningless. > And I see from your other posts that you believe "the as-if rule applies > to execution, not memory layout". If that belief were true, then you > would be correct that struct layout is exempt from as-if optimisation. > However, it is /not/ true. > Once again you are incorrect. > There are two reasons for me saying this. First, there is nowhere in > the standards (C standards at least - I haven't read as much of the C++ > standards) that makes this distinction. > Again you are incorrect. The same rule applies to C. > Secondly, as long as we are talking about memory that can only be seen > from within the program (while following the rules of C), memory layout > is nothing more than an effect of execution. The way a struct is laid > out is not observable behaviour in itself, and thus the compiler is free > to change it. > The struct layout is observable behavior, and cannot be changed. 9.2.13 says so. > It is /not/ free to change struct layout when that data is passed to > external functions, written to files, or has volatile behaviour - those > are observable effects. But if the data stays within the program as > known to the compiler, the compiler is free to do as it wants. > Sorry, you are once again wrong. The compiler doesn't know what a function does. You are really grasping at straws now, David. Just admit you are wrong and move on. Or explain why 9.2.13 exists, when according to you, it is meaningless. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-02 17:59 +0200 |
| Message-ID | <nqc7lh$f15$1@dont-email.me> |
| In reply to | #44733 |
On 02/09/16 14:50, Jerry Stuckle wrote: > On 9/2/2016 3:35 AM, David Brown wrote: >> On 02/09/16 03:02, Jerry Stuckle wrote: >>> On 9/1/2016 5:14 PM, David Brown wrote: >>>> On 01/09/16 21:34, Jerry Stuckle wrote: >>>>> On 9/1/2016 3:35 AM, David Brown wrote: >>>>>> On 01/09/16 05:17, Jerry Stuckle wrote: >>>> >>>>>>> >>>>>>> Incorrect. Order of data members in the struct must be as they are >>>>>>> declared in the struct. There may be padding between the members, but >>>>>>> the order cannot change. >>>>>>> >>>>>>> Compilers cannot "generate anything they want as long as the runs as >>>>>>> if". They are bound by other rules. >>>>>> >>>>>> No, to a very large extent they /can/ generate anything they want - as >>>>>> long as the code runs "as if" it followed the rules strictly. This is >>>>>> one of the key points for an optimising compiler. >>>>>> >>>>> >>>>> They can "to a very large extent". But this does NOT include reordering >>>>> members of a struct. The most they can do is add padding between >>>>> members. That is not reordering. >>>>> >>>> >>>> Read up a bit about the "as if" rule. >>>> >>>> You might also want to look up the "-fipa-struct-reorg" flag to gcc, >>>> which existed between versions 4.4 and 4.8. >>>> >>>> Here's a link so that you don't have to google: >>>> >>>> <http://stackoverflow.com/questions/14671253/is-there-a-gcc-keyword-to-allow-structure-reordering> >>>> >>>> >>>> And here's a paper discussing it on the Pathscale compiler: >>>> >>>> <http://www.capsl.udel.edu/conferences/open64/2008/Papers/111.pdf> >>>> >>>> Of course, it is conceivable that /you/ understand C and C++ far better >>>> than the people writing these compilers - but I think it is unlikely. >>>> >>>> >>> >>> And it is conceivable the quote I got from the standard shows how wrong >>> you are. But you never read that quote, did you? >>> >> >> Yes, I read the quotation. And note here that I referenced compiler >> writers opinions on applying the as-if rule to struct layout - not just >> my own. Are you telling me that you know better than they do? >> > > The as-if rule applies to execution. If it applied here, 9.2.13 would > be meaningless. No, it would not be meaningless - it is as meaningful as the rest of the standard. The as-if rule says that could must produce observable behaviour as though it slavishly followed the standard - including 9.2.13. As long as the program produces the same observable behaviour, it can rearrange structs as it wants - just as it can make optimisations that appear to contradict any other rules. There is nothing special about 9.2.13 in this regard. Now, you failed to answer my question - are /you/ claiming to understand the standards better than the people who wrote the Pathscale compiler and the people who wrote gcc? > >> And I see from your other posts that you believe "the as-if rule applies >> to execution, not memory layout". If that belief were true, then you >> would be correct that struct layout is exempt from as-if optimisation. >> However, it is /not/ true. >> > > Once again you are incorrect. > >> There are two reasons for me saying this. First, there is nowhere in >> the standards (C standards at least - I haven't read as much of the C++ >> standards) that makes this distinction. >> > > Again you are incorrect. The same rule applies to C. I am happy to believe that the same rule applies here in C and C++. It is simply not the rule that you think it is. > >> Secondly, as long as we are talking about memory that can only be seen >> from within the program (while following the rules of C), memory layout >> is nothing more than an effect of execution. The way a struct is laid >> out is not observable behaviour in itself, and thus the compiler is free >> to change it. >> > > The struct layout is observable behavior, and cannot be changed. 9.2.13 > says so. No, 9.2.13 says nothing about observable behaviour. Read it again, and see if you spot that phrase. And in the definition of observable behaviour (section 1.9.8), no mention is made of struct layout or memory (except in regard to volatile accesses). You are simply wrong here. You are making things up that are not in the standards. > >> It is /not/ free to change struct layout when that data is passed to >> external functions, written to files, or has volatile behaviour - those >> are observable effects. But if the data stays within the program as >> known to the compiler, the compiler is free to do as it wants. >> > > Sorry, you are once again wrong. The compiler doesn't know what a > function does. You are really grasping at straws now, David. If the compiler does not know what a function does (such as for external functions), then it must assume the worst - it must assume it has volatile accesses to all globally visible data, for example, and thus any such data must follow the rules for struct layout. But it can assume that the external function has defined behaviour - and thus cannot read local data or file static data that has not escaped in some way, and it can re-arrange such data as it likes. And if the compiler knows the definition of the function, then it will know which re-arrangements and optimisations are safe. With whole-program or link-time optimisation, the compiler may even know the definitions of every function in the program. > > Just admit you are wrong and move on. Or explain why 9.2.13 exists, > when according to you, it is meaningless. > No, only you have claimed it is meaningless. I am quite happy with its meaning.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-09-02 12:49 -0400 |
| Message-ID | <nqcai2$pte$1@jstuckle.eternal-september.org> |
| In reply to | #44744 |
On 9/2/2016 11:59 AM, David Brown wrote:
> On 02/09/16 14:50, Jerry Stuckle wrote:
>> On 9/2/2016 3:35 AM, David Brown wrote:
>>> On 02/09/16 03:02, Jerry Stuckle wrote:
>>>> On 9/1/2016 5:14 PM, David Brown wrote:
>>>>> On 01/09/16 21:34, Jerry Stuckle wrote:
>>>>>> On 9/1/2016 3:35 AM, David Brown wrote:
>>>>>>> On 01/09/16 05:17, Jerry Stuckle wrote:
>>>>>
>>>>>>>>
>>>>>>>> Incorrect. Order of data members in the struct must be as they are
>>>>>>>> declared in the struct. There may be padding between the members, but
>>>>>>>> the order cannot change.
>>>>>>>>
>>>>>>>> Compilers cannot "generate anything they want as long as the runs as
>>>>>>>> if". They are bound by other rules.
>>>>>>>
>>>>>>> No, to a very large extent they /can/ generate anything they want - as
>>>>>>> long as the code runs "as if" it followed the rules strictly. This is
>>>>>>> one of the key points for an optimising compiler.
>>>>>>>
>>>>>>
>>>>>> They can "to a very large extent". But this does NOT include reordering
>>>>>> members of a struct. The most they can do is add padding between
>>>>>> members. That is not reordering.
>>>>>>
>>>>>
>>>>> Read up a bit about the "as if" rule.
>>>>>
>>>>> You might also want to look up the "-fipa-struct-reorg" flag to gcc,
>>>>> which existed between versions 4.4 and 4.8.
>>>>>
>>>>> Here's a link so that you don't have to google:
>>>>>
>>>>> <http://stackoverflow.com/questions/14671253/is-there-a-gcc-keyword-to-allow-structure-reordering>
>>>>>
>>>>>
>>>>> And here's a paper discussing it on the Pathscale compiler:
>>>>>
>>>>> <http://www.capsl.udel.edu/conferences/open64/2008/Papers/111.pdf>
>>>>>
>>>>> Of course, it is conceivable that /you/ understand C and C++ far better
>>>>> than the people writing these compilers - but I think it is unlikely.
>>>>>
>>>>>
>>>>
>>>> And it is conceivable the quote I got from the standard shows how wrong
>>>> you are. But you never read that quote, did you?
>>>>
>>>
>>> Yes, I read the quotation. And note here that I referenced compiler
>>> writers opinions on applying the as-if rule to struct layout - not just
>>> my own. Are you telling me that you know better than they do?
>>>
>>
>> The as-if rule applies to execution. If it applied here, 9.2.13 would
>> be meaningless.
>
> No, it would not be meaningless - it is as meaningful as the rest of the
> standard. The as-if rule says that could must produce observable
> behaviour as though it slavishly followed the standard - including
> 9.2.13. As long as the program produces the same observable behaviour,
> it can rearrange structs as it wants - just as it can make optimisations
> that appear to contradict any other rules. There is nothing special
> about 9.2.13 in this regard.
>
> Now, you failed to answer my question - are /you/ claiming to understand
> the standards better than the people who wrote the Pathscale compiler
> and the people who wrote gcc?
>
>>
>>> And I see from your other posts that you believe "the as-if rule applies
>>> to execution, not memory layout". If that belief were true, then you
>>> would be correct that struct layout is exempt from as-if optimisation.
>>> However, it is /not/ true.
>>>
>>
>> Once again you are incorrect.
>>
>>> There are two reasons for me saying this. First, there is nowhere in
>>> the standards (C standards at least - I haven't read as much of the C++
>>> standards) that makes this distinction.
>>>
>>
>> Again you are incorrect. The same rule applies to C.
>
> I am happy to believe that the same rule applies here in C and C++. It
> is simply not the rule that you think it is.
>
>>
>>> Secondly, as long as we are talking about memory that can only be seen
>>> from within the program (while following the rules of C), memory layout
>>> is nothing more than an effect of execution. The way a struct is laid
>>> out is not observable behaviour in itself, and thus the compiler is free
>>> to change it.
>>>
>>
>> The struct layout is observable behavior, and cannot be changed. 9.2.13
>> says so.
>
> No, 9.2.13 says nothing about observable behaviour. Read it again, and
> see if you spot that phrase. And in the definition of observable
> behaviour (section 1.9.8), no mention is made of struct layout or memory
> (except in regard to volatile accesses).
>
> You are simply wrong here. You are making things up that are not in the
> standards.
>
No, you are making up things which are not what the standard says. No,
section 1.9.8 doesn't say anything about struct layout. That is not its
purpose.
And 1.9.1 refers to the remainder of section 1.9, not the entire
standard. Plus, 1.9 refers to program execution - not memory layout.
Layout is not behavior.
1.9.1 is for things like the following:
a = 2;
b = 3;
c = 2;
Can be reordered to
a = c = 2;
b = 3;
Of course it's more than that. But to stay in line with what you can
understand, I'm keeping it simple.
>>
>>> It is /not/ free to change struct layout when that data is passed to
>>> external functions, written to files, or has volatile behaviour - those
>>> are observable effects. But if the data stays within the program as
>>> known to the compiler, the compiler is free to do as it wants.
>>>
>>
>> Sorry, you are once again wrong. The compiler doesn't know what a
>> function does. You are really grasping at straws now, David.
>
> If the compiler does not know what a function does (such as for external
> functions), then it must assume the worst - it must assume it has
> volatile accesses to all globally visible data, for example, and thus
> any such data must follow the rules for struct layout. But it can
> assume that the external function has defined behaviour - and thus
> cannot read local data or file static data that has not escaped in some
> way, and it can re-arrange such data as it likes.
>
And how is the compiler to know that? Does it predict the future?
struct mystruc {
int a, b;
};
func f() }
struct mystruct ms;
ms.a = 1; // The structure has been defined
ms.b = 2;
write(ms); // NOW the compiler knows that there is a call
}
It is a one-pass compiler. There is no way for it to know when
assigning ms.a that there is going to be a call to another function.
> And if the compiler knows the definition of the function, then it will
> know which re-arrangements and optimisations are safe. With
> whole-program or link-time optimisation, the compiler may even know the
> definitions of every function in the program.
>
Not before the structure has been defined.
>>
>> Just admit you are wrong and move on. Or explain why 9.2.13 exists,
>> when according to you, it is meaningless.
>>
>
> No, only you have claimed it is meaningless. I am quite happy with its
> meaning.
>
No, you said the compiler is free to reorder the memory. That is in
direct conflict with 9.2.13. So it is you who declare it meaningless.
You are just digging yourself a deeper and deeper hole,
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-02 20:36 +0200 |
| Message-ID | <nqcgs9$hmf$1@dont-email.me> |
| In reply to | #44750 |
On 02/09/16 18:49, Jerry Stuckle wrote:
> On 9/2/2016 11:59 AM, David Brown wrote:
>> On 02/09/16 14:50, Jerry Stuckle wrote:
>>> On 9/2/2016 3:35 AM, David Brown wrote:
>>>> On 02/09/16 03:02, Jerry Stuckle wrote:
<snip>
>>>> Secondly, as long as we are talking about memory that can only be seen
>>>> from within the program (while following the rules of C), memory layout
>>>> is nothing more than an effect of execution. The way a struct is laid
>>>> out is not observable behaviour in itself, and thus the compiler is free
>>>> to change it.
>>>>
>>>
>>> The struct layout is observable behavior, and cannot be changed. 9.2.13
>>> says so.
>>
>> No, 9.2.13 says nothing about observable behaviour. Read it again, and
>> see if you spot that phrase. And in the definition of observable
>> behaviour (section 1.9.8), no mention is made of struct layout or memory
>> (except in regard to volatile accesses).
>>
>> You are simply wrong here. You are making things up that are not in the
>> standards.
>>
>
> No, you are making up things which are not what the standard says. No,
> section 1.9.8 doesn't say anything about struct layout. That is not its
> purpose.
>
I did not say that 1.9.8 discussed the layout of structs - I said it did
/not/ cover struct layout.
> And 1.9.1 refers to the remainder of section 1.9, not the entire
> standard. Plus, 1.9 refers to program execution - not memory layout.
> Layout is not behavior.
1.9.1 refers to the observable behaviour, which is defined "below" in
1.9.8. Section 1.9.8 refers to the entire rest of the standard.
And memory layout is behaviour.
>
> 1.9.1 is for things like the following:
>
> a = 2;
> b = 3;
> c = 2;
>
> Can be reordered to
>
> a = c = 2;
> b = 3;
>
> Of course it's more than that. But to stay in line with what you can
> understand, I'm keeping it simple.
It covers /vastly/ more than that. It is the basis for the concept of
an "optimising compiler".
>
>>>
>>>> It is /not/ free to change struct layout when that data is passed to
>>>> external functions, written to files, or has volatile behaviour - those
>>>> are observable effects. But if the data stays within the program as
>>>> known to the compiler, the compiler is free to do as it wants.
>>>>
>>>
>>> Sorry, you are once again wrong. The compiler doesn't know what a
>>> function does. You are really grasping at straws now, David.
>>
>> If the compiler does not know what a function does (such as for external
>> functions), then it must assume the worst - it must assume it has
>> volatile accesses to all globally visible data, for example, and thus
>> any such data must follow the rules for struct layout. But it can
>> assume that the external function has defined behaviour - and thus
>> cannot read local data or file static data that has not escaped in some
>> way, and it can re-arrange such data as it likes.
>>
>
> And how is the compiler to know that? Does it predict the future?
>
> struct mystruc {
> int a, b;
> };
>
> func f() }
> struct mystruct ms;
> ms.a = 1; // The structure has been defined
> ms.b = 2;
> write(ms); // NOW the compiler knows that there is a call
> }
>
> It is a one-pass compiler. There is no way for it to know when
> assigning ms.a that there is going to be a call to another function.
>
That was perhaps true in the days when compilers read programs on
punched cards. But these days, compilers are smarter than that. Before
the compiler generates anything for "ms.a", it has already parsed all
the rest of the file - and perhaps all the other files in the program.
Perhaps you use a one-pass compiler, with all its limitations. I don't
know how many passes modern gcc or clang have, but according to a quick
google gcc 4.6.2 had 207 unique passes.
>
>> And if the compiler knows the definition of the function, then it will
>> know which re-arrangements and optimisations are safe. With
>> whole-program or link-time optimisation, the compiler may even know the
>> definitions of every function in the program.
>>
>
> Not before the structure has been defined.
The compiler collects all the information about the program, data,
structures, functions, etc., before it starts organising the data or
generating the code. That's the point of whole-program optimisation.
>
>>>
>>> Just admit you are wrong and move on. Or explain why 9.2.13 exists,
>>> when according to you, it is meaningless.
>>>
>>
>> No, only you have claimed it is meaningless. I am quite happy with its
>> meaning.
>>
>
> No, you said the compiler is free to reorder the memory. That is in
> direct conflict with 9.2.13. So it is you who declare it meaningless.
Yes, the compiler is free to re-order anything it likes - code,
functions, memory, structs, whatever - as long as the observable
behaviour is unchanged.
>
> You are just digging yourself a deeper and deeper hole,
>
You simply don't understand much about how compilers work. That's okay,
you don't have to know how they work in order to use them. But you do
look silly by continuing to flaunt your ignorance.
But keep going, if you like - it is somewhat entertaining. The idea
that a modern C compiler is one-pass and generates the code for one line
of source before reading the next line gave me a bit of a chuckle.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web