Opened 9 years ago
Closed 9 years ago
#6883 closed enhancement (fixed)
llvm-3.7.0
Reported by: | Fernando de Oliveira | Owned by: | Fernando de Oliveira |
---|---|---|---|
Priority: | normal | Milestone: | 7.8 |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description
http://llvm.org/releases/3.7.0/llvm-3.7.0.src.tar.xz
http://llvm.org/releases/3.7.0/llvm-3.7.0.src.tar.xz.sig
http://llvm.org/releases/3.7.0/cfe-3.7.0.src.tar.xz
http://llvm.org/releases/3.7.0/cfe-3.7.0.src.tar.xz.sig
http://llvm.org/releases/3.7.0/compiler-rt-3.7.0.src.tar.xz
http://llvm.org/releases/3.7.0/compiler-rt-3.7.0.src.tar.xz.sig
http://lists.llvm.org/pipermail/llvm-announce/2015-September/000065.html
[llvm-announce] LLVM 3.7 Release Hans Wennborg via llvm-announce llvm-announce at lists.llvm.org Tue Sep 1 14:04:40 PDT 2015 It is my pleasure to announce that LLVM 3.7.0 is now available! Get it here: http://llvm.org/releases/ This release contains the work of the LLVM community over the past six months: full OpenMP 3.1 support (behind a flag), the On Request Compilation (ORC) JIT API, a new backend for Berkeley Packet Filter (BPF), Control Flow Integrity checking, as well as improved optimizations, new Clang warnings, many bug fixes, and more. For details on what's new, see the release notes: http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html Many thanks to everyone who helped with testing, fixing, and getting the release into a good state! Special thanks to the volunteer release builders and testers, without whom this release would not be possible: Dimitry Andric, Sebastian Dreßler, Renato Golin, Pavel Labath, Sylvestre Ledru, Ed Maste, Ben Pope, Daniel Sanders, and Nikola Smiljanić! If you have any questions or comments about this release, please contact the community on the mailing lists. Onwards to 3.8! - Hans
http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html
LLVM 3.7 Release Notes • Introduction • Non-comprehensive list of changes in this release ◦ Changes to the MIPS Target ◦ Changes to the PowerPC Target ◦ Changes to the SystemZ Target ◦ Changes to the JIT APIs • Sub-project Status Update ◦ Polly - The Polyhedral Loop Optimizer in LLVM • External Open Source Projects Using LLVM 3.7 ◦ LDC - the LLVM-based D compiler ◦ Portable Computing Language (pocl) ◦ TTA-based Co-design Environment (TCE) ◦ BPF Compiler Collection (BCC) ◦ LLVMSharp & ClangSharp • Additional Information Introduction This document contains the release notes for the LLVM Compiler Infrastructure, release 3.7. Here we describe the status of LLVM, including major improvements from the previous release, improvements in various subprojects of LLVM, and some of the current users of the code. All LLVM releases may be downloaded from the LLVM releases web site. For more information about LLVM, including information about the latest release, please check out the main LLVM web site. If you have questions or comments, the LLVM Developer’s Mailing List is a good place to send them. Note that if you are reading this file from a Subversion checkout or the main LLVM web page, this document applies to the next release, not the current one. To see the release notes for a specific release, please see the releases page. Non-comprehensive list of changes in this release • The minimum required Visual Studio version for building LLVM is now 2013 Update 4. • A new documentation page, Performance Tips for Frontend Authors, contains a collection of tips for frontend authors on how to generate IR which LLVM is able to effectively optimize. • The DataLayout is no longer optional. All the IR level optimizations expects it to be present and the API has been changed to use a reference instead of a pointer to make it explicit. The Module owns the datalayout and it has to match the one attached to the TargetMachine for generating code. • In 3.6, a pass was inserted in the pipeline to make the DataLayout accessible: MyPassManager->add(new DataLayoutPass(MyTargetMachine->getDataLayout())); In 3.7, you don’t need a pass, you set the DataLayout on the Module: MyModule->setDataLayout(MyTargetMachine->createDataLayout()); The LLVM C API LLVMGetTargetMachineData is deprecated to reflect the fact that it won’t be available anymore from TargetMachine in 3.8. • Comdats are now ortogonal to the linkage. LLVM will not create comdats for weak linkage globals and the frontends are responsible for explicitly adding them. • On ELF we now support multiple sections with the same name and comdat. This allows for smaller object files since multiple sections can have a simple name (.text, .rodata, etc). • LLVM now lazily loads metadata in some cases. Creating archives with IR files with debug info is now 25X faster. • llvm-ar can create archives in the BSD format used by OS X. • LLVM received a backend for the extended Berkely Packet Filter instruction set that can be dynamically loaded into the Linux kernel via the bpf(2) syscall. Support for BPF has been present in the kernel for some time, but starting from 3.18 has been extended with such features as: 64-bit registers, 8 additional registers registers, conditional backwards jumps, call instruction, shift instructions, map (hash table, array, etc.), 1-8 byte load/store from stack, and more. Up until now, users of BPF had to write bytecode by hand, or use custom generators. This release adds a proper LLVM backend target for the BPF bytecode architecture. The BPF target is now available by default, and options exist in both Clang (-target bpf) or llc (-march=bpf) to pick eBPF as a backend. • Switch-case lowering was rewritten to avoid generating unbalanced search trees (PR22262) and to exploit profile information when available. Some lowering strategies are now disabled when optimizations are turned off, to save compile time. • The debug info IR class hierarchy now inherits from Metadata and has its own bitcode records and assembly syntax (documented in LangRef). The debug info verifier has been merged with the main verifier. • LLVM IR and APIs are in a period of transition to aid in the removal of pointer types (the end goal being that pointers are typeless/opaque - void*, if you will). Some APIs and IR constructs have been modified to take explicit types that are currently checked to match the target type of their pre-existing pointer type operands. Further changes are still needed, but the more you can avoid using PointerType::getPointeeType, the easier the migration will be. • Argument-less TargetMachine::getSubtarget and TargetMachine::getSubtargetImpl have been removed from the tree. Updating out of tree ports is as simple as implementing a non-virtual version in the target, but implementing full Function based TargetSubtargetInfo support is recommended. • This is expected to be the last major release of LLVM that supports being run on Windows XP and Windows Vista. For the next major release the minimum Windows version requirement will be Windows 7. Changes to the MIPS Target During this release the MIPS target has: • Added support for MIPS32R3, MIPS32R5, MIPS32R3, MIPS32R5, and microMIPS32. • Added support for dynamic stack realignment. This is of particular importance to MSA on 32-bit subtargets since vectors always exceed the stack alignment on the O32 ABI. • Added support for compiler-rt including: ◦ Support for the Address, and Undefined Behaviour Sanitizers for all MIPS subtargets. ◦ Support for the Data Flow, and Memory Sanitizer for 64-bit subtargets. ◦ Support for the Profiler for all MIPS subtargets. • Added support for libcxx, and libcxxabi. • Improved inline assembly support such that memory constraints may now make use of the appropriate address offsets available to the instructions. Also, added support for the ZC constraint. • Added support for 128-bit integers on 64-bit subtargets and 16-bit floating point conversions on all subtargets. • Added support for read-only .eh_frame sections by storing type information indirectly. • Added support for MCJIT on all 64-bit subtargets as well as MIPS32R6. • Added support for fast instruction selection on MIPS32 and MIPS32R2 with PIC. • Various bug fixes. Including the following notable fixes: ◦ Fixed ‘jumpy’ debug line info around calls where calculation of the address of the function would inappropriately change the line number. ◦ Fixed missing __mips_isa_rev macro on the MIPS32R6 and MIPS32R6 subtargets. ◦ Fixed representation of NaN when targeting systems using traditional encodings. Traditionally, MIPS has used NaN encodings that were compatible with IEEE754-1985 but would later be found incompatible with IEEE754-2008. ◦ Fixed multiple segfaults and assertions in the disassembler when disassembling instructions that have memory operands. ◦ Fixed multiple cases of suboptimal code generation involving $zero. ◦ Fixed code generation of 128-bit shifts on 64-bit subtargets. ◦ Prevented the delay slot filler from filling call delay slots with instructions that modify or use $ra. ◦ Fixed some remaining N32/N64 calling convention bugs when using small structures on big-endian subtargets. ◦ Fixed missing sign-extensions that are required by the N32/N64 calling convention when generating calls to library functions with 32-bit parameters. ◦ Corrected the int64_t typedef to be long for N64. ◦ -mno-odd-spreg is now honoured for vector insertion/extraction operations when using -mmsa. ◦ Fixed vector insertion and extraction for MSA on 64-bit subtargets. ◦ Corrected the representation of member function pointers. This makes them usable on microMIPS subtargets. Changes to the PowerPC Target There are numerous improvements to the PowerPC target in this release: • LLVM now supports the ISA 2.07B (POWER8) instruction set, including direct moves between general registers and vector registers, and built-in support for hardware transactional memory (HTM). Some missing instructions from ISA 2.06 (POWER7) were also added. • Code generation for the local-dynamic and global-dynamic thread-local storage models has been improved. • Loops may be restructured to leverage pre-increment loads and stores. • QPX - The vector instruction set used by the IBM Blue Gene/Q supercomputers is now supported. • Loads from the TOC area are now correctly treated as invariant. • PowerPC now has support for i128 and v1i128 types. The types differ in how they are passed in registers for the ELFv2 ABI. • Disassembly will now print shorter mnemonic aliases when available. • Optional register name prefixes for VSX and QPX registers are now supported in the assembly parser. • The back end now contains a pass to remove unnecessary vector swaps from POWER8 little-endian code generation. Additional improvements are planned for release 3.8. • The undefined-behavior sanitizer (UBSan) is now supported for PowerPC. • Many new vector programming APIs have been added to altivec.h. Additional ones are planned for release 3.8. • PowerPC now supports __builtin_call_with_static_chain. • PowerPC now supports the revised -mrecip option that permits finer control over reciprocal estimates. • Many bugs have been identified and fixed. Changes to the SystemZ Target • LLVM no longer attempts to automatically detect the current host CPU when invoked natively. • Support for all thread-local storage models. (Previous releases would support only the local-exec TLS model.) • The POPCNT instruction is now used on z196 and above. • The RISBGN instruction is now used on zEC12 and above. • Support for the transactional-execution facility on zEC12 and above. • Support for the z13 processor and its vector facility. Changes to the JIT APIs • Added a new C++ JIT API called On Request Compilation, or ORC. ORC is a new JIT API inspired by MCJIT but designed to be more testable, and easier to extend with new features. A key new feature already in tree is lazy, function-at-a-time compilation for X86. Also included is a reimplementation of MCJIT’s API and behavior (OrcMCJITReplacement). MCJIT itself remains in tree, and continues to be the default JIT ExecutionEngine, though new users are encouraged to try ORC out for their projects. (A good place to start is the new ORC tutorials under llvm/examples/kaleidoscope/orc). ...
http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html
Clang 3.7 Release Notes • Introduction • What’s New in Clang 3.7? ◦ Major New Features ◦ Improvements to Clang’s diagnostics ◦ New Compiler Flags ◦ Objective-C Language Changes in Clang ◦ Profile Guided Optimization ◦ OpenMP Support ◦ Internal API Changes ◦ Static Analyzer ◦ SystemZ ◦ clang-tidy ◦ Last release which will run on Windows XP and Windows Vista • Additional Information Written by the LLVM Team Introduction This document contains the release notes for the Clang C/C++/Objective-C frontend, part of the LLVM Compiler Infrastructure, release 3.7. Here we describe the status of Clang in some detail, including major improvements from the previous release and new feature work. For the general LLVM release notes, see the LLVM documentation. All LLVM releases may be downloaded from the LLVM releases web site. For more information about Clang or LLVM, including information about the latest release, please check out the main please see the Clang Web Site or the LLVM Web Site. What’s New in Clang 3.7? Some of the major new features and improvements to Clang are listed here. Generic improvements to Clang as a whole or to its underlying infrastructure are described first, followed by language-specific sections with improvements to Clang’s support for those languages. Major New Features • Use of the __declspec language extension for declaration attributes now requires passing the -fms-extensions or -fborland compiler flag. This language extension is also enabled when compiling CUDA code, but its use should be viewed as an implementation detail that is subject to change. • On Windows targets, some uses of the __try, __except, and __finally language constructs are supported in Clang 3.7. MSVC-compatible C++ exceptions are not yet supported, however. • Clang 3.7 fully supports OpenMP 3.1 and reported to work on many platforms, including x86, x86-64 and Power. Also, pragma omp simd from OpenMP 4.0 is supported as well. See below for details. • Clang 3.7 includes an implementation of control flow integrity, a security hardening mechanism. Improvements to Clang’s diagnostics Clang’s diagnostics are constantly being improved to catch more issues, explain them more clearly, and provide more accurate source information about them. The improvements since the 3.6 release include: • -Wrange-loop-analysis analyzes the loop variable type and the container type to determine whether copies are made of the container elements. If possible, suggest a const reference type to prevent copies, or a non-reference type to indicate a copy is made. • -Wredundant-move warns when a parameter variable is moved on return and the return type is the same as the variable. Returning the variable directly will already make a move, so the call is not needed. • -Wpessimizing-move warns when a local variable is moved on return and the return type is the same as the variable. Copy elision cannot take place with a move, but can take place if the variable is returned directly. • -Wmove is a new warning group which has the previous two warnings, -Wredundant-move and -Wpessimizing-move, as well as previous warning -Wself-move. In addition, this group is part of -Wmost and -Wall now. • -Winfinite-recursion, a warning for functions that only call themselves, is now part of -Wmost and -Wall. • -Wobjc-circular-container prevents creation of circular containers, it covers NSMutableArray, NSMutableSet, NSMutableDictionary, NSMutableOrderedSet and all their subclasses. New Compiler Flags The sized deallocation feature of C++14 is now controlled by the -fsized-deallocation flag. This feature relies on library support that isn’t yet widely deployed, so the user must supply an extra flag to get the extra functionality. Objective-C Language Changes in Clang • objc_boxable attribute was added. Structs and unions marked with this attribute can be used with boxed expressions (@(...)) to create NSValue. Profile Guided Optimization Clang now accepts GCC-compatible flags for profile guided optimization (PGO). You can now use -fprofile-generate=<dir>, -fprofile-use=<dir>, -fno-profile-generate and -fno-profile-use. These flags have the same semantics as their GCC counterparts. However, the generated profile is still LLVM-specific. PGO profiles generated with Clang cannot be used by GCC and vice-versa. Clang now emits function entry counts in profile-instrumented binaries. This has improved the computation of weights and frequencies in profile analysis. OpenMP Support OpenMP 3.1 is fully supported, but disabled by default. To enable it, please use the -fopenmp=libomp command line option. Your feedback (positive or negative) on using OpenMP-enabled clang would be much appreciated; please share it either on cfe-dev or openmp-dev mailing lists. In addition to OpenMP 3.1, several important elements of the 4.0 version of the standard are supported as well: • omp simd, omp for simd and omp parallel for simd pragmas • atomic constructs • proc_bind clause of omp parallel pragma • depend clause of omp task pragma (except for array sections) • omp cancel and omp cancellation point pragmas • omp taskgroup pragma Internal API Changes These are major API changes that have happened since the 3.6 release of Clang. If upgrading an external codebase that uses Clang as a library, this section should help get you past the largest hurdles of upgrading. • Some of the PPCallbacks interface now deals in MacroDefinition objects instead of MacroDirective objects. This allows preserving full information on macros imported from modules. • clang-c/Index.h no longer #includes clang-c/Documentation.h. You now need to explicitly #include "clang-c/Documentation.h" if you use the libclang documentation API. Static Analyzer • The generated plists now contain the name of the check that generated it. • Configuration options can now be passed to the checkers (not just the static analyzer core). • New check for dereferencing object that the result of a zero-length allocation. • Also check functions in precompiled headers. • Properly handle alloca() in some checkers. • Various improvements to the retain count checker. SystemZ • Clang will now always default to the z10 processor when compiling without any -march= option. Previous releases used to automatically detect the current host CPU when compiling natively. If you wish to still have clang detect the current host CPU, you now need to use the -march=native option. • Clang now provides the <s390intrin.h> header file. • Clang now supports the transactional-execution facility and provides associated builtins and the <htmintrin.h> and <htmxlintrin.h> header files. Support is enabled by default on zEC12 and above, and can additionally be enabled or disabled via the -mhtm / -mno-htm command line options. • Clang now supports the vector facility. This includes a change in the ABI to pass arguments and return values of vector types in vector registers, as well as a change in the default alignment of vector types. Support is enabled by default on z13 and above, and can additionally be enabled or disabled via the -mvx / -mno-vx command line options. • Clang now supports the System z vector language extension, providing a “vector” keyword to define vector types, and a set of builtins defined in the <vecintrin.h> header file. This can be enabled via the -fzvector command line option. For compatibility with GCC, Clang also supports the -mzvector option as an alias. • Several cases of ABI incompatibility with GCC have been fixed. clang-tidy Added new checks: • google-global-names-in-headers: flag global namespace pollution in header files. • misc-assert-side-effect: detects assert() conditions with side effects which can cause different behavior in debug / release builds. • misc-assign-operator-signature: finds declarations of assign operators with the wrong return and/or argument types. • misc-inaccurate-erase: warns when some elements of a container are not removed due to using the erase() algorithm incorrectly. • misc-inefficient-algorithm: warns on inefficient use of STL algorithms on associative containers. • misc-macro-parentheses: finds macros that can have unexpected behavior due to missing parentheses. • misc-macro-repeated-side-effects: checks for repeated argument with side effects in macros. • misc-noexcept-move-constructor: flags user-defined move constructors and assignment operators not marked with noexcept or marked with noexcept(expr) where expr evaluates to false (but is not a false literal itself). • misc-static-assert: replaces assert() with static_assert() if the condition is evaluable at compile time. • readability-container-size-empty: checks whether a call to the size() method can be replaced with a call to empty(). • readability-else-after-return: flags conditional statements having the else branch, when the true branch has a return as the last statement. • readability-redundant-string-cstr: finds unnecessary calls to std::string::c_str(). • readability-shrink-to-fit: replaces copy and swap tricks on shrinkable containers with the shrink_to_fit() method call. • readability-simplify-boolean-expr: looks for boolean expressions involving boolean constants and simplifies them to use the appropriate boolean expression directly (if (x == true) ... -> if (x), etc.)
Change History (15)
comment:1 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:3 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
After reboot, cups-2.1.0 restored the initial behavior with
Performing 4.2-cups-printer-ops.test: PASS Performing 4.3-job-ops.test: PASS Performing 4.4-subscription-ops.test: FAIL Performing ipp-2.1.test: PASS
Taking back the tickets. Hope to close them tomorrow.
follow-up: 5 comment:4 by , 9 years ago
Had small health problem yesterday, and stopped working.
This ticket is OK, tests are OK, was almost updating, then remembered that didn't test packages building with it.
Problem with mesa-10.6.5:
Package libomxil-bellagio was not found in the pkg-config search path. Perhaps you should add the directory containing `libomxil-bellagio.pc' to the PKG_CONFIG_PATH environment variable No package 'libomxil-bellagio' found checking for NOUVEAU... yes checking for RADEON... yes checking for RADEON... yes checking for RADEON... yes configure: error: LLVM R600 Target not enabled. You can enable it when building the LLVM sources with the --enable-experimental-targets=R600 configure flag real 0m9.407s user 0m4.549s sys 0m1.786s END - Building mesa-10.6.5 - Qui Set 3 11:34:08 BRT 2015
The warning about libomxil-bellagio.pc is also worrying me. perhaps it is the one missing.
Removed and tried to reinstall llvm-3.7.0 with --enable-experimental-targets=R600 and got an error:
llvm[2]: Compiling UnreachableBlockElim.cpp for Release build llvm[2]: Compiling VirtRegMap.cpp for Release build llvm[2]: Compiling WinEHPrepare.cpp for Release build llvm[2]: Building Release Archive Library libLLVMCodeGen.a make[2]: Leaving directory '/tmp/porg-build-2015.09.03-11h55m42s/llvm-3.7.0.src/build/lib/CodeGen' make[1]: Leaving directory '/tmp/porg-build-2015.09.03-11h55m42s/llvm-3.7.0.src/build/lib' /tmp/porg-build-2015.09.03-11h55m42s/llvm-3.7.0.src/Makefile.rules:880: recipe for target 'all' failed make: *** [all] Error 1
That was already when I was in bed, came back reinstalled it without the switch.
Considering that it takes over 36min to build and install (with -j4), I will try to investigate later, to get other tickets done, first.
Other than that missing package, I am tending to investigate mesa development version.
But any help would be much appreciated.
comment:5 by , 9 years ago
Replying to fo:
Had small health problem yesterday, and stopped working.
This ticket is OK, tests are OK, was almost updating, then remembered that didn't test packages building with it.
Problem with mesa-10.6.5:
Package libomxil-bellagio was not found in the pkg-config search path. Perhaps you should add the directory containing `libomxil-bellagio.pc' to the PKG_CONFIG_PATH environment variable No package 'libomxil-bellagio' found checking for NOUVEAU... yes checking for RADEON... yes checking for RADEON... yes checking for RADEON... yes configure: error: LLVM R600 Target not enabled. You can enable it when building the LLVM sources with the --enable-experimental-targets=R600 configure flag real 0m9.407s user 0m4.549s sys 0m1.786s END - Building mesa-10.6.5 - Qui Set 3 11:34:08 BRT 2015The warning about libomxil-bellagio.pc is also worrying me. perhaps it is the one missing.
libomxil-bellagio.pc is OpenMAX according to sourceforge's page for OpenMAX.
Removed and tried to reinstall llvm-3.7.0 with --enable-experimental-targets=R600 and got an error:
llvm[2]: Compiling UnreachableBlockElim.cpp for Release build llvm[2]: Compiling VirtRegMap.cpp for Release build llvm[2]: Compiling WinEHPrepare.cpp for Release build llvm[2]: Building Release Archive Library libLLVMCodeGen.a make[2]: Leaving directory '/tmp/porg-build-2015.09.03-11h55m42s/llvm-3.7.0.src/build/lib/CodeGen' make[1]: Leaving directory '/tmp/porg-build-2015.09.03-11h55m42s/llvm-3.7.0.src/build/lib' /tmp/porg-build-2015.09.03-11h55m42s/llvm-3.7.0.src/Makefile.rules:880: recipe for target 'all' failed make: *** [all] Error 1That was already when I was in bed, came back reinstalled it without the switch.
Considering that it takes over 36min to build and install (with -j4), I will try to investigate later, to get other tickets done, first.
Other than that missing package, I am tending to investigate mesa development version.
But any help would be much appreciated.
follow-up: 7 comment:6 by , 9 years ago
According to the following locations:
https://github.com/llvm-mirror/llvm/commit/953c6814730951ad9a286d7991e9c8c481433d45 http://www.phoronix.com/scan.php/www.../...phoronix.../scan.php?page=news_item&px=AMD-R600-AMDGPU-LLVM
The LLVM R600 backend has been renamed to AMDGPU. So I would recommend trying --enable-experimental-targets=AMDGPU next.
comment:7 by , 9 years ago
Replying to renodr:
The LLVM R600 backend has been renamed to AMDGPU. So I would recommend trying --enable-experimental-targets=AMDGPU next.
That sounds odd - I was looking at amdgpu a couple of days ago, after seeing a bug report from somebody who was testing it in a 32-bit build, probably with mesa-11.0. The thing is - it's a different driver. My kaveri can possibly use it (with a 4.2 kernel), but that is only for testing. The amdgpu is for new stuff : Carrizo does not seem to be available yet. Link to Xorg announcement: http://lists.freedesktop.org/archives/dri-devel/2015-April/081501.html and wikipedia on Carrizo : https://en.wikipedia.org/wiki/Excavator_%28microarchitecture%29. Oh well, I suppose llvm intend to try to cover everything recent from AMD in that part of their code.
Google found references to libomxil-bellagio.pc for fedora and debian, but they date back more than a year, it looks as if it has been optional.
Anyway, my most recent mesa build used --enable-gallium-llvm, I've had that for ages and it was apparently still recognised by mesa-10.6.1. Not sure what it does/did, nor if it is relevant.
I build llvm in /opt (partly to ensure it cannot get picked up for anything except mesa), I can knock-up a test script to play with this if needed (I need the radeon and radeonsi drivers). It might also be the case that llvm-3.7 is too new for mesa-10.6.
follow-up: 9 comment:8 by , 9 years ago
The biggest problem with 3.7.0 is that it defaults to building everything. Fernando will already know that it needs a build directory, but I'll mention that for anyone playing along at home. The build is considerably quicker with --enable-targets=host,r600
I think libomxil-bellagio was a red herring : I've been misled by similar configure output in the past. What I got with mesa-10.6.5 was:
checking for llvm-config... /opt/llvm-370/bin/llvm-config Package libomxil-bellagio was not found in the pkg-config search path. Perhaps you should add the directory containing `libomxil-bellagio.pc' to the PKG_CONFIG_PATH environment variable No package 'libomxil-bellagio' found checking for NOUVEAU... yes checking for RADEON... yes checking for RADEON... yes checking for RADEON... yes configure: error: LLVM R600 Target not enabled. You can enable it when building the LLVM sources with the --enable-experimental-targets=R600 configure flag
Looking at config.log was barely more useful, but it told me the problem was related to line 24865 where it runs
$LLVM_CONFIG --targets-built | grep -qvw 'R600'
With 3.7.0 and my targets above that option returns AMDGPU and X86. [ note to self - if I do not otherwise use llvm, perhaps I could restrict the target to only r600 ]
So, I tried the minimal sed:
sed -i "s/'R600'/'AMDGPU'/" configure
but after a few minutes the build failed: [ sorry, trac is confused by this, the text turns bold ]
{{{make[4]: Entering directory '/scratch/working/mesa-10.6.5/src/gallium/auxiliary'
CXX gallivm/lp_bld_misc.lo
gallivm/lp_bld_misc.cpp: In function 'LLVMBool lp_build_create_jit_compiler_for_module(LLVMOpaqueExecutionEngine, lp_generated_code, LLVMModuleRef, LLVMMCJITMemoryManagerRef, unsigned int, int, char)': gallivm/lp_bld_misc.cpp:442:12: error: 'class llvm::TargetOptions' has no member named 'NoFramePointerElim'
options.NoFramePointerElim = true;
Makefile:2236: recipe for target 'gallivm/lp_bld_misc.lo' failed make[4]: * [gallivm/lp_bld_misc.lo] Error 1 }}}
I saw a couple of reports about mesa-10.6-dev with llvm-3.7 at phoronix : one pointed to a ubuntu ppa, and the comments there said it was based on somebody else's, but included changes for llvm-3.7 : it was from a few months ago, I could not see how to download it or get the source. Another item was a comment about a game - somebody said to use mesa-10.6-devel and (on debian) install llvm-3.7 because debian used llvm-3.5 at that time. So, I suppose there are some fixes for either mesa or llvm out there, but I have not found them.
In the absence of fixes, can we leave this until mesa-11.0 is released ?
follow-up: 11 comment:9 by , 9 years ago
Milestone: | 7.8 → hold |
---|---|
Priority: | normal → low |
After I wrote, found there is a new mesa-10.6.6 out. Perhaps...
Replying to ken@…:
Fernando will already know that it needs a build directory, but I'll mention that for anyone playing along at home. The build is considerably quicker with --enable-targets=host,r600
Yes. Wrote the day after I had the problem, forgot to mention.
Here I had a problem: does host include cpp, which I understand is clang++?
I think libomxil-bellagio was a red herring:
OK.
Looking at config.log ... told me the problem was related to line 24865 where it runs
$LLVM_CONFIG --targets-built | grep -qvw 'R600'
With 3.7.0 and my targets above that option returns AMDGPU and X86.
So, I tried the minimal sed:
sed -i "s/'R600'/'AMDGPU'/" configure
but after a few minutes the build failed:
gallivm/lp_bld_misc.cpp:442:12: error: 'class llvm::TargetOptions' has no member named 'NoFramePointerElim' options.NoFramePointerElim = true; ^ Makefile:2236: recipe for target 'gallivm/lp_bld_misc.lo' failed make[4]: *** [gallivm/lp_bld_misc.lo] Error 1
So, I suppose there are some fixes for either mesa or llvm out there, but I have not found them.
In the absence of fixes, can we leave this until mesa-11.0 is released?
My idea was testing with mesa-11.0.0 (I think there is an 11.1.0). We have used those developments in BLFS, before.
But I agree. I am modifying to hold and low.
Ken, you made much more progress than I did. Would you mind taking this ticket from me?
comment:11 by , 9 years ago
Replying to fo:
Here I had a problem: does host include cpp, which I understand is clang++?
I do not know. I only build this for Mesa. In fact, with 11.0.0-rc I was able to build Mesa using only --enable-targets=r600. That option is also available in 3.6, I will be trying that in a current LFS build sometime soon (maybe this weekend). Then I will propose an 'option' addition.
In the absence of fixes, can we leave this until mesa-11.0 is released?
My idea was testing with mesa-11.0.0 (I think there is an 11.1.0). We have used those developments in BLFS, before.
But I agree. I am modifying to hold and low.
Ken, you made much more progress than I did. Would you mind taking this ticket from me?
Sorry, I can't - I don't build any of the extras. You have the expertise and you have done the main building and testing.
comment:12 by , 9 years ago
OK.
I think I solved the configure problem of mesa (working with 10.6.6). Problem is still there, but not in mesa-11.0.0-rc2. Following, trying to apply 11.0.0-rc2 fix to 10.6.6.
Found the following patch
http://cgit.freedesktop.org/mesa/mesa/patch/?id=4d35eef326e49cc8da50879d30a1c5088d4775e1
But make didn't complete. Still trying something.
comment:13 by , 9 years ago
Build completed, after applying another patch. It was another problem with llvm-3.7.
comment:14 by , 9 years ago
Milestone: | hold → 7.8 |
---|---|
Priority: | low → normal |
I'm sorry, don't know what is happening. Earlier, got Performing 4.4-subscription-ops.test: FAIL. Trying to solve it, changed remote server, configurations, now it is worse: