Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

undefined reference to __mulodi4 #14841

Closed
llvmbot opened this issue Nov 30, 2012 · 11 comments
Closed

undefined reference to __mulodi4 #14841

llvmbot opened this issue Nov 30, 2012 · 11 comments
Labels
bugzilla Issues migrated from bugzilla compiler-rt:builtins duplicate Resolved as duplicate

Comments

@llvmbot
Copy link
Member

llvmbot commented Nov 30, 2012

Bugzilla Link 14469
Version 3.1
OS Linux
Blocks llvm/llvm-bugzilla-archive#24345
Attachments test
Reporter LLVM Bugzilla Contributor
CC @apolukhin,@echristo,@RKSimon,@slacka,@nikic,@seanm

Extended Description

Multiplication of two long long int translates into the code that requires to call missing function __mulodi4 if compiled with -ftrapv -m32 (on 64 bit linux)

Please compile the attached code with clang -ftrapv -m32 (at least on a 64 bit machine).

Removing either -ftrapv or -m32 will produce fine executable.

ps:
clang version 3.1 (branches/release_31)
Target: x86_64-unknown-linux-gnu

@echristo
Copy link
Contributor

echristo commented Nov 30, 2012

You'll need to use compiler-rt instead of libgcc for your runtime library. It
contains mulodi4.

@llvmbot
Copy link
Member Author

llvmbot commented Nov 30, 2012

You'll need to use compiler-rt instead of libgcc for your runtime library. It
contains mulodi4.

Thanks, what is the best way to do that?

@llvmbot
Copy link
Member Author

llvmbot commented Nov 30, 2012

Besides gcc -ftrapv -m32 leads to call __mulvdi3 on the same place

@echristo
Copy link
Contributor

echristo commented Nov 30, 2012

mulvidi3 is fine if you want to abort on overflow, but there are language rules with overflow that'll cause an exception to be thrown (c++ new for example) where you don't want an abort, hence the mulvdi3.

http://compiler-rt.llvm.org/

has the information (via a link to clang's page) that you'll want for using compiler-rt with your clang.

@llvmbot
Copy link
Member Author

llvmbot commented Dec 1, 2012

mulvidi3 is fine if you want to abort on overflow, but there are language rules
with overflow that'll cause an exception to be thrown (c++ new for example)
where you don't want an abort, hence the mulvdi3.

Since compiling with clang -ftrapv on a x86_64 bit machine work just fine without any additional libraries (simply sends signals) it really looks like an issue of clang's ftapv implementation on x86_32.
Therefore i believe that such things can only be intended if all the required libraries (for any possible compiler output) are packaged together with with clang so that they can be imbedded by clang without any extra tweaks...

Is there any way to make clang to generate the same code as gcc in such cases (and thus avoid compiler-rt)?

http://compiler-rt.llvm.org/
has the information (via a link to clang's page) that you'll want for using
compiler-rt with your clang.

i will have to build it with -m32, right?

@llvmbot
Copy link
Member Author

llvmbot commented Jan 28, 2013

Ok, i switched to the latest clang:

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]= 0x732b5091cf73e6fb06bb2fdc32f9f620978ef291, stripped,
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

and built the following libraries:

/usr/lib/clang/3.2/lib/linux/libclang_rt.asan-i386.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.asan-x86_64.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.full-i386.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.full-x86_64.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.profile-i386.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.profile-x86_64.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.tsan-x86_64.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.ubsan-i386.a
/usr/lib/clang/3.2/lib/linux/libclang_rt.ubsan-x86_64.a

Nevertheless compiling the previously attached tests with clang -v -ftrapv -m32 ./32.cc still leads to the following error:

clang version 3.2 (tags/RELEASE_32/final)
Target: i386-unknown-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple i386-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name 32.cc -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -target-linker-version 2.23.1 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2 -internal-isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/x86_64-unknown-linux-gnu/32 -internal-isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/motsak/Downloads -ferror-limit 19 -fmessage-length 190 -ftrapv -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/32-Eu9MBw.o -x c++ ./32.cc
clang -cc1 version 3.2 based upon LLVM 3.2 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/x86_64-unknown-linux-gnu/32
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward
 /usr/local/include
 /usr/bin/../lib/clang/3.2/include
 /usr/include
End of search list.
 "/usr/bin/ld.gold" --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o a.out /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib32/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/32/crtbegin.o -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/32 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../.. -L/lib -L/usr/lib /tmp/32-Eu9MBw.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/32/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib32/crtn.o
/tmp/32-Eu9MBw.o:./32.cc:function main: error: undefined reference to '__mulodi4'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I would guess that clang generates code assuming libclang_rt, but linker
ignores all libclang_rt.*.a and sticks to libgcc instead.

What did i do wrong?

ps: clang -fsanitize=undefined -m32 ./32.cc leads to the same error message.

@apolukhin
Copy link
Member

apolukhin commented Apr 11, 2013

Same error occurs while compiling code on Windows with clang++ and flag -ftrapv:

"clang++" -c -x c++ -O0 -g -ftrapv -fno-inline -Wall -g -ftrapv -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "F:\boost\Clang\trunk\results\boost\bin.v2\libs\conversion\test\lexical_cast_integral_types_test.test\clang-linux-3.2\debug\link-static\lexical_cast_integral_types_test.obj" "..\libs\conversion\test\lexical_cast_integral_types_test.cpp"

Link [2013-03-31 00:08:59 UTC]: fail

  "clang++"    -o "F:\boost\Clang\trunk\results\boost\bin.v2\libs\conversion\test\lexical_cast_integral_types_test.test\clang-linux-3.2\debug\link-static\lexical_cast_integral_types_test.exe" "F:\boost\Clang\trunk\results\boost\bin.v2\libs\conversion\test\lexical_cast_integral_types_test.test\clang-linux-3.2\debug\link-static\lexical_cast_integral_types_test.obj" "F:\boost\Clang\trunk\results\boost\bin.v2\libs\test\build\clang-linux-3.2\debug\link-static\libboost_unit_test_framework-clang32-d-1_54.lib"    -g 

F:\boost\Clang\trunk\results\boost\bin.v2\libs\conversion\test\lexical_cast_integral_types_test.test\clang-linux-3.2\debug\link-static\lexical_cast_integral_types_test.obj: In function `Z39test_conversion_from_integral_to_stringIxcEvT0_':

Operating System: Windows 7 Ultimate 64-bit, Service Pack 1
Microsoft Windows [Version 6.1.7601]

Compiler: MinGW-w64's clang-3.2.
clang version 3.2 (tags/RELEASE_32/final)
Target: i686-w64-mingw32
Thread model: posix

@llvmbot
Copy link
Member Author

llvmbot commented Feb 26, 2014

*** This bug has been marked as a duplicate of bug #14269 ***

@slacka
Copy link
Mannequin

slacka mannequin commented Mar 22, 2019

This was incorrectly closed as a duplicate. bug 13897 is fixed, but the test case here is still not working.

$ gcc -ftrapv -m32 32.cc 

$ clang -ftrapv -m32 32.cc 
/usr/bin/ld: /tmp/32-cc3c8b.o: in function `main':
32.cc:(.text+0x4f): undefined reference to `__mulodi4'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)

$ clang --version
clang version 9.0.0 (https://github.com/llvm/llvm-project.git 0f472e1d01d60b6e615cd71a09b0a52eb8e42072)
Target: i686-pc-linux-gnu

@llvmbot
Copy link
Member Author

llvmbot commented Nov 26, 2021

mentioned in issue llvm/llvm-bugzilla-archive#24345

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
@philnik777
Copy link
Contributor

This looks like a duplicate of #16778.

@philnik777 philnik777 closed this as not planned Won't fix, can't repro, duplicate, stale Aug 12, 2024
@philnik777 philnik777 added the duplicate Resolved as duplicate label Aug 12, 2024
@Endilll Endilll changed the title undefined reference to '__mulodi4' undefined reference to __mulodi4 Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla compiler-rt:builtins duplicate Resolved as duplicate
Projects
None yet
Development

No branches or pull requests

5 participants