diff mbox series

[committed] Fix gnu23-builtins-no-dfp

Message ID 3dbc2b93-78fb-47b3-95a6-1efc76d78077@gmail.com
State Committed
Commit f37744662cbc74efcceb790b99dcd6521c51a578
Headers
Series [committed] Fix gnu23-builtins-no-dfp |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gcc_build--master-arm warning Patch is already merged
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 warning Patch is already merged

Commit Message

Jeff Law Dec. 3, 2023, 5:55 a.m. UTC 
  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.

Comments

Florian Weimer Dec. 3, 2023, 7:41 a.m. UTC | #1 
* 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).
Thomas Schwinge Dec. 3, 2023, 12:23 p.m. UTC | #2 
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
Jeff Law Dec. 3, 2023, 8:57 p.m. UTC | #3 
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 mbox series

Patch

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);