LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 14469 - undefined reference to '__mulodi4'
Summary: undefined reference to '__mulodi4'
Status: REOPENED
Alias: None
Product: libraries
Classification: Unclassified
Component: Common Code Generator Code (show other bugs)
Version: 3.1
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks: 24345
  Show dependency tree
 
Reported: 2012-11-30 14:47 PST by Oleksandr Motsak
Modified: 2019-03-23 15:26 PDT (History)
12 users (show)

See Also:
Fixed By Commit(s):


Attachments
test (348 bytes, text/x-c++src)
2012-11-30 14:47 PST, Oleksandr Motsak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oleksandr Motsak 2012-11-30 14:47:49 PST
Created attachment 9628 [details]
test

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
Comment 1 Eric Christopher 2012-11-30 14:52:29 PST
You'll need to use compiler-rt instead of libgcc for your runtime library. It
contains mulodi4.
Comment 2 Oleksandr Motsak 2012-11-30 14:55:21 PST
(In reply to comment #1)
> 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?
Comment 3 Oleksandr Motsak 2012-11-30 14:58:48 PST
Besides gcc -ftrapv -m32 leads to 'call __mulvdi3' on the same place
Comment 4 Eric Christopher 2012-11-30 15:03:04 PST
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.
Comment 5 Oleksandr Motsak 2012-11-30 17:26:15 PST
(In reply to comment #4)
> 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?
Comment 6 Oleksandr Motsak 2013-01-28 11:02:30 PST
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.
Comment 7 Antony Polukhin 2013-04-11 09:51:28 PDT
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
Comment 8 Kerem Kat 2014-02-26 15:43:36 PST
*** This bug has been marked as a duplicate of bug 13897 ***
Comment 9 Luke 2019-03-22 15:17:10 PDT
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