This is the mail archive of the 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: [PATCH] Use sufficient alignment when expanding VCE (PR target/35366)

On Tue, Nov 11, 2008 at 09:40:16AM -0600, Richard Guenther wrote:
> On Tue, Nov 11, 2008 at 7:30 AM, Jakub Jelinek <> wrote:
> > This is another patch for PR35366, either of the patches fixes the failure,
> > but IMHO we want both.  If for whatever reason VIEW_CONVERT_EXPR <double, STRING_CST>
> > (or some other VCE) isn't folded, and the TREE_TYPE of the VCE needs bigger
> > alignment than the inner operand, the inner constant is emitted with a small
> > alignment, but it is actually accessed as if the alignment was big enough
> > for the outer type.  The following patch makes sure an inner constant
> > is sufficiently aligned.
> >
> > Ok for trunk?
> Is it always possible to force the alignment of the inner object?  I think

For constants yes (that's why I use CONSTANT_CLASS_P), otherwise no.

> the same problem may exist for V_C_E <double> (*p) when we cannot
> influence the alignment of *p.  So shouldn't we make sure to have the
> correct MEM_ALIGN instead?  Or does it work in that case already?

If you have an unaligned pointer and V_C_E <double> (*p), then
MEM_ALIGN will be correct I believe (at least, without this patch
it is A8 for LC2, matching its alignment).  Of course whether it
works or not depends on whether the target requires strict alignment
or not, but I'd say if it does and the pointer isn't aligned, it was
a programmer's bug.
V_C_E of a constant is something that is generated by the compiler itself
and is something we can align sufficiently, so we IMHO should.


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