This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Re: More SJLJ exception breakage
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: iant at google dot com (Ian Lance Taylor)
- Cc: richard dot guenther at gmail dot com (Richard Guenther), gcc-patches at gcc dot gnu dot org, hubicka at ucw dot cz
- Date: Tue, 21 Apr 2009 21:55:47 +0200 (CEST)
- Subject: Re: [PATCH] Re: More SJLJ exception breakage
Ian Lance Taylor wrote:
> The return label is bypassed because the return label is for code which
> copies the return value pseudo-register into the return hard register.
> This is for cases like this:
>
> int
> f(int i)
> {
> if (i)
> my_exit_function();
> else
> return i;
> }
>
> Here let's assume that my_exit_function() does not have the noreturn
> attribute and that the user is ignoring warnings about not returning a
> value. Without the naked return label the copy of the uninitialized
> pseudo-register into the return register would trigger inappropriate
> warnings and perhaps even break the old flow code.
>
> It's entirely possible that these issues don't matter any more. You do
> need to confirm that code like the above does not issue an inappropriate
> warning about an uninitialized value. You may need to check that in a
> few different languages.
I've experimented with various versions of the above, and I never get
any inappropriate warning. In fact, the RTL contains an explicit
clobber of the result *pseudo*-register -- that's probably why it
would have worked even with the old flow code.
What we now have is
--- fall-through ---
clobbers generated by clobber_return_register (both result pseudo
and hard return registers are clobbered)
return_label:
copy result pseudo into hard return register
naked_return_label:
use return register
On the other hand, even without my patch, very similar sequences are
already being generated; the above example, *without* the patch,
results in:
call my_exit_function
clobbers generated by clobber_return_register
goto return_label
[...]
return_label:
copy result
naked_return_label:
use return register
This is because the tree before expand contains a naked return statment,
which gets expanded via expand_null_return, which basically does a
clobber_return_register followed by goto return_label.
So it seems to me that the patch does not actually introduce any significantly
different situations from what we already today have and handle ...
In addition, as requested by Richard, I've now successfully completed a full
bootstrap and test run (all languages except Ada) on i686-linux with no
regressions.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com