On 3/11/19 9:30 AM, Jakub Jelinek wrote: > On Mon, Mar 11, 2019 at 09:13:57AM +0100, Martin Liška wrote: >> The patch adds a lot of option name wrapping in string format messages. I >> added a new contrib >> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot >> file and reports >> errors. >> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> Apart from that I built all cross compilers and compared all warnings so that >> I don't introduce a bootstrap error. It's expected that various >> target-specific >> tests will need wrapping in scanned patterns. >> >> Is it fine for next stage1? > > Generally looks good to me, but I'm not sure about corner cases like: > %<-misr-secure=X%>, shouldn't the X be after %>? X is not what users would > type. Or reword these to %<-misr-secure=%s%> argument not in between 0 and > 23 or similar.
Well, in order to make it consistent, I would put the closing '%>' after the whole option=argument expression. > > On the other side: > %<-mcpu%>=%s conflicts with %<-march%>=%s > the =%s should be before %>. > Same with %<-mrgf-banked-regs%>=%s . > > Similarly > %<-mstringop-strategy=rep%>_8byte > or > %<-mcpu=v8%>.30.a > or > %<-mfloat128%>-hardware > look wrong. I'm going to fix all these. > > Don't we want to commit it now (after fixing above issues), rather than > waiting for stage1? We have changed tons of translations recently and this > is something that the translators have been asking for a long time, we need > to upload new gcc.pot anyway and let them adjust translations, plus your > it will be hard to maintain your patch for another month or two. I would be happy to get it in right now. Yes, patch conflicts would happen during the time. I'll send updated version as a reply for the second Jakub's email. Martin > > Jakub >
