Bug 2223978 - Clang get stuck with "load address" s390x assembly instruction
Summary: Clang get stuck with "load address" s390x assembly instruction
Keywords:
Status: VERIFIED
Alias: None
Deadline: 2023-08-14
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: clang
Version: 8.9
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tulio Magno Quites Machado Filho
QA Contact: Jesus Checa
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-07-19 12:59 UTC by Jesus Checa
Modified: 2023-08-03 07:06 UTC (History)
5 users (show)

Fixed In Version: llvm-toolset-rhel8-8090020230729140947.b46abd14
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-162761 0 None None None 2023-07-19 13:41:55 UTC

Description Jesus Checa 2023-07-19 12:59:13 UTC
Description of problem:

If trying to assemble an instruction like "la %r2,_end-start(%r2)" with Clang, the compiler gets stuck and never returns the prompt back. 

FTR: This issue popped up while running the test we added for bug 2216906 in RHEL 9.3. It's similar but it's not the same issue.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. echo "start: la %r2,_end-start(%r2)" > /tmp/test.S
2. clang -v -c -o /tmp/test.o /tmp/test.S

Actual results:
# clang -v -c -o /tmp/test.o /tmp/test.S
clang version 16.0.6 (Red Hat 16.0.6-1.module+el8.9.0+19220+2631d101)
Target: s390x-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/s390x-redhat-linux/12
Selected GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/s390x-redhat-linux/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/usr/bin/clang-16" -cc1 -triple s390x-redhat-linux-gnu -E -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test.S -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu z10 -debugger-tuning=gdb -v -fcoverage-compilation-dir=/root -resource-dir /usr/lib64/clang/16 -internal-isystem /usr/lib64/clang/16/include -internal-isystem /usr/local/include -internal-isystem /opt/rh/gcc-toolset-12/root/usr/lib/gcc/s390x-redhat-linux/12/../../../../s390x-redhat-linux/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/root -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/test-237dca.s -x assembler-with-cpp /tmp/test.S
clang -cc1 version 16.0.6 based upon LLVM 16.0.6 default target s390x-redhat-linux-gnu
ignoring nonexistent directory "/opt/rh/gcc-toolset-12/root/usr/lib/gcc/s390x-redhat-linux/12/../../../../s390x-redhat-linux/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib64/clang/16/include
 /usr/local/include
 /usr/include
End of search list.
 "/usr/bin/clang-16" -cc1as -triple s390x-redhat-linux-gnu -filetype obj -main-file-name test.S -target-cpu z10 -fdebug-compilation-dir=/root -dwarf-debug-producer "clang version 16.0.6 (Red Hat 16.0.6-1.module+el8.9.0+19220+2631d101)" -dwarf-version=4 -mrelocation-model static -o /tmp/test.o /tmp/test-237dca.s

[ clang gets stuck here and prompt is never returned ]

Expected results:
clang should report Unsupported PC-relative address and return the prompt. 


Additional info:
GCC is able to compile the test.S file just fine.

Comment 1 Tulio Magno Quites Machado Filho 2023-07-19 13:04:38 UTC
I suspect this is the RHEL 8 version of bug #2216906.
I'm investigating.

Comment 2 Tulio Magno Quites Machado Filho 2023-07-19 20:21:42 UTC
I confirmed they're indeed the same issue, but on different versions of RHEL.
I created a merge request at https://gitlab.com/redhat/centos-stream/rpms/llvm/-/merge_requests/47


Note You need to log in before you can comment on or make changes to this bug.