On Thu, 26 Mar 2020, Jakub Jelinek wrote: > Hi! > > On Thu, Mar 26, 2020 at 10:24:29AM +0100, Richard Biener wrote: > > On Thu, 26 Mar 2020, Jakub Jelinek wrote: > > > > > On Thu, Mar 26, 2020 at 10:14:35AM +0100, Richard Biener wrote: > > > > Ick. I fear we really need a better way of dealing with this > > > > STATEMENT_LIST appearance with only -g ... > > > > > > Yeah, it is very ugly and in some PRs I'm out of ideas what to do. > > > > I think a more sustainable "fix" would be to simply not emit > > the DEBUG_BEGIN_STMT when it would be the only reason to > > emit a STATEMENT_LIST ... > > > > Or always emit a STATEMENT_LIST node whenever there could be one > > (hopefully not every stmt could be a stmt list and hopefully > > we don't treat single-stmt STATEMENT_LIST specially). > > > > That is, the fix should be to avoid this difference in the first > > place, not try to deal with the difference later. > > Or perhaps just a flag on the STATEMENT_LIST that would make it clear the > STATEMENT_LIST wouldn't be there without -g. Or different tree code like > STATEMENT_LIST, except that it would be only this kind of container.
But then you still need to deal with those so the fixups would look similar, it just shortens the checks a bit. > Or disable -gstatement-frontiers by default and declare it -fcompare-debug > incompatible. Do any debug info consumers consume this? I'm not aware of any. Richard. > In any case, I'd really like Alex' feedback on this. > > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
