This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR 6212
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, "rth at redhat dot com" <rth at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sun, 05 May 2002 22:43:15 -0700
- Subject: Re: PR 6212
> Fixing it without major work is tricky. The problem is that we are
> removing a divide/multiply combination, so we lose the info that
> there's an aligned value here.
How did it work before? I know these things changed a lot, but still it
would be useful to know how we got it right in the past.
> But now I just realized that one way of doing this may be saying that
> a POINTER_TYPE variable has the alignment of the underlying type.
Let's be clear.
I think what you're saying is that we could assume that the value stored
in a T*, considered as an integer, is divisible by the alignment of T.
Is that right?
That is a safe assumption only when the pointer is being dereferenced.
The C standard guarantees this property; you can't use a T* to access
something that is not a T, and a T must, by definition, be aligned as
required for a T.
If the pointer value is merely being read, the assumption does not hold,
For example, we must not optimize:
(int)(T*)x % alignof(T)
to 0.
> That's an easy change, but one that has the potential of causing
> regressions. What's the thought here?
It depends on the patch. I will have to make a judgement call.
It would be helpful if you post and begin testing a patch. Since it's
easy, please do this soon.
You should, in any case, fix this on the mainline quickly. There, you
can of course use a more invasive technique if you like. Fixing it
there will give us a chance to test the change and, possibly, incorporate
it in GCC 3.1.1 if your easy patch doesn't work out.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com