public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vineet Gupta <vineetg@rivosinc.com>
To: Thomas Schwinge <thomas.schwinge@siemens.com>,
	Kito Cheng <kito.cheng@gmail.com>,
	"Maciej W. Rozycki" <macro@embecosm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Andrew Waterman <andrew@sifive.com>,
	Kito Cheng <kito.cheng@sifive.com>,
	patrick@rivosinc.com, jlaw@ventanamicro.com,
	Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [PATCH] RISC-V/testsuite: Run target testing over all the usual optimization levels
Date: Thu, 25 May 2023 14:17:15 -0700	[thread overview]
Message-ID: <1bfe6de8-8510-4c30-7b2d-f22a599e750d@rivosinc.com> (raw)
In-Reply-To: <87edn4ruzi.fsf@dem-tschwing-1.ger.mentorg.com>

Hi Thomas,

On 5/25/23 13:56, Thomas Schwinge wrote:
> Hi!
>
> On 2022-02-08T00:22:37+0800, Kito Cheng via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>> Hi Maciej:
>>
>> Thanks for doing this, OK to trunk.
>>
>> On Tue, Feb 1, 2022 at 7:04 AM Maciej W. Rozycki <macro@embecosm.com> wrote:
>>> Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the
>>> RISC-V testsuite as several targets already do.  Adjust test options
>>> across individual test cases accordingly where required.
>>>
>>> As some tests want to be run at `-Og', add a suitable optimization
>>> variant via ADDITIONAL_TORTURE_OPTIONS, and include the moderately
>>> recent `-Oz' variant as well.
>>>
>>>          * testsuite/gcc.target/riscv/riscv.exp: Use `gcc-dg-runtest'
>>>          rather than `dg-runtest'.  Add `-Og -g' and `-Oz' variants via
>>>          ADDITIONAL_TORTURE_OPTIONS.
>>>   As to adding `-Og -g' and `-Oz', this should probably be done globally in
>>> gcc-dg.exp, but such a change would affect all the interested targets at
>>> once and would require a huge one-by-one test case review.  Therefore I
>>> think adding targets one by one instead is more feasible, and then we can
>>> switch once all the targets have.
>>> --- gcc.orig/gcc/testsuite/gcc.target/riscv/riscv.exp
>>> +++ gcc/gcc/testsuite/gcc.target/riscv/riscv.exp
>>> @@ -21,6 +21,8 @@ if ![istarget riscv*-*-*] then {
>>>     return
>>>   }
>>>
>>> +lappend ADDITIONAL_TORTURE_OPTIONS {-Og -g} {-Oz}
>>> +
>>>   # Load support procs.
>>>   load_lib gcc-dg.exp
> Per my understanding, that is not the correct way to do this.  See
> 'gcc/doc/sourcebuild.texi':
>
>      [...] add to the default list by defining
>      @var{ADDITIONAL_TORTURE_OPTIONS}.  Define these in a @file{.dejagnurc}
>      file or add them to the @file{site.exp} file; for example [...]
>
> Notice '.dejagnurc' or 'site.exp', that is: globally.  (Doing this
> "globally in gcc-dg.exp" -- as you'd mentioned above -- would work too,
> conditionalized to '[istarget riscv*-*-*]' only, for now, as you
> suggested.)
>
> Otherwise, per what we've not got, either of the following two happens:
> before any other 'load_lib gcc-dg.exp', 'gcc.target/riscv/riscv.exp'
> happens to be read first, does set 'ADDITIONAL_TORTURE_OPTIONS', then
> does its 'load_lib gcc-dg.exp' -- which then incorporates
> 'ADDITIONAL_TORTURE_OPTIONS' for *all* (!) following '*.exp' files as
> part of that 'runtest' instance.  Alternatively, any other '*.exp' file's
> 'load_lib gcc-dg.exp' comes first (without the desired
> 'ADDITIONAL_TORTURE_OPTIONS' being set), and once
> 'gcc.target/riscv/riscv.exp' is read, while it then does set
> 'ADDITIONAL_TORTURE_OPTIONS', its 'load_lib gcc-dg.exp' is a no-op, as
> that one has already been loaded, and therefore the
> 'ADDITIONAL_TORTURE_OPTIONS' aren't incorporated.
>
> Instead, I suggest to do this locally: do 'load_lib torture-options.exp',
> 'torture-init', 'set-torture-options [...]' (where that includes your
> special options), 'gcc-dg-runtest', 'torture-finish'.  See other '*.exp'
> files.
>
>
> (No, I didn't invent this interface.)
>
>
> (I however don't see yet how this would be related to the current
> "ERROR: torture-init: torture_without_loops is not empty as expected"
> discussion, as has, kind of, been claimed in
> <https://inbox.sourceware.org/d7e7dcfa-6ef7-959b-05d8-fb742f281554@rivosinc.com>
> "RISC-V: Add missing torture-init and torture-finish for rvv.exp" and the
> following.)

Thanks for taking a look at this. Please don't get me wrong, never mean 
to vilify the patches above - and I should have verified first (by 
reverting those) if they caused the issue - if at all. It just seemed 
that we started seeing these relatively recently and the timing of your 
changes seemed to coincide. As you say above, RV likely has existing 
less than ideal constructs which somehow used to work before, but not in 
the new regime.

Anyhow the goal is to get this fixed for RV and any more help will be 
appreciated since I'm really a TCL noob.

It seems my claim yesterday that adding torture-{init,finish} fixed RV 
issues were just premature. I was trying a mix of running the full suite 
vs. just  RUNTESTFLAGS="riscv.exp" and in some cases latter can give a 
false positive (I was making sure dejagnu got rebuilt and rekicked etc, 
but anyhow different issue).

I'm currently removing the ADDITIONAL_TORTURE_OPTIONS to see if this 
helps cure it and then try the new sequence you pointed to above.

FWIW if you want to test this out at your end, it is super easy.

|git clone https://github.com/riscv-collab/riscv-gnu-toolchain 
toolchain-upstream cd toolchain-upstream git submodule init git 
submodule update ||./configure --with-arch=rv64imafdc --with-abi=lp64d --enable-multilib 
--enable-linux --prefix=<path-to-install> make -j make report-linux 
SIM=qemu Thx, -Vineet |||


  reply	other threads:[~2023-05-25 21:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 23:04 Maciej W. Rozycki
2022-02-07 16:22 ` Kito Cheng
2022-02-08 12:24   ` Maciej W. Rozycki
2023-05-25 20:56   ` Thomas Schwinge
2023-05-25 21:17     ` Vineet Gupta [this message]
2023-05-25 21:20       ` Vineet Gupta
2023-05-26  0:06       ` Vineet Gupta

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=1bfe6de8-8510-4c30-7b2d-f22a599e750d@rivosinc.com \
    --to=vineetg@rivosinc.com \
    --cc=andrew@sifive.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jlaw@ventanamicro.com \
    --cc=kito.cheng@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=macro@embecosm.com \
    --cc=palmer@dabbelt.com \
    --cc=patrick@rivosinc.com \
    --cc=thomas.schwinge@siemens.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).