This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: mike stump <mrs at windriver dot com>
- To: torvalds at transmeta dot com
- Cc: dennis at juniper dot net, gcc at gcc dot gnu dot org, paulus at samba dot org, rth at redhat dot com
- Date: Sat, 5 Jan 2002 23:45:24 -0800 (PST)
- Subject: Re: [PATCH] C undefined behavior fix
> Date: Sat, 5 Jan 2002 20:54:57 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: mike stump <mrs@windriver.com>
> > and notice that the compiler does the right thing. Try it without
> > the call to foo, and watch it do the wrong thing.
> This is by no mans guaranteed by the standard either, and I don't
> think gcc really guarantees it either.
By running your code at an address that the compiler doesn't know
about in a way the compiler doesn't know about, you have violated the
model so throughly that few things will get you back in the the land
of guarantees. Start with that. Now, pretend you want the most
milage out of it that you can get. I can tell you how to do that.
Washing it though volatile does this. In gcc, barring bugs, for that
last 10 years, and most likely for the next 20 years, it means this.
You want a hard guarantee, move it back, and run it in the normal
place.
> Traditionally "volatile" has only had an impact on _accesses_, not
> on pointer arithmetic.
? I had an access. return v is an access. Certainly you understand
that volatile means that the compiler is to forget everything it might
have known about the value written to memory at that location. You
_must_ understand this.
> And if you cast to volatile only to cast back to non-volatile, I
> suspect that the behaviour will be different on different versions
> of gcc.
You have failed to understand my code, or volatile. You are free to
try and find a compiler in the world that assumes it knows anything
about the value of something that was fetched from a volatile
location. If you search, you will find that you will fail. Ok, maybe
you will find a buggy compiler... Certainly gcc had volatile bugs in
the past.
> I tried the "cast to volatile and back", and it has no impact on
> code generation for me when done as a straightforward macro,
You must have misunderstood, or done it wrong, or not have understood
my suggestion. To be _very_ concrete, here is the code, compile with
-fno-builtin-strcpy. You will get 3 routines that work flawlessly.
You can pick which solution you like, they all work and have
worked.
char buf[100];
inline void *foo(void *vp) { void *volatile v; v = vp; return v; }
#define bar(vp) ({ void *volatile v; v = vp; v; })
int main() {
strcpy (buf, foo("hithere lksjdf lfdlkfd lkjsdfl lkjadsl kadl jkkjsadl kjaldkjasldkj aldskj alkjdlaskjd lakjdlaskd l adjlfdkjslkjfd ljfd "+20));
}
int mymain() {
strcpy (buf, bar("hithere lksjdf lfdlkfd lkjsdfl lkjadsl kadl jkkjsadl kjaldkjasldkj aldskj alkjdlaskjd lakjdlaskd l adjlfdkjslkjfd ljfd "+20));
}
int lastmain() {
strcpy (buf, "hithere lksjdf lfdlkfd lkjsdfl lkjadsl kadl jkkjsadl kjaldkjasldkj aldskj alkjdlaskjd lakjdlaskd l adjlfdkjslkjfd ljfd "+20);
}
> while it generated truly horrible code when done in an inline
> function.
Gosh, my last version generates truly nice code. You can have any
code you want. If you want to pay the price of the last one, use
-fno-builtin-strcpy. It is guaranteed to fix the bug under
discussion. Not only that, it is guaranteed to always fix the bug
under discussion, well, so long as we have the flag.
> In short, I think you're not really showing off any gcc feature,
> you're showing off a random effect of the fact that many gcc
> optimizations throw up their hands in surrender when they see
> "volatile". Often with very little reason.
? The only stupidness wrt volatile that I am aware of is volatile_ok.
What others are there?
I cannot believe that you believe that. [ stunned silence ] I'm not
sure what to say.
Why would you think the compiler is permitted to know anything about
the value of a fetched volatile? Now, I can come up with cases that
would require some changes (must run all through a global or an opaque
pointer to volatile), must not fail to inform the compilation system
about the specialness of that location... But, certainly in the last
case, that would be stretching my imagination.
I cannot fathom why you would think such a thing. What do you think
volatile means?
> But it is definitely _not_ a feature you can depend on (I bet you
> noticed this, and that you also noticed that when you tried to use a
> straight macro your example just didn't work ;)
Not only can I use a macro and have it work, I can use no macro and
have it work also, next.