On 11/02/2016 03:20 PM, Marek Polacek wrote: > On Wed, Nov 02, 2016 at 11:10:53AM +0100, Jakub Jelinek wrote: >> On Wed, Nov 02, 2016 at 10:59:26AM +0100, Jakub Jelinek wrote: >>>> 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); >>>> } >> >>> 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? >> >> Wonder if for the variables declared inside of switch body, because we don't >> care about uses before scope, it wouldn't be more efficient to arrange for >> int *p, *q, *r; >> switch (x) >> { >> int a; >> case 1: >> p = &a; >> a = 5; >> break; >> int b; >> case 2: >> int c; >> q = &b; >> r = &c; >> b = 3; >> c = 4; >> break; >> } >> to effectively ASAN_MARK (2, &a, 4); ASAN_MARK (2, &b, 4); ASAN_MARK (2, &c, >> 4); >> before the GIMPLE_SWITCH, instead of unpoisoning them on every case label >> where they might be in scope. Though, of course, at least until lower pass >> that is quite ugly, because it would refer to "not yet declared" variables. >> Perhaps we'd need to move the ASAN_MARK and GIMPLE_SWITCH (but of course not >> the expression evaluation of the switch control expression) inside of the >> switches' GIMPLE_BIND. > > So is there anything I should do wrt -Wswitch-unreachable? > > Marek >
Probably not. I'm having a patch puts GIMPLE_SWITCH statement to a proper place in GIMPLE_BIND. Let's see whether such patch can bootstrap and survive regression tests. Thanks, Martin