This is the mail archive of the gcc-patches@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: [patch] Fix PR middle-end/51994


On Tue, Feb 7, 2012 at 10:50 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> Hi,
>
> this is a regression present on mainline and 4.6 branch, apparently a fallout
> of the MEM_REF introduction. ?get_inner_reference can be called on MEM_REFs
> whose base has been shifted to the left
>
> ?char *output = buf;
>
> ?output += a;
> ?output -= 1;
>
> ?output[0];
>
> and, since the constant negative offset is merged into the MEM_REF, it will be
> returned as the BITPOS by get_inner_reference, which wreaks havoc later in the
> bitfield manipulation routines which expect non-negative bit positions.
>
> Clearly nothing says that the returned BITPOS should be non-negative but, on
> the other hand, it de facto was in the pre-MEM_REF world for valid programs
> (except maybe in a very specific case in Ada). ?The attached patch attempts to
> patch things up to bring us back to the previous de facto situation.
>
> Bootstrapped/regtested on x86_64-suse-linux, OK for mainline and 4.6 branch?

Ok.

Note that with your patch we can still get negative bitpos for invalid code
like

char *output = buf;
output[-1];

but I suppose we don't need to worry about this case too much (if we do
we'd need to adjust the TREE_CODE (offset) == INTEGER_CST case
as well).

Thanks,
Richard.

>
> 2012-02-07 ?Eric Botcazou ?<ebotcazou@adacore.com>
>
> ? ? ? ?PR middle-end/51994
> ? ? ? ?* expr.c (get_inner_reference): If there is an offset, add a negative
> ? ? ? ?bit position to it (if any).
>
>
> 2012-02-07 ?Eric Botcazou ?<ebotcazou@adacore.com>
>
> ? ? ? ?* gcc.c-torture/execute/20120207-1.c: New test.
>
>
> --
> Eric Botcazou


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