From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 96B3D38618A2; Wed, 28 Jul 2021 04:36:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 96B3D38618A2 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 6Y4LCRbZ6BIYoB4VyfqBJkl9g+j+K57C08L7sTZ/LtIKFWCqt8z2u0tIQgtOFtgVFSawU03Vmy CZNQ2SL9TriaXjP7JlRT0Yqukd2Bq3oATen58aw+se6HuTLIn7pga0jWnd7vieZY4JaVYfl5ZA DVoTXAW+zvjtr6V/DxnfI+/XzDW2xOvYViRV4h1XDJsGvykQqSsCD8FDWgWyazuiVi8iI80Qq+ xxKlqch3/YkHydZmumrBkInkWCMs8muAdCUhY7geokL9xSthPqtndQDjTK9Slxz/b+Ygzy4vst qIMImzPnbs8TPIaJ7ryPXRNo X-IronPort-AV: E=Sophos;i="5.84,275,1620720000"; d="scan'208";a="64168598" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 27 Jul 2021 20:36:14 -0800 IronPort-SDR: 9G91vCYp0IVd1bc0HZw3qsmuKg+wzWZdKy6PiBtdQ2Fm9UamBJuOze9M6XoEAKs/LOyEDBWNzf Ehm60cOhtbHThJIJZuyzGur/t6l6OGH/7t3SGGrtUCFeCHA+NIiFZ1RAV1eFaBTX3/4Cf3NApa uDcF0SlUPwWD+BEGaXgB97rVYLHTPY8039L13RoQoT+xZQcsv6Eo+pmqX1zqv+s9T6F0vbQc5x dj4Zmhd2c7a+fvZxTRwb3ND6GYjmXDpr//JfiERUrOMpUq6hCfxVfk+FOFoqOY76ScJOuxywmP Ois= Subject: Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite From: Sandra Loosemore To: Tobias Burnus , , References: <20210713212859.1532449-1-sandra@codesourcery.com> <20210713212859.1532449-4-sandra@codesourcery.com> <09689f06-0ef6-b669-1de8-a064ff0f4b5e@codesourcery.com> <1d543137-1b00-ef37-c131-341b4ac57765@codesourcery.com> <72f86537-70c3-60d7-0ea5-9746f0524492@codesourcery.com> Message-ID: <382f4838-bc85-8986-21ca-3cee5b5905df@codesourcery.com> Date: Tue, 27 Jul 2021 22:36:07 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <72f86537-70c3-60d7-0ea5-9746f0524492@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 04:36:18 -0000 On 7/26/21 2:13 PM, Sandra Loosemore wrote: > On 7/26/21 3:45 AM, Tobias Burnus wrote: >> >> [snip] >> >> PS: Still, it would be nice if the proper multi-lib ISO*.h could be >> found; >> while it usually does not matter, it could do so in some cases. > > I think I ought to fix this now instead of just sweeping it under the > rug.  The suggestion you made previously to add > >> # Flags for finding libgfortran ISO*.h files. >> if [info exists TOOL_OPTIONS] { >>    set specpath [get_multilibs ${TOOL_OPTIONS}] >> } else { >>    set specpath [get_multilibs] >> } >> set options "-I $specpath/libgfortran/" > > to the .exp files looks consistent with what I see elsewhere for adding > things to the include path, so I will give it a try and see how it works. Unfortunately, I could not get this to work. For installed-tree testing, this resulted in diagnostics about a nonexistent directory on the include path. In my i686-pc-linux-gnu build I was having other problems when I tried build-tree testing using make check-gfortran RUNTESTFLAGS="--target-board=localhost/m64" or similar variants of --target-board (it seemed to be ignoring all the xfails?) so I did not think that could be the way people who normally test in the build tree can be doing it. And when I tried a recipe like make check-gfortran RUNTESTFLAGS="ts29113.exp --tool_opts='-m64'" it found the ISO_Fortran_binding.h via the correct /64-specific path via a -B option, same as for installed-tree testing. Since the patch was already approved without additional hacks to include file paths, I went ahead and pushed it as-is. If somebody can provide me with an exact recipe for reproducing failures to find the include file, I'll take another stab at it, but TBH this is far from my area of expertise. :-( BTW, I can't find any documentation for what get_multilibs is supposed to do. It seems to be part of Dejagnu itself rather than the gcc test support? -Sandra