Andrew Dunstan <[EMAIL PROTECTED]> writes:
Just a thought - if we are messing with the List definition should we at the same time address the strict aliasing issues arising from Node's multiple personalities (I think it is the main offender).
Or is the intention never to do this, or not any time soon?
I have no intention of messing with the Node concept; it's built into the backend far too firmly to consider any significant change.
I don't think we understand exactly what we'd have to avoid in order to enable strict aliasing, but if it requires getting rid of Node then it ain't happening. (I doubt that it does, anyway. I think the issues are probably quite localized. The main problem I see is that we don't have any trustworthy check to find out everyplace that strict aliasing could cause problems.)
*nod* (I made the last point previously :-) )
I don't claim that my understanding is anything like complete.
However, in the case of gcc it might be easier to fix than you think, without a lot of declaration rearranging, using gcc's new "may_alias" type attribute, (see http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Type-Attributes.html ) which could probably be added in a very few places (e.g. Node's typedef) to fix things.
Of course, that doesn't help when vendor foo's compiler starts doing type-based alias analysis.
Still, to quote "Airplane", that's not important right now.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
