On Fri, 2016-09-23 at 23:10 +0900, Oleg Endo wrote:
> On Fri, 2016-09-23 at 14:07 +, Wilco Dijkstra wrote:
> >
> > After discussion (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg007
> > 18
> > .html)
> > here is the latest version of the strchr patch. This uses a gimple
> > statement for
> >
On Wed, Sep 28, 2016 at 5:45 PM, Jason Merrill wrote:
> OK.
>
> On Wed, Sep 28, 2016 at 11:43 AM, Wilco Dijkstra
> wrote:
>> Jason Merrill wrote:
>>> I think this broke g++.dg/ext/builtin10.C.
>>
>> That's odd. It appears if you add a fold in gimple-fold.c, it no longer
>> calls the
>> folding
On 28 September 2016 at 16:45, Jason Merrill wrote:
> I think this broke g++.dg/ext/builtin10.C.
>
> Jason
It also broke:
gc gcc.c-torture/execute/builtins/strchr.c execution, -O1
c.c-torture/execute/builtins/strchr.c (execution) on arm* and aarch64*
Christophe
OK.
On Wed, Sep 28, 2016 at 11:43 AM, Wilco Dijkstra wrote:
> Jason Merrill wrote:
>> I think this broke g++.dg/ext/builtin10.C.
>
> That's odd. It appears if you add a fold in gimple-fold.c, it no longer calls
> the
> folding code in builtins.c. No idea what the idea behind that is (especially
Jason Merrill wrote:
> I think this broke g++.dg/ext/builtin10.C.
That's odd. It appears if you add a fold in gimple-fold.c, it no longer calls
the
folding code in builtins.c. No idea what the idea behind that is (especially
since
there are other builtins that appear in both files), but this sim
I think this broke g++.dg/ext/builtin10.C.
Jason
On Fri, Sep 23, 2016 at 4:10 PM, Oleg Endo wrote:
> On Fri, 2016-09-23 at 14:07 +, Wilco Dijkstra wrote:
>> After discussion (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00718
>> .html)
>> here is the latest version of the strchr patch. This uses a gimple
>> statement for
>> the pointer add
On Fri, 2016-09-23 at 14:07 +, Wilco Dijkstra wrote:
> After discussion (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00718
> .html)
> here is the latest version of the strchr patch. This uses a gimple
> statement for
> the pointer addition so the gsi_prev always points at the strlen
> call.
After discussion (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00718.html)
here is the latest version of the strchr patch. This uses a gimple statement
for
the pointer addition so the gsi_prev always points at the strlen call.
Optimize strchr (s, 0) to s + strlen (s). strchr (s, 0) appears a c
