On 2022-05-05 02:52, Alexandre Oliva wrote:
Regstrapped on x86_64-linux-gnu and ppc64le-linux-gnu, also tested
targeting ppc- and ppc64-vx7r2. Ok to install?
I am ok with the modified version of the patch. It looks reasonable for
me and I support its commit.
But I think I can not approve
On Thu, May 05, 2022 at 03:52:01AM -0300, Alexandre Oliva wrote:
> The testcase for pr100106, compiled with optimization for 32-bit
> powerpc -mcpu=604 with -mstrict-align expands the initialization of a
> union from a float _Complex value into a load from an SCmode
> constant pool entry, aligned t
On Thu, May 05, 2022 at 08:59:21AM +0100, Richard Sandiford wrote:
> Alexandre Oliva via Gcc-patches writes:
> I know this is the best being the enemy of the good, but given
> that we're at the start of stage 1, would it be feasible to try
> to get rid of (subreg (mem)) altogether for GCC 13?
Yes
Alexandre Oliva via Gcc-patches writes:
> The testcase for pr100106, compiled with optimization for 32-bit
> powerpc -mcpu=604 with -mstrict-align expands the initialization of a
> union from a float _Complex value into a load from an SCmode
> constant pool entry, aligned to 4 bytes, into a DImode
The testcase for pr100106, compiled with optimization for 32-bit
powerpc -mcpu=604 with -mstrict-align expands the initialization of a
union from a float _Complex value into a load from an SCmode
constant pool entry, aligned to 4 bytes, into a DImode pseudo,
requiring 8-byte alignment.
The patch