From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 6B0EA3858298 for ; Fri, 27 Oct 2023 17:42:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B0EA3858298 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6B0EA3858298 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698428574; cv=none; b=gr9vgYoJOf/RUjotoJE2Zqx2i/p+zRUD6K2Tr+Kw9m2Ow6n4Lt+G4ITvL1Tof5I7jk1U/xtImBHuuBGOSbRqeu/J2pMMhIos4a6R1ZLR91kyw7qjPIvVsHbicqBvIG/kL62QIn0nxBBPPNO23k85nj74+avC+uKAPO10iuuwYpM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698428574; c=relaxed/simple; bh=lh9dYc5EFMjc9ATxflHsJ8cW3UGgk3iGuxxTVQ9gDYI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Mx6WHTlmwdeXZpRKpbx69rUJc+QXy+EwRIiHxwOTrZ60KZP4UY/RbGvc1S0D2ktnFDmW2DY+K/rVob8LL2IHv0qIPfCknkXjD1ZYzDEpt9PAwQBDKsxiooErGM9sQYSdpk4f4nwqc5gslwjPbuKP+kpm7BtHI7KZXKTfUcgV0Y4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1cc2575dfc7so6188565ad.1 for ; Fri, 27 Oct 2023 10:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698428572; x=1699033372; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xYcTy+V8ZhAWxaPP7/MQvET7W84nAfVwqCPPels6IC8=; b=HueUdm+vq1q0tIAbc7EbN2v9zaKb30EMvtn4bou8qE9Fp9W+JUyn3R2yQQ4qTD4aKX x520SHhAdWm7ayDGDlLkOr19rWXwHnTd3RpufViG8VfND4MrOOfqslLgVOlvJj/TZLbR GW5EL8DuLa9GpCB3+6j48JWpGl0MNvgAHbOGOWt+pGQ2hOOVzj0nfbH5eYdepvAb5ysf 5OL95D/8q9tQABZ9ZOKXwPVYVZd12dOf2sjsOtUGSlAD0h3WnGE4Q3BdbRpgoJHWcVHf H+Xv/0XZK6IDC86kaj6pCO0IqCUh2DFUsBxq8fGf0itOfzbBB/rpbrZrvyV3C7X6xQh5 AGhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698428572; x=1699033372; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xYcTy+V8ZhAWxaPP7/MQvET7W84nAfVwqCPPels6IC8=; b=VisBZnhJtTwSzZzaoIt1WN0E9tR64kDL/i7f37Lx/SnoWKzNJAM264uspg0I9iAwmU 794U4PBWURrjGgp5crtGAuCgM+PES9n+cVvU00VjkrUYR1Y67ecs/RS8XmYnd1fob8PQ 1Im8NFRCW5c8DWXb8LKwejixPRrs+Y+TSTPNqML3j6Up2lknyIC07V/LrGmfx1UCx66D S+UPWxv4I+kJqXfvVFYUCtk1hq9wQHqX2kIeJ20A2UNOzjCIP4BHFt9qGgzFAQY4TMtI j4Egam2Vnzs6FzJ0Pcjyg89gmexJ0daCnKrKaVnaxjrMIYghy6hV9jUKmtJw5jmU92pX 6zMw== X-Gm-Message-State: AOJu0YxUojLXpL1jBYf5XcHa9E6a0zXdXfGL/HAJAstpB9l8plfTB1gh TskAiGGzBq4tAY7u18uTGnDokz+5rGk= X-Google-Smtp-Source: AGHT+IGRCRl0thvs2mDJreg6akqpR56XPVaE4rmG6iLBsehuHZ9MGc+IC6tMUUblOIJsqchnpaDONw== X-Received: by 2002:a17:902:eecc:b0:1c9:e508:ad43 with SMTP id h12-20020a170902eecc00b001c9e508ad43mr3243956plb.8.1698428572234; Fri, 27 Oct 2023 10:42:52 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id f1-20020a170902860100b001bf5e24b2a8sm1852327plo.174.2023.10.27.10.42.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Oct 2023 10:42:51 -0700 (PDT) Message-ID: <0cdd3832-22de-454a-afb4-2acae699cab0@gmail.com> Date: Fri, 27 Oct 2023 11:42:46 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [committed] RISC-V: Make stack_save_restore tests more robust Content-Language: en-US To: Patrick O'Neill , Jeff Law , "gcc-patches@gcc.gnu.org" References: <10382874-cea3-93d3-de15-bc3b7383cd61@ventanamicro.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/27/23 11:34, Patrick O'Neill wrote: > > On 8/25/23 15:36, Jeff Law wrote: >> Spurred by Jivan's patch and a desire for cleaner testresults, I went >> ahead and make the stack_save_restore tests independent of the precise >> stack size by using a regexp. >> >> Pushed to the trunk. >> >> Jeff > > Hi Jeff, A recent change that I'm still bisecting [1] caused > stack_save_restore_2.c to start failing. > > Debug log: > > Executing on host: /github/patrick-postcommit-runner-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc -B/github/patrick-postcommit-runner-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/ /github/patrick-postcommit-runner-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/stack_save_restore_2.c -march=rv32gcv -mabi=ilp32d -mcmodel=medlow -fdiagnostics-plain-output -O0 -march=rv32imafc -mabi=ilp32f -msave-restore -O2 -fno-schedule-insns -fno-schedule-insns2 -fno-unroll-loops -fno-peel-loops -fno-lto -S -o stack_save_restore_2.s (timeout = 600) > spawn -ignore SIGHUP /github/patrick-postcommit-runner-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc -B/github/patrick-postcommit-runner-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/ /github/patrick-postcommit-runner-1/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/stack_save_restore_2.c -march=rv32gcv -mabi=ilp32d -mcmodel=medlow -fdiagnostics-plain-output -O0 -march=rv32imafc -mabi=ilp32f -msave-restore -O2 -fno-schedule-insns -fno-schedule-insns2 -fno-unroll-loops -fno-peel-loops -fno-lto -S -o stack_save_restore_2.s > PASS: gcc.target/riscv/stack_save_restore_2.c -O0 (test for excess errors) > body: \tcall t0,__riscv_save_(3|4) > \taddi sp,sp,-[0-9]+ > .*\tli t0,-[0-9]+ > \tadd sp,sp,t0 > .*\tli t0,[0-9]+ > \tadd sp,sp,t0 > .*\taddi sp,sp,[0-9]+ > \ttail __riscv_restore_(3|4) > > against: call t0,__riscv_save_5 > addi sp,sp,-2016 > fsw fs0,2012(sp) > fsw fs1,2008(sp) > fsw fs2,2004(sp) > fsw fs3,2000(sp) > fsw fs4,1996(sp) > li t0,-12288 > add sp,sp,t0 > call getf > fmv.s fs1,fa0 > call getf > fmv.s fs4,fa0 > call getf > fmv.s fs3,fa0 > call getf > fmv.s fs2,fa0 > li s0,0 > fmv.s.x fs0,zero > lui a5,%hi(.LC0) > lw s2,%lo(.LC0)(a5) > lw s3,%lo(.LC0+4)(a5) > addi s4,sp,1984 > li s1,4096 > addi s1,s1,-528 > call my_getchar > call __floatsidf > mv a2,s2 > mv a3,s3 > call __muldf3 > call __truncdfsf2 > slli a5,s0,2 > add a5,s4,a5 > fsw fa0,-1984(a5) > flw fa5,-1984(a5) > fadd.s fs0,fs0,fa5 > addi s0,s0,1 > bne s0,s1,.L2 > fadd.s fa5,fs1,fs0 > fadd.s fa5,fa5,fs4 > fadd.s fa5,fa5,fs3 > fadd.s fa5,fa5,fs2 > fcvt.w.s a0,fa5,rtz > li t0,12288 > add sp,sp,t0 > flw fs0,2012(sp) > flw fs1,2008(sp) > flw fs2,2004(sp) > flw fs3,2000(sp) > flw fs4,1996(sp) > addi sp,sp,2016 > tail __riscv_restore_5 > > FAIL: gcc.target/riscv/stack_save_restore_2.c -O0 check-function-bodies bar > > It looks like the issue is that your regex matches > __riscv_save_(3|4) where now gcc emits __riscv_restore_5. > > Would it be OK to update the regex to also accept 5 (& are we going to > bump into this again)? Thanks for looking at this -- my tester flagged them yesterday as well and I hadn't dug into them yet: > Tests that now fail, but worked before (11 tests): > > gcc.target/riscv/rv32i_zcmp.c -Os check-function-bodies test1 > gcc.target/riscv/rv32i_zcmp.c -Os check-function-bodies test2_step1_0_size > gcc.target/riscv/rv32i_zcmp.c -Os check-function-bodies test3 > gcc.target/riscv/stack_save_restore_2.c -O0 check-function-bodies bar > gcc.target/riscv/stack_save_restore_2.c -O1 check-function-bodies bar > gcc.target/riscv/stack_save_restore_2.c -O2 check-function-bodies bar > gcc.target/riscv/stack_save_restore_2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none check-function-bodies bar > gcc.target/riscv/stack_save_restore_2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects check-function-bodies bar > gcc.target/riscv/stack_save_restore_2.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions check-function-bodies bar > gcc.target/riscv/stack_save_restore_2.c -O3 -g check-function-bodies bar > gcc.target/riscv/stack_save_restore_2.c -Os check-function-bodies bar Yes, I think accepting more cases here is quite reasonable. In fact, you might just change it to look for __riscv_save_ without the numeric suffix. jeff