> 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 subprogram of the library unit if the results are not needed after the call.(...)[This permission applies even if the subprogram produces other side effects when called.]". > I suppose if the C or C++ frontends like to have pure/const attributed > functions not throw they could mark functions accordingly themselves. > > Which also means, the Ada functions are DECL_PURE_P but not 'pure' > according to the extend.texi documentation of the user-visible > attribute? That said, I think if my C++ testcase is valid then we > should amend this documentation (or if not then as well, to not > re-iterate this every N years). Do you agree? Yes, the documentation was written without considering other languages with exception handling, but it's originally an extension of the C language and documented in the manual of the C compiler, so that's not very surprising. Pure Ada functions are "const" in the GNU C sense if all their parameters are passed by copy and "pure" in the GNU C sense if their parameters not passed by value (i.e. by reference) are In parameters; in all the other cases, pure Ada functions are neither "const" nor "pure" in the GNU C sense. I think that we need to add an explicit sentence about exception handling to the declaration of DECL_PURE_P: /* Nonzero in a FUNCTION_DECL means this function should be treated as "pure" function (like const function, but may read global memory). */ #define DECL_PURE_P(NODE) (FUNCTION_DECL_CHECK (NODE)>function_decl.pure_flag) Maybe: "Note that being pure or const for a function is orthogonal to being no-throw, i.e. it is valid to have DECL_PURE_P set and TREE_NOTHROW cleared". -- Eric Botcazou
