On Fri, 2 Feb 2018 14:25:22 +0100 Bernhard Reutner-Fischer <rep.dot....@gmail.com> wrote:
> On 19 June 2016 at 22:21, Mike Stump <mikest...@comcast.net> wrote: > > On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer > > <rep.dot....@gmail.com> wrote: > >> > >> A branch with a name matching scan-assembler pattern triggers > >> inappropriate FAIL. > > > >> The patch below adds -fno-ident if a testcase contains one of > >> scan-assembler, scan-assembler-not or scan-assembler-times. > > > > Kinda gross. I'd like to consensus build a little, as I don't know that I > > have a better solution than the solution you propose to fix the issue. I'd > > love it if one or more of Jacob, Law and Richard can chime in on direction > > here. I'll have to think about this some more and see if I can come up > > with something that I like better. > > > > If no one has a better solution, I'll approve the proposed solution. Let's > > give people a little time to chime in. > > Given the overwhelming silence this proposal has received, i take it > for granted that folks are thrilled and even up until now speechless > :) > > So how should we proceed with -fno-ident. > And, btw, -fno-file to inhibit .file directives for the same reason, AFAICS we still do not pass -fno-file in tests. Every now and then this still results in unnecessary, silly workarounds like this one: > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01785.html and all our which we should not have to afford. > ugly filenames like gcc.target/powerpc/swps-p8-36.c which strive to > workaround the assembler-scans. > > All those non-automatic hacks like naming swap() tests swps-, > uglifying scan-patterns (which are not terribly straight forward to > read anyway even without uglifying them) are error prone and costly. > IMHO we should make sure time is spent for useful stuff and not be > wasted to fight our very own testsuite. > > -fno-ident ok for stage1? We've fixed the ident thing some time ago. > What about -fno-file? Clever alternative suggestions? Don't care? We still didn't fix the .file directives in assembler output. It's about the same as always. See if the target supports -fno-file and/or -ffile. If the testcase does NOT specify -fno-file or -ffile ¹) then pass an appropriate default like -fno-file, otherwise do not add anything. ¹) The real complication seems to be that there is neither a -fno-file nor a (let's say) -ffile=foo.c implemented anywhere. And TBH we do not need it nor want it for the purpose at hand. That suggests that it would probably be cheaper to run sed on the (remote) output file -- or do it locally and only then copy it to the remote. The net effect being that .file directives in the testsuite are gone and can no longer compromise tests. thanks,
