This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]