This is the mail archive of the
mailing list for the GCC project.
Re: Check that unlinked uses do not contain ssa-names when renaming.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Tom de Vries <Tom_deVries at mentor dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 16 Oct 2014 10:14:19 +0200
- Subject: Re: Check that unlinked uses do not contain ssa-names when renaming.
- Authentication-results: sourceware.org; auth=none
- References: <50715D1B dot 3080203 at mentor dot com> <CAFiYyc1ovwf_dE8Cp9gv6Ec03BNP4gzKfGKmGKvqDfxFPsk27g at mail dot gmail dot com> <543F71C4 dot 1000206 at mentor dot com>
On Thu, Oct 16, 2014 at 9:20 AM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> On 08/10/12 11:24, Richard Guenther wrote:
>> On Sun, Oct 7, 2012 at 12:44 PM, Tom de Vries <Tom_deVries@mentor.com> wrote:
>>> attached patch checks that unlinked uses do not contain ssa-names when renaming.
>>> This assert triggers when compiling (without the fix) the PR54735 example.
>>> AFAIU, it was due to chance that we caught the PR54735 bug by hitting the
>>> verification failure, because the new vdef introduced by renaming happened to be
>>> the same name as the ssa name referenced in the invalid unlinked use (in terms
>>> of maybe_replace_use: rdef == use).
>>> The assert from this patch catches all cases that an unlinked use contains an
>>> Bootstrapped and reg-tested on x86_64 (Ada inclusive).
>>> OK for trunk?
>> I don't think that is exactly what we should assert here ... (I thought about
>> adding checking myself ...). What we'd want to assert is that before
>> any new DEF is registered (which may re-allocate an SSA name) that
>> no uses with SSA_NAME_IN_FREELIST appear. Thus, a light verification
>> pass would be necessary at the beginning of update_ssa
>> (which I queued onto my TODO list ...). We'd want that anyway to for
>> example catch the case where a non-virtual operand is partially renamed.
> while developing a patch, I ran into the same 'no immediate_use list'
> verification error again, caused by an unlinked use containing an ssa-name.
> The verification error was caused by an error in my patch, but triggered by
> chance, by an unrelated change in the patch.
> I've tried to implement the 'light verification pass' you describe above, and
> I've checked that the error in my patch is found, also when I remove the trigger
> for the verification error from my patch.
> Bootstrapped and reg-tested on x86_64 (with the ENABLE_CHECKING guarding
> removed, in order to ensure the code is active).
> OK for trunk?
Ok with changing the gcc_assert to
if (SSA_NAME_IN_FREE_LIST (use))
error ("statement uses released SSA name");
err = true;
and after checking all stmts
internal_error ("cannot update SSA form");
you might want to push/pop TV_TREE_STMT_VERIFY around all this
> - Tom