[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 --- 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 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 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
[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=112793&action=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::vector&)':
> ../../../../../../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
). 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 --- (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
[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 --- (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] 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
> >
> > I thought you already had Tom's rb.
> > you can add mine as well
> > Reviewed-by: Jan Vesely
>
> 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 Vesely
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
Re: [Mesa-dev] [PATCH] configure: Link against all LLVM targets when building clover
Jan Vesely 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
>> >
>> > I thought you already had Tom's rb.
>> > you can add mine as well
>> > Reviewed-by: Jan Vesely
>>
>> 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 Vesely
> ___
> 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] [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
---
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
---
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
[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
---
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 --- Created attachment 112818 --> https://bugs.freedesktop.org/attachment.cgi?id=112818&action=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
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 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
> ---
> 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 v2] Fixing an x86 FPU bug.
From: Marius Predut
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:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82668
Signed-off-by: Marius Predut
---
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, UINT_AS_UNION(V0), UINT_AS_UNION(V1),
UINT_AS_UNION(V2), UINT_AS_UNIO
[Mesa-dev] [PATCH v2] mesa: simplify detection of fpclassify
Fixes compilation with musl libc.
Reviewed-by: Ian Romanick
---
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
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
