Re: [patch] Fix internal error on store to FP component at -O2

2020-05-25 Thread Richard Biener via Gcc-patches
On Mon, May 25, 2020 at 2:14 PM Eric Botcazou wrote: > > > Hmm, MAX_BITSIZE_MODE_ANY_INT looks a bit arbitrary since on > > x86 it (IIRC) includes things like OImode. Maybe MOVE_MAX or > > MAX_FIXED_MODE_SIZE are better suited here? > > I forgot to mention that I picked MAX_BITSIZE_MODE_ANY_INT

Re: [patch] Fix internal error on store to FP component at -O2

2020-05-25 Thread Eric Botcazou
> Hmm, MAX_BITSIZE_MODE_ANY_INT looks a bit arbitrary since on > x86 it (IIRC) includes things like OImode. Maybe MOVE_MAX or > MAX_FIXED_MODE_SIZE are better suited here? I forgot to mention that I picked MAX_BITSIZE_MODE_ANY_INT because of: bool invalid = (base_addr == NULL_TREE

Re: [patch] Fix internal error on store to FP component at -O2

2020-05-25 Thread Eric Botcazou
> Hmm, MAX_BITSIZE_MODE_ANY_INT looks a bit arbitrary since on > x86 it (IIRC) includes things like OImode. Maybe MOVE_MAX or > MAX_FIXED_MODE_SIZE are better suited here? You're right, MAX_FIXED_MODE_SIZE is better, I'm going to change it. > The IL correctness fix looks OK to me but it smells

Re: [patch] Fix internal error on store to FP component at -O2

2020-05-25 Thread Richard Biener via Gcc-patches
On Mon, May 25, 2020 at 12:33 PM Eric Botcazou wrote: > > Hi, > > the attached Ada testcase triggers a GIMPLE verification failure at -O2 or > above because the GIMPLE store merging pass generates a NOP_EXPR between a FP > type and an integral type. This happens when the bit-field insertion path

[patch] Fix internal error on store to FP component at -O2

2020-05-25 Thread Eric Botcazou
Hi, the attached Ada testcase triggers a GIMPLE verification failure at -O2 or above because the GIMPLE store merging pass generates a NOP_EXPR between a FP type and an integral type. This happens when the bit-field insertion path is taken for a FP field, which can happen in Ada for