Re: [HACKERS] ANSI-strict pointer aliasing rules
On Wed, Apr 26, 2006 at 08:13:21PM -0400, Tom Lane wrote: Actually, if xlc is behaving as Taral says then I'm pretty convinced it's *broken*; it is assuming far more than is allowed even by the ANSI aliasing rules. As I read the spec, ANSI aliasing says that a given value must always be accessed through equivalent (up to signedness) primitive types, ie, if you store through an int pointer and fetch through a long pointer the compiler is allowed to reorder those two references. That's right, except I read object, not primative type. The question revolves a bit around what an object is. This discussion on the GCC lists [1] suggests that the syntax a-b is merely syntactic sugar for (*a).b and thus the object being accessed is (*a), the type of b is not relevent to the decision. The standard [2] (at least that version) says: 3.14 object region of data storage in the execution environment, the contents of which can represent values So is not limited to primitive types. In the example Taral gives, both field references are to fields of type NodeTag. I don't see anything in the spec that allows the compiler to assume they are distinct variables just because they are members of different struct types. The spec restriction is defined in terms of the lvalue type of the particular store or fetch access, not on what kind of structure it's part of. Well, I imagine it doesn't help that the result of malloc(), which normally can't alias anything, is assigned to a global variable of a particular type, and subsequently cast to its actual type. However, the posters original example doesn't exist in the current codebase (we never assign T_String to a tag field, only to the type field), so wherever the problem is, it's not here. At the end of the day, our use of pointer casts makes the strict-aliasing rules a risk so we're hardly likely to enable it anytime soon. Have a nice day, [1] http://gcc.gnu.org/ml/gcc/2003-02/msg01438.html [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf Quotes from standard: 6.5 Expressions 7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types: rules 6.3.2.1 Lvalues, arrays, and function designators An lvalue is an expression with an object type or an incomplete type other than void; -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] ANSI-strict pointer aliasing rules
4. Find the option for disabling strict alias and get configure to add that. You'll still lose performance, but the option is -qalias=noansi. My old xlc does not show that option, it is unfortunately version specific. The currently compatible option to turn it off would be -qnoansialias So we can use: xlc -qnoansialias The default cc options are: -qlanglvl=extended -qnoro -qnoroconst So I guess we could also use (but above is imho clearer/better): cc -qro -qroconst -qlanglvl=extc89 Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ANSI-strict pointer aliasing rules
Taral wrote: 4. Find the option for disabling strict alias and get configure to add that. You'll still lose performance, but the option is -qalias=noansi. Next time we have this discussion I wish someone would actually document the performance differences. IIRC most of what I have seen makes it at best marginal. Personally, I think this whole mess results from a bad case of committee-itis. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Thu, Apr 27, 2006 at 07:34:19PM +0930, Andrew Dunstan wrote:
Next time we have this discussion I wish someone would actually document
the performance differences. IIRC most of what I have seen makes it at
best marginal.
I can imagine there are cases where the performance difference is
nontrivial. Take this (somewhat contrived) example:
int *i;
char *c;
while( *i BIG_NUMBER )
*i += *c;
With strict aliasing, the compiler need only load *c once, without it
needs to load it each time through the loop because it has to consider
the possibility that 'i' and 'c' point to the same memory location.
PostgreSQL doesn't actually have loops of this kind so it's not
something we need worry about. And you can acheive all the benefits by
explicitly loading *c into a local variable before the loop. I can
beleive that certain RISC architectures would benefit more than
something like the Intel CISC architecture.
Personally, I think this whole mess results from a bad case of
committee-itis.
I think the goal was noble (at least, according to the best version
I've heard so far): make it easier to compete with Fortran in numerical
processing. If you define a struct vector { double x,y,z,d; } and the
compiler can assume that values in that structure can only be changed
via a (vector*) pointer, it can do things like load an array of them
into a large parallel processing unit.
Ofcourse, this is useless for most of the programs written in C, and in
C99 they fixed it the right way using the restrict keyword, which is
actually far more usful for the above purpose than strict-aliasing.
Compiler writers love it because it makes it easier for them, but
actual benefits, hmm...
Have a nice day,
--
Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/
From each according to his ability. To each according to his ability to
litigate.
signature.asc
Description: Digital signature
Re: [HACKERS] ANSI-strict pointer aliasing rules
Martijn van Oosterhout kleptog@svana.org writes: That's right, except I read object, not primative type. The question revolves a bit around what an object is. This discussion on the GCC lists [1] suggests that the syntax a-b is merely syntactic sugar for (*a).b and thus the object being accessed is (*a), the type of b is not relevent to the decision. The part of the spec that I'm looking at says [#7] An object shall have its stored value accessed only by an lvalue expression that has one of the following types:61) -- a type compatible with the effective type of the object, -- a qualified version of a type compatible with the effective type of the object, -- a type that is the signed or unsigned type corresponding to the effective type of the object, -- a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, -- an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or -- a character type. 61)The intent of this list is to specify those circumstances in which an object may or may not be aliased. Which wouldn't be especially interesting, except for that footnote (which in fact is one of only two uses of alias in the document; there isn't any other discussion about aliasing at all). As I read this, the aliasing rules are driven by the type of the lvalue being fetched or assigned. Thus, when you fetch or assign a whole struct, your reading would be correct, but not for a fetch or assignment of a single struct field. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Thu, Apr 27, 2006 at 12:52:42PM +0200, Martijn van Oosterhout wrote: Next time we have this discussion I wish someone would actually document the performance differences. IIRC most of what I have seen makes it at best marginal. I can imagine there are cases where the performance difference is nontrivial. Take this (somewhat contrived) example: int *i; char *c; while( *i BIG_NUMBER ) *i += *c; With strict aliasing, the compiler need only load *c once, without it needs to load it each time through the loop because it has to consider the possibility that 'i' and 'c' point to the same memory location. PostgreSQL doesn't actually have loops of this kind so it's not something we need worry about. And you can acheive all the benefits by ... PostgreSQL might not - however PostgreSQL does use GLIBC, which does have inlined or preprocessor defined code. I haven't done the timings myself - but I think the optimization would in theory apply to wider code than just the above. *c doesn't need to be constant. It can be moving, as would be in the case of an strcpy() or memcpy() implementation. As you pointed out, such things as auto-vectorization become impossible if it cannot guarantee that the data is different. The aliasing rules are one part, the 'restrict' keyword is the more important part I would imagine. Not dissimilar to the C compiler auto-assigning variables into registers, but allowing for the designer to hint using the 'register' keyword. In the modern day, I see fewer and fewer people using 'register', as not only does the compiler tend to get it right, but the compiler may actually do a better job. I could see the same thing being true of auto-detect using aliasing rules vs 'restrict' keyword usage. Even if it was only 1% - 2%. Isn't it worth it? :-) Especially for a practice, that under existing code, has implementation defined semantics. It might not work in the future, or with a new optimizer mode that comes out, or a new platform... Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ANSI-strict pointer aliasing rules
[EMAIL PROTECTED] writes: Even if it was only 1% - 2%. Isn't it worth it? :-) No. According to the ancient saying, I can make this program arbitrarily fast ... if it doesn't have to give the right answer. Percentage-point improvements are not worth the risk of introducing hard-to-find, compiler-and-hardware-dependent bugs. Show me how to find/prevent those bugs, and I'm all for going with the stricter rules. But you're so far off base with the above argument that I wonder whether we understand each other at all. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Thu, Apr 27, 2006 at 10:49:02AM -0400, Tom Lane wrote: [EMAIL PROTECTED] writes: Even if it was only 1% - 2%. Isn't it worth it? :-) No. According to the ancient saying, I can make this program arbitrarily fast ... if it doesn't have to give the right answer. Percentage-point improvements are not worth the risk of introducing hard-to-find, compiler-and-hardware-dependent bugs. Addressing the aliasing rule concerns raised by the compiler, at least in theory, is improving the compatibility of the program, and reducing the number of bugs that may be exposed under unusual circumstances. If PostgreSQL isn't alias safe - it means that there is casting happening, that is not generally accepted as valid, minimizing the optimization potential of the code, and certainly not guaranteed to be correct. Every cast in C has the potential to contain bugs today, or tomorrow when somebody changes the lvalue or rvalue. If the types are incompatible, according the compiler, the odds of a bug happening today or tomorrow become greater. If you are worried about PostgreSQL making use of the optimization potential - and suggesting that by PostgreSQL making this impossible currently, that you are preventing a compiler-and-hardware-dependent bug, I strongly disagree. If most code is compiled with the aliasing rules enabled in the optimizer, and your code is compiled with the aliasing rules disabled, then you are using the lesser used optimization paths in the compiler, actually raising the likelihood of such a compiler bug being exposed. Compilers do have bugs - and by choosing to use the non-standard optimization models, the chance of you finding it first increases. You don't really want to be first. You want the regression testing of the compiler to be first. :-) Show me how to find/prevent those bugs, and I'm all for going with the stricter rules. But you're so far off base with the above argument that I wonder whether we understand each other at all. I think we can agree on the intrusiveness of the change needing to be linear or less to the value of the change. If the fix is simple, and it generates a 1% - 2% gain - you are buying both performance, and correctness. Personally, I value correctness. I think some would value performance though. We're both playing opposite roles, to lead to a balanced discussion, which is good. Not off base. Contrary. How could you expect to have a balanced discussion otherwise? :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ANSI-strict pointer aliasing rules
I ran afoul of these rules the other day when compiling pgsql 8.1 on AIX. The configure scripts are set up to look for xlc instead of cc, and that command invokes cc with -qalias=ansi, the ANSI-strict pointer aliasing mode. Can you please explain what exactly was not working ? xlc has in the past shown warnings that were actually problematic code that gcc did not show (and the cc variant of xlc also does not show). Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Thu, Apr 27, 2006 at 11:08:59AM -0400, [EMAIL PROTECTED] wrote: ... If PostgreSQL isn't alias safe - it means that there is casting happening, that is not generally accepted as valid, minimizing the optimization potential of the code, and certainly not guaranteed to be correct. Every cast in C has the potential to contain bugs today, or tomorrow when somebody changes the lvalue or rvalue. If the types are incompatible, according the compiler, the odds of a bug happening today or tomorrow become greater. You're right, PostgreSQL uses a form of subclassing, so that a (for example) struct ArrayRefExprState is occasionally referred to using a (struct ExprState*) or even a (struct Node*). In C, the logical way to get that to work it by casting, do you have a better way? The fact is, strict-aliasing only breaks things in the name of performence. I think we can agree on the intrusiveness of the change needing to be linear or less to the value of the change. If the fix is simple, and it generates a 1% - 2% gain - you are buying both performance, and correctness. Personally, I value correctness. I think some would value performance though. The fix is not simple. We wouldn't have disabled it if the fix was easy. Basically, with strict-aliasing enabled, things break. The compiler won't identify all the issues for you, how do you know you're safe? So the system is actually *more* correct with strict-aliasing disabled, because then it does exactly what the code says... The two major other places we use casts are converting Datums to their actual types, and our MemSet which replaces the braindead GCC one. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] ANSI-strict pointer aliasing rules
Martijn van Oosterhout kleptog@svana.org writes: You're right, PostgreSQL uses a form of subclassing, so that a (for example) struct ArrayRefExprState is occasionally referred to using a (struct ExprState*) or even a (struct Node*). In C, the logical way to get that to work it by casting, do you have a better way? There are other ways of achieving the same thing. Structs containing a union for the subclass fields for example. -- greg ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ANSI-strict pointer aliasing rules
Greg Stark [EMAIL PROTECTED] writes: Martijn van Oosterhout kleptog@svana.org writes: You're right, PostgreSQL uses a form of subclassing, so that a (for example) struct ArrayRefExprState is occasionally referred to using a (struct ExprState*) or even a (struct Node*). In C, the logical way to get that to work it by casting, do you have a better way? There are other ways of achieving the same thing. Structs containing a union for the subclass fields for example. Doesn't achieve the same thing, unless you mandate that every part of the system use the identical massively-overloaded union struct to refer to every node. That would (a) defeat the purpose of extensibility, and (b) make the code more error prone not less so (since it'd be notationally easy to refer to a field that's not actually present in the given node subtype). regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ANSI-strict pointer aliasing rules
On 4/27/06, Zeugswetter Andreas DCP SD [EMAIL PROTECTED] wrote:
Can you please explain what exactly was not working ?
xlc has in the past shown warnings that were actually problematic code
that gcc did not show (and the cc variant of xlc also does not show).
This has nothing to do with warnings. With xlc version 6, this code:
Value *
makeString(char *str)
{
Value *v = makeNode(Value);
v-type = T_String;
v-val.str = str;
return v;
}
Will return objects whose type field is T_Value (650), because the
compiler reorders the assignment that makeNode makes with that of the
main function.
--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ANSI-strict pointer aliasing rules
On 4/27/06, Tom Lane [EMAIL PROTECTED] wrote:
Greg Stark [EMAIL PROTECTED] writes:
There are other ways of achieving the same thing. Structs containing a union
for the subclass fields for example.
Doesn't achieve the same thing, unless you mandate that every part of
the system use the identical massively-overloaded union struct to refer
to every node.
If we do subclassing like this:
struct Node { ... };
struct Value { struct Node; ... };
etc.
do we still run into the alias problem?
--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] ANSI-strict pointer aliasing rules
On 4/27/06, Taral [EMAIL PROTECTED] wrote:
If we do subclassing like this:
struct Node { ... };
struct Value { struct Node; ... };
etc.
do we still run into the alias problem?
Nope, it appears to get rid of the alias problem completely. But it
requires anonymous structure support (C99?) to work without changing
anything other than headers.
As a bonus, if we ever change Node, we don't have to update any other
structures...
--
Taral [EMAIL PROTECTED]
You can't prove anything.
-- Gödel's Incompetence Theorem
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Thu, Apr 27, 2006 at 12:21:55PM -0500, Taral wrote:
If we do subclassing like this:
struct Node { ... };
struct Value { struct Node; ... };
etc.
do we still run into the alias problem?
Nope, it appears to get rid of the alias problem completely. But it
requires anonymous structure support (C99?) to work without changing
anything other than headers.
On that compiler maybe, but what about others? What other problems does
strict-alias cause? Anyway, near as I can tell, anonymous structs are
not in the C standard and I don't think GCC supports them either...
As a bonus, if we ever change Node, we don't have to update any other
structures...
Node is unlikely to ever change, it's been like this for at least ten
years...
Have a nice day,
--
Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/
From each according to his ability. To each according to his ability to
litigate.
signature.asc
Description: Digital signature
Re: [HACKERS] ANSI-strict pointer aliasing rules
Tom Lane [EMAIL PROTECTED] writes: Greg Stark [EMAIL PROTECTED] writes: There are other ways of achieving the same thing. Structs containing a union for the subclass fields for example. Doesn't achieve the same thing, unless you mandate that every part of the system use the identical massively-overloaded union struct to refer to every node. Are you saying it's important to preserve the ability for modules to add new node types without notifying the rest of the code? I thought all the node types were defined in a single header file currently anyways. That would (a) defeat the purpose of extensibility, and (b) make the code more error prone not less so (since it'd be notationally easy to refer to a field that's not actually present in the given node subtype). You could use a local pointer to be preserve the existing model of a single point where the decision is made. That could be encapsulated in a macro that included an assertion to verify the type tag. It would be pretty cool to have a type-safe codebase. It just seems like too an awful lot of work for a mostly aesthetic improvement. -- greg ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ANSI-strict pointer aliasing rules
On 27 Apr 2006 15:25:45 -0400, Greg Stark [EMAIL PROTECTED] wrote: It would be pretty cool to have a type-safe codebase. It just seems like too an awful lot of work for a mostly aesthetic improvement. Does anyone have some benchmarks I can run? I can run tests to see if this aliasing makes a noticeable difference or not... -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ANSI-strict pointer aliasing rules
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: Doesn't achieve the same thing, unless you mandate that every part of the system use the identical massively-overloaded union struct to refer to every node. Are you saying it's important to preserve the ability for modules to add new node types without notifying the rest of the code? I thought all the node types were defined in a single header file currently anyways. No, they're scattered through at least half a dozen headers. We don't really have dynamic extensibility because the NodeTag enum is declared in just one place, but we do have separation of concerns: stuff dealing with parsenodes.h need not import all the executor node types, for instance. The big objection to a single-union-struct approach is that it forecloses any locality of knowledge about node types. (I also wonder how many compilers would give up the ghost entirely on being fed a union type of 250+ separate structs, with in aggregate several thousand fields ... and even if they didn't fail, how fast they'd compile code making heavy use of such a beast.) It would be pretty cool to have a type-safe codebase. It just seems like too an awful lot of work for a mostly aesthetic improvement. Yeah, I think that's how we all feel. I'd not even waste any time thinking about it, except that I'm afraid the compiler guys may eventually stop supporting the traditional semantics ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Thu, Apr 27, 2006 at 02:42:35PM -0500, Taral wrote: On 27 Apr 2006 15:25:45 -0400, Greg Stark [EMAIL PROTECTED] wrote: It would be pretty cool to have a type-safe codebase. It just seems like too an awful lot of work for a mostly aesthetic improvement. Does anyone have some benchmarks I can run? I can run tests to see if this aliasing makes a noticeable difference or not... You would have to fix the code first. :-) I completely back down when it comes down to the suspected intrusiveness of the change, causing too much upset. It's the idea that the aliasing rules are not worth following, that caused me to enter. Until a good patch is available, that is less intrusive than what people are suspecting, nothing is going to change. I suspect a patch to convert PostgreSQL to C++ wouldn't be welcomed. Haha... Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ANSI-strict pointer aliasing rules
I suspect a patch to convert PostgreSQL to C++ wouldn't be welcomed. Haha... Checking my calendar, I think you are about 26 days too late to make that suggestion... -rocco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] ANSI-strict pointer aliasing rules
Taral [EMAIL PROTECTED] writes: I ran afoul of these rules the other day when compiling pgsql 8.1 on AIX. The configure scripts are set up to look for xlc instead of cc, and that command invokes cc with -qalias=ansi, the ANSI-strict pointer aliasing mode. We've looked at this before. There's no way we are buying into the strict aliasing rules: it's not so much the code we know will break, as the fear of what we don't know about. gcc, at least, is utterly useless about warning about constructs that might change behavior under strict aliasing ... but without fairly reliable warnings of such problems, we have little hope of getting all the bugs out. You'll notice that configure already goes out of its way to force traditional aliasing for gcc, and I'd recommend doing the same for AIX's compiler. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Wed, Apr 26, 2006 at 03:45:00PM -0500, Taral wrote: I ran afoul of these rules the other day when compiling pgsql 8.1 on AIX. The configure scripts are set up to look for xlc instead of cc, and that command invokes cc with -qalias=ansi, the ANSI-strict pointer aliasing mode. PostgreSQL doesn't work with strict aliasing rules. That's why for GCC we pass -fno-strict-aliasing. What's the equivalent option for that compiler? The fix is one of two things: Well, there are a number of fixes, it's questionable whether it's worth the effort. In GCC you can mark structures that are aliased to avoid the problem (attribute((may_alias)) iirc), but we don't do that. 3. Get configure to select cc instead of xlc: No code change, loses some performance. 4. Find the option for disabling strict alias and get configure to add that. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Wed, Apr 26, 2006 at 04:58:31PM -0400, Tom Lane wrote:
We've looked at this before. There's no way we are buying into the
strict aliasing rules: it's not so much the code we know will break,
as the fear of what we don't know about. gcc, at least, is utterly
useless about warning about constructs that might change behavior
under strict aliasing ... but without fairly reliable warnings of
such problems, we have little hope of getting all the bugs out.
These warnings will never happen. Strict-aliasing could effect
anything, all you'd get would be zillions of useless warnings.
Take for example this innocuous looking code from libpq/hba.c:
static void
parse_hba_auth(ListCell **line_item, UserAuth *userauth_p,
char **auth_arg_p, bool *error_p)
{
char *token;
*auth_arg_p = NULL;
if (!*line_item)
{
Strict aliasing says that 'line_item' and 'auth_arg_p' can't point to
the same location because they are different types. Hence the
store/load could be overlapped safely. *We* know that will never be a
problem, but the compiler can't know, so it has to assume one way or
the other. With no-strict-aliasing, it can't reorder and it might add
wait-states instead, just in case (CPU dependant obviously).
The compiler could warn you about this, but it'd be useless since you
can't do anything about it anyway. In the grandparent's case I think
the compiler is being really stupid because it can know the two
pointers are the same. But I'm sure there are more subtle cases where
it won't know. PostgreSQL typecasts pointers fairly freely.
Have a nice day,
--
Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/
From each according to his ability. To each according to his ability to
litigate.
signature.asc
Description: Digital signature
Re: [HACKERS] ANSI-strict pointer aliasing rules
On 4/26/06, Martijn van Oosterhout kleptog@svana.org wrote: Well, there are a number of fixes, it's questionable whether it's worth the effort. In GCC you can mark structures that are aliased to avoid the problem (attribute((may_alias)) iirc), but we don't do that. There's also C99's restrict. 4. Find the option for disabling strict alias and get configure to add that. You'll still lose performance, but the option is -qalias=noansi. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ANSI-strict pointer aliasing rules
Martijn van Oosterhout kleptog@svana.org writes: In the grandparent's case I think the compiler is being really stupid because it can know the two pointers are the same. But I'm sure there are more subtle cases where it won't know. PostgreSQL typecasts pointers fairly freely. Actually, if xlc is behaving as Taral says then I'm pretty convinced it's *broken*; it is assuming far more than is allowed even by the ANSI aliasing rules. As I read the spec, ANSI aliasing says that a given value must always be accessed through equivalent (up to signedness) primitive types, ie, if you store through an int pointer and fetch through a long pointer the compiler is allowed to reorder those two references. In the example Taral gives, both field references are to fields of type NodeTag. I don't see anything in the spec that allows the compiler to assume they are distinct variables just because they are members of different struct types. The spec restriction is defined in terms of the lvalue type of the particular store or fetch access, not on what kind of structure it's part of. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] ANSI-strict pointer aliasing rules
Tom Lane [EMAIL PROTECTED] writes: As I read the spec, ANSI aliasing says that a given value must always be accessed through equivalent (up to signedness) primitive types It there a difference between C89 and C99 here? -- greg ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ANSI-strict pointer aliasing rules
On Wed, Apr 26, 2006 at 11:42:11PM -0400, Greg Stark wrote: Tom Lane [EMAIL PROTECTED] writes: As I read the spec, ANSI aliasing says that a given value must always be accessed through equivalent (up to signedness) primitive types It there a difference between C89 and C99 here? I believe C89 makes no reference to aliasing restrictions. It only leaves certain operations, in certain contexts, implementation defined. That is, if you wish to maintain portable behaviour, you would choose not to make use of C features that have implementation defined semantics... :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
