similar to: [LLVMdev] llvm 1.0, g++, SuSE 9, internal compiler error

> > - 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. I agree. > You can try sending a bug report to SuSE. hm, sending bug report is

> 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!

> > 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

Hi LLVMers, there were a gcc ICE problem discussed in current mail list. Chris was right here: http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-December/000693.html saying that the PR 12544 is not really the corresponding issue :) The correct one is PR 13392: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13392 Interesting fact is that -O2 (or -O3) goes somehow around this

Hi all, compilation of package llvm-1.0.tar.gz under redhat 9 is failed with following output: ------- make[3]: *** No rule to make target `/home/vak/llvm/llvm/runtime/GCCLibraries/crtend/BytecodeObj/C++-Exception.bc', needed by `/home/vak/llvm/llvm/lib/BytecodeLibs/libcrtend.bc'. Stop. make[3]: Leaving directory `/home/vak/llvm/llvm/runtime/GCCLibraries/crtend' ...skipped -------

On Fri, 14 Nov 2003, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > > 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. Even better, thanks a lot!! :) -Chris -- http://llvm.cs.uiuc.edu/

Hi all, some note i.r.t. the problem. it looks like, ICE while compiling llvm under SUSE 9.0 is caused by: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12544 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

Greetings to all developers of the Network UPS Tools, and Merry Christmas greetings to those of you who celebrate! I have been looking in to your work from time to time, and I am very impressed with your efforts. I think this is a good time to officially supply the required information about Gamatronic products to the community. Furthermore, I would like to know how our company may contribute

Hi Leon! Thanks for your effort in reaching out! I have been involved in Open Source projects and used Open Source for years. Your questions are very common ones for companies interested in getting involved in Open Source projects, so I will attempt to provide you with some answers. NUT is a collaborative effort, but as these projects go there is not a single person "in charge"

Hi LLVM’ers! We are hosting a BoF at this year's Dev Meeting on a subject we hope will be of interest to some (many?) of you: shipping software (entirely) as LLVM IR. You can find our proposal in the meeting schedule online: https://llvmdevelopersmeetingbay2016.sched.org/event/8Yzq/shipping-software-as-llvm-ir The BoF is scheduled to last 45 minutes, which will go by very quickly! To make

Hi Vikram, It is a bit more that just “efficient (de)serialization” as there is some amount of tradeoff to make between “size” vs “speed” vs “flexibility” (which are all some sort of “efficient”). For instance what if we get a faster deserialization but got larger size? That might be an issue for some people who’d like to ship bitcode. Another thing is that we may get better speed/size by

On Sun, 26 Oct 2003, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > compilation of package llvm-1.0.tar.gz under redhat 9 is failed with > following output: > make[3]: *** No rule to make target `/home/vak/llvm/llvm/runtime/GCCLibraries/crtend/BytecodeObj/C++-Exception.bc', needed by `/home/vak/llvm/llvm/lib/BytecodeLibs/libcrtend.bc'. Stop. > make[3]: Leaving

Hi Mehdi, Yes, we did see your earlier post. Efficient (de)serialization is definitely important for both exporting (a la LTO and ThinLTO) and for shipping code as IR. I expect most use cases of the latter would benefit. -—Vikram // Vikram S. Adve // Professor, Department of Computer Science // University of Illinois at Urbana-Champaign // vadve at illinois.edu<mailto:vadve at

Hi I am late to the party. Here is my personal take of the topic: * Do you ship software as IR today? What lessons have you learned? Yes. We accept AppStore submission in bitcode (LLVM IR). The core function in clang is upstreamed and you can look up the related code path triggered by -fembed-bitcode option. * Challenges of shipping software as IR Compatibility: We are trying to enhance the

On 25 May 2013 04:59, Jeffrey Walton <noloader at gmail.com> wrote: > 4 cd llvm-3.2.src/tools > 5 tar xvf ../../clang-3.2.src.tar.gz > 6 mv clang-3.2.src clang > 7 cd .. > You don't need to do any of it, there are already symlinks on the llvm.src dir to point to all others on the same root. Just unpack each source tar ball and be happy. ;) > 8 ./configure

<snip/> Compiling InstrSelectorEmitter.cpp InstrSelectorEmitter.cpp: In member function `virtual void llvm::InstrSelectorEmitter::run(std::ostream&)': InstrSelectorEmitter.cpp:1295: internal compiler error: in convert_from_eh_region_ranges_1, at except.c:1159 Please submit a full bug report, with preprocessed source if appropriate. See

> Compiling InstrSelectorEmitter.cpp > InstrSelectorEmitter.cpp: In member function `virtual void > llvm::InstrSelectorEmitter::run(std::ostream&)': > InstrSelectorEmitter.cpp:1295: internal compiler error: in > convert_from_eh_region_ranges_1, at except.c:1159 > Please submit a full bug report, GCC 3.3.2 is not compatible with LLVM, sorry! -Chris > with

> 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

> > 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!"); >

On Thu, 13 Nov 2003, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > > 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