[Bug other/113182] New: [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[Bug other/113182] New: [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org]

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

            Bug ID: 113182
           Summary: [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C
                    -std=c++14 execution test
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: danglin at gcc dot gnu.org
                CC: jemarch at gcc dot gnu.org
  Target Milestone: ---
              Host: hppa64-hp-hpux11.11
            Target: hppa64-hp-hpux11.11
             Build: hppa64-hp-hpux11.11

Executing on host: /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B/h
ome/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../  exceptions_enabled19821.cc
  -fdiagnostics-plain-output  -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-h
p-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir
64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v
3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/
gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-Wno-complain-wrong-l
ang  -S -o exceptions_enabled19821.s    (timeout = 300)
spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../ exceptions_enabled19821.cc
-fdiagnostics-plain-output -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-h
pux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/
hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/l
ibsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu
/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-Wno-complain-wrong-lang
 -S -o exceptions_enabled19821.s
PASS: g++.dg/cpp0x/udlit-namespace.C  -std=c++14 (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/experimental/.libs:/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../..:.:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/experimental/.libs:/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../..
Execution timeout is: 300
spawn [open ...]
FAIL: g++.dg/cpp0x/udlit-namespace.C  -std=c++14 execution test

Similar fails:
FAIL: g++.dg/cpp0x/udlit-namespace.C  -std=c++17 execution test
FAIL: g++.dg/cpp0x/udlit-namespace.C  -std=c++20 execution test

(gdb) r
Starting program:
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/udlit-namespace.exe

Program received signal SIGSEGV, Segmentation fault.
0x800003ffbfcd3000 in ?? ()
   from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl.6
(gdb) bt
#0  0x800003ffbfcd3000 in ?? ()
   from
/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl.6
#1  0x800003ffbfe5f3f4 in fmodl (x=<optimized out>, y=<optimized out>)
    at ../../../../../gcc/libstdc++-v3/src/c++98/math_stubs_long_double.cc:117
Backtrace stopped: Cannot access memory at address 0x3333333333333323

This problem was introduced by the following commit:

bash-5.1$ git bisect bad
f31a019d1161ec78846473da743aedf49cca8c27 is the first bad commit
commit f31a019d1161ec78846473da743aedf49cca8c27
Author: Jose E. Marchesi <jose.marchesi@oracle.com>
Date:   Fri Nov 24 06:30:28 2023 +0100

    Emit funcall external declarations only if actually used.

    There are many places in GCC where alternative local sequences are
    tried in order to determine what is the cheapest or best alternative
    to use in the current target.  When any of these sequences involve a
    libcall, the current implementation of emit_library_call_value_1
    introduce a side-effect consisting on emitting an external declaration
    for the funcall (such as __divdi3) which is thus emitted even if the
    sequence that does the libcall is not retained.

    This is problematic in targets such as BPF, because the kernel loader
    chokes on the spurious symbol __divdi3 and makes the resulting BPF
    object unloadable.  Note that BPF objects are not linked before being
    loaded.

    This patch changes asssemble_external_libcall to defer emitting
    declarations of external libcall symbols, by saving the call tree
    nodes in a temporary list pending_libcall_symbols and letting
    process_pending_assembly_externals to emit them only if they have been
    referenced.  Solution suggested and sketched by Richard Sandiford.

    Regtested in x86_64-linux-gnu.
    Tested with host x86_64-linux-gnu with target bpf-unknown-none.

    gcc/ChangeLog

            PR target/109253
            * varasm.cc (pending_libcall_symbols): New variable.
            (process_pending_assemble_externals): Process
            pending_libcall_symbols.
            (assemble_external_libcall): Defer emitting external libcall
            symbols to process_pending_assemble_externals.

    gcc/testsuite/ChangeLog

            PR target/109253
            * gcc.target/bpf/divmod-libcall-1.c: New test.
            * gcc.target/bpf/divmod-libcall-2.c: Likewise.
            * gcc.c-torture/compile/libcall-2.c: Likewise.

 gcc/testsuite/gcc.c-torture/compile/libcall-2.c |  8 ++++++++
 gcc/testsuite/gcc.target/bpf/divmod-libcall-1.c | 19 +++++++++++++++++++
 gcc/testsuite/gcc.target/bpf/divmod-libcall-2.c | 16 ++++++++++++++++
 gcc/varasm.cc                                   | 22 +++++++++++++++++++++-
 4 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/compile/libcall-2.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-libcall-1.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-libcall-2.c

The problem is we have lost the types for libcall symbols.

bash-5.1$ /usr/bin/nm
./hppa64-hp-hpux11.11/libstdc++-v3/src/c++98/math_stubs_long_double.o|less
[Index]    Value                  Size    Type  Bind  O Shndx    Name

[0]      |                     0|       0|NOTYP|LOCAL|0|   UNDEF|
...
[69]     |                     0|       0|NOTYP|GLOB |0|   UNDEF|_U_Qfadd
[43]     |                     0|       0|NOTYP|GLOB |0|  
UNDEF|_U_Qfcnvff_dbl_to_quad
[42]     |                     0|       0|NOTYP|GLOB |0|  
UNDEF|_U_Qfcnvff_quad_to_dbl
[71]     |                     0|       0|NOTYP|GLOB |0|   UNDEF|_U_Qfdiv
[70]     |                     0|       0|NOTYP|GLOB |0|   UNDEF|_U_Qfeq
[72]     |                     0|       0|NOTYP|GLOB |0|   UNDEF|_U_Qfmpy
[45]     |                     0|       0|FUNC |GLOB |0|   UNDEF|acos
[44]     |                     0|      64|FUNC |GLOB |0|.text.acosl|acosl

_U_Qfcnvff_dbl_to_quad, etc, need to have type FUNC.  The HP linker does
not correctly handle calls to symbols that have type NOTYP.  As a result,
the call to _U_Qfcnvff_dbl_to_quad branches to a data address.  This
generates a segmentation fault.

See pa_init_libfuncs() in pa.cc.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |pinskia at gcc dot gnu.org
   Target Milestone|---                         |14.0
          Component|other                       |middle-end

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I figured it would be PA RISC which would have issues with this too.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2023-12-30 1:30 p.m., pinskia at gcc dot gnu.org wrote:
> I figured it would be PA RISC which would have issues with this too.
It's only an issue on hpux.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 56966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56966&action=edit
Preprocessed source

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 56967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56967&action=edit
Assembler output

There are no .type directives for _U_* libfuncs.

They are emitted by ASM_OUTPUT_EXTERNAL_LIBCALL:

/* We need set the type for external libcalls.  Also note that not all
   libcall names are passed to targetm.encode_section_info (e.g., __main).
   Thus, we also have to do the section encoding if it hasn't been done
   already.  */
#undef ASM_OUTPUT_EXTERNAL_LIBCALL
#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN)                  \
do {                                                            \
  if (!FUNCTION_NAME_P (XSTR (FUN, 0)))                         \
    pa_encode_label (FUN);                                      \
  ASM_OUTPUT_TYPE_DIRECTIVE (FILE, XSTR (FUN, 0), "function");  \
} while (0)

The .type directives that are emitted are now at the end:

        .section        .debug_str,"",@progbits
        .ident  "GCC: (GNU) 14.0.0 20231128 (experimental)
[remotes/origin/trunk r14-6831-ged60b2868ab]"
        .type   tanh, @function

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin <danglin at gcc dot gnu.org> ---
The problem is TREE_SYMBOL_REFERENCED is not set for libfuncs.  This fixes
problem on hppa64-hpux:

bash-5.1$ git diff gcc/varasm.cc
diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index 69f8f8ee018..0a1cc022023 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -2527,9 +2527,7 @@ process_pending_assemble_externals (void)
   for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
     {
       rtx symbol = XEXP (list, 0);
-      tree id = get_identifier (XSTR (symbol, 0));
-      if (TREE_SYMBOL_REFERENCED (id))
-       targetm.asm_out.external_libcall (symbol);
+      targetm.asm_out.external_libcall (symbol);
     }

   pending_assemble_externals = 0;

If you don't care about libfuncs, you could move the TREE_SYMBOL_REFERENCED
check into the bpf target.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[rguenth at gcc dot gnu.org]

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

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

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

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to John David Anglin from comment #5)
> The problem is TREE_SYMBOL_REFERENCED is not set for libfuncs.  This fixes
> problem on hppa64-hpux:
> 
> bash-5.1$ git diff gcc/varasm.cc
> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
> index 69f8f8ee018..0a1cc022023 100644
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -2527,9 +2527,7 @@ process_pending_assemble_externals (void)
>    for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
>      {
>        rtx symbol = XEXP (list, 0);
> -      tree id = get_identifier (XSTR (symbol, 0));
> -      if (TREE_SYMBOL_REFERENCED (id))
> -       targetm.asm_out.external_libcall (symbol);
> +      targetm.asm_out.external_libcall (symbol);
>      }
> 
>    pending_assemble_externals = 0;
> 
> If you don't care about libfuncs, you could move the TREE_SYMBOL_REFERENCED
> check into the bpf target.

Then the bug is that it isn't set when they are actually referenced.
The whole point of the patch was avoid referencing something that isn't really
referenced.  And it wasn't specific to one backend, many backends simply used
to emit say externs for both signed and unsigned division when expansion saw
range of operands would allow both signed and unsigned division and so expanded
both to pick the cheaper one.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2024-01-08 9:29 a.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |jakub at gcc dot gnu.org
>
> --- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to John David Anglin from comment #5)
>> The problem is TREE_SYMBOL_REFERENCED is not set for libfuncs.  This fixes
>> problem on hppa64-hpux:
>>
>> bash-5.1$ git diff gcc/varasm.cc
>> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
>> index 69f8f8ee018..0a1cc022023 100644
>> --- a/gcc/varasm.cc
>> +++ b/gcc/varasm.cc
>> @@ -2527,9 +2527,7 @@ process_pending_assemble_externals (void)
>>     for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
>>       {
>>         rtx symbol = XEXP (list, 0);
>> -      tree id = get_identifier (XSTR (symbol, 0));
>> -      if (TREE_SYMBOL_REFERENCED (id))
>> -       targetm.asm_out.external_libcall (symbol);
>> +      targetm.asm_out.external_libcall (symbol);
>>       }
>>
>>     pending_assemble_externals = 0;
>>
>> If you don't care about libfuncs, you could move the TREE_SYMBOL_REFERENCED
>> check into the bpf target.
> Then the bug is that it isn't set when they are actually referenced.
Exactly.  This has been a problem for a long time.  There is a work around in
the define
for ASM_OUTPUT_EXTERNAL_LIBCALL in pa/som.h.  Issue is also mentioned in
sol2.cc.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, normally TREE_SYMBOL_REFERENCED should be set through something like
output_addr_const (or whatever else) -> assemble_name -> assemble_name_resolve
-> mark_referenced.  Why doesn't trigger that on PA?  Or does it trigger, but
the assembler requires the externs to be before the calls?

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #9 from dave.anglin at bell dot net ---
On 2024-01-09 1:00 p.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Note, normally TREE_SYMBOL_REFERENCED should be set through something like
> output_addr_const (or whatever else) -> assemble_name -> assemble_name_resolve
> -> mark_referenced.  Why doesn't trigger that on PA?  Or does it trigger, but
> the assembler requires the externs to be before the calls?
As far as I can tell, mark_referenced() is called for the symbols in question.

I don't believe the assembler requires the externs (.type statments) to be
before the calls.

I have to think issue is with get_identifier().  Will have to do another build
to debug further.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #10 from dave.anglin at bell dot net ---
On 2024-01-09 2:56 p.m., dave.anglin at bell dot net wrote:
> I have to think issue is with get_identifier().  Will have to do another build
> to debug further.
The new code in process_pending_assemble_externals() doesn't strip the name
encoding
from XSTR (symbol, 0).  Maybe that's the problem.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #11 from dave.anglin at bell dot net ---
On 2024-01-09 3:03 p.m., dave.anglin at bell dot net wrote:
> The new code in process_pending_assemble_externals() doesn't strip the name
> encoding
> from XSTR (symbol, 0).  Maybe that's the problem.
Stripping the name encoding fixes the problem.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #12 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 57024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57024&action=edit
Patch

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #13 from John David Anglin <danglin at gcc dot gnu.org> ---
Although the patch fixes the udlit-namespace.C test, I think the patch
still isn't correct.  I think the code should use maybe_get_identifier
instead of get_identifier.  See assemble_name_resolve.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to John David Anglin from comment #13)
> Although the patch fixes the udlit-namespace.C test, I think the patch
> still isn't correct.  I think the code should use maybe_get_identifier
> instead of get_identifier.  See assemble_name_resolve.

Why do you think so?  When assemble_external_libcall is called, it calls
get_identifier to make sure such an identifier exists.

Though, if the targetm.strip_name_encoding call is needed, it should be done
not just in process_pending_assemble_externals, but also in
assemble_external_libcall.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I'm going to bootstrap/regtest:
2024-01-11  John David Anglin  <danglin@gcc.gnu.org>
            Jakub Jelinek  <jakub@redhat.com>

        PR middle-end/113182
        * varasm.cc (process_pending_assemble_externals,
        assemble_external_libcall): Use targetm.strip_name_encoding
        before calling get_identifier.

--- gcc/varasm.cc.jj    2024-01-08 21:56:04.968516120 +0100
+++ gcc/varasm.cc       2024-01-11 18:44:19.171399167 +0100
@@ -2543,7 +2543,8 @@ process_pending_assemble_externals (void
   for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
     {
       rtx symbol = XEXP (list, 0);
-      tree id = get_identifier (XSTR (symbol, 0));
+      const char *name = targetm.strip_name_encoding (XSTR (symbol, 0));
+      tree id = get_identifier (name);
       if (TREE_SYMBOL_REFERENCED (id))
        targetm.asm_out.external_libcall (symbol);
     }
@@ -2631,7 +2632,8 @@ assemble_external_libcall (rtx fun)
          reference to it will mark its tree node as referenced, via
          assemble_name_resolve.  These are eventually emitted, if
          used, in process_pending_assemble_externals. */
-      get_identifier (XSTR (fun, 0));
+      const char *name = targetm.strip_name_encoding (XSTR (fun, 0));
+      get_identifier (name);
       pending_libcall_symbols = gen_rtx_EXPR_LIST (VOIDmode, fun,
                                                   pending_libcall_symbols);
     }

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #16 from dave.anglin at bell dot net ---
On 2024-01-11 12:37 p.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> --- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to John David Anglin from comment #13)
>> Although the patch fixes the udlit-namespace.C test, I think the patch
>> still isn't correct.  I think the code should use maybe_get_identifier
>> instead of get_identifier.  See assemble_name_resolve.
> Why do you think so?  When assemble_external_libcall is called, it calls
> get_identifier to make sure such an identifier exists.
get_identifier allocates a new identifier node if one doesn't exist.  While it
may not matter
much at this point, I don't think this code should be allocating new identifier
nodes.
assemble_name_resolve avoids creating new nodes.
>
> Though, if the targetm.strip_name_encoding call is needed, it should be done
> not just in process_pending_assemble_externals, but also in
> assemble_external_libcall.
Will look at.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The allocation is completely intentional, exactly to be able to track whether
it was referenced or not.  Otherwise the exercise makes no sense.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #18 from dave.anglin at bell dot net ---
On 2024-01-11 1:25 p.m., jakub at gcc dot gnu.org wrote:
> The allocation is completely intentional, exactly to be able to track whether
> it was referenced or not.  Otherwise the exercise makes no sense.
In assemble_external_libcall, it's intentional.  But in
process_pending_assemble_externals,
all the allocations that are going to happen should have already happened.  It
is called in final.

When the name encoding wasn't stripped, get_identifier just created a new
identifier node that
wasn't referenced.  I tend to think there's a problem if the identifier node
doesn't already exist
in process_pending_assemble_externals.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think stringpool hash table is never purged (unless libgccjit and
reinitializes stuff), so once something is looked up, it will be findable later
on as well.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net]

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

--- Comment #20 from dave.anglin at bell dot net ---
On 2024-01-11 2:05 p.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> --- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I think stringpool hash table is never purged (unless libgccjit and
> reinitializes stuff), so once something is looked up, it will be findable later
> on as well.
Okay, then maybe get_identifier is the correct function to use.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from GCC 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:c05beab4ae240a593299c08ef8c775d91187a141

commit r14-7188-gc05beab4ae240a593299c08ef8c775d91187a141
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 12 13:58:07 2024 +0100

    varasm: Fix up process_pending_assemble_externals [PR113182]

    John reported that on HP-UX we no longer emit needed external libcalls.

    The problem is that we didn't strip name encoding when looking up
    the identifiers in assemble_external_libcall and
    process_pending_assemble_externals, while
    assemble_name_resolve does that:
      const char *real_name = targetm.strip_name_encoding (name);
      tree id = maybe_get_identifier (real_name);

      if (id)
        {
    ...
          mark_referenced (id);
    The intention is that assemble_external_libcall ensures the IDENTIFIER
    exists for the external libcall, then for actually emitted calls
    assemble_name_resolve sees those IDENTIFIERS and sets
TREE_SYMBOL_REFERENCED
    on them and finally process_pending_assemble_externals looks the
    IDENTIFIER up again and checks its TREE_SYMBOL_REFERENCED.

    But without the strip_name_encoding call, they can look up different
    identifiers and those are likely never used.

    In the PR, John was discussing whether get_identifier or
    maybe_get_identifier should be used, I believe in assemble_external_libcall
    we definitely want to use get_identifier, we need an IDENTIFIER allocated
    so that it can be actually tracked, in process_pending_assemble_externals
    it doesn't matter, the IDENTIFIER should be already created.

    2024-01-12  John David Anglin  <danglin@gcc.gnu.org>
                Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/113182
            * varasm.cc (process_pending_assemble_externals,
            assemble_external_libcall): Use targetm.strip_name_encoding
            before calling get_identifier.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Assuming fixed, please reopen if that is not the case.