Hi aLLvm,
compiling LLVMrelease 1.0 under SuSE 9 brings the following:
Your favorite choice:
- gcc bug
- problem with SuSE distribution
One of these two. In theory GCC should never crash (even if the LLVM
sources had problems), and since SuSE made modifications to the compiler
before they shipped it, they implicitly took responsibility for the end
result. You can try sending a bug report to SuSE.
That said, if you can figure out what is causing the problem, I would
definitely like to put a workaround in the LLVM code, assuming it's not
too ugly. Compatibility with a broad range of compilers is important,
even if they are buggy. 
-Chris
> - gcc bug
> - problem with SuSE distributionOne of these two. In theory GCC should never crash (even if the LLVM
sources had problems), and since SuSE made modifications to the compiler
before they shipped it, they implicitly took responsibility for the end
result.
I agree.
You can try sending a bug report to SuSE.
hm, sending bug report is not my favorite hobby
That said, if you can figure out what is causing the problem,
well, I know:
assert( expression && "my way to kick out gcc from SuSE 9 :)" )
BTW, the following
(expression && "my way to kick out gcc from SuSE 9 :)")
is ok for gcc. So the problem comes from composition this argument with assert itself.
I would definitely like to put a workaround in the LLVM code, assuming it's not
too ugly. Compatibility with a broad range of compilers is important,
even if they are buggy.
I see. The following ugly workaround helps:
#ifdef NDEBUG
bool b = getOption(ArgName) == Opt ;
assert( b && "Arg not in map!");
#endif
Well, one could camouflage this
> I would definitely like to put a workaround in the LLVM code, assuming it's not
> too ugly. Compatibility with a broad range of compilers is important,
> even if they are buggy.I see. The following ugly workaround helps:
#ifdef NDEBUG
bool b = getOption(ArgName) == Opt ;
assert( b && "Arg not in map!");
#endif
You might try something like
assert((getOption(ArgName) == Opt) && "Arg not in map!");
(note extra parens)
-Brian
> You can try sending a bug report to SuSE.
hm, sending bug report is not my favorite hobby
Well if you don't, it might never get fixed 
> That said, if you can figure out what is causing the problem,
well, I know:
assert( expression && "my way to kick out gcc from SuSE 9 :)" )
BTW, the following
(expression && "my way to kick out gcc from SuSE 9 :)")
is ok for gcc. So the problem comes from composition this argument with assert itself.
If it is just one or two places in the source base, it's probably ok to
work around this. If the SuSE compiler has problems with that construct
in general, however, it will never compile LLVM (we use it all over the
place).
It might be possible to hack your <cassert> header file or something
though...
-Chris
You might try something like
assert((getOption(ArgName) == Opt) && "Arg not in map!");
(note extra parens)
I've tried. It doesn't help
BTW, the same workaround helps in:
utils/TableGen/InstrSelectorEmitter.cpp
lib/Analysis/IntervalPartition.cpp
lib/CodeGen/RegAlloc/PhyRegAlloc.cpp
interesting, that assert couses internal error not in every instance :-/
Well, but then comes:
> hm, sending bug report is not my favorite hobby
Well if you don't, it might never get fixed
OK-OK, let's save the world
Well, I've made it.
It might be possible to hack your <cassert> header file or something
though...
it is just a few places in three files as reported in my previous post. Then comes assert violation with message from llvm sources.
regards,
Unfortunately, without your help, we won't be able to fix this (none of us
have a SuSE box). Can you provide some patches?
-Chris
Forgive me because I've only been following the messages in a very cursory fashion, so this may already have been covered. I'm running fine on Red Hat 9.0. Maybe this should be an issue for SuSE?
-- Robert.
Forgive me because I've only been following the messages in a very cursory
fashion, so this may already have been covered. I'm running fine on Red
Hat 9.0. Maybe this should be an issue for SuSE?
SuSE was brave enough to put the newer version of gcc in the SuSE 9 package. RedHat 9 has simply older gcc version
Unfortunately, without your help, we won't be able to fix this (none of us
have a SuSE box).
OK-OK, I will be a SuSE-batman for a while
Can you provide some patches?
I do believe that the right way here is to provide some patches to newest gcc instead. If it fails, then let's polute nice llvm sources.
I am waiting for feedback from SuSE team.
have a nice day!
Even better, thanks a lot!!
-Chris
Hi all,
some note i.r.t. the problem.
it looks like, ICE while compiling llvm under SUSE 9.0
is caused by:
12544 – [3.3/3.4 regression] ICE with large parameters used in nested functions
which is bug present in gcc 3.3.1 (from SUSE 9)
This bug is fixed in 3.3.2
I don't know why SUSE team still denies to provide us with
gcc 3.3.2 under SUSE 9
Hm, for suse 7.3 new gcc is already provided about a month ago or
so...
kind regards
Really? I'm kind of suprised, we don't use nested functions at all in
LLVM: they are a non-portable GCC extension. I guess they are getting
pulled in from system header files or something?
In any case, I'm glad you found the problem!
-Chris