This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, i386, Pointer Bounds Checker 33/x] MPX ABI
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, Jeff Law <law at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 10 Oct 2014 19:33:29 +0200
- Subject: Re: [PATCH, i386, Pointer Bounds Checker 33/x] MPX ABI
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4a4JiD4Z8ygzvtODWaNtEz8pZbXYO+rBkWUL3MXv6ySOQ at mail dot gmail dot com> <20140919075558 dot GE50194 at msticlxl57 dot ims dot intel dot com> <CAFULd4ZSE3y=yf4Yf1+9qYbK5KzNs61qehyw-qokhLwAJm+=LA at mail dot gmail dot com> <542068E1 dot 5060504 at redhat dot com> <CAMbmDYZu9NpXsVn+DWQckcKhj6zR-Fh_EQ10FhdiQ03hqgxEgQ at mail dot gmail dot com> <5421B591 dot 6090705 at redhat dot com> <CAMbmDYahdc32CZvQzFGP33dQVFEALUTzRmBuMdyXSidPaUrrTg at mail dot gmail dot com> <CAMbmDYZX1+8F+YOODkPk_Pm7dfLaXRHLAvStem-unDwq+P7qCw at mail dot gmail dot com> <542316DC dot 5030700 at redhat dot com> <CAMbmDYZ0=yhFusghp5hupzs8SWoa1XEF1qrSA3gW=e2xHbmHhg at mail dot gmail dot com> <CAMbmDYbzqhiGTgnnBzAs=G1eBQUXnTn-qHALyjLYNUqwwARHXw at mail dot gmail dot com> <542C4E8F dot 8030502 at redhat dot com> <CAFULd4bnH2cc+yFYq74eaN+Z286bFx3p-hgHjDs=Di+68OoJ6A at mail dot gmail dot com> <CAMbmDYZagLgv2a9C5bvpjuvBgReejHJ+b9wwjDtJqHWNeNFg-A at mail dot gmail dot com>
On Fri, Oct 10, 2014 at 7:29 PM, Ilya Enkovich <firstname.lastname@example.org> wrote:
> 2014-10-10 21:10 GMT+04:00 Uros Bizjak <email@example.com>:
>> On Wed, Oct 1, 2014 at 8:57 PM, Vladimir Makarov <firstname.lastname@example.org> wrote:
>>> The problem is in code introduced by Bernd in IRA and caller-saves.c in
>>> 2012. It is basically an optimization for functions returning always the
>>> same result as one argument (e.g. memcpy returning 1st argument).
>>> There are two possible solutions. First one is to prohibit the
>>> optimizations when there is a parallel in SET. Second one is to go deeper
>>> if the call result is guaranteed in the first element which is true for the
>> I suspect that the first solution will regress
>> gcc.target/i386/retarg.c on i686 - that testcase test if referred
>> optimization is effective. All things equal, I think we should go with
>> the second solution.
> The first solutions is in trunk since October 3
> (https://gcc.gnu.org/ml/gcc-cvs/2014-10/msg00094.html) and I don't see
> such fail. Patch actually just checks for a case which never occurs
> right now and therefore should be quite safe.
True, but after MPX patches are committed, PARALLELs will be passed as
call targets. I wonder if the testcase fails then.