On Tue, 4 May 2021, Eric Botcazou wrote:
> > Do you have extra fixes in your tree or does -fnon-call-exceptions
> > somehow magically paper over the issue?
>
> This optimization is valid in Ada for pure functions. RM 10.2.1(18/3) says:
> "If a library unit is declared pure, then the
> Do you have extra fixes in your tree or does -fnon-call-exceptions
> somehow magically paper over the issue?
This optimization is valid in Ada for pure functions. RM 10.2.1(18/3) says:
"If a library unit is declared pure, then the implementation is permitted to
omit a call on a library-level
On Mon, 3 May 2021, Michael Matz wrote:
> Hello,
>
> On Mon, 3 May 2021, Jan Hubicka wrote:
>
> > > (it should not abort). The documentation of 'pure' must be read
> > > as that 'pure' is not valid for 'foo' since throwing an exception
> > > is obviously an observable effect on the state of
Hello,
On Mon, 3 May 2021, Jan Hubicka wrote:
> > (it should not abort). The documentation of 'pure' must be read
> > as that 'pure' is not valid for 'foo' since throwing an exception
> > is obviously an observable effect on the state of the program
> > (in particular for the testcase at hand).
On Mon, 3 May 2021, Eric Botcazou wrote:
> > So - what is it? Are pure functions allowed to throw or not?
>
> We keep going back to this every N years and I'm not sure why... In Ada the
> answer is definitely yes, we have entire library units marked Pure and thus
> containing bunch of pure
> So - what is it? Are pure functions allowed to throw or not?
We keep going back to this every N years and I'm not sure why... In Ada the
answer is definitely yes, we have entire library units marked Pure and thus
containing bunch of pure functions but they can throw like any other function.
On Mon, 3 May 2021, Jan Hubicka wrote:
> > note that if you wrap foo () into another noinline
> > wrap_foo () { foo (); return 1; } function then we need to make
> > sure to not DCE this call either even though it only throws
> > externally. Now the question is whether this testcase is valid
> >
> note that if you wrap foo () into another noinline
> wrap_foo () { foo (); return 1; } function then we need to make
> sure to not DCE this call either even though it only throws
> externally. Now the question is whether this testcase is valid
> (it should not abort). The documentation of
There is -fdelete-dead-exceptions now and we're tracking
nothrow and const/pure bits separately and I do remember that
const or pure does _not_ imply nothrow.
Now, in the light of the PR100382 fix which added a
stmt_unremovable_because_of_non_call_eh_p guard to DSEs "DCE"
I wondered how
