On 11/02/2016 10:59 AM, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 10:36:44AM +0100, Martin Liška wrote: >> On 11/01/2016 03:53 PM, Jakub Jelinek wrote: >>> What kind of false positives it is for each case? Is it with normal >>> asan-bootstrap (without your -fsanitize-use-after-scope changes), or >>> only with those changes, or only with those changes and >>> -fsanitize-use-after-scope used during bootstrap? >> >> Ok, the situation is simpler than I thought: > > CCing also Marek. >> >> #include <stdio.h> >> >> int main(int argc, char **argv) >> { >> int *ptr; >> >> switch (argc) >> { >> int a; >> >> case 1: >> break; >> >> default: >> ptr = &a; >> break; >> } >> >> fprintf (stderr, "v: %d\n", *ptr); >> return 0; >> } >> >> Which is gimplified as: >> >> int * ptr; >> >> switch (argc) <default: <D.2575>, case 1: <D.2573>> >> { >> int a; >> >> try >> { >> ASAN_MARK (2, &a, 4); >> <D.2573>: >> goto <D.2574>; >> <D.2575>: >> ptr = &a; >> goto <D.2574>; >> } >> finally >> { >> ASAN_MARK (1, &a, 4); >> } >> } >> <D.2574>: >> _1 = *ptr; >> stderr.0_2 = stderr; >> fprintf (stderr.0_2, "v: %d\n", _1); >> D.2577 = 0; >> return D.2577; >> } >> D.2577 = 0; >> return D.2577; >> >> and thus we get: >> /tmp/switch-case.c:9:11: warning: statement will never be executed >> [-Wswitch-unreachable] >> int a; >> >> I'm wondering where properly fix that, we can either find all these >> ASAN_MARKs in gimplify_switch_expr >> and distribute it to all labels (which are gimplified). Or we can put such >> variables to asan_poisoned_variables >> if we have information that we're gimplifing statements before a first >> label. Do we know that from gimple context? >> If so, these variables will be unpoisoned at the very beginning of each >> label and the ASAN_MARK call in between >> switch statement and a first label can be removed. > > Wouldn't it be easiest if -Wswitch-unreachable warning just ignored > the ASAN_MARK internal calls altogether? > Do you emit there any other statements, or just ASAN_MARK and nothing else?
Yep, skipping warning can be done easily, however gimplified code is wrong as un-poisoning is not done for variable (even for a valid program). > > Shouldn't there be also ASAN_MARK on the implicit gotos from the switch > statement? Otherwise, consider this being done in a loop, after the first > iteration you ASAN_MARK (1, &a, 4) (i.e. poison), then you iterate say with > args 1 and have in case 1: a = 0;, won't that trigger runtime error? Hopefully having the un-poisoning call be encapsulated in finally block would properly clean up the variable. Or am I wrong? Martin > > Jakub >