This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]