[Mesa-dev] [Bug 69874] Automake throws a lot of [...] option 'subdir-objects' is disabled

2015-01-25 Thread bugzilla-daemon 
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

2015-01-25 Thread bugzilla-daemon 
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

2015-01-25 Thread bugzilla-daemon 
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

2015-01-25 Thread Jan Vesely 
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

2015-01-25 Thread Connor Abbott 
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

2015-01-25 Thread Connor Abbott 
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

2015-01-25 Thread Francisco Jerez 
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'

2015-01-25 Thread bugzilla-daemon 
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

2015-01-25 Thread Iago Toral 
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.

2015-01-25 Thread marius . predut 
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

2015-01-25 Thread Felix Janda 
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)

2015-01-25 Thread bugzilla-daemon 
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)

2015-01-25 Thread bugzilla-daemon 
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

2015-01-25 Thread Jason Ekstrand 
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

2015-01-25 Thread Jan Vesely 
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)

2015-01-25 Thread bugzilla-daemon 
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