[Bug libstdc++/97163] New: Build error with -mcpu=power9 on ppc64

[Bug libstdc++/97163] New: Build error with -mcpu=power9 on ppc64

[pkubaj at anongoth dot pl]

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

            Bug ID: 97163
           Summary: Build error with -mcpu=power9 on ppc64
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pkubaj at anongoth dot pl
  Target Milestone: ---

The same error happens also on GCC 9.3.0.
I'm using Clang 11.0.0 rc2 to build, but it happened before with 10 (I only now
got to report it).

Issue:
gmake[5]: Entering directory
'/tmp/usr/ports/lang/gcc10/work/.build/build-powerpc64-portbld-freebsd13.0/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
c++ -std=gnu++98  -I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp -I.
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/../include
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/include -DLIBICONV_PLUG -O2
-pipe -mcpu=power9   -DLIBICONV_PLUG  -W -Wall -Wno-narrowing -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp -I.
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/../include
-I/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/include -DLIBICONV_PLUG  -c
-o lex.o -MT lex.o -MMD -MP -MF .deps/lex.Tpo
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c
c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated [-Wdeprecated]
In file included from
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:23:
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/system.h:439:9: warning:
keyword is hidden by macro definition [-Wkeyword-macro]
#define true 1
        ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/system.h:440:9: warning:
keyword is hidden by macro definition [-Wkeyword-macro]
#define false 0
        ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:544:26: warning: unknown
attribute 'altivec' ignored [-Wunknown-attributes]
  typedef __attribute__((altivec(vector))) unsigned char vc;
                         ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:546:12: error: excess
elements in scalar initializer
  const vc repl_nl = {
           ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:550:12: error: excess
elements in scalar initializer
  const vc repl_cr = {
           ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:554:12: error: excess
elements in scalar initializer
  const vc repl_bs = {
           ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:558:12: error: excess
elements in scalar initializer
  const vc repl_qm = {
           ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:571:14: error: use of
undeclared identifier '__builtin_vec_vsx_ld'
      data = __builtin_vec_vsx_ld (0, s);
             ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:574:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
      m_nl = (vc) __builtin_vec_cmpeq(data, repl_nl);
                  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:575:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
      m_cr = (vc) __builtin_vec_cmpeq(data, repl_cr);
                  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:576:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
      m_bs = (vc) __builtin_vec_cmpeq(data, repl_bs);
                  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:577:19: error: use of
undeclared identifier '__builtin_vec_cmpeq'
      m_qm = (vc) __builtin_vec_cmpeq(data, repl_qm);
                  ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:584:11: error: use of
undeclared identifier '__builtin_vec_vcmpeq_p'
  while (!__builtin_vec_vcmpeq_p(/*__CR6_LT_REV*/3, t, zero));
          ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:595:23: error: array is
too large (18446744073709551615 elements)
      unsigned long l[(N == 2 || N == 4) ? N : -1];
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:602:13: warning: no case
matching constant switch condition '0'
    switch (N)
            ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:590:12: note: expanded
from macro 'N'
#define N  (sizeof(vc) / sizeof(long))
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1729:8: warning: result
of comparison against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
              BUF_APPEND ("\\", 1);
              ^~~~~~~~~~~~~~~~~~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1699:30: note: expanded
from macro 'BUF_APPEND'
            && (const uchar *)(STR) != base                     \
               ~~~~~~~~~~~~~~~~~~~~ ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1738:5: warning: result
of comparison against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
                  BUF_APPEND (" ", 1);
                  ^~~~~~~~~~~~~~~~~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1699:30: note: expanded
from macro 'BUF_APPEND'
            && (const uchar *)(STR) != base                     \
               ~~~~~~~~~~~~~~~~~~~~ ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1741:8: warning: result
of comparison against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
              BUF_APPEND ("\n", 1);
              ^~~~~~~~~~~~~~~~~~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1699:30: note: expanded
from macro 'BUF_APPEND'
            && (const uchar *)(STR) != base                     \
               ~~~~~~~~~~~~~~~~~~~~ ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1764:5: warning: result
of comparison against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
                  BUF_APPEND ("??", 2);
                  ^~~~~~~~~~~~~~~~~~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1699:30: note: expanded
from macro 'BUF_APPEND'
            && (const uchar *)(STR) != base                     \
               ~~~~~~~~~~~~~~~~~~~~ ^
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1773:9: warning: result
of comparison against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
                      BUF_APPEND ("/", 1);
                      ^~~~~~~~~~~~~~~~~~~
/tmp/usr/ports/lang/gcc10/work/gcc-10.2.0/libcpp/lex.c:1699:30: note: expanded
from macro 'BUF_APPEND'
            && (const uchar *)(STR) != base                     \
               ~~~~~~~~~~~~~~~~~~~~ ^
9 warnings and 11 errors generated.
gmake[5]: *** [Makefile:224: lex.o] Error 1
gmake[5]: Leaving directory
'/tmp/usr/ports/lang/gcc10/work/.build/build-powerpc64-portbld-freebsd13.0/libcpp'
gmake[4]: *** [Makefile:2923: all-build-libcpp] Error 2
gmake[4]: Leaving directory '/tmp/usr/ports/lang/gcc10/work/.build'
gmake[3]: *** [Makefile:22903: stage1-bubble] Error 2
gmake[3]: Leaving directory '/tmp/usr/ports/lang/gcc10/work/.build'
gmake[2]: *** [Makefile:23235: bootstrap-lean] Error 2
gmake[2]: Leaving directory '/tmp/usr/ports/lang/gcc10/work/.build'
*** Error code 1

[Bug libstdc++/97163] Build error with -mcpu=power9 on ppc64

[pkubaj at anongoth dot pl]

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

--- Comment #1 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
This is on FreeBSD head, which uses ELFv2.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess we need something like:
-#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__)
+#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) && defined(__ALTIVEC__)
in libcpp/lex.c if clang doesn't support the altivec attribute and the
builtins.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Guess we need something like:
> -#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__)
> +#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) && defined(__ALTIVEC__)
> in libcpp/lex.c if clang doesn't support the altivec attribute and the
> builtins.

But it should!  What is actually going wrong here?  The compiler should
not declare it supports what is tested for by __ALTIVEC__ if it doesn't.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, libcpp isn't using the standard Altivec intrinsics, but their gcc
underlying implementation.  Looking at clang altivec.h, I see they use vector
keyword everywhere and not sure what exactly they map it to under the hood, but
clearly not to altivec attribute, and they have different __builtin_* calls to
implement e.g. vsx_ld and the like.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Yeah, good point.

So either we can convert to the normal intrinsics, or (much easier)
check we are building with GCC at all.  But why 4.5?  Do earlier
versions not work?

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It can be anything > 4.2 (because clang pretends to be GCC 4.2).

4.5 was just because the other altivec section was >= 4.5.
PR45381 contains some details about that.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Ah.

Is there no better way to detect GCC impostors?  Oh well.

Since we require 4.5 as bootstrap compiler, this makes no difference
at all for compilers that truthfully claim to be GCC, so it has my
blessing if you want that :-)

Thanks!

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r11-3476-gd00b1b023ecfc3ddc3fe952c0063dab7529d5f7a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 26 10:07:41 2020 +0200

    powerpc, libcpp: Fix gcc build with clang on power8 [PR97163]

    libcpp has two specialized altivec implementations of search_line_fast,
    one for power8+ and the other one otherwise.
    Both use __attribute__((altivec(vector))) and the GCC builtins rather than
    altivec.h and the APIs from there, which is fine, but should be restricted
    to when libcpp is built with GCC, so that it can be relied on.
    The second elif is
    and thus e.g. when built with clang it isn't picked, but the first one was
    just guarded with
    and so according to the bugreporter clang fails miserably on that.

    The following patch fixes that by adding the same GCC_VERSION requirement
    as the second version.  I don't know where the 4.5 in there comes from and
    the exact version doesn't matter that much, as long as it is above 4.2 that
    clang pretends to be and smaller or equal to 4.8 as the oldest gcc we
    support as bootstrap compiler ATM.
    Furthermore, the patch fixes the comment, the version it is talking about
is
    not pre-GCC 5, but actually the GCC 5+ one.

    2020-09-26  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/97163
            * lex.c (search_line_fast): Only use _ARCH_PWR8 Altivec version
            for GCC >= 4.5.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r10-8851-gcd547f0ddcd3a54e5b73bcda5ac0f0c46808db8b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 26 10:07:41 2020 +0200

    powerpc, libcpp: Fix gcc build with clang on power8 [PR97163]

    libcpp has two specialized altivec implementations of search_line_fast,
    one for power8+ and the other one otherwise.
    Both use __attribute__((altivec(vector))) and the GCC builtins rather than
    altivec.h and the APIs from there, which is fine, but should be restricted
    to when libcpp is built with GCC, so that it can be relied on.
    The second elif is
    and thus e.g. when built with clang it isn't picked, but the first one was
    just guarded with
    and so according to the bugreporter clang fails miserably on that.

    The following patch fixes that by adding the same GCC_VERSION requirement
    as the second version.  I don't know where the 4.5 in there comes from and
    the exact version doesn't matter that much, as long as it is above 4.2 that
    clang pretends to be and smaller or equal to 4.8 as the oldest gcc we
    support as bootstrap compiler ATM.
    Furthermore, the patch fixes the comment, the version it is talking about
is
    not pre-GCC 5, but actually the GCC 5+ one.

    2020-09-26  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/97163
            * lex.c (search_line_fast): Only use _ARCH_PWR8 Altivec version
            for GCC >= 4.5.

    (cherry picked from commit d00b1b023ecfc3ddc3fe952c0063dab7529d5f7a)

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[pkubaj at anongoth dot pl]

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

--- Comment #10 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
Would it be possible to backport this issue to 9?

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r9-9388-gc60d0f6b7b586ff623e423c28f403ab7e5e78fbc
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 26 10:07:41 2020 +0200

    powerpc, libcpp: Fix gcc build with clang on power8 [PR97163]

    libcpp has two specialized altivec implementations of search_line_fast,
    one for power8+ and the other one otherwise.
    Both use __attribute__((altivec(vector))) and the GCC builtins rather than
    altivec.h and the APIs from there, which is fine, but should be restricted
    to when libcpp is built with GCC, so that it can be relied on.
    The second elif is
    and thus e.g. when built with clang it isn't picked, but the first one was
    just guarded with
    and so according to the bugreporter clang fails miserably on that.

    The following patch fixes that by adding the same GCC_VERSION requirement
    as the second version.  I don't know where the 4.5 in there comes from and
    the exact version doesn't matter that much, as long as it is above 4.2 that
    clang pretends to be and smaller or equal to 4.8 as the oldest gcc we
    support as bootstrap compiler ATM.
    Furthermore, the patch fixes the comment, the version it is talking about
is
    not pre-GCC 5, but actually the GCC 5+ one.

    2020-09-26  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/97163
            * lex.c (search_line_fast): Only use _ARCH_PWR8 Altivec version
            for GCC >= 4.5.

    (cherry picked from commit cd547f0ddcd3a54e5b73bcda5ac0f0c46808db8b)

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r8-10858-gebb474647037a7bd429e400b21b2dedbb78fee5e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 26 10:07:41 2020 +0200

    powerpc, libcpp: Fix gcc build with clang on power8 [PR97163]

    libcpp has two specialized altivec implementations of search_line_fast,
    one for power8+ and the other one otherwise.
    Both use __attribute__((altivec(vector))) and the GCC builtins rather than
    altivec.h and the APIs from there, which is fine, but should be restricted
    to when libcpp is built with GCC, so that it can be relied on.
    The second elif is
    and thus e.g. when built with clang it isn't picked, but the first one was
    just guarded with
    and so according to the bugreporter clang fails miserably on that.

    The following patch fixes that by adding the same GCC_VERSION requirement
    as the second version.  I don't know where the 4.5 in there comes from and
    the exact version doesn't matter that much, as long as it is above 4.2 that
    clang pretends to be and smaller or equal to 4.8 as the oldest gcc we
    support as bootstrap compiler ATM.
    Furthermore, the patch fixes the comment, the version it is talking about
is
    not pre-GCC 5, but actually the GCC 5+ one.

    2020-09-26  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/97163
            * lex.c (search_line_fast): Only use _ARCH_PWR8 Altivec version
            for GCC >= 4.5.

    (cherry picked from commit cd547f0ddcd3a54e5b73bcda5ac0f0c46808db8b)

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug bootstrap/97163] Build error with -mcpu=power9 on ppc64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |8.5