This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Julian Brown <julian at codesourcery dot com>
- Date: Fri, 15 Nov 2013 15:10:27 +0100
- Subject: Re: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 1/2
- Authentication-results: sourceware.org; auth=none
- References: <52463CA4 dot 7060303 at codesourcery dot com> <CAFiYyc1z=BVSME0317W7HVr9HAvZ0PvKsdT9Yx-vsmNgEjE52g at mail dot gmail dot com> <526161EC dot 5070200 at codesourcery dot com> <325c359b-22e1-43dc-8050-5a11deb66e95 at email dot android dot com> <52649035 dot 6000802 at codesourcery dot com> <DUB122-W9C01556B8690D446546A6E4080 at phx dot gbl> <526F2B94 dot 8020907 at codesourcery dot com> <DUB122-W1396BF39760E97A090742BE4090 at phx dot gbl> <5271A851 dot 6000808 at codesourcery dot com> <CAFiYyc3bYPF5xSXSSq-3ZU-dT5Ou00x=qC-u5sXxkZVf3tH86g at mail dot gmail dot com> <DUB122-W25E69525F3AA97742A1188E4F80 at phx dot gbl> <CAFiYyc2af8kUuAJ3ocF+N+=Fa-HCr-nOPDgB_0BpVYaNxb-O3w at mail dot gmail dot com> <DUB122-W156FAE71D5E58C1366D1D1E4FB0 at phx dot gbl> <CAFiYyc2A-he96v+T-5Mg9ro8Lx_rrP_NK5OwJqJiMQ3UF+_7SA at mail dot gmail dot com> <DUB122-W414FF92FA702FE3EDA09D9E4FB0 at phx dot gbl> <CAFiYyc2JLZndiu+x9DgrGczWQcZWiAOawFiJ5_vgmH3FXm=T=w at mail dot gmail dot com> <DUB122-W5C926173306050F7C40C5E4FB0 at phx dot gbl>
On Fri, Nov 15, 2013 at 2:24 PM, Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
>>
>> But then why is the mode QImode in the first place? The access is
>> definitely of SImode.
>>
>
> that's in the test case:
>
> s->arr[0] = 0x12345678;
>
>
> it is QImode from that in expand_assignment:
>
> to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
>
> tem is "s", a MEM_REF, of QImode, perfectly aligned. the mode is only
> OK to access *s or s->pad. It is wrong for s->srr[0].
I undestand that, but why isn't that immediately adjusted to use
TYPE_MODE (TREE_TYPE (to))? The above expands *s, not s->arr[0].
Using the mode of *s if it is not equal to that of the destination doesn't
make any sense (usually it will be BLKmode anyway). This seems to
be the source of multiple problems.
> in store_bit_field the mode is used in store_fixed_bit_field:
>
> mode = GET_MODE (op0);
> if (GET_MODE_BITSIZE (mode) == 0
> || GET_MODE_BITSIZE (mode)> GET_MODE_BITSIZE (word_mode))
> mode = word_mode;
> mode = get_best_mode (bitsize, bitnum, bitregion_start, bitregion_end,
> MEM_ALIGN (op0), mode, MEM_VOLATILE_P (op0));
>
> if (mode == VOIDmode)
> goto boom;
>
> so this restricts the possible access mode. word_mode, means no restriction.
> Everything would be OK if MEM_ALIGN(op0) was byte-aligned, but we have
> a problem if MEM_ALIGN(op0)>=WORD_MODE.
>
> Do you understand?
>
> Bernd.