[Mesa-dev] [Bug 69874] Automake throws a lot of [...] option 'subdir-objects' is disabled
https://bugs.freedesktop.org/show_bug.cgi?id=69874 --- Comment #12 from Kai k...@dev.carbon-project.org --- Just to note the progress here: my latest build of Mesa (d2811c29da) shows this warning for only one directory. Seems like Mesa is almost there to be Automake 1.14 ready. ;-) -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Kai k...@dev.carbon-project.org changed: What|Removed |Added Depends on||88780 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Kai k...@dev.carbon-project.org changed: What|Removed |Added Depends on||88781 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: Link against all LLVM targets when building clover
On Sun, 2015-01-25 at 01:02 +0100, Niels Ole Salscheider wrote: On Saturday 24 January 2015, 18:24:16, Jan Vesely wrote: On Sat, 2015-01-24 at 22:49 +0100, Niels Ole Salscheider wrote: Since 8e7df519bd8556591794b2de08a833a67e34d526, we initialise all targets in clover. This fixes bug 85380. v2: Mention correct bug in commit message Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de I thought you already had Tom's rb. you can add mine as well Reviewed-by: Jan Vesely jan.ves...@rutgers.edu Ok, thanks. But I do not have write access to mesa - would you mind to push it for me? sorry, I don't have access either. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1cce517..2b7f576 100644 --- a/configure.ac +++ b/configure.ac @@ -1902,7 +1902,7 @@ if test x$enable_gallium_llvm = xyes; then fi if test x$enable_opencl = xyes; then -LLVM_COMPONENTS=${LLVM_COMPONENTS} ipo linker instrumentation +LLVM_COMPONENTS=${LLVM_COMPONENTS} all-targets ipo linker instrumentation # LLVM 3.3 = 177971 requires IRReader if $LLVM_CONFIG --components | grep -qw 'irreader'; then LLVM_COMPONENTS=${LLVM_COMPONENTS} irreader -- Jan Vesely jan.ves...@rutgers.edu -- Jan Vesely jan.ves...@rutgers.edu signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] nir: add a helper function for getting the number of source components
Unlike with non-SSA ALU instructions, where if they're per-component you have to look at the writemask to know which source channels are being used, SSA ALU instructions always have all the possible channels enabled so we can just look at the number of components in the SSA definition for per-component instructions to say how many source components are being used. Signed-off-by: Connor Abbott cwabbo...@gmail.com --- src/glsl/nir/nir.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h index 0ef83a1..efcaa9d 100644 --- a/src/glsl/nir/nir.h +++ b/src/glsl/nir/nir.h @@ -652,6 +652,21 @@ nir_alu_instr_channel_used(nir_alu_instr *instr, unsigned src, unsigned channel) return (instr-dest.write_mask channel) 1; } +/* + * For instructions whose destinations are SSA, get the number of channels + * used for a source + */ +static inline unsigned +nir_alu_instr_ssa_src_components(nir_alu_instr *instr, unsigned src) +{ + assert(instr-dest.dest.is_ssa); + + if (nir_op_infos[instr-op].input_sizes[src] 0) + return nir_op_infos[instr-op].input_sizes[src]; + + return instr-dest.dest.ssa.num_components; +} + typedef enum { nir_deref_type_var, nir_deref_type_array, -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] nir: fix a bug with constant folding non-per-component instructions
Before, we were only copying the first N channels, where N is the size of the SSA destination, which is fine for per-component instructions, but non-per-component instructions like fdot3 can have more source components than destination components. Fix this using the helper function introduced in the last patch. Signed-off-by: Connor Abbott cwabbo...@gmail.com --- Whoops, sorry I missed this during review... src/glsl/nir/nir_opt_constant_folding.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/glsl/nir/nir_opt_constant_folding.c b/src/glsl/nir/nir_opt_constant_folding.c index f727453..e79e287 100644 --- a/src/glsl/nir/nir_opt_constant_folding.c +++ b/src/glsl/nir/nir_opt_constant_folding.c @@ -56,7 +56,8 @@ constant_fold_alu_instr(nir_alu_instr *instr, void *mem_ctx) return false; nir_load_const_instr* load_const = nir_instr_as_load_const(src_instr); - for (unsigned j = 0; j instr-dest.dest.ssa.num_components; j++) { + for (unsigned j = 0; j nir_alu_instr_ssa_src_components(instr, i); + j++) { src[i].u[j] = load_const-value.u[instr-src[i].swizzle[j]]; } -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure: Link against all LLVM targets when building clover
Jan Vesely jan.ves...@rutgers.edu writes: On Sun, 2015-01-25 at 01:02 +0100, Niels Ole Salscheider wrote: On Saturday 24 January 2015, 18:24:16, Jan Vesely wrote: On Sat, 2015-01-24 at 22:49 +0100, Niels Ole Salscheider wrote: Since 8e7df519bd8556591794b2de08a833a67e34d526, we initialise all targets in clover. This fixes bug 85380. v2: Mention correct bug in commit message Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de I thought you already had Tom's rb. you can add mine as well Reviewed-by: Jan Vesely jan.ves...@rutgers.edu Ok, thanks. But I do not have write access to mesa - would you mind to push it for me? sorry, I don't have access either. Thanks! R-b and pushed. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 1cce517..2b7f576 100644 --- a/configure.ac +++ b/configure.ac @@ -1902,7 +1902,7 @@ if test x$enable_gallium_llvm = xyes; then fi if test x$enable_opencl = xyes; then -LLVM_COMPONENTS=${LLVM_COMPONENTS} ipo linker instrumentation +LLVM_COMPONENTS=${LLVM_COMPONENTS} all-targets ipo linker instrumentation # LLVM 3.3 = 177971 requires IRReader if $LLVM_CONFIG --components | grep -qw 'irreader'; then LLVM_COMPONENTS=${LLVM_COMPONENTS} irreader -- Jan Vesely jan.ves...@rutgers.edu -- Jan Vesely jan.ves...@rutgers.edu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev pgpjnYlKOfezN.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 88766] codegen/nv50_ir.h:585:9: error: no member named 'tr1' in namespace 'std'
https://bugs.freedesktop.org/show_bug.cgi?id=88766 --- Comment #7 from Francisco Jerez curroje...@riseup.net --- (In reply to Ilia Mirkin from comment #6) (In reply to Francisco Jerez from comment #5) Most likely this bug is not caused by the Clang compiler itself, but by the standard library implementation. Apparently FreeBSD ships with Yes, absolutely. LLVM's libc++ as default implementation these days, which implements the C++11 standard library and doesn't attempt to support the TR1 namespace, which is a C++03-specific extension. OK. nouveau doesn't work on FreeBSD; any reason for me to care about it? *Shrug*, maybe not until the remainig bits are ported to FreeBSD. In any case libc++ is nothing FreeBSD-specific, most major Linux distributions package it as well. If someone maps out the various version support for all this, perhaps we can make a decision. Or some other approach is the standard way to deal with this? I'd suggest we apply Vinson's patch and then build the codegen back-end with -std=c++0x (available on GCC 4.3 and later), otherwise GNU's libstdc++ will emit an error if you include any of the C++11 headers while building in C++98/03 mode. -std=c++11 would work too but it's only supported since GCC 4.7. Any reasonably recent Clang version (at least 2.9) should support both switches. My concern is the boxes on which nouveau works fine but have older compilers (I'm thinking of RHEL or Ubuntu LTS style situations). I want those to work a lot more than I want nouveau to build on FreeBSD/OSX/whatever. IIRC tr1 support came with GCC 4.0 or 4.1 or so, but I don't know which compilers came with which distros. I guess mesa already requires gcc 4.2 for something, so moving that up to 4.3 for nouveau may not be such a huge deal. I guess a patch which turns on -std=c++0x for codegen would be fine by me. Maybe, I don't know if there's anyone left using GCC 4.2, and whether we should care. GCC 4.3 happened almost 7 years ago, Ubuntu 10 LTS (the oldest release still supported by Canonical), RHEL 5 and 6 seem to be shipping GCC 4.4 already. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] glsl: GLSL ES identifiers cannot exceed 1024 characters
Ian, does this version get your R-b? On Tue, 2015-01-20 at 17:07 +0100, Iago Toral Quiroga wrote: v2 (Ian Romanick) - Move the check to the lexer before rallocing a copy of the large string. Fixes the following 2 dEQP tests: dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_vertex dEQP-GLES3.functional.shaders.keywords.invalid_identifiers.max_length_fragment --- src/glsl/glsl_lexer.ll | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll index 57c46be..48ba463 100644 --- a/src/glsl/glsl_lexer.ll +++ b/src/glsl/glsl_lexer.ll @@ -544,7 +544,13 @@ subroutine KEYWORD(0, 300, 0, 0, SUBROUTINE); [_a-zA-Z][_a-zA-Z0-9]* { struct _mesa_glsl_parse_state *state = yyextra; void *ctx = state; - yylval-identifier = ralloc_strdup(ctx, yytext); + if (state-es_shader strlen(yytext) 1024) { +_mesa_glsl_error(yylloc, state, + Identifier `%s' exceeds 1024 characters, + yytext); + } else { + yylval-identifier = ralloc_strdup(ctx, yytext); + } return classify_identifier(state, yytext); } ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] Fixing an x86 FPU bug.
From: Marius Predut marius.pre...@intel.com On 32-bit, for floating point operations is used x86 FPU registers instead SSE, reason for when reinterprets an integer as a float result is unexpected (modify floats when they are written to memory). The defect was checked with and without -O3 compiler flag. CC: mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82668 Signed-off-by: Marius Predut marius.pre...@intel.com --- src/mesa/main/context.c |3 ++- src/mesa/main/macros.h| 47 - src/mesa/vbo/vbo_attrib_tmp.h | 20 ++ src/mesa/vbo/vbo_exec.h |3 ++- src/mesa/vbo/vbo_exec_api.c | 31 +-- src/mesa/vbo/vbo_exec_eval.c | 22 ++- src/mesa/vbo/vbo_save_api.c | 16 +++--- src/mesa/vbo/vbo_save_draw.c |4 ++-- 8 files changed, 90 insertions(+), 56 deletions(-) diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c index 400c158..11ab8a9 100644 --- a/src/mesa/main/context.c +++ b/src/mesa/main/context.c @@ -134,6 +134,7 @@ #include math/m_matrix.h #include main/dispatch.h /* for _gloffset_COUNT */ #include uniforms.h +#include macros.h #ifdef USE_SPARC_ASM #include sparc/sparc.h @@ -656,7 +657,7 @@ _mesa_init_constants(struct gl_constants *consts, gl_api api) consts-MaxSamples = 0; /* GLSL default if NativeIntegers == FALSE */ - consts-UniformBooleanTrue = FLT_AS_UINT(1.0f); + consts-UniformBooleanTrue = FLOAT_AS_UNION(1.0f).u; /* GL_ARB_sync */ consts-MaxServerWaitTimeout = 0x1fff7fffULL; diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h index cd5f2d6..2651ffc 100644 --- a/src/mesa/main/macros.h +++ b/src/mesa/main/macros.h @@ -32,6 +32,7 @@ #define MACROS_H #include imports.h +#include program/prog_parameter.h /** @@ -170,27 +171,26 @@ extern GLfloat _mesa_ubyte_to_float_color_tab[256]; ub = ((GLubyte) F_TO_I((f) * 255.0F)) #endif -static inline GLfloat INT_AS_FLT(GLint i) +static union gl_constant_value UINT_AS_UNION(GLuint u) { - fi_type tmp; - tmp.i = i; - return tmp.f; + union gl_constant_value tmp; + tmp.u = u; + return tmp; } -static inline GLfloat UINT_AS_FLT(GLuint u) +static inline union gl_constant_value INT_AS_UNION(GLint i) { - fi_type tmp; - tmp.u = u; - return tmp.f; + union gl_constant_value tmp; + tmp.i = i; + return tmp; } -static inline unsigned FLT_AS_UINT(float f) +static inline union gl_constant_value FLOAT_AS_UNION(GLfloat f) { - fi_type tmp; + union gl_constant_value tmp; tmp.f = f; - return tmp.u; + return tmp; } - /** * Convert a floating point value to an unsigned fixed point value. * @@ -382,6 +382,15 @@ do {\ V[3] = V3; \ } while(0) +/** Assignment union*/ +#define ASSIGN_4V_UNION( V, V0, V1, V2, V3 ) \ +do {\ +V[0].f = V0; \ +V[1].f = V1; \ +V[2].f = V2; \ +V[3].f = V3; \ +} while(0) + /*@}*/ @@ -620,23 +629,23 @@ do { \ * The default values are chosen based on \p type. */ static inline void -COPY_CLEAN_4V_TYPE_AS_FLOAT(GLfloat dst[4], int sz, const GLfloat src[4], +COPY_CLEAN_4V_TYPE_AS_FLOAT(gl_constant_value dst[4], int sz, const gl_constant_value src[4], GLenum type) { switch (type) { case GL_FLOAT: - ASSIGN_4V(dst, 0, 0, 0, 1); + ASSIGN_4V_UNION(dst, 0, 0, 0, 1); break; case GL_INT: - ASSIGN_4V(dst, INT_AS_FLT(0), INT_AS_FLT(0), - INT_AS_FLT(0), INT_AS_FLT(1)); + ASSIGN_4V_UNION(dst, INT_AS_UNION(0).f, INT_AS_UNION(0).f, +INT_AS_UNION(0).f, INT_AS_UNION(1).f); break; case GL_UNSIGNED_INT: - ASSIGN_4V(dst, UINT_AS_FLT(0), UINT_AS_FLT(0), - UINT_AS_FLT(0), UINT_AS_FLT(1)); + ASSIGN_4V_UNION(dst, UINT_AS_UNION(0).f, UINT_AS_UNION(0).f, +UINT_AS_UNION(0).f, UINT_AS_UNION(1).f); break; default: - ASSIGN_4V(dst, 0.0f, 0.0f, 0.0f, 1.0f); /* silence warnings */ + ASSIGN_4V_UNION(dst, 0.0f, 0.0f, 0.0f, 1.0f); /* silence warnings */ ASSERT(!Unexpected type in COPY_CLEAN_4V_TYPE_AS_FLOAT macro); } COPY_SZ_4V(dst, sz, src); diff --git a/src/mesa/vbo/vbo_attrib_tmp.h b/src/mesa/vbo/vbo_attrib_tmp.h index ec66934..17a0a10 100644 --- a/src/mesa/vbo/vbo_attrib_tmp.h +++ b/src/mesa/vbo/vbo_attrib_tmp.h @@ -28,6 +28,18 @@ USE OR OTHER DEALINGS IN THE SOFTWARE. #include util/u_format_r11g11b10f.h #include main/varray.h + +/* ATTR */ +#define ATTR( A, N, T, V0, V1, V2, V3 ) ATTR_##T((A), (N), (T), (V0), (V1), (V2), (V3)) + +#define ATTR_GL_UNSIGNED_INT( A, N, T, V0, V1, V2, V3 ) \ +ATTR_UNION(A, N, T,
[Mesa-dev] [PATCH v2] mesa: simplify detection of fpclassify
Fixes compilation with musl libc. Reviewed-by: Ian Romanick ian.d.roman...@intel.com --- Changes in v2: Add comment by Ian Romanick on fpclassify in C99 --- src/mesa/main/querymatrix.c | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/src/mesa/main/querymatrix.c b/src/mesa/main/querymatrix.c index eb36c76..ef85175 100644 --- a/src/mesa/main/querymatrix.c +++ b/src/mesa/main/querymatrix.c @@ -37,8 +37,12 @@ #define INT_TO_FIXED(x) ((GLfixed) ((x) 16)) #define FLOAT_TO_FIXED(x) ((GLfixed) ((x) * 65536.0)) -#if defined(_MSC_VER) -#if _MSC_VER 1800 /* Not required on VS2013 and above. */ +#if defined(fpclassify) +/* ISO C99 says that fpclassify is a macro. Assume that any implementation + * of fpclassify, whether it's in a C99 compiler or not, will be a macro. + */ +#elif defined(_MSC_VER) +/* Not required on VS2013 and above. */ /* Oddly, the fpclassify() function doesn't exist in such a form * on MSVC. This is an implementation using slightly different * lower-level Windows functions. @@ -71,16 +75,8 @@ fpclassify(double x) return FP_NAN; } } -#endif /* _MSC_VER 1800 */ - -#elif defined(__APPLE__) || defined(__CYGWIN__) || defined(__FreeBSD__) || \ - defined(__OpenBSD__) || defined(__NetBSD__) || defined(__DragonFly__) || \ - (defined(__sun) defined(__C99FEATURES__)) || defined(__MINGW32__) || \ - (defined(__sun) defined(__GNUC__)) || defined(ANDROID) || defined(__HAIKU__) - -/* fpclassify is available. */ -#elif !defined(_XOPEN_SOURCE) || _XOPEN_SOURCE 600 +#else enum {FP_NAN, FP_INFINITE, FP_ZERO, FP_SUBNORMAL, FP_NORMAL} fpclassify(double x) -- 2.0.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 88783] FTBFS: Clover: src/gallium/state_trackers/clover/llvm/invocation.cpp:335:49: error: no matching function for call to 'llvm::TargetLibraryInfo::TargetLibraryInfo(llvm::Triple)
https://bugs.freedesktop.org/show_bug.cgi?id=88783 Bug ID: 88783 Summary: FTBFS: Clover: src/gallium/state_trackers/clover/llvm/invocation.cpp: 335:49: error: no matching function for call to 'llvm::TargetLibraryInfo::TargetLibraryInfo(llvm::Trip le) Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Other Assignee: mesa-dev@lists.freedesktop.org Reporter: k...@dev.carbon-project.org QA Contact: mesa-dev@lists.freedesktop.org CC: adf.li...@gmail.com Created attachment 112793 -- https://bugs.freedesktop.org/attachment.cgi?id=112793action=edit Full build log of failing build, produced by pbuilder With LLVM r226934 I get the following build error in a clean chroot build environment (pbuilder): ../../../../../../src/gallium/state_trackers/clover/llvm/invocation.cpp: In function 'void {anonymous}::optimize(llvm::Module*, unsigned int, const std::vectorllvm::Function*)': ../../../../../../src/gallium/state_trackers/clover/llvm/invocation.cpp:335:49: error: no matching function for call to 'llvm::TargetLibraryInfo::TargetLibraryInfo(llvm::Triple)' llvm::Triple(mod-getTargetTriple())); ^ ../../../../../../src/gallium/state_trackers/clover/llvm/invocation.cpp:335:49: note: candidates are: In file included from ../../../../../../src/gallium/state_trackers/clover/llvm/invocation.cpp:60:0: /usr/lib/llvm-3.7/include/llvm/Analysis/TargetLibraryInfo.h:785:3: note: llvm::TargetLibraryInfo::TargetLibraryInfo(llvm::TargetLibraryInfo) TargetLibraryInfo(TargetLibraryInfo TLI) : Impl(TLI.Impl) {} ^ /usr/lib/llvm-3.7/include/llvm/Analysis/TargetLibraryInfo.h:785:3: note: no known conversion for argument 1 from 'llvm::Triple' to 'llvm::TargetLibraryInfo' /usr/lib/llvm-3.7/include/llvm/Analysis/TargetLibraryInfo.h:784:3: note: llvm::TargetLibraryInfo::TargetLibraryInfo(const llvm::TargetLibraryInfo) TargetLibraryInfo(const TargetLibraryInfo TLI) : Impl(TLI.Impl) {} ^ /usr/lib/llvm-3.7/include/llvm/Analysis/TargetLibraryInfo.h:784:3: note: no known conversion for argument 1 from 'llvm::Triple' to 'const llvm::TargetLibraryInfo' /usr/lib/llvm-3.7/include/llvm/Analysis/TargetLibraryInfo.h:781:12: note: llvm::TargetLibraryInfo::TargetLibraryInfo(const llvm::TargetLibraryInfoImpl) explicit TargetLibraryInfo(const TargetLibraryInfoImpl Impl) : Impl(Impl) {} ^ /usr/lib/llvm-3.7/include/llvm/Analysis/TargetLibraryInfo.h:781:12: note: no known conversion for argument 1 from 'llvm::Triple' to 'const llvm::TargetLibraryInfoImpl' Makefile:857: recipe for target 'llvm/libclllvm_la-invocation.lo' failed make[4]: *** [llvm/libclllvm_la-invocation.lo] Error 1 This bug was first reported by Andy Furniss on the mesa-dev list on 2014-01-24 at 15:06 UTC (see http://thread.gmane.org/gmane.comp.video.mesa3d.devel/93649). This bug is intended to make it easier for multiple persons to track. A full build log of the failing build is attached to this report. Let me know, if you need something else. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 88783] FTBFS: Clover: src/gallium/state_trackers/clover/llvm/invocation.cpp:335:49: error: no matching function for call to 'llvm::TargetLibraryInfo::TargetLibraryInfo(llvm::Triple)
https://bugs.freedesktop.org/show_bug.cgi?id=88783 --- Comment #1 from Kai k...@dev.carbon-project.org --- (In reply to Kai from comment #0) With LLVM r226934 I get the following build error in a clean chroot build Small clarification: SVN r226934 was my last successful build. I saw the failure with r227016. Somewhere between those two the definition for the method must have changed. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] nir: add a helper function for getting the number of source components
On Sun, Jan 25, 2015 at 8:56 AM, Connor Abbott cwabbo...@gmail.com wrote: Unlike with non-SSA ALU instructions, where if they're per-component you have to look at the writemask to know which source channels are being used, SSA ALU instructions always have all the possible channels enabled so we can just look at the number of components in the SSA definition for per-component instructions to say how many source components are being used. Signed-off-by: Connor Abbott cwabbo...@gmail.com --- src/glsl/nir/nir.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h index 0ef83a1..efcaa9d 100644 --- a/src/glsl/nir/nir.h +++ b/src/glsl/nir/nir.h @@ -652,6 +652,21 @@ nir_alu_instr_channel_used(nir_alu_instr *instr, unsigned src, unsigned channel) return (instr-dest.write_mask channel) 1; } +/* + * For instructions whose destinations are SSA, get the number of channels + * used for a source + */ +static inline unsigned +nir_alu_instr_ssa_src_components(nir_alu_instr *instr, unsigned src) The name instr_ssa_src_components is kind of deceiving when the source isn't what has to be SSA. It's the destination that's SSA. I'm not coming up with a better name off hand, but we should try and find one. Also, There are a lot of other places that need this than just constant folding. A quick grep for input_sizes would probably reveal the ones that are open-coding it. Other than that, I like the series. --Jason +{ + assert(instr-dest.dest.is_ssa); + + if (nir_op_infos[instr-op].input_sizes[src] 0) + return nir_op_infos[instr-op].input_sizes[src]; + + return instr-dest.dest.ssa.num_components; +} + typedef enum { nir_deref_type_var, nir_deref_type_array, -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] clover: Fix build with llvm after r226981
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88783 Signed-off-by: Jan Vesely jan.ves...@rutgers.edu --- src/gallium/state_trackers/clover/llvm/invocation.cpp | 4 1 file changed, 4 insertions(+) diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp b/src/gallium/state_trackers/clover/llvm/invocation.cpp index 6cc07b2..7a0be53 100644 --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp @@ -331,7 +331,11 @@ namespace { llvm::PassManagerBuilder PMB; PMB.OptLevel = optimization_level; +#if HAVE_LLVM 0x0307 PMB.LibraryInfo = new llvm::TargetLibraryInfo( +#else + PMB.LibraryInfo = new llvm::TargetLibraryInfoImpl( +#endif llvm::Triple(mod-getTargetTriple())); PMB.populateModulePassManager(PM); PM.run(*mod); -- 2.1.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 88783] FTBFS: Clover: src/gallium/state_trackers/clover/llvm/invocation.cpp:335:49: error: no matching function for call to 'llvm::TargetLibraryInfo::TargetLibraryInfo(llvm::Triple)
https://bugs.freedesktop.org/show_bug.cgi?id=88783 --- Comment #2 from Jan Vesely jan.ves...@rutgers.edu --- Created attachment 112818 -- https://bugs.freedesktop.org/attachment.cgi?id=112818action=edit Fix build after 226981 (In reply to Kai from comment #1) (In reply to Kai from comment #0) With LLVM r226934 I get the following build error in a clean chroot build Small clarification: SVN r226934 was my last successful build. I saw the failure with r227016. Somewhere between those two the definition for the method must have changed. The change was introduced in r226981. The attached patch fixes the issue for me. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev