similar to: HEAD compilation causes gcc internal error

Sure this is more likely a gcc bug. However, same toolchain compiled without any problems a week ago. Also, in some organizations, upgrading gcc is very hard if not impossible. On Fri, Jul 22, 2016 at 11:11 AM, Paulo Matos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 22/07/16 20:08, Welson Sun via llvm-dev wrote: > > This is gcc4.8.0 compiling HEAD synced on

Hi, Migrating from 3.5 to 3.9. There is a module pass that uses alias analysis started breaking at runtime: llvm/lnx64/llvm/include/llvm/PassAnalysisSupport.h:236: AnalysisType& llvm::Pass::getAnalysisID(llvm::AnalysisID) const [with AnalysisType = llvm::AAResultsWrapperPass; llvm::AnalysisID = const void*]: Assertion `ResultPass && "getAnalysis*() called on an analysis that was

Thanks Eli. Ashutosh once asked the same question, and later said: 'createLegacyPMAAResults' can help here. But how should this be used to solve the assertion problem? On Jan 25, 2017, 4:10 PM -0800, Friedman, Eli <efriedma at codeaurora.org>, wrote: > On 1/25/2017 4:00 PM, Welson Sun via llvm-dev wrote: > > Hi, > > > > Migrating from 3.5 to 3.9. There is a

Hello. I seem to be having the same problem that Paul had in the thread titled "[Rd] R 2.15.2 make check failure on 32-bit --with-blas="-lgoto2"" from October of last year <https://stat.ethz.ch/pipermail/r-devel/2012-October/065103.html> Unfortunately, that thread ended without an answer to his last question. Briefly, I am trying to compile an Rblas for Windows NT 32bit

On Wed, 5 May 2004, Patrick Flanagan wrote: > >> and I'm not convinced that GCC is doing a very good job (ie, without > >> syntactic loops). > > > > Yup, this is EXACTLY what is going on. > > Interesting. Now that you mention it, I do recall thinking the loops > that llvm generated looked a bit different than the gcc loops. I'll go > back and take

How about this patch then? -bw Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 43658) +++ gcc/llvm-convert.cpp (working copy) @@ -758,7 +758,7 @@ } -Value *TreeToLLVM::Emit(tree exp, Value *DestLoc) { +Value *TreeToLLVM::Emit(tree exp, Value *DestLoc, unsigned Alignment) {

On May 4, 2004, at 10:36 PM, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: >> I suspect that a large reason that LLVM does worst than a native C >> compiler with the CBE+GCC is that LLVM generates very low-level C >> code, >> and I'm not convinced that GCC is doing a very good job (ie, without >> syntactic loops). > > Yup, this is

Yest. thanks. I just resolved this error by installing MPFR, MPC and GMP(by the way, these are not listed as prerequisites in the website.). But other errors come: /home/xxx/llvm/tools/dragonegg/src/TypeConversion.cpp: In function > ‘llvm::FunctionType* ConvertArgListToFnType(tree_node*, > llvm::ArrayRef<tree_node*>, tree_node*, bool, llvm::CallingConv::ID&, >

any ideas what library has these symbols lang_eh_catch_all get_pointer_alignment validate_arglist i get these linker errors when trying to link llvm-gcc: make[1]: Entering directory `/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-gcc-4.2-2.7.source-objtree' make[2]: Entering directory

Fedora rawhide now builds on ARM as well as 32-bit and 64-bit x86, and while the x86 builds are successful, the ARM build is failing. I was able to fix the first problem, which was reported in a Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715424 However, there are further build errors for which I haven't found appropriate fixes. It looks like there might be a namespace

Given the following hash: #... @project_list = { ''Contract0'' => nil, ''Contract1'' => { ''Project1'' => nil, ''Project2'' => nil, ''Project3'' => { ''task1'' =>

I can't build llvm-gcc from working directories updated an hour ago. -Dave /tools/llvm-tools/i686-pc-linux-gnu/bin/g++ -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -pedantic -Wno-long-long -Wno-variadic-macros -fno-common -DHAVE_CONFIG_H -Wno-unused -DTARGET_NAME=\"i686-pc-linux-gnu\" -DENABLE_LLVM

Thank you for reply, I have tried building llvm-2.6 first in place, and configure llvm-gcc-4.2 with --enable-llvm=/path\to\llvm-2.6/, but, still the same problerm, and there's no files missed reported in the error message, such as "lvm/System/DataTypes.h", in the file system including /usr/include and ~/llvm/llvm-2.6/include/. May these files should be generated during llvm-2.6

I am new to LLVM, and I'm trying to compile llvm and llvm-gcc from subversion on a Solaris10/SPARC machine. I have already tried building llvm-2.4 on this machine, but it failed. I then tried the subversion sources (rev. # 65253 fro llvm and rev#65263 for llvm-gcc) and llvm at least builds correctly ( I however have not tried testing it!). I can execute binaries located in

I try to build llvm-gcc-4.2-2.6.source before build and install llvm-2.6, the configure is shown bellow ../llvm-gcc-4.2/configure --prefix=/home/ts/program/ --program-prefix=llvm- --enable-llvm=/home/ts/llvm/llvm-2.6 --enable-languages=c,c++ where, it is the path where llvm-2.6 source is stored, -enable-llvm=/home/ts/llvm/llvm-2.6 the "make" gave error message as bellow:

After worked around the problem in SimplifyCFG.cpp (calling isCast() instead of comparing opcode), I hit another gcc crash for FunctionImport.cpp line 480, which I have no idea what's wrong with the code. "Luckily", I found gcc4.8.2 and gave it a try, both crashes are gone. *New problem though:* /llvm-clang-trunk/src/tools/clang/lib/CodeGen/CGBuiltin.cpp: In member function

Bam. This is about as reduced as it gets. I think I can spot the problem point: chandlerc at osiris ~/code/compilers/build/llvm-gcc $ cat testcase.i void foo () { float x __attribute__ ((mode (XF))); } chandlerc at osiris ~/code/compilers/build/llvm-gcc $ ./gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const

g++ -m32 -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings - pedantic -Wno-long-long -Wno-variadic-macros -Wmissing-format- attribute -Werror -mdynamic-no-pic -DHAVE_CONFIG_H -Wno-unused - DTARGET_NAME=\"i686-apple-darwin9\" -DNDEBUG -I. -I. -I/tmp/ llvmgcc42.roots/llvmgcc42~obj/src/gcc -I/tmp/llvmgcc42.roots/ llvmgcc42~obj/src/gcc/.

I've built a debug build of llvm 2.6, and llvm-gcc 2.6 for arm-elf with --enable-checking=yes. On the attached test case (which is g++.dg/expr/bitfield4.C from the GCC 4.2 testsuite) I get: $ cc1plus bitfield4.ii -emit-llvm-bc -o bitfield4.o -quiet cc1plus: /home/foad/svn/antix/toolchain/branches/w/foad/2757llvm26/toolchain/llvm/llvm-gcc/gcc/llvm-convert.cpp:999: llvm::Value*

Hi, Duncan I saw you started to port dragonegg to gcc 4.6, which is a good news. And I am also trying to do that. The attachment get src/Convert.cpp to compile against gcc-4.6. Now I get a error while compiling dragonegg, --- Compiling Debug.cpp /tmp/chenwj/dragonegg/src/Debug.cpp: In member function 'llvm::DIType llvm::DebugInfo::createArrayType(tree_node*)':