<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 2:48 PM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 11/22, Aaron Watry wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
disk_cache_get returns void*, but we were storing/comparing a char*.<br>
<br>
Signed-off-by: Aaron Watry <<a href="mailto:awatry@gmail.com" target="_blank">awatry@gmail.com</a>><br>
---<br>
Note that this did, and still, segfaults for me when I actually run it...<br>
</blockquote>
<br></span>
Strange. It passes for me.<span class="gmail-"><br></span></blockquote><div><br></div><div>I guess that I should have clarified, this is also in the "building a 32-bit mesa on 64-bit host" scenario of my other two patches.<br><br></div><div>If I enable the shader cache on a 64-bit build, it works fine.<br><br></div><div>I'm not sure which scenario you're building for...<br><br></div><div>What I'm getting in my cross-compile scenario is:<br>/home/me/src/mesa/bin/test-driver: line 107: 10596 Segmentation fault      (core dumped) "$@" > $log_file 2>&1<br>FAIL: glsl/tests/cache-test<br><br></div><div>If I try to run the test directly, I get:<br>Error: Test 'disk_cache_create with no environment variables' failed: Result=NULL, but expected something else.<br>Segmentation fault (core dumped)<br><br></div><div>Valgrind says:<br>==26330== Invalid read of size 4<br>==26330==    at 0x804A366: disk_cache_destroy (disk_cache.c:318)<br>==26330==    by 0x8048FA3: test_disk_cache_create (cache_test.c:143)<br>==26330==    by 0x8048FA3: main (cache_test.c:391)<br>==26330==  Address 0x8 is not stack'd, malloc'd or (recently) free'd<br><br></div><div>WIth that being said, I'm not seeing the warning that I thought I saw before... I'm going to go back to the drawing board with this one and see if I can address the segfault (looks like a failure to determine the user's home directory for my environment, and I'm not sure why that's happening for the 32-bit case).  <br><br>The warnings that I thought I was getting before are no longer present, and as you noted below should be allowed. It's possible I saw it when building with clang instead of gcc, but I'm not sure anymore (I've been carrying this patch locally for a while).<br><br></div><div>--Aaron<br></div><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But at least the compiler is no longer complaining about the type mismatch.<br>
src/compiler/glsl/tests/cache_<wbr>test.c | 6 +++---<br>
1 file changed, 3 insertions(+), 3 deletions(-)<br>
<br>
diff --git a/src/compiler/glsl/tests/cach<wbr>e_test.c b/src/compiler/glsl/tests/cach<wbr>e_test.c<br>
index 0ef05aa..c663e54 100644<br>
--- a/src/compiler/glsl/tests/cach<wbr>e_test.c<br>
+++ b/src/compiler/glsl/tests/cach<wbr>e_test.c<br>
@@ -208,14 +208,14 @@ test_put_and_get(void)<br>
   _mesa_sha1_compute(blob, sizeof(blob), blob_key);<br>
<br>
   /* Ensure that disk_cache_get returns nothing before anything is added. */<br>
-   result = disk_cache_get(cache, blob_key, &size);<br>
+   result = (char*) disk_cache_get(cache, blob_key, &size);<br>
</blockquote>
<br></span>
void * is implicitly convertable to char *, so I think the code is fine<br>
as is. Maybe if I saw the compiler warning.<br>
<br>
"result" could be declared void * to begin with, and that would be fine.<br>
I just tested it, and it seems to work.<br>
<br>
Also, please use (char *) for casts and not (char*) in Mesa.<br></blockquote><div><br></div>But, what I've also been seeing is sporadic warnings in the nir control flow tests regarding signed/unsigned comparisons.<br></div><br></div></div>