introduce target tmpnam and require it in tests relying on it

Martin Sebor msebor@gmail.com
Thu Apr 23 17:19:28 GMT 2020


On 4/23/20 2:21 AM, Alexandre Oliva wrote:
> On Apr 21, 2020, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> 
>> On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>>> On 4/17/20 11:48 AM, Alexandre Oliva wrote:
>>>> On Apr  9, 2020, Alexandre Oliva <oliva@adacore.com> wrote:
>>>>
>>>>> Some target C libraries that aren't recognized as freestanding don't
>>>>> have filesystem support, so calling tmpnam, fopen/open and
>>>>> remove/unlink fails to link.
>>>>
>>>>> This patch introduces a tmpnam effective target to the testsuite,
>>> and
>>>>> requires it in the tests that call tmpnam.
> 
>>>>> for  gcc/testsuite/ChangeLog
>>>>
>>>>> * lib/target-supports.exp (check_effective_target_tmpnam): New.
>>>>> * gcc.c-torture/execute/fprintf-2.c: Require it.
>>>>> * gcc.c-torture/execute/printf-2.c: Likewise.
>>>>> * gcc.c-torture/execute/user-printf.c: Likewise.
>>>>
>>>> Ping?
>>>>
>>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543672.html
>>>
>>> I'm okay with the changes to the tests.
>>>
>>> The target-supports.exp changes look reasonable to me as well but
>>> I can't approve them.  Since you said it's for targets that don't
>>> have file I/O functions I wonder if the name would better reflect
>>> that if it were called, say, check_effective_target_fileio?
> 
>> If you want a fileio predicate then please do not keys it off obsolescent functions.
> 
> I'd actually considered adding two expect/dejagnu procs, one for fileio,
> one for tmpnam, possibly with the latter depending on the former, but
> decided to take the simpler path on the grounds that all tests that
> would have depended on fileio would also depend on tmpnam.
> 
> Plus, it did seem to make sense to test for tmpnam, since it probably
> won't be found on freestanding environments (the affected tests require
> non-freestanding effective target, but that translate to requiring I/O
> support), and tmpnam might be removed from standards in the future.  We
> might want to catch that, rather than silently skip the test, though.
> 
> I'd be glad to add an intermediate fileio effective target, or rename
> the proposed one and drop tmpnam from it, if there's agreement such a
> separate effective target would be more useful.
> 
> 
> So, should I rename _tmpnam to _fileio and drop tmpnam() from the code
> snippet in the effective target test?  Or should I keep _tmpnam and
> introduce _fileio?  With or without a dependency of _tmpnam on _fileio?
> 
> Since Jeff Law approved the patch as is, would you guys mind if I make
> any further changes as separate, followup patches?

Sure.  I'd go with _fileio but that's just a suggestion.  I don't
think there are enough uses of tmpnam in the test suite or risk
that it will disappear anytime soon to justify its own target test
or removing its uses, but I'm not opposed to it either.

Martin


More information about the Gcc-patches mailing list