| Message ID | 3dbc2b93-78fb-47b3-95a6-1efc76d78077@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] Fix gnu23-builtins-no-dfp | expand |
* Jeff Law: > Anyway, this test was the one I was most concerned about. Basically > we're testing that on a !dfp target that the builtins are not available. > It expects a warning, but gets an error by default now. I just > changed the test to use -fpermissive, so that the test behaves as it did > previously. In these ambiguous cases, I cloned tests into -fpermissive and error variants. This might be appropriate here as well (or I should remove the clones again if those are the wrong thing to do).
Hi! On 2023-12-03T08:41:59+0100, Florian Weimer <fw@deneb.enyo.de> wrote: > * Jeff Law: > >> Anyway, this test was the one I was most concerned about. Basically >> we're testing that on a !dfp target that the builtins are not available. >> It expects a warning, but gets an error by default now. I just >> changed the test to use -fpermissive, so that the test behaves as it did >> previously. > > In these ambiguous cases, I cloned tests into -fpermissive and error > variants. This might be appropriate here as well (or I should remove > the clones again if those are the wrong thing to do). For that test case, it did seem appropriate to me to simply 's%dg-warning%dg-error', which I already had posted in <https://inbox.sourceware.org/87fs0luded.fsf@euler.schwinge.homeip.net> "c: Turn -Wimplicit-function-declaration into a permerror: Fix 'gcc.dg/gnu23-builtins-no-dfp-1.c'", awaiting review. Rationale: For this test case it's secondary *how* "implicit declaration of function" is diagnosed, so I'd test the standard way, which instead of "warning" now is "error". (But no strong feelings either way.) ;-) Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
On 12/3/23 05:23, Thomas Schwinge wrote: > Hi! > > On 2023-12-03T08:41:59+0100, Florian Weimer <fw@deneb.enyo.de> wrote: >> * Jeff Law: >> >>> Anyway, this test was the one I was most concerned about. Basically >>> we're testing that on a !dfp target that the builtins are not available. >>> It expects a warning, but gets an error by default now. I just >>> changed the test to use -fpermissive, so that the test behaves as it did >>> previously. >> >> In these ambiguous cases, I cloned tests into -fpermissive and error >> variants. This might be appropriate here as well (or I should remove >> the clones again if those are the wrong thing to do). > > For that test case, it did seem appropriate to me to simply > 's%dg-warning%dg-error', which I already had posted in > <https://inbox.sourceware.org/87fs0luded.fsf@euler.schwinge.homeip.net> > "c: Turn -Wimplicit-function-declaration into a permerror: Fix 'gcc.dg/gnu23-builtins-no-dfp-1.c'", > awaiting review. Rationale: For this test case it's secondary *how* > "implicit declaration of function" is diagnosed, so I'd test the standard > way, which instead of "warning" now is "error". (But no strong feelings > either way.) ;-) Sorry, I missed your fix. I like it better then mine. Approved, along with reverting my bits. jeff
diff --git a/gcc/testsuite/gcc.dg/gnu23-builtins-no-dfp-1.c b/gcc/testsuite/gcc.dg/gnu23-builtins-no-dfp-1.c index 9fa25f0dd13..8fe4efbdd98 100644 --- a/gcc/testsuite/gcc.dg/gnu23-builtins-no-dfp-1.c +++ b/gcc/testsuite/gcc.dg/gnu23-builtins-no-dfp-1.c @@ -1,7 +1,7 @@ /* Test C23 built-in functions: test DFP built-in functions are not available when no DFP support. Bug 91985. */ /* { dg-do compile { target { ! dfp } } } */ -/* { dg-options "-std=gnu23" } */ +/* { dg-options "-std=gnu23 -fpermissive" } */ int fabsd32 (void); int fabsd64 (void);
Last patch for the night. There's still a bit of minor fallout left in GCC (loongarch testsuite for example). But things are looking good on the targets I test. The plan is to start submitting the various newlib/libgloss fixes tomorrow. Anyway, this test was the one I was most concerned about. Basically we're testing that on a !dfp target that the builtins are not available. It expects a warning, but gets an error by default now. I just changed the test to use -fpermissive, so that the test behaves as it did previously. Pushed to the trunk. Jeff commit f37744662cbc74efcceb790b99dcd6521c51a578 Author: Jeff Law <jlaw@ventanamicro.com> Date: Sat Dec 2 22:54:46 2023 -0700 [committed] Fix gnu23-builtins-no-dfp Last patch for the night. There's still a bit of minor fallout left in GCC (loongarch testsuite for example). But things are looking good on the targets I test. The plan is to start submitting the various newlib/libgloss fixes tomorrow. Anyway, this test was the one I was most concerned about. Basically we're testing that on a !dfp target that the builtins are not available. It expects a warning, but gets an error by default now. I just changed the test to use -fpermissive, so that the test behaves as it did previously. Pushed to the trunk. gcc/testsuite * gcc.dg/gnu23-builtins-no-dfp-1.c: Add -fpermissive.