[Bug preprocessor/106840] New: glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[Bug preprocessor/106840] New: glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[marxin at gcc dot gnu.org]

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

            Bug ID: 106840
           Summary: glibc master build failure on ppc64le-linux-gnu since
                    r13-2212-geb4879ab905308
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: drepper at gcc dot gnu.org, jakub at gcc dot gnu.org,
                    segher at gcc dot gnu.org
  Target Milestone: ---
              Host: ppc64le-linux-gnu

Since the revision, I can't build glibc master on ppc64le-linux:

python3 -B ../scripts/gen-as-const.py --cc="gcc -std=gnu11 -fgnu89-inline  -g
-O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition
-fmath-errno  -mabi=ieeelongdouble -Wno-psabi -mno-gnu-attribute
-mlong-double-128    -ftls-model=initial-exec      -I../include
-I/home/marxin/Programming/glibc/objdir/csu 
-I/home/marxin/Programming/glibc/objdir 
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/le/fpu 
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/fpu 
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64/le 
-I../sysdeps/unix/sysv/linux/powerpc/powerpc64 
-I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/unix/sysv/linux/powerpc 
-I../sysdeps/powerpc/nptl  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread 
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv 
-I../sysdeps/unix/powerpc  -I../sysdeps/unix  -I../sysdeps/posix 
-I../sysdeps/powerpc/powerpc64/le/power8/fpu/multiarch 
-I../sysdeps/powerpc/powerpc64/le/power7/fpu/multiarch 
-I../sysdeps/powerpc/powerpc64/le/fpu/multiarch 
-I../sysdeps/powerpc/powerpc64/le/power8/fpu 
-I../sysdeps/powerpc/powerpc64/le/power7/fpu 
-I../sysdeps/powerpc/powerpc64/le/fpu  -I../sysdeps/powerpc/powerpc64/fpu 
-I../sysdeps/powerpc/powerpc64/le/power8/multiarch 
-I../sysdeps/powerpc/powerpc64/le/power7/multiarch 
-I../sysdeps/powerpc/powerpc64/le/multiarch 
-I../sysdeps/powerpc/powerpc64/multiarch 
-I../sysdeps/powerpc/powerpc64/le/power8  -I../sysdeps/powerpc/powerpc64/power8
 -I../sysdeps/powerpc/powerpc64/le/power7 
-I../sysdeps/powerpc/powerpc64/power7  -I../sysdeps/powerpc/powerpc64/power6 
-I../sysdeps/powerpc/powerpc64/power4  -I../sysdeps/powerpc/power4 
-I../sysdeps/powerpc/powerpc64/le  -I../sysdeps/powerpc/powerpc64 
-I../sysdeps/wordsize-64  -I../sysdeps/powerpc/fpu  -I../sysdeps/powerpc 
-I../sysdeps/ieee754/ldbl-128ibm-compat 
-I../sysdeps/ieee754/ldbl-128ibm/include -I../sysdeps/ieee754/ldbl-128ibm 
-I../sysdeps/ieee754/ldbl-opt  -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/float128 
-I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.  
-D_LIBC_REENTRANT -include /home/marxin/Programming/glibc/objdir/libc-modules.h
-DMODULE_NAME=libc -include ../include/libc-symbols.h      
-DTOP_NAMESPACE=glibc -DGEN_AS_CONST_HEADERS \
                   -MD -MP -MF
/home/marxin/Programming/glibc/objdir/rtld-sizes.h.dT \
                   -MT '/home/marxin/Programming/glibc/objdir/rtld-sizes.h.d
/home/marxin/Programming/glibc/objdir/rtld-sizes.h'" \
          rtld-sizes.sym > /home/marxin/Programming/glibc/objdir/rtld-sizes.hT
In file included from ../sysdeps/unix/powerpc/sysdep.h:21,
                 from ../sysdeps/unix/sysv/linux/powerpc/sysdep.h:23,
                 from ../sysdeps/unix/sysv/linux/powerpc/powerpc64/sysdep.h:23,
                 from ../sysdeps/powerpc/nptl/tls.h:49,
                 from ../include/link.h:51,
                 from <stdin>:1:
../sysdeps/powerpc/powerpc64/sysdep.h:42:13: error: '\N' not followed by '{'
   42 |         .if \NARG
      |             ^
../sysdeps/powerpc/powerpc64/sysdep.h:43:18: error: '\N' not followed by '{'
   43 |         SAVE_ARG \NARG-1
      |                  ^
../sysdeps/powerpc/powerpc64/sysdep.h:44:19: error: '\N' not followed by '{'
   44 |         std    
2+\NARG,-FRAME_MIN_SIZE_PARM+FRAME_PARM_SAVE-8+8*(\NARG)(1)
      |                   ^
../sysdeps/powerpc/powerpc64/sysdep.h:44:67: error: '\N' not followed by '{'
   44 |         std    
2+\NARG,-FRAME_MIN_SIZE_PARM+FRAME_PARM_SAVE-8+8*(\NARG)(1)
      |                                                                   ^
../sysdeps/powerpc/powerpc64/sysdep.h:49:13: error: '\N' not followed by '{'
   49 |         .if \NARG
      |             ^

[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-09-05
             Status|UNCONFIRMED                 |NEW

[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600940.html

[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
This is inside #ifdef __ASSEMBLER__ .  Running assembler code (or anything else
that isn't C) through the C preprocessor is the subject of one of my "why would
you ever do that" rants: the assembler macro processor is strictly more capable
already, and has much saner semantics (for assembler code).

[Bug preprocessor/106840] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600940.html

I know it's caused by the revision, anything you wanted to point out in
particular?

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
            Summary|glibc master build failure  |[13 Regression] glibc
                   |on ppc64le-linux-gnu since  |master build failure on
                   |r13-2212-geb4879ab905308    |ppc64le-linux-gnu since
                   |                            |r13-2212-geb4879ab905308

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, why does this C++ feature affect assembler source?  The invocation
specifies -std=gnu11 so I would have expected the preprocessor to be set up in
"C mode"?

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is treated as an extension even for C and older C++.
But given the discussions Joseph started, the above patch changes it such that
it only will be recognized as an extension outside of string/character literals
if it starts with \N{ rather than just \N and only in the non-standard modes
(-std=gnu*) except for -std=c++2{3,b}.
So \NARG will be handled as before without any diagnostics...

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
Apparently, Joseph noticed that before at the mailing list where the patch was
discussed.

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Target|                            |ppc64le-linux-gnu

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I believe this should have been fixed with:
https://gcc.gnu.org/g:572f5e1bc68e131b25cd2d5ba231e932f5038904

commit r13-2508-g572f5e1bc68e131b25cd2d5ba231e932f5038904
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Sep 7 08:44:38 2022 +0200

    libcpp: Named universal character escapes and delimited escape sequence
tweaks

    On Tue, Aug 30, 2022 at 09:10:37PM +0000, Joseph Myers wrote:
    > I'm seeing build failures of glibc for powerpc64, as illustrated by the
    > following C code:
    >
    > #if 0
    > \NARG
    > #endif
    >
    > (the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
    > __ASSEMBLER__).
    >
    > This shows some problems with this feature - and with delimited escape
    > sequences - as it affects C.  It's fine to accept it as an extension
    > inside string and character literals, because \N or \u{...} would be
    > invalid in the absence of the feature (i.e. the syntax for such literals
    > fails to match, meaning that the rule about undefined behavior for a
    > single ' or " as a pp-token applies).  But outside string and character
    > literals, the usual lexing rules apply, the \ is a pp-token on its own
and
    > the code is valid at the preprocessing level, and with expansion of
macros
    > appearing before or after the \ (e.g. u defined as a macro in the \u{...}
    > case) it may be valid code at the language level as well.  I don't know
    > what older C++ versions say about this, but for C this means e.g.
    >
    > #define z(x) 0
    > #define a z(
    > int x = a\NARG);
    >
    > needs to be accepted as expanding to "int x = 0;", not interpreted as
    > using the \N feature in an identifier and produce an error.

    The following patch changes this, so that:
    1) outside of string/character literals, \N without following { is never
       treated as an error nor warning, it is silently treated as \ separate
       token followed by whatever is after it
    2) \u{123} and \N{LATIN SMALL LETTER A WITH ACUTE} are not handled as
       extension at all outside of string/character literals in the strict
       standard modes (-std=c*) except for -std=c++{23,2b}, only in the
       -std=gnu* modes, because it changes behavior on valid sources, e.g.
       #define z(x) 0
       #define a z(
       int x = a\u{123});
       int y = a\N{LATIN SMALL LETTER A WITH ACUTE});
    3) introduces -Wunicode warning (on by default) and warns for cases
       of what looks like invalid delimited escape sequence or named
       universal character escape outside of string/character literals
       and is treated as separate tokens

    2022-09-07  Jakub Jelinek  <jakub@redhat.com>

    libcpp/
            * include/cpplib.h (struct cpp_options): Add cpp_warn_unicode
member.
            (enum cpp_warning_reason): Add CPP_W_UNICODE.
            * init.cc (cpp_create_reader): Initialize cpp_warn_unicode.
            * charset.cc (_cpp_valid_ucn): In possible identifier contexts,
don't
            handle \u{ or \N{ specially in -std=c* modes except -std=c++2{3,b}.
            In possible identifier contexts, don't emit an error and punt
            if \N isn't followed by {, or if \N{} surrounds some lower case
            letters or _.  In possible identifier contexts when not C++23,
don't
            emit an error but warning about unknown character names and treat
as
            separate tokens.  When treating as separate tokens \u{ or \N{, emit
            warnings.
    gcc/
            * doc/invoke.texi (-Wno-unicode): Document.
    gcc/c-family/
            * c.opt (Winvalid-utf8): Use ObjC instead of objC.  Remove
            " in comments" from description.
            (Wunicode): New option.
    gcc/testsuite/
            * c-c++-common/cpp/delimited-escape-seq-4.c: New test.
            * c-c++-common/cpp/delimited-escape-seq-5.c: New test.
            * c-c++-common/cpp/delimited-escape-seq-6.c: New test.
            * c-c++-common/cpp/delimited-escape-seq-7.c: New test.
            * c-c++-common/cpp/named-universal-char-escape-5.c: New test.
            * c-c++-common/cpp/named-universal-char-escape-6.c: New test.
            * c-c++-common/cpp/named-universal-char-escape-7.c: New test.
            * g++.dg/cpp23/named-universal-char-escape1.C: New test.
            * g++.dg/cpp23/named-universal-char-escape2.C: New test.

[Bug preprocessor/106840] [13 Regression] glibc master build failure on ppc64le-linux-gnu since r13-2212-geb4879ab905308

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Assuming fixed.