From: "Richard Guenther" <richard.guenther@gmail.com>
To: "Jakub Jelinek" <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Use sufficient alignment when expanding VCE (PR target/35366)
Date: Tue, 11 Nov 2008 19:53:00 -0000 [thread overview]
Message-ID: <84fc9c000811111135l38d3669fk931e8f0c953b8d2@mail.gmail.com> (raw)
In-Reply-To: <20081111184051.GH3572@tyan-ft48-01.lab.bos.redhat.com>
On Tue, Nov 11, 2008 at 12:40 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Nov 11, 2008 at 09:40:16AM -0600, Richard Guenther wrote:
>> On Tue, Nov 11, 2008 at 7:30 AM, Jakub Jelinek <jakub@redhat.com> 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.
Ok. The patch is ok then.
Thanks,
Richard.
> Jakub
>
next prev parent reply other threads:[~2008-11-11 19:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 13:48 Jakub Jelinek
2008-11-11 15:42 ` Richard Guenther
2008-11-11 18:54 ` Jakub Jelinek
2008-11-11 19:53 ` Richard Guenther [this message]
2008-11-12 3:29 ` Geert Bosch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84fc9c000811111135l38d3669fk931e8f0c953b8d2@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).