This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: Jeff Law <law at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 9 Dec 2013 10:57:27 +0100
- Subject: Re: [REPOST] Invalid Code when reading from unaligned zero-sized array
- Authentication-results: sourceware.org; auth=none
- References: <DUB122-W20B5CD3C7B50824A33E21AE4D50 at phx dot gbl> <55501474 dot 8ce4n3Il8S at polaris> <52A240CA dot 4040904 at redhat dot com> <5897284 dot r5JpveH9KC at polaris> <52A5411D dot 40501 at redhat dot com> <DUB122-W145DBB0F3D4CB7AC51261BE4D30 at phx dot gbl>
On Mon, Dec 9, 2013 at 10:07 AM, Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
>> On 12/07/13 03:44, Eric Botcazou wrote:
>>>> I'd certainly be concerned. Ports have (for better or worse) keyed on
>>>> BLKmode rather than looking at the underlying types. So if something
>>>> which was previously SImode or DImode is now BLKmode, there's a nonzero
>>>> chance we're going to change how it gets passed.
>>>
>>> Well, we have been saying that calling conventions need to be keyed on types
>>> rather than modes for more than a decade... I recall auditing and fixing the
>>> SPARC back-end circa 2003, so how long are we going to use this argument?
>> I don't recall such a change in policy -- but that doesn't mean it
>> didn't happen :-)
>>
>> If we already declared that ports should be looking at the underlying
>> types rather than the mode and it's been in place that long, then I
>> think any port that hasn't been audited/updated deserves its fate and we
>> shouldn't let them stand in the way of making progress on this issue.
>>
>> jeff
>
> The ports are one thing, but this non-BLKmode thing can also be visible to
> the user code:
>
> If we have
>
> struct s{ char x[8]; };
>
> We can place that in a register like this:
>
> register struct s x __asm__("eax");
>
> Previous experimentation showed that this code can break with that ABI change.
>
> So if we change that structure mode, we should make sure that this has no other
> unexpected implications, especially in phase 3.
We supposedly can force the mode of the DECL to be that of EAX
at the declaration, even if the mode of the type is BLKmode.
Richard.
> Bernd.