public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "danglin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/113182] New: [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C  -std=c++14 execution test
Date: Sat, 30 Dec 2023 18:03:06 +0000	[thread overview]
Message-ID: <bug-113182-4@http.gcc.gnu.org/bugzilla/> (raw)

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.

             reply	other threads:[~2023-12-30 18:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-30 18:03 danglin at gcc dot gnu.org [this message]
2023-12-30 18:30 ` [Bug middle-end/113182] " pinskia at gcc dot gnu.org
2023-12-30 18:38 ` dave.anglin at bell dot net
2023-12-30 19:19 ` danglin at gcc dot gnu.org
2023-12-30 19:26 ` danglin at gcc dot gnu.org
2024-01-01 20:41 ` danglin at gcc dot gnu.org
2024-01-08 14:19 ` rguenth at gcc dot gnu.org
2024-01-08 14:29 ` jakub at gcc dot gnu.org
2024-01-08 15:56 ` dave.anglin at bell dot net
2024-01-09 18:00 ` jakub at gcc dot gnu.org
2024-01-09 19:56 ` dave.anglin at bell dot net
2024-01-09 20:03 ` dave.anglin at bell dot net
2024-01-10 13:57 ` dave.anglin at bell dot net
2024-01-10 17:49 ` danglin at gcc dot gnu.org
2024-01-11 16:55 ` danglin at gcc dot gnu.org
2024-01-11 17:37 ` jakub at gcc dot gnu.org
2024-01-11 17:47 ` jakub at gcc dot gnu.org
2024-01-11 18:03 ` dave.anglin at bell dot net
2024-01-11 18:25 ` jakub at gcc dot gnu.org
2024-01-11 18:56 ` dave.anglin at bell dot net
2024-01-11 19:05 ` jakub at gcc dot gnu.org
2024-01-11 19:21 ` dave.anglin at bell dot net
2024-01-12 12:59 ` cvs-commit at gcc dot gnu.org
2024-01-12 13:06 ` jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-113182-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).