[Bug 97532] Regression: GLB 2.7 segfaults due to bogus linker precision error (259fc505) on dead variable

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Sep 2 10:45:23 UTC 2016


https://bugs.freedesktop.org/show_bug.cgi?id=97532

--- Comment #11 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to Kenneth Graunke from comment #8)
> You have to enforce language rules regardless of whether or not code is used.
> 
> Nobody would suggest that a C compiler should compile:
> 
> void main()
> {
>    int x = "lol, who needs rules?";
>    return 0;
> }
> 
> just because 'x' isn't used.  That's crazy.

C-code variant of this would be:
----------- foo.c -----------
#include <stdint.h>
extern int32_t x;
----------- bar.c -----------
#include <stdint.h>

extern int64_t x;

void do_something_with_x(...)
{
...
}
-----------------------------

And question would be whether C-linker should warn that global variable 'x' has
been declared with different type/size in different objects, because program
where this library would be linked can only be providing one type.

Whether things work in above example, depends only on whether the int64_t type
matches the (at this moment unknown) "external" type, because that's the only
type that's actually used by the code.  Usage here (in above C-code, and Egypt
shaders) isn't dependent on whether the code is optimized, because the other
declared type is NOT used at all, it's just declared.  Spec talks only about
mismatch in use, not definition.


One can say that linker doesn't know whether the reason why uniform isn't used
in the linked code is result of shader stage optimization or not, i.e. is it in
use in unoptimized code.  That's why it must definitely be warned about.

However, only the case where different types are actually in use, is the only
case where it's certain that it's not going to work -> clearly an error where
program should be stopped.


The reason why I don't think there should be an error about the first case is
that it can easily be a regression on fully functional programs (like here),
and those regressions will go unnoticed because Mesa's regular testing is
mainly for GL, there's not much testing for GLES (WebGL etc).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160902/0cd40ba5/attachment.html>


More information about the intel-3d-bugs mailing list