[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-12-15
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug middle-end/64313] New: [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

            Bug ID: 64313
           Summary: [5 Regression] gcc.dg/torture/builtin-explog-1.c fails
                    on bare-metal targets
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org

According to comment #23 in PR14541 the testcase now FAILs on trunk after
r218308.
This is probably related to
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00357.html

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
For aarch64-elf ordinary builtins declared as DEF_LIB_BUILTIN are implicitely
available but for example expf is not as the target computes
targetm.libc_has_function (function_c99_misc) as false.  This is because of

config/elfos.h:#undef TARGET_LIBC_HAS_FUNCTION
config/elfos.h:#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function

One solution is to properly guard the testcase with c99_runtime (even GNU
runtime, as it uses exp10/log10/pow10).  But it expects all tests to be
folded away which means that builtins need to be recognized (which they
are because they match their prototype - sth that is not enough according
to Joseph).

IMHO even if system headers declare such prototype we can't be sure they
are really the correct function (system headers include non-C-library runtime
headers).  To be sure we'd need to know the names are really reserved which
for example for exp10 is if _GNU_SOURCE is defined at the point of
prototyping exp10.  Not sure if what libcpp provides for this is convenient
(there are some related callbacks to track what is defined / undefined),
but whatever we do it should also work for -save-temps which means we need
to make sure to emit the #defines to the preprocessed source as well and
_not_ use -fpreprocessed(?).

The pragmatic solution is to make builtins implicitely available once they
are seen in the instruction stream, for example during gimplification.

A more complex solution is to turn genmatch upside-down and make it clever,
similar to how fold_builtin_logarithm gets around this - re-use the decl
we get in the matching IL.  Note that this isn't easily possible with low
overhead (well, maybe making code_helper a bit heavier weight and pass
tree_code or builtin decl around).

I'm leaning towards either reverting the single builtin patch for GCC 5
or implementing the pragmatic solution.

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This very likely affects all newlib targets.

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #5 from John David Anglin <danglin at gcc dot gnu.org> ---
Also fails at -O1 and above on hppa64-hp-hpux11.11.

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
So sth like

Index: gcc/c-family/c-gimplify.c
===================================================================
--- gcc/c-family/c-gimplify.c   (revision 219839)
+++ gcc/c-family/c-gimplify.c   (working copy)
@@ -300,6 +300,20 @@ c_gimplify_expr (tree *expr_p, gimple_se
        break;
       }

+    case ADDR_EXPR:
+      {
+       /* If we see a call to a declared builtin or see its address
+          being taken (we can unify those cases) then we can mark
+          the builtin for implicit generation by GCC.  */
+       tree fndecl = TREE_OPERAND (*expr_p, 0);
+       if (TREE_CODE (fndecl) == FUNCTION_DECL
+           && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
+           /* C_DECL_DECLARED_BUILTIN */
+           && DECL_LANG_FLAG_3 (fndecl))
+         set_builtin_decl_implicit_p (DECL_FUNCTION_CODE (fndecl), true);
+       break;
+      }
+
     case CILK_SPAWN_STMT:
       gcc_assert
        (fn_contains_cilk_spawn_p (cfun)

works for C (yeah, that flag check needs to become a new langhook due to the
way we share c_gimplify across frontends... :/).  For C++ there isn't anything
similar to C_DECL_DECLARED_BUILTIN, but of course the testcase is only
exercised for C.  Alternatively we can add a flag to the middle-end that FEs
can set to treat a builtin as candidate for implicit use if it is used
(but that way we can't distinguish uses of __builtin_log10 from declared
log10).
Thus, similar to [set_]builtin_decl_implicit_p have a
[set_]builtin_decl_declared_p - then we can handle the above in generic
gimplifier routines.

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34485&action=edit
patch

The middle-end approach, testing on x86_64-linux, verified that it fixes the
testcase on aarch64-elf.

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Jan 21 09:04:53 2015
New Revision: 219928

URL: https://gcc.gnu.org/viewcvs?rev=219928&root=gcc&view=rev
Log:
2015-01-21  Richard Biener  <rguenther@suse.de>

    PR middle-end/64313
    * tree-core.h (builtin_info, builtin_info_type): Turn from
    an object with two arrays into an array of an object with
    decl and two flags, implicit_p and declared_p.
    * tree.h (builtin_decl_explicit, builtin_decl_implicit,
    set_builtin_decl, set_builtin_decl_implicit_p,
    builtin_decl_explicit_p, builtin_decl_implicit_p): Adjust.
    (set_builtin_decl_declared_p, builtin_decl_declared_p): New functions.
    * builtins.c (builtin_info): Adjust.
    * gimplify.c (gimplify_addr_expr): References to builtins
    that have been declared by the user makes them eligible for
    use by the compiler.  Call set_builtin_decl_implicit_p on them.

    c/
    * c-decl.c (merge_decls): Call set_builtin_decl_declared_p
    for builtins the user declared correctly.

    cp/
    * decl.c (duplicate_decls): Call set_builtin_decl_declared_p
    for builtins the user declared correctly.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-decl.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl.c
    trunk/gcc/gimplify.c
    trunk/gcc/tree-core.h
    trunk/gcc/tree.h

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64313

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.