<p dir="ltr">Ok, I raised the priority back to Normal in the bug, since the work around wasn't good enough. </p>
<p dir="ltr">Cheers, <br>
Renato </p>
<div class="gmail_quote">On 13 Jan 2015 11:57, "Simon Taylor" <<a href="mailto:simontaylor1@ntlworld.com">simontaylor1@ntlworld.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 5 Jan 2015, at 13:08, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br>
><br>
> On 5 January 2015 at 12:13, James Molloy <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>> wrote:<br>
>> For this reason Renato I don't think we should advise people to work around<br>
>> the API, as who knows what problems that will cause later.<br>
><br>
> I stand corrected (twice). But we changed the subject a bit, so things<br>
> got different midway through.<br>
><br>
> There were only two codes: full C, with pointers, vectorized some<br>
> times; and full NEON, with extra loads. The mix between the two came<br>
> later, as a quick fix. My comment to that, I agree, was misplaced, and<br>
> both you and Tim are correct is asking for it not to be used as a<br>
> final solution. But as an interim solution, with the care around<br>
> alignment, endian and all, it is "fine”.<br>
<br>
After a bit more testing applying the pointer dereferencing workaround in my real code (which has some layers of templates and inline functions) I’ve decided against using it in practice.<br>
<br>
GCC produced incorrect code unless -fno-strict-aliasing was specified. It’s probably entirely entitled to do that, so it just seems too flaky to recommend in any case.<br>
<br>
Simon<br>
<br>
</blockquote></div>