Hi,
> 1. might I suggest using the {} form of quoting these regexes - it makes
> them much more readable.
Sure.
> 2. I think there are some syntax errors in the regexes for these tests
> (because it’s very hard to check them when using the “” quotes).
>
> "(?:movdqu|movups)\[ \\t\]+\[^\n\]*%xmm1,\[^\n\r]*16"
> ………………………………………………………^ missing \ (in several places)
Sorry, I will change them.
> 3. are you intending to update the tests?
Yes, so could you tell me what does missing “_” means? I have some
trouble building darwin target for now.
> ==== As for the comments on the asm output.
>
> 1) it would seem that both comments can’t be correct (since they contradict!)
> 2) AFAICT, None of the assemblers I use has any issue with either order
> 3) perhaps there’s no assembler in use that cares any more
> 4) clang produces symbol+offset for that case on Darwin (i.e. the same as
> final.c).
>
That means the i386.c part should align with final.c, but I can't make the
decision, and I'm not sure if there is more failure in x86 tests with this
change.
Iain Sandoe <i...@sandoe.co.uk> 于2020年11月4日周三 下午4:27写道：
>
> Hi,
>
> Hongyu Wang via Gcc <gcc@gcc.gnu.org> wrote:
>
> >> Maybe those scan-asm regexp are too strict and should be relaxed a
> >> bit.
> >
> > I agree with this, since with -fPIC the code produced would be different,
> > just use symbol + constant may be too strict.
> >
> > I think the scan-assembler could be reduced to
> > /* { dg-final { scan-assembler "(?:movdqu|movups)\[
> > \\t\]+\[^\n\]*%xmm1,\[^\n\r]*16" } } */
>
> 1. might I suggest using the {} form of quoting these regexes - it makes
> them much more readable.
>
> … e.g. more like this:
> {(?:movdqu|movups)[\t]+[^\n]*%xmm1,[^\n\r]*16}
>
> 2. I think there are some syntax errors in the regexes for these tests
> (because it’s very hard to check them when using the “” quotes).
>
> "(?:movdqu|movups)\[ \\t\]+\[^\n\]*%xmm1,\[^\n\r]*16"
> ………………………………………………………^ missing \ (in several places)
>
> 3. are you intending to update the tests?
>
>
> ==== As for the comments on the asm output.
>
> 1) it would seem that both comments can’t be correct (since they contradict!)
> 2) AFAICT, None of the assemblers I use has any issue with either order
> 3) perhaps there’s no assembler in use that cares any more
> 4) clang produces symbol+offset for that case on Darwin (i.e. the same as
> final.c).
>
> thanks
> Iain
>
--
Regards,
Hongyu, Wang
