[Bug lto/102347] New: "fatal error: target specific builtin not available" with MMA and LTO

[Bug lto/102347] New: "fatal error: target specific builtin not available" with MMA and LTO

[chip.kerchner at ibm dot com]

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

            Bug ID: 102347
           Summary: "fatal error: target specific builtin not available"
                    with MMA and LTO
           Product: gcc
           Version: 10.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chip.kerchner at ibm dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I'm seeing MMA problems with LTO.  With this simple program (main.ii)

----------------------
#pragma GCC target "cpu=power10"
int main() {
  float *b;
  __vector_quad c;
  __builtin_mma_disassemble_acc(b, &c);
  return 0;
}
----------------------

And this compile

----------------------
g++ -flto=auto -mcpu=power9 main.ii
----------------------

I'm seeing this error (which does NOT occur without LTO)

----------------------
lto1: error: '__builtin_mma_xxmfacc_internal' requires the '-mmma' option
lto1: fatal error: target specific builtin not available
compilation terminated.
----------------------

[Bug lto/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linkw at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
I'll have a look first.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|lto                         |target
             Target|                            |powerpc
           Keywords|                            |lto

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
it's a target issue not handling the builtin properly in the target hook.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
This seems not a target specific issue. I noticed the target_option tree node
is created expectedly when seeing target pragma, it explains why it works well
without lto. When lto does streaming out, it does stream the target_option
node. 

Creating output block for decls
Creating compressed section .gnu.lto_.decls.db802b44a7cc3ae9
Outputting global stream
 0:  <function_decl 0x7d785d7f9e00 main>
    Streaming tree  <function_decl 0x7d785d7f9e00 main>
     Start of LTO_tree_scc of size 1
      Streaming header of  <optimization_node 0x7d785d590000>  to decls
      Streaming body of  <optimization_node 0x7d785d590000>  to decls
     286 bytes
     Start of LTO_tree_scc of size 1
      Streaming header of  <target_option_node 0x7d785d580030>  to decls
      Streaming body of  <target_option_node 0x7d785d580030>  to decls
     149 bytes

But debugging the read_decls part, I noticed it can materialize the
corresponding option_node, but it seems we don't associate this option_node to
the related function_decl. 


I constructed one aarch64 test case, it fails as well.

int64x2_t v1 = {100, 200};
int32x4_t v2 = {11, 22, 33, 44};

#pragma GCC target ("+simd")
int main()
{
  uint64x2_t vres = (uint64x2_t) __builtin_aarch64_usubw2v4si (v1, v2);
  printf("vres: %lld %lld\n", vres[0], vres[1]);
  return 0;
}

Command: -march=armv8-a+nosimd -flto

It can pass without -flto.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
I found i386 port seems doesn't have this issue.

#include <stdio.h>
#include <xmmintrin.h>

typedef union
{
  __m128  x;
  float a[4];
} union128;

#pragma GCC target("sse")
int main() {
  union128 u;
  __m128 a = _mm_set_ps (24.43, 68.346, 43.35, 546.46);
  __m128 b = _mm_set_ps (1.17, 2.16, 3.15, 4.14);
  u.x = _mm_add_ps (a,b);
  printf("u: %f %f %f %f\n", u.a[0], u.a[1],u.a[2],u.a[3]);
  return 0;
}

Command line: -mno-sse -flto

i386 ports seems to initialize all built-ins in bif table.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Right for aarch64, most people won't use +simd/+nosimd combo (though it might
show up inside the kernel) but they might use +sve/+nosve ...
So the aarch64 bug should be fixed ...

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
Quickly looking at the rs6000 code, it fails here:

#1  0x0000000011a0993c in rs6000_invalid_builtin
(fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
../../gcc/config/rs6000/rs6000-call.c:11643
#2  0x0000000011a13134 in rs6000_builtin_decl (code=1603, initialize_p=true) at
../../gcc/config/rs6000/rs6000-call.c:13870
#3  0x00000000115c3900 in unpack_ts_function_decl_value_fields
(bp=0x3fffffffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
#4  0x00000000115c4790 in streamer_read_tree_bitfields (ib=0x3fffffffe6a0,
data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
#5  0x0000000010deaa28 in lto_read_tree_1 (ib=0x3fffffffe6a0,
data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697

which relies on rs6000_builtin_mask. Note the mask is set here:
rs6000_builtin_mask = rs6000_builtin_mask_calculate ();

where rs6000_builtin_mask_calculate is based on TARGET_* values.

I think the mask check should be deferred later as it should be based on proper
target_node that is set via rs6000_set_current_function. It should not check
it in lto_read_tree_1.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #6)
> Quickly looking at the rs6000 code, it fails here:
> 
> #1  0x0000000011a0993c in rs6000_invalid_builtin
> (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
> ../../gcc/config/rs6000/rs6000-call.c:11643
> #2  0x0000000011a13134 in rs6000_builtin_decl (code=1603, initialize_p=true)
> at ../../gcc/config/rs6000/rs6000-call.c:13870
> #3  0x00000000115c3900 in unpack_ts_function_decl_value_fields
> (bp=0x3fffffffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
> #4  0x00000000115c4790 in streamer_read_tree_bitfields (ib=0x3fffffffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
> #5  0x0000000010deaa28 in lto_read_tree_1 (ib=0x3fffffffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697
> 
> which relies on rs6000_builtin_mask. Note the mask is set here:
> rs6000_builtin_mask = rs6000_builtin_mask_calculate ();
> 
> where rs6000_builtin_mask_calculate is based on TARGET_* values.

Is that really the issue though?  In a non-lto compile, handle_pragma_target()
ends up calling rs6000_option_override_internal which sets the TARGET_* flags
for the function given the pragma options.  Where does LTO do that?  I think I
see lto read in the default options that were set on the command line, but
where and when does LTO set the options defined by the pragma?  Are they even
streamed out to the fat obj file?  They could be there, but I'm not seeing it.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktkachov at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #6)
> Quickly looking at the rs6000 code, it fails here:
> 
> #1  0x0000000011a0993c in rs6000_invalid_builtin
> (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
> ../../gcc/config/rs6000/rs6000-call.c:11643
> #2  0x0000000011a13134 in rs6000_builtin_decl (code=1603, initialize_p=true)
> at ../../gcc/config/rs6000/rs6000-call.c:13870
> #3  0x00000000115c3900 in unpack_ts_function_decl_value_fields
> (bp=0x3fffffffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
> #4  0x00000000115c4790 in streamer_read_tree_bitfields (ib=0x3fffffffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
> #5  0x0000000010deaa28 in lto_read_tree_1 (ib=0x3fffffffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697
> 
> which relies on rs6000_builtin_mask. Note the mask is set here:
> rs6000_builtin_mask = rs6000_builtin_mask_calculate ();
> 
> where rs6000_builtin_mask_calculate is based on TARGET_* values.
> 
> I think the mask check should be deferred later as it should be based on
> proper
> target_node that is set via rs6000_set_current_function. It should not check
> it in lto_read_tree_1.

Thanks for looking into this, Martin! I tried to investigate if we can set
target_option_node as the appropriate fndecl when doing the check, then both
rs6000 and aarch64 ports don't need to change the hook since both of them
respect target_option_node switches well.

We have streamed out those fndecls with their target_option_nodes (if they
have)
into the .gnu.lto_.decls.xxx, fndecls are built well after reading, for one
bif fndecl, if we know which function it exists in, we can set_current_function
to the corresponding fndecl when checking the bif. After some hackings, I
noticed that there are two difficulties:
  1) For one bif, we need a way to know which fndecls use it. Now there seems
no
     information easy for this right before checking the bif?
  2) One bif can sit in several functions which probably have different
     target_option_nodes, we have to iterate all of them. This seems artificial
     just for this need.

I might still miss something, but after the hacking I agree to update the
target hooks is better. For rs6000, the mask checking removal aligns with the
way that i386 uses and also some changes like r10-7462 by neglecting mask.
Later rs6000_expand_builtin will still do the check with mask. But the erroring
would be in LTRANS, WPA phase won't emit error then. Is it one concern? If so,
which place can we delay this check to?

For aarch64 port, it seems to need some more adjustments?

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

--- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #7)
> (In reply to Martin Liška from comment #6)
> > Quickly looking at the rs6000 code, it fails here:
> > 
> > #1  0x0000000011a0993c in rs6000_invalid_builtin
> > (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
> > ../../gcc/config/rs6000/rs6000-call.c:11643
> > #2  0x0000000011a13134 in rs6000_builtin_decl (code=1603, initialize_p=true)
> > at ../../gcc/config/rs6000/rs6000-call.c:13870
> > #3  0x00000000115c3900 in unpack_ts_function_decl_value_fields
> > (bp=0x3fffffffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
> > #4  0x00000000115c4790 in streamer_read_tree_bitfields (ib=0x3fffffffe6a0,
> > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
> > #5  0x0000000010deaa28 in lto_read_tree_1 (ib=0x3fffffffe6a0,
> > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697
> > 
> > which relies on rs6000_builtin_mask. Note the mask is set here:
> > rs6000_builtin_mask = rs6000_builtin_mask_calculate ();
> > 
> > where rs6000_builtin_mask_calculate is based on TARGET_* values.
> 
> Is that really the issue though?  In a non-lto compile,
> handle_pragma_target() ends up calling rs6000_option_override_internal which
> sets the TARGET_* flags for the function given the pragma options.  Where
> does LTO do that?  I think I see lto read in the default options that were
> set on the command line, but where and when does LTO set the options defined
> by the pragma?  Are they even streamed out to the fat obj file?  They could
> be there, but I'm not seeing it.

I guess the problem here is this bif checking is so early, it's when we make up
the bif function_decl tree_node, at that time the context is still the one with
default option. I may be wrong, what I understood is that the target_option is
streamed out as part of its associated function decl into decls section, when
streaming in the decls section, the decls are constructed (including function
decls with target_option and bif decls), the bif validity checking happen here.
But function decls with target_option will be used for setting current function
later when lto starts to process cgraph_node one by one. IIUC, fat obj file
should not affect since it's mainly to control normal non-lto sections
generated or not.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 23 Sep 2021, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
> 
> --- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
> (In reply to Peter Bergner from comment #7)
> > (In reply to Martin Liška from comment #6)
> > > Quickly looking at the rs6000 code, it fails here:
> > > 
> > > #1  0x0000000011a0993c in rs6000_invalid_builtin
> > > (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
> > > ../../gcc/config/rs6000/rs6000-call.c:11643
> > > #2  0x0000000011a13134 in rs6000_builtin_decl (code=1603, initialize_p=true)
> > > at ../../gcc/config/rs6000/rs6000-call.c:13870
> > > #3  0x00000000115c3900 in unpack_ts_function_decl_value_fields
> > > (bp=0x3fffffffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
> > > #4  0x00000000115c4790 in streamer_read_tree_bitfields (ib=0x3fffffffe6a0,
> > > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
> > > #5  0x0000000010deaa28 in lto_read_tree_1 (ib=0x3fffffffe6a0,
> > > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697
> > > 
> > > which relies on rs6000_builtin_mask. Note the mask is set here:
> > > rs6000_builtin_mask = rs6000_builtin_mask_calculate ();
> > > 
> > > where rs6000_builtin_mask_calculate is based on TARGET_* values.

Yeah, that's not going to work - if there are different builtin
decls for different flags then you have to use different BUILT_IN_*
codes as well.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-11-26

--- Comment #11 from Kewen Lin <linkw at gcc dot gnu.org> ---
Status update: one proposed fix was posted to gcc-patches@ on Sep 28
(https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580357.html), there
were some discussion following that, we agreed the proposed fix is safe
eventually. There are no further new versions for it, so keep the original one
being ping-ed for review.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:6c7d489a1e6592bc73db03678c1231748fd7a126

commit r12-5590-g6c7d489a1e6592bc73db03678c1231748fd7a126
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Nov 29 21:22:32 2021 -0600

    rs6000: Remove builtin mask check from builtin_decl [PR102347]

    As the discussion in PR102347, currently builtin_decl is invoked so
    early, it's when making up the function_decl for builtin functions,
    at that time the rs6000_builtin_mask could be wrong for those
    builtins sitting in #pragma/attribute target functions, though it
    will be updated properly later when LTO processes all nodes.

    This patch is to align with the practice i386 port adopts, also
    align with r10-7462 by relaxing builtin mask checking in some places.

    gcc/ChangeLog:

            PR target/102347
            * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
mask
            check.

    gcc/testsuite/ChangeLog:

            PR target/102347
            * gcc.target/powerpc/pr102347.c: New test.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by William Schmidt <wschmidt@gcc.gnu.org>:

https://gcc.gnu.org/g:d683a1b3e89007211a7c800bb61647d8ac42cb6b

commit r12-5695-gd683a1b3e89007211a7c800bb61647d8ac42cb6b
Author: Bill Schmidt <wschmidt@linux.ibm.com>
Date:   Wed Dec 1 09:20:15 2021 -0600

    rs6000: Mirror fix for PR102347 in new builtins support

    Recently Kewen fixed a problem in the old builtins support where
    rs6000_builtin_decl prematurely indicated that a target builtin is
    unavailable.  This also needs to be done for the new builtins support, but
in
    this case we have to ensure the error message is still produced from the
    overload support in rs6000-c.c.  Unfortunately, this is less
straightforward
    than it could be, because header file includes need to be adjusted to make
this
    happen.  Someday we'll consolidate all the builtin code in one file and
this
    won't have to be so ugly.

    2021-12-01  Bill Schmidt  <wschmidt@linux.ibm.com>

    gcc/
            PR target/102347
            * config/rs6000/rs6000-c.c (rs6000-builtins.h): Stop including.
            (rs6000-internal.h): Include.
            (altivec_resolve_new_overloaded_builtin): Move call to
            rs6000_invalid_new_builtin here from rs6000_new_builtin_decl.
            * config/rs6000/rs6000-call.c (rs6000-builtins.h): Stop including.
            (rs6000_invalid_new_builtin): Remove static qualifier.
            (rs6000_new_builtin_decl): Remove test for supported builtin.
            * config/rs6000/rs6000-internal.h (rs6000-builtins.h): Include.
            (rs6000_invalid_new_builtin): Declare.
            * config/rs6000/rs6000.c (rs6000-builtins.h): Don't include.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://gcc.gnu.org/bugzill |
                   |a/show_bug.cgi?id=103622    |

--- Comment #14 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Removing the "see also" for 103622, which is not really related.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:4636d61e9ad2a57a9c072e60f9d30429e83c2f4e

commit r11-9384-g4636d61e9ad2a57a9c072e60f9d30429e83c2f4e
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Nov 29 21:22:32 2021 -0600

    rs6000: Remove builtin mask check from builtin_decl [PR102347]

    As the discussion in PR102347, currently builtin_decl is invoked so
    early, it's when making up the function_decl for builtin functions,
    at that time the rs6000_builtin_mask could be wrong for those
    builtins sitting in #pragma/attribute target functions, though it
    will be updated properly later when LTO processes all nodes.

    This patch is to align with the practice i386 port adopts, also
    align with r10-7462 by relaxing builtin mask checking in some places.

    gcc/ChangeLog:

            PR target/102347
            * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
mask
            check.

    gcc/testsuite/ChangeLog:

            PR target/102347
            * gcc.target/powerpc/pr102347.c: New test.

    (cherry picked from commit 6c7d489a1e6592bc73db03678c1231748fd7a126)

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:b562a5811a24eff140eb64dce0bb3dc94c238a5d

commit r10-10339-gb562a5811a24eff140eb64dce0bb3dc94c238a5d
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Nov 29 21:22:32 2021 -0600

    rs6000: Remove builtin mask check from builtin_decl [PR102347]

    As the discussion in PR102347, currently builtin_decl is invoked so
    early, it's when making up the function_decl for builtin functions,
    at that time the rs6000_builtin_mask could be wrong for those
    builtins sitting in #pragma/attribute target functions, though it
    will be updated properly later when LTO processes all nodes.

    This patch is to align with the practice i386 port adopts, also
    align with r10-7462 by relaxing builtin mask checking in some places.

    gcc/ChangeLog:

            PR target/102347
            * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
mask
            check.

    gcc/testsuite/ChangeLog:

            PR target/102347
            * gcc.target/powerpc/pr102347.c: New test.

    (cherry picked from commit 6c7d489a1e6592bc73db03678c1231748fd7a126)

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:031d42adff2c958cd5bc8457fd89cc5b6f8b8c7b

commit r9-9869-g031d42adff2c958cd5bc8457fd89cc5b6f8b8c7b
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Dec 15 01:16:31 2021 -0600

    rs6000: Remove builtin mask check from builtin_decl [PR102347]

    As the discussion in PR102347, currently builtin_decl is invoked so
    early, it's when making up the function_decl for builtin functions,
    at that time the rs6000_builtin_mask could be wrong for those
    builtins sitting in #pragma/attribute target functions, though it
    will be updated properly later when LTO processes all nodes.

    This patch is to align with the practice i386 port adopts, also
    align with r10-7462 by relaxing builtin mask checking in some places.

    gcc/ChangeLog:

            PR target/102347
            * config/rs6000/rs6000.c (rs6000_builtin_decl): Remove builtin mask
            check.

    gcc/testsuite/ChangeLog:

            PR target/102347
            * gcc.target/powerpc/pr102347.c: New test.

    (cherry picked from commit 6c7d489a1e6592bc73db03678c1231748fd7a126)

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #18 from Kewen Lin <linkw at gcc dot gnu.org> ---
Fixed on trunk and backported to all active release branches.

Note that gcc-9 has some difference from the original commit on trunk since it
doesn't support power10 and its rs6000_builtin_decl isn't factored out either.
So I cooked one different test case which doesn't require power10 but still has
the same test coverage. As testing, the case works on ppc64le Power9 and ppc64
Power8 (BE), which can expose the original problem and pass with the fix now.
The patch against gcc-9 was also bootstrapped and regress-tested on ppc64le
Power9.

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

[linkw at gcc dot gnu.org]

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

--- Comment #19 from Kewen Lin <linkw at gcc dot gnu.org> ---
Filed PR103727 for aarch64 issue tracking.