public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Paul Hua <paul.hua.gm@gmail.com>
Cc: "Martin Liška" <mliska@suse.cz>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Enhance dump_probability function.
Date: Wed, 14 Jun 2017 05:53:00 -0000	[thread overview]
Message-ID: <yddefun6rqt.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <CAKjxQH=iSB4=HdO0BP6O6C=c6m6XMQ7siuNNnuiE_2-v1Y6J_g@mail.gmail.com>	(Paul Hua's message of "Wed, 14 Jun 2017 10:02:11 +0800")

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

Hi Paul,

> New "ERROR: (DejaGnu)" on mips64el target.
>
> my DejaGnu version is 1.5.1.
>
> 1)
> make check-gcc RUNTESTFLAGS="tree-ssa.exp=builtin-sprintf-2.c"
> ...
> ERROR: (DejaGnu) proc "^:\\" does not exist.
> The error code is TCL LOOKUP COMMAND ^:\\
> The info on the error is:
> invalid command name "^:\"
>     while executing
> "::tcl_unknown ^:\\"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel 1 ::tcl_unknown $args"
> ...
>
> 2)
> make check-gcc RUNTESTFLAGS="tree-ssa.exp=vrp101.c"
> ...
> ERROR: (DejaGnu) proc "^:\\" does not exist.
> The error code is TCL LOOKUP COMMAND ^:\\
> The info on the error is:
> invalid command name "^:\"
>     while executing
> "::tcl_unknown ^:\\"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel 1 ::tcl_unknown $args"
> ...
>
> I don't known how to debug this, any advice ?

both revised scan-tree-dump patterns got the quoting wrong, leading to
attempts to run unknown procs ^\\: instead of matching [^:] ;-(

This totally broke make check-gcc: the affected partial test runs
aborted at that point, leading to gcc.{sum,log} files that make
contrib/dg-extract-results.py choke, producing empty combined
gcc.{sum,log} files.  No idea how this was tested (probably not at all).

The following patch fixes the syntax error


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ts.patch --]
[-- Type: text/x-patch, Size: 1658 bytes --]

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c
@@ -290,7 +290,7 @@ RNG (0,  6,   8, "%s%ls", "1", L"2");
 
 /*  Only conditional calls to must_not_eliminate must be made (with
     any probability):
-    { dg-final { scan-tree-dump-times "> \\\[\[0-9.\]+%\\\]\\ \\\[count:\\[^:\\]*\\\]:\n *must_not_eliminate" 127 "optimized" { target { ilp32 || lp64 } } } }
-    { dg-final { scan-tree-dump-times "> \\\[\[0-9.\]+%\\\]\\ \\\[count:\\[^:\\]*\\\]:\n *must_not_eliminate" 96 "optimized" { target { { ! ilp32 } && { ! lp64 } } } } }
+    { dg-final { scan-tree-dump-times "> \\\[\[0-9.\]+%\\\]\\ \\\[count:\\\[^:\\]*\\\]:\n *must_not_eliminate" 127 "optimized" { target { ilp32 || lp64 } } } }
+    { dg-final { scan-tree-dump-times "> \\\[\[0-9.\]+%\\\]\\ \\\[count:\\\[^:\\]*\\\]:\n *must_not_eliminate" 96 "optimized" { target { { ! ilp32 } && { ! lp64 } } } } }
     No unconditional calls to abort should be made:
     { dg-final { scan-tree-dump-not ";\n *must_not_eliminate" "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp101.c b/gcc/testsuite/gcc.dg/tree-ssa/vrp101.c
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp101.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp101.c
@@ -10,4 +10,4 @@ int main ()
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "<bb 2> \\\[\[0-9.\]+%\\\] \\\[count: \\[^:\\]*\\\]:\[\n\r \]*return 0;" "optimized" } } */
+/* { dg-final { scan-tree-dump "<bb 2> \\\[\[0-9.\]+%\\\] \\\[count: \\\[^:\\]*\\\]:\[\n\r \]*return 0;" "optimized" } } */

[-- Attachment #3: Type: text/plain, Size: 581 bytes --]


but both tests still come out as FAIL:

+FAIL: gcc.dg/tree-ssa/builtin-sprintf-2.c scan-tree-dump-times optimized "> \\\
\[[0-9.]+%\\\\]\\\\ \\\\[count:\\\\[^:\\\\]*\\\\]:\\n *must_not_eliminate" 127

+FAIL: gcc.dg/tree-ssa/vrp101.c scan-tree-dump optimized "<bb 2> \\\\[[0-9.]+%\\
\\] \\\\[count: \\\\[^:\\\\]*\\\\]:[\\n\\r ]*return 0;"

Martin should check what he really meant to match here and fix the
patterns accordingly.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

  reply	other threads:[~2017-06-14  5:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-13  8:15 Martin Liška
2017-06-14  2:02 ` Paul Hua
2017-06-14  5:53   ` Rainer Orth [this message]
2017-06-14  6:31     ` Jakub Jelinek
2017-06-14  7:14       ` Martin Liška
2017-06-14  7:18     ` Andreas Schwab
2017-06-16 11:38 ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yddefun6rqt.fsf@CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mliska@suse.cz \
    --cc=paul.hua.gm@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).