Will take care of this regressions tomorrow. Thanks for pointing.

(In reply to Mark Janes from comment #0)
> 2 piglit tests regressed on 32 bit builds, bisected to:

> /tmp/build_root/m32/lib/piglit/bin/gl-3.1-link-empty-prog-core -auto -fbo

> /tmp/build_root/m32/lib/piglit/bin/arb_separate_shader_object-api-errors

I was not able to reproduce the regressions with such tests. I tried with today master with the HEAD at the pointed commit. So perhaps it 32-bit builds on a specific scenario.

I tested it using a Haswell GPU, with the i965 driver. In order to ensure a 32-bit build I set up a chroot with ubuntu artful with the i386 sources:

$ file ./bin/arb_separate_shader_object-api-errors 
./bin/arb_separate_shader_object-api-errors: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=2cc6fd68471c30fb3eeafe9e2729aefb9648737d, with debug_info, not stripped

Anything specific about 32-bit build where those tests regressed?

This test fails for me when mesa/piglit are compiled with debug flags, but passes in release.  How are you compiling?

Oops! sorry, ignore that last comment.  I was testing the wrong version of mesa, and debug/release has nothing to do with it.

Debug/release *does* seem to make a difference.  I had the wrong version for one of my tests, but the test does fail when mesa is compiled with CPPFLAGS=-DDEBUG and this cross file:

https://github.com/janesma/mesa_ci/blob/master/build_support/x86-linux-gcc.cross

I can pretty easily reproduce this using debug and !debug (the default debugoptimzed will also reproduce it) for *mesa*. building piglit with/without debug seems to have no effect.

This fails:
meson build -Ddri-drivers=i965 -Dgallium-drivers= -Dvulkan-drivers=

This passes:
meson build -Ddri-drivers=i965 -Dgallium-drivers= -Dvulkan-drivers= --buildtype=debug

I also commented out -DDEBUG, so we can rule that out.'

I also attached gdb, and I can see that there is in fact a shader attached to the prog in a non-debug build, but I'm having trouble figuring out what it is since much of the information about it has been optimized away in a non-debug build.

I have a patch, I'll CC you.

fixed by
6f6e711c721eba8dad1541479e31d5db5108b41d
Author:     Dylan Baker <dylan@pnwbakers.com>
AuthorDate: Mon Apr 2 15:29:45 2018 -0700
Commit:     Dylan Baker <dylan@pnwbakers.com>
CommitDate: Tue Apr 3 08:47:59 2018 -0700

Parent:     d3e96b10630 radeonsi/gfx9: fix bad LLVM params in monolithic LS+HS
Containing: master
Follows:    17.3-branchpoint (4386)

mesa: ensure that variable is initialized

This variable controls whether we link using the glsl code path or the
spirv path. It's set when we validate that all shaders are glsl or
spirv, but if there are no shaders attached to the program it will
remain unset, resulting in undefined behavior. We want to go down the
glsl path in that case, so initialize to false.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105820
Fixes: 16f6634e7fb5ada308e55b852cd49251e7f3f8b1
       ("mesa/program: Link SPIR-V shaders using the SPIR-V code-path")
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>