This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 9 Feb 2012 13:56:33 +0100
- Subject: Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result
- References: <CAEwic4a8P-xbjDfiYNyj6jJXW07c1asE8xC6JBRvbX56kM63Mg@mail.gmail.com> <CAFiYyc21SsPcCNmqfyrrC__HB0yd8BMi=JKdsRqyu_cDawN6dw@mail.gmail.com> <CAEwic4abEtJ5nTMtHgckOU2bnoV0cQTNQtqouWvg2QRZU7GLRg@mail.gmail.com> <CAFiYyc26UOq4nGKm9iaT6nHqh3KVX0DtfQCMofOaezyOK3fcNQ@mail.gmail.com> <CAFiYyc3da8nBg6Mffs+uxuYBhY6VYytpyx0wUyvyQ4mXkJkAKw@mail.gmail.com> <CAEwic4aEQ1nhF7f7stNky=kg4FQUEOrbisDU35MkPeHt1N_67Q@mail.gmail.com> <CAFiYyc0WeCoDFvgRe-Qg+HXm5rJNenjZ356fLfkqjHM5353uQA@mail.gmail.com> <CAEwic4YWJriFkeTfyxn-SO4mxunbNkUzod2+UrRHAoHoU65LSg@mail.gmail.com> <CAFiYyc0m-AqL2pRpaqALxAKiJNPJoH2qFRO-22OJKZLxTAFGQA@mail.gmail.com> <CAFiYyc22oS_yEypAaVtObDWeu5EdHRRB6p1=rOT0Z9Lcppsqaw@mail.gmail.com>
On Thu, Feb 9, 2012 at 11:53 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>> 2012/1/11 Richard Guenther <richard.guenther@gmail.com>:
>>>>
>>>> count despite being declared volatile and only loaded once in the source
>>>> is loaded twice in gimple. ?If it were a HW register which destroys the
>>>> device after the 2nd load without an intervening store you'd wrecked
>>>> the device ;)
>>>>
>>>> Richard.
>>>
>>> Thanks for explaination. ?I tried to flip order for lhs/rhs in
>>> gimplify_modify_expr & co. ?Issue here is that for some cases we are
>>> relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
>>> is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
>>> like:
>>>
>>> typedef const unsigned char _Jv_Utf8Const;
>>> typedef __SIZE_TYPE__ uaddr;
>>>
>>> void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
>>> {
>>> ?union {
>>> ? ?_Jv_Utf8Const *signature;
>>> ? ?uaddr signature_bits;
>>> ?};
>>> ?signature = s;
>>> ?special = signature_bits & 1;
>>> ?signature_bits -= special;
>>> ?s = signature;
>>> }
>>>
>>> So I modified gimplify_self_mod_expr for post-inc/dec so that we use
>>> following sequence
>>> and add it to pre_p for it:
>>>
>>> tmp = lhs;
>>> lvalue = tmp (+/-) rhs
>>> *expr_p = tmp;
>>
>> As I explained this is the wrong place to fix the PR. ?The issue is not
>> about self-modifying expressions but about evaluating call argument
>> side-effects before side-effects of the lhs.
>
> I am testing the attached instead.
Doesn't work. Btw, Kai, your patch surely breaks things if you put
the lvalue update into the pre queue.
Consider a simple
a[i++] = i;
you gimplify that to
i.0 = i;
D.1709 = i.0;
i = D.1709 + 1;
a[D.1709] = i;
which is wrong.
Seems we are lacking some basic pre-/post-modify testcases ...
Richard.