This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: const-elim-1.c
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: mark at codesourcery dot com
- Cc: gcc at gcc dot gnu dot org, rearnsha at arm dot com
- Date: Sun, 28 Dec 2003 18:44:00 -0800
- Subject: Re: const-elim-1.c
- References: <200312290232.hBT2Wt8h005762@sirius.codesourcery.com>
Mark Mitchell <mark@codesourcery.com> writes:
> Zack --
>
> gcc.dg/const-elim-1.c is a test that you added back in May.
>
> It fails on arm-none-elf, and also on i686-pc-linux-gnu, unless you
> use -mtune=pentiumpro.
>
> The issue in both cases relates to this code:
>
> const struct S S = { 23, { 1.414, 1.618 }, 0 };
>
> If the compiler chooses to do a block copy from a read-only data into
> "S", then the compiler is unable to eliminate the block copy, and is
> therefore unable to eliminate the constant pool. The compiler is
> unable to eliminate the block copy because the code at the end of
> init_propagate_block_info that handles SETs to MEMs doesn't fire for
> these block copies. Ideally, that code would be made smarter, but
> really the elimination should really happen in tree-ssa code, not in
> RTL code anyhow.
Hmm, no, the bug is in the code that decides that 'auto' overrides
'const' in this case; we needn't generate a copy at all. I will look
into this.
zw