https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65425
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2015-03-18
CC| |jsm28 at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think we have a duplicate bug for this - if-conversion transforms the loop
body to execute the log10 unconditionally:
iftmp.0_11 = log10 (_10);
iftmp.0_2 = _10 > 0.0 ? iftmp.0_11 : -9.9999e+4;
it's
static bool
if_convertible_stmt_p (gimple stmt, vec<data_reference_p> refs,
bool *any_mask_load_store)
{
...
case GIMPLE_CALL:
{
tree fndecl = gimple_call_fndecl (stmt);
if (fndecl)
{
int flags = gimple_call_flags (stmt);
if ((flags & ECF_CONST)
&& !(flags & ECF_LOOPING_CONST_OR_PURE)
/* We can only vectorize some builtins at the moment,
so restrict if-conversion to those. */
&& DECL_BUILT_IN (fndecl))
return true;
}
return false;
which fails to check whether the call may trap.
I have a patch for that issue, but log10 is also using ATTR_NOTHROW_*
thus it is declared as never trapping. It looks like _all_ functions
will have this issue.
Then the canonical helper gimple_could_trap_p doesn't consider the _body_
of the call but only the call instruction itself. So we have to "abuse"
gimple_call_nothrow_p here.
I'm not sure about how to deal with this (adding another layer distinguishing
flag_trapping_math in builtins.def)?
