Hi all,
I am a new user of LLVM, and wanted to explore it in conjunction with
the compilers course I am taking in my university. To this end, I
downloaded the code for the LLVM suite and the LLVM-gcc front end from
the respective repositories. Then, I built the LLVM suite without any
hitch, but when I tried to build the llvm-gcc frontend (exactly
following the instructions of README.LLVM) , I got compilator errors.
I am using "gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2)" on Ubuntu 7.10, Intel Core Duo. I have attached the
make file output with this mail. (I did not find any mention of this
mailing list's policy on attachments, and if it's against the rules
then I apologise).
I wished to know if the error is a result of some recent changes
taking place in the code and if using the pre-compiled binaries will
help, or is there something wrong at my end?
Regards
Gautam
make.out (6.83 KB)
Forgot to mention - I am using revision 66876.
Hello,
I wished to know if the error is a result of some recent changes
taking place in the code and if using the pre-compiled binaries will
help, or is there something wrong at my end?
It seems, that your llvm and llvm-gcc sources are out of sync.
PS: gcc 4.1.x is know to be the source of all sorts of miscompilations, I don't know whether it's still true for 4.1.3, but definitely so fo 4.1.2
Hi, the versions of llvm-gcc and llvm you are using are
not synchronized. Probably one is from subversion while
the other is not.
Ciao,
Duncan.
Hi,
Ok, I 'synchronized' both of them, but now I am getting a different
error. On running make, the output ends with the following error:
please don't only reply to me, please reply to the list too.
That way others can comment, and the discussion is archived.
cc1: /home/gautam/code/llvm/llvm/include/llvm/Transforms/Utils/InlineCost.h:44:
llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost
exceeds InlineCost precision"' failed.
../../trunk/gcc/libgcov.c:644: internal compiler error: Aborted
Please submit a full bug report,
your system compiler is broken, this is a known symptom.
I also tried using the gcc-4.2 compiler (by changing the value of the
environment variables CC and CXX), but got the same error.
This should work. Since it didn't, I guess you made a mistake
when trying to use gcc-4.2 and g++-4.2 and actually used the
4.1 versions instead.
Ciao,
Duncan.
Ok, I 'synchronized' both of them, but now I am getting a different
error. On running make, the output ends with the following error:
/home/gautam/code/llvm/llvm-gcc-4.2/obj/./gcc/xgcc
-B/home/gautam/code/llvm/llvm-gcc-4.2/obj/./gcc/
-B/home/gautam/code/llvm/llvm-gcc-4.2/obj/../install/i686-pc-linux-gnu/bin/
-B/home/gautam/code/llvm/llvm-gcc-4.2/obj/../install/i686-pc-linux-gnu/lib/
-isystem /home/gautam/code/llvm/llvm-gcc-4.2/obj/../install/i686-pc-linux-gnu/include
-isystem /home/gautam/code/llvm/llvm-gcc-4.2/obj/../install/i686-pc-linux-gnu/sys-include
-O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../trunk/gcc
-I../../trunk/gcc/. -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber
-I../libdecnumber -I/home/gautam/code/llvm/llvm_install/include
-I/home/gautam/code/llvm/llvm/include -DL_gcov -c
../../trunk/gcc/libgcov.c -o libgcc/./_gcov.o
cc1: /home/gautam/code/llvm/llvm/include/llvm/Transforms/Utils/InlineCost.h:44:
llvm::InlineCost::InlineCost(int, int): Assertion `Cost == C && "Cost
exceeds InlineCost precision"' failed.
../../trunk/gcc/libgcov.c:644: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[4]: *** [libgcc/./_gcov.o] Error 1
make[4]: Leaving directory `/home/gautam/code/llvm/llvm-gcc-4.2/obj/gcc'
make[3]: *** [libgcc.a] Error 2
make[3]: Leaving directory `/home/gautam/code/llvm/llvm-gcc-4.2/obj/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/gautam/code/llvm/llvm-gcc-4.2/obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/gautam/code/llvm/llvm-gcc-4.2/obj'
make: *** [all] Error 2
I also tried using the gcc-4.2 compiler (by changing the value of the
environment variables CC and CXX), but got the same error.
Where am I going wrong? Any help would be greatly appreciated.
Regards
Gautam
Gautam Sewani wrote:
Hi, the versions of llvm-gcc and llvm you are using are
not synchronized. Probably one is from subversion while
the other is not.
I've run into this, too. The problem is that the inliner pass uses a 30
bit integer to store the inline cost; the code that calculates the
inline cost generates a cost that is too large, and so you hit the
assertion.
I haven't yet distilled a test case for this yet (had some problems with
bugpoint for some mysterious reason), but I do have a work-around: go
into include/llvm/Transforms/Utils/InlineCost.h and make the following
change:
Index: InlineCost.h
That worked like a charm. Thanks a lot!
Gautam
Gautam Sewani wrote:
Hi, the versions of llvm-gcc and llvm you are using are
not synchronized. Probably one is from subversion while
the other is not.
I've run into this, too. The problem is that the inliner pass uses a 30
bit integer to store the inline cost; the code that calculates the
inline cost generates a cost that is too large, and so you hit the
assertion.
I haven't yet distilled a test case for this yet (had some problems with
bugpoint for some mysterious reason), but I do have a work-around: go
into include/llvm/Transforms/Utils/InlineCost.h and make the following
change:
Glad that works for you, but it means that if the 32-bit cost computation overflows, we won't be told about it. I think the right thing is to make sure the computation saturates at 30 bits instead of overflowing. Am I going to talk myself into overloading operator+ ?
Hi,
Glad that works for you, but it means that if the 32-bit cost
computation overflows, we won't be told about it. I think the right
thing is to make sure the computation saturates at 30 bits instead of
overflowing. Am I going to talk myself into overloading operator+ ?
is this problem really real? Or has LLVM been miscompiled?
The two people who have reported this were running very similar
systems with broken compiler versions...
Ciao,
Duncan.
Ah. Probably not a real problem then; I was quite surprised it overflowed 30 bits, although it's certainly possible in theory. I haven't seen any costs that come anywhere close to overflowing. A broken host compiler would explain it nicely, I missed that.
This is weird, because I tried it using the gcc-4.2 compiler too, and
it gave the same result. I'll probably try with Intel now. BTW,
changing the CC and CXX environment variables is the correct way to
change the compiler used for building llvm-gcc frontend right? (The
docs specified this method for changing the compiler while building
the llvm suite).
Hi,
This is weird, because I tried it using the gcc-4.2 compiler too, and
it gave the same result. I'll probably try with Intel now. BTW,
changing the CC and CXX environment variables is the correct way to
change the compiler used for building llvm-gcc frontend right? (The
docs specified this method for changing the compiler while building
the llvm suite).
you need to rebuild both llvm and llvm-gcc using gcc-4.2. Using
CC and CXX should work. Alternatively, you can make sure that
gcc-4.2 occurs first in your path.
Ciao,
Duncan.
It occurs to me that the problem may be negative costs, which are possible. The signedness of "int" bitfields is implementation-defined, so this one really ought to be declared "signed int". Could you try that and see if it helps?