search for: llvm_projects

That source file was removed from LLVM in r232397 on March 16, 2015. It looks like lljvm hasn't been updated in a long time. LLVM's C++ APIs are not stable, so there is no expectation that a project built against LLVM's C++ API in 2015 would build or reasonably function against LLVM trunk. The project probably works against LLVM 3.6.2 which was (I believe) the last LLVM release to

...rmv7-none-gnueabi -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard -mthumb -I"C:\Program Files\CodeSourcery\Sourcery_CodeBench_for_ARM_EABI\arm-none-eabi\include" -ferror-limit=1000 and the followings are error codes. Thanks and regards, Seung-yeon. In file included from helloneon.c:4: d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: error: invalid vector element type 'int32_t' (aka 'long') typedef __attribute__((neon_vector_type(2))) int32_t int32x2_t; ^ d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:42:24:...

Hi we observed that below errors occur on AMD platform since 25de7691a0e27c29c8d783a22373cc265571f5e9 root at lkp-opteron1 /opt/rootfs/llvm_project/src/build# cmake -DCMAKE_BUILD_TYPE=release -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=/opt/cross/ -- clang project is enabled -- clang-tools-extra project is disabled -- compiler-rt project is disabled

LKP framework can guarantee that all the software environment are same on AMD and INTEL platform. INTEL platform always work well, after revert this patch, AMD works well. we tried below commit on AMD. 1) 25de7691a0e27c29c8d783a22373cc265571f5e9: bad 2) a82235843b102202766115e10003c9465a8b83ae: good the error logs(build/CMakeFiles/CMakeError.log) has no difference b/w 1) and 2) on AMD platform

I believe what's happening here is that clang translates the -fuse-ld=lld into calling the ld.lld executable, which is actually the ELF LLD linker, not the Mach-O one. On 6.0, the Mach-O linker symlink is called ld64.lld instead (and clang has been changed to call out to that name) to disambiguate the two. For 5.0, I'm not sure how best to force the Mach-O linker (I'm not familiar with

Hi. I'm using LLVM 5.0.1 on macOS 10.12. I have a very simple program (program.c): int main() {} When attempting to compile with LLD, I get this output: $ clang -fuse-ld=lld program.c /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -no_deduplicate /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -dynamic /opt/llvm/5.0.1/bin/ld.lld: error: unknown argument: -arch

Hello > In file included from helloneon.c:4: > d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: > error: invalid vector element type 'int32_t' (aka 'long') This looks weird, why int32_t is long? Are you using cygwin somehow? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Peter...

...lly, I also specified include dir of arm codesourcery latest toolchain because of missing stdio.h and stdint.h . Thanks and best regards, Seung-yeon. 2011/11/23 Anton Korobeynikov <anton at korobeynikov.info> > Hello > > > In file included from helloneon.c:4: > > > d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: > > error: invalid vector element type 'int32_t' (aka 'long') > This looks weird, why int32_t is long? Are you using cygwin somehow? > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematic...

I'm trying to do a simple build from the git 8.0.0 sources. The sources seem to build OK but a link step fails from running out of memory. I need some clues how to figure out where the bottleneck might be. The cmake command is: cmake -G Ninja                                          \     -DLLVM_TARGETS_TO_BUILD=X86                         \    

...dint.h .**** > > ** ** > > Thanks and best regards,**** > > Seung-yeon.**** > > ** ** > > ** ** > > 2011/11/23 Anton Korobeynikov <anton at korobeynikov.info>**** > > Hello**** > > > > In file included from helloneon.c:4: > > > d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: > > error: invalid vector element type 'int32_t' (aka 'long')**** > > This looks weird, why int32_t is long? Are you using cygwin somehow? > > -- > With best regards, Anton Korobeynikov > Faculty of M...

...ds,**** >> >> Seung-yeon.**** >> >> ** ** >> >> ** ** >> >> 2011/11/23 Anton Korobeynikov <anton at korobeynikov.info>**** >> >> Hello**** >> >> >> > In file included from helloneon.c:4: >> > >> d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: >> > error: invalid vector element type 'int32_t' (aka 'long')**** >> >> This looks weird, why int32_t is long? Are you using cygwin somehow? >> >> -- >> With best regards, Anton Korobe...

...ified include dir of arm codesourcery latest toolchain because of missing stdio.h and stdint.h . Thanks and best regards, Seung-yeon. 2011/11/23 Anton Korobeynikov <anton at korobeynikov.info<mailto:anton at korobeynikov.info>> Hello > In file included from helloneon.c:4: > d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: > error: invalid vector element type 'int32_t' (aka 'long') This looks weird, why int32_t is long? Are you using cygwin somehow? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Peters...

...dint.h .**** > > **** > > Thanks and best regards,**** > > Seung-yeon.**** > > **** > > **** > > 2011/11/23 Anton Korobeynikov <anton at korobeynikov.info>**** > > Hello**** > > > > In file included from helloneon.c:4: > > > d:/llvm_projects/llvm-3.0rc4/bin/../lib/clang/3.0/include\arm_neon.h:41:24: > > error: invalid vector element type 'int32_t' (aka 'long')**** > > This looks weird, why int32_t is long? Are you using cygwin somehow? > > -- > With best regards, Anton Korobeynikov > Faculty of M...

I understand that a difference between ninja and xcode is they use a different way to determine code dependencies. So to my understanding xcode needs dependencies to be properly created whereas ninja just doesn’t care. Maybe this is why ninja is able to find what it needs for the compilation to succeed, but not xcode. So I have now looked at the CMakeLists.txt files and found that all the missing

Try using ninja generator, most people do not use Xcode for building, so since it lesser-used, it also lesser tested. Note that it’s perfectly possible to use Xcode for code browsing, debugging, editing while using ninja for building, which is what I think most people do On Sun, Jul 7, 2019 at 4:20 AM Joan Lluch via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I also filled a bug

Hi Zachary: I was able to reproduce the greendragon results locally (OSX), and fix the problem by excluding 'debuginfo-tests' from check-clang -- this prevents them from being added twice, once for check-clang and again for check-debuginfo. Below are the minimized patches I used to reproduce and fix the problem -- based on your originals. I've verified these patches work when

> On Dec 6, 2017, at 10:21 AM, Zachary Turner <zturner at google.com> wrote: > > Can I have some assurance that if it fails again, someone will look into who has access to the builders so I don't have to keep doing speculative commits? Sure. I did this last time and I promise to also do it this time. -- adrian > > On Wed, Dec 6, 2017 at 10:13 AM Adrian Prantl

> On Dec 6, 2017, at 10:10 AM, Zachary Turner <zturner at google.com> wrote: > > Adrian, Mike, Chris? Any update on this? I've temporarily switched to working on something different, but I plan to be back on this in a couple of weeks. It's been a month since my first revert of this CL, which seems like a reasonable amount of lead-time to deal with issues surrounding

hello, I am trying to build LLVM with default options. I am getting the following error message after make. [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/metadata.c.o [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/module.c.o [100%] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/object.c.o [100%] Building C object

I’m not saying you can’t use Xcode, I’m just saying that instead of *building* in Xcode, just type “ninja” on the command line to do your build and then use Xcode as you normally would. I don’t think it’s the case that LLVM does not intend to support Xcode, just that its a community driven project, so unless someone is sufficiently motivated to fix whatever this problem is, it might stay this way