On Wed, Feb 8, 2017 at 8:37 PM, Nicolai Hähnle wrote:
> On 08.02.2017 20:17, Marek Olšák wrote:
>>
>> The no_sanitize attribute seems to be the most acceptable approach.
>
>
> I disagree. gcc produces the same code even with just -O, and the ?: version
> very clearly avoids undefined behavior. If
On 08.02.2017 20:17, Marek Olšák wrote:
The no_sanitize attribute seems to be the most acceptable approach.
I disagree. gcc produces the same code even with just -O, and the ?:
version very clearly avoids undefined behavior. If we could get into the
habit of regularly running tests with the v
The no_sanitize attribute seems to be the most acceptable approach.
Marek
On Wed, Feb 8, 2017 at 8:14 PM, Roland Scheidegger wrote:
> So, I'd be happy with either changing the code to check for null
> pointers or using no_sanitize attribute. But it looks like others might
> not agree...
>
> Rola
So, I'd be happy with either changing the code to check for null
pointers or using no_sanitize attribute. But it looks like others might
not agree...
Roland
Am 08.02.2017 um 19:21 schrieb Bartosz Tomczyk:
> I find ASAN and UBSAN extremely useful while debugging, but currently
> there is hundreds
I find ASAN and UBSAN extremely useful while debugging, but currently there
is hundreds issues reported while running simple test. That make it very
hard to use it.
As Brian mention, first argument is never NULL. It can simplify changes
while still make UBSAN happy.
Roland, yes compiler will opt
FWIW, I'd like us to focus on real issues instead of trying to please
static analyzers.
If one of the reference functions stops working, we'll know that
pretty quickly. Until then, there is nothing to do.
Marek
On Wed, Feb 8, 2017 at 6:12 PM, Roland Scheidegger wrote:
> no_sanitize attribute lo
no_sanitize attribute looks like a reasonable solution to me (as long as
it still compiles everywhere, of course).
(But as said, since this is iffy, I'd be ok with changing the code too,
iff you can prove that compilers optimize this away.)
Roland
Am 08.02.2017 um 16:54 schrieb Bartosz Tomczyk:
>
I'm not insist to push it, although it looks like undefined behavior by C
standard, all known compilers generates perfectly legal code for those
construction. If there is strong objections about the patches, how about
disabling UBSAN for those function
with __attribute__((no_sanitize("undefined"))
Am 08.02.2017 um 10:21 schrieb Nicolai Hähnle:
> On 07.02.2017 23:00, Brian Paul wrote:
>> Yeah, it would never make sense to pass NULL as the first argument to
>> any of the _reference() functions.
>>
>> Would putting an assert(ptr) at the start of pipe_surface_reference(),
>> for example, silence
On 07.02.2017 23:00, Brian Paul wrote:
Yeah, it would never make sense to pass NULL as the first argument to
any of the _reference() functions.
Would putting an assert(ptr) at the start of pipe_surface_reference(),
for example, silence the UBSAN warning?
I think the point is that *ptr is NULL,
Yeah, it would never make sense to pass NULL as the first argument to
any of the _reference() functions.
Would putting an assert(ptr) at the start of pipe_surface_reference(),
for example, silence the UBSAN warning?
-Brian
On 02/07/2017 02:45 PM, Roland Scheidegger wrote:
I'm not quite sur
I'm not quite sure there's really a bug here?
As far as I can tell, these functions are architected specifically to
look like that - they do not actually dereference potential null
pointers, but only take the address in the end. This change seems to add
some overhead.
Roland
Am 07.02.2017 um 19
---
src/gallium/auxiliary/util/u_inlines.h | 65 --
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_inlines.h
b/src/gallium/auxiliary/util/u_inlines.h
index b7b8313583..3bb3bcd6e0 100644
--- a/src/gallium/auxiliary/util/
13 matches
Mail list logo
