Message ID | 20211129140050.82907-1-aldyh@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 496263857818 for <patchwork@sourceware.org>; Mon, 29 Nov 2021 14:02:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 496263857818 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1638194531; bh=Vomd/htT4uUXlFFBwItWQnMZuYxhFs6l1RU6bXrFkQM=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=PYVveH91zuzN4Hd/uKcpmWb/x0W6vcVtTT3TcT4cfWwupzuEdRu2CEdqlotAW/aZQ Qlm0uZLc4lDwqiKowqA1qpkMmIsAa6QKo9BPP9TEON3Y7camcAcd7flK/ksNc0zIoG 6Be/5su/obVeKMnxNEVQyA+zlPNucNSViNBCTVtc= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 29358385C403 for <gcc-patches@gcc.gnu.org>; Mon, 29 Nov 2021 14:01:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29358385C403 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-290-V22f6Z_7NMegSOP4NAJbCA-1; Mon, 29 Nov 2021 09:01:16 -0500 X-MC-Unique: V22f6Z_7NMegSOP4NAJbCA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A7F6F100CE8F; Mon, 29 Nov 2021 14:01:15 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.193.111]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AA565F4E1; Mon, 29 Nov 2021 14:01:00 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.16.1/8.15.2) with ESMTPS id 1ATE0vgx083113 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 29 Nov 2021 15:00:57 +0100 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.16.1/8.16.1/Submit) id 1ATE0uct083112; Mon, 29 Nov 2021 15:00:56 +0100 To: Richard Biener <richard.guenther@gmail.com> Subject: [PATCH] Remove can_throw_non_call_exceptions special case from operator_div::wi_fold. Date: Mon, 29 Nov 2021 15:00:50 +0100 Message-Id: <20211129140050.82907-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Aldy Hernandez <aldyh@redhat.com> Cc: GCC patches <gcc-patches@gcc.gnu.org> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
Remove can_throw_non_call_exceptions special case from operator_div::wi_fold.
|
|
Commit Message
Aldy Hernandez
Nov. 29, 2021, 2 p.m. UTC
As discussed in the PR. The code makes no difference, so whatever test we added this special case for has been fixed or is being papered over. I think we should fix any fall out upstream. [Unless Andrew can remember why we added this and it still applies.] Tested on x86-64 Linux. OK for trunk? PR 103451 gcc/ChangeLog: * range-op.cc (operator_div::wi_fold): Remove can_throw_non_call_exceptions special case. gcc/testsuite/ChangeLog: * gcc.dg/pr103451.c: New test. --- gcc/range-op.cc | 7 ------- gcc/testsuite/gcc.dg/pr103451.c | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 7 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/pr103451.c
Comments
On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > As discussed in the PR. The code makes no difference, so whatever test > we added this special case for has been fixed or is being papered over. > I think we should fix any fall out upstream. > > [Unless Andrew can remember why we added this and it still applies.] > > Tested on x86-64 Linux. > > OK for trunk? > > PR 103451 > > gcc/ChangeLog: > > * range-op.cc (operator_div::wi_fold): Remove > can_throw_non_call_exceptions special case. > > gcc/testsuite/ChangeLog: > > * gcc.dg/pr103451.c: New test. I'll defer to Andrew, but it seems wrong to me. The whole point is to set the result to varying so that we don't know the result and never remove the division which is critical for -fnon-call-exceptions. > --- > gcc/range-op.cc | 7 ------- > gcc/testsuite/gcc.dg/pr103451.c | 17 +++++++++++++++++ > 2 files changed, 17 insertions(+), 7 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/pr103451.c > > diff --git a/gcc/range-op.cc b/gcc/range-op.cc > index bbf2924f815..6fe5f1cb4e0 100644 > --- a/gcc/range-op.cc > +++ b/gcc/range-op.cc > @@ -1832,13 +1832,6 @@ operator_div::wi_fold (irange &r, tree type, > return; > } > > - // If flag_non_call_exceptions, we must not eliminate a division by zero. > - if (cfun->can_throw_non_call_exceptions) > - { > - r.set_varying (type); > - return; > - } > - > // If we're definitely dividing by zero, there's nothing to do. > if (wi_zero_p (type, divisor_min, divisor_max)) > { > diff --git a/gcc/testsuite/gcc.dg/pr103451.c b/gcc/testsuite/gcc.dg/pr103451.c > new file mode 100644 > index 00000000000..b83646d0b83 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/pr103451.c > @@ -0,0 +1,17 @@ > +// { dg-do compile } > +// { dg-options "-O2 -w" } ISTM that what you want to test for is that the division by zero remains in the IL for -fnon-call-exceptions. jeff
On Mon, Nov 29, 2021 at 3:39 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > > As discussed in the PR. The code makes no difference, so whatever test > > we added this special case for has been fixed or is being papered over. > > I think we should fix any fall out upstream. > > > > [Unless Andrew can remember why we added this and it still applies.] > > > > Tested on x86-64 Linux. > > > > OK for trunk? > > > > PR 103451 > > > > gcc/ChangeLog: > > > > * range-op.cc (operator_div::wi_fold): Remove > > can_throw_non_call_exceptions special case. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/pr103451.c: New test. > I'll defer to Andrew, but it seems wrong to me. The whole point is to > set the result to varying so that we don't know the result and never > remove the division which is critical for -fnon-call-exceptions. But that has nothing to do with computing the value range for the result which is only accessible when the stmt does _not_ throw ... That is, if we compute non-VARYING here and because of that remove the stmt then _that's_ the place to fix (IMO) > > > --- > > gcc/range-op.cc | 7 ------- > > gcc/testsuite/gcc.dg/pr103451.c | 17 +++++++++++++++++ > > 2 files changed, 17 insertions(+), 7 deletions(-) > > create mode 100644 gcc/testsuite/gcc.dg/pr103451.c > > > > diff --git a/gcc/range-op.cc b/gcc/range-op.cc > > index bbf2924f815..6fe5f1cb4e0 100644 > > --- a/gcc/range-op.cc > > +++ b/gcc/range-op.cc > > @@ -1832,13 +1832,6 @@ operator_div::wi_fold (irange &r, tree type, > > return; > > } > > > > - // If flag_non_call_exceptions, we must not eliminate a division by zero. > > - if (cfun->can_throw_non_call_exceptions) > > - { > > - r.set_varying (type); > > - return; > > - } > > - > > // If we're definitely dividing by zero, there's nothing to do. > > if (wi_zero_p (type, divisor_min, divisor_max)) > > { > > diff --git a/gcc/testsuite/gcc.dg/pr103451.c b/gcc/testsuite/gcc.dg/pr103451.c > > new file mode 100644 > > index 00000000000..b83646d0b83 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.dg/pr103451.c > > @@ -0,0 +1,17 @@ > > +// { dg-do compile } > > +// { dg-options "-O2 -w" } > ISTM that what you want to test for is that the division by zero remains > in the IL for -fnon-call-exceptions. > > jeff >
On Mon, Nov 29, 2021 at 3:48 PM Richard Biener <richard.guenther@gmail.com> wrote: > > On Mon, Nov 29, 2021 at 3:39 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > > > As discussed in the PR. The code makes no difference, so whatever test > > > we added this special case for has been fixed or is being papered over. > > > I think we should fix any fall out upstream. > > > > > > [Unless Andrew can remember why we added this and it still applies.] > > > > > > Tested on x86-64 Linux. > > > > > > OK for trunk? > > > > > > PR 103451 > > > > > > gcc/ChangeLog: > > > > > > * range-op.cc (operator_div::wi_fold): Remove > > > can_throw_non_call_exceptions special case. > > > > > > gcc/testsuite/ChangeLog: > > > > > > * gcc.dg/pr103451.c: New test. > > I'll defer to Andrew, but it seems wrong to me. The whole point is to > > set the result to varying so that we don't know the result and never > > remove the division which is critical for -fnon-call-exceptions. > > But that has nothing to do with computing the value range for > the result which is only accessible when the stmt does _not_ throw ... > > That is, if we compute non-VARYING here and because of that > remove the stmt then _that's_ the place to fix (IMO) Ughh, I think you're both right. We should fix this upstream AND we should test for the presence of the division by 0 in the optimized dump. Of course doing both opens a can of worms. The division by zero can be cleaned up by (at least) DCE, DSE, and the code sinking passes. I've fixed all 3 in the attached (untested) patch. Dunno what y'all want to do at this point. Aldy
On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > On Mon, Nov 29, 2021 at 3:48 PM Richard Biener > <richard.guenther@gmail.com> wrote: > > > > On Mon, Nov 29, 2021 at 3:39 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > > > > > On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > > > > As discussed in the PR. The code makes no difference, so whatever test > > > > we added this special case for has been fixed or is being papered over. > > > > I think we should fix any fall out upstream. > > > > > > > > [Unless Andrew can remember why we added this and it still applies.] > > > > > > > > Tested on x86-64 Linux. > > > > > > > > OK for trunk? > > > > > > > > PR 103451 > > > > > > > > gcc/ChangeLog: > > > > > > > > * range-op.cc (operator_div::wi_fold): Remove > > > > can_throw_non_call_exceptions special case. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > * gcc.dg/pr103451.c: New test. > > > I'll defer to Andrew, but it seems wrong to me. The whole point is to > > > set the result to varying so that we don't know the result and never > > > remove the division which is critical for -fnon-call-exceptions. > > > > But that has nothing to do with computing the value range for > > the result which is only accessible when the stmt does _not_ throw ... > > > > That is, if we compute non-VARYING here and because of that > > remove the stmt then _that's_ the place to fix (IMO) > > Ughh, I think you're both right. > > We should fix this upstream AND we should test for the presence of the > division by 0 in the optimized dump. > > Of course doing both opens a can of worms. The division by zero can > be cleaned up by (at least) DCE, DSE, and the code sinking passes. > I've fixed all 3 in the attached (untested) patch. Dunno what y'all > want to do at this point. I think you need to add -fno-delete-dead-exceptions to the testcase. The sinking bug looks real, but just && (cfun->can_delete_dead_exceptions || !stmt_could_throw_p (cfun, stmt)) is needed there. That change is OK. Thanks, Richard. > > Aldy
On Tue, Nov 30, 2021 at 8:37 AM Richard Biener <richard.guenther@gmail.com> wrote: > > On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > On Mon, Nov 29, 2021 at 3:48 PM Richard Biener > > <richard.guenther@gmail.com> wrote: > > > > > > On Mon, Nov 29, 2021 at 3:39 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > > > > > > > > > On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > > > > > As discussed in the PR. The code makes no difference, so whatever test > > > > > we added this special case for has been fixed or is being papered over. > > > > > I think we should fix any fall out upstream. > > > > > > > > > > [Unless Andrew can remember why we added this and it still applies.] > > > > > > > > > > Tested on x86-64 Linux. > > > > > > > > > > OK for trunk? > > > > > > > > > > PR 103451 > > > > > > > > > > gcc/ChangeLog: > > > > > > > > > > * range-op.cc (operator_div::wi_fold): Remove > > > > > can_throw_non_call_exceptions special case. > > > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > * gcc.dg/pr103451.c: New test. > > > > I'll defer to Andrew, but it seems wrong to me. The whole point is to > > > > set the result to varying so that we don't know the result and never > > > > remove the division which is critical for -fnon-call-exceptions. > > > > > > But that has nothing to do with computing the value range for > > > the result which is only accessible when the stmt does _not_ throw ... > > > > > > That is, if we compute non-VARYING here and because of that > > > remove the stmt then _that's_ the place to fix (IMO) > > > > Ughh, I think you're both right. > > > > We should fix this upstream AND we should test for the presence of the > > division by 0 in the optimized dump. > > > > Of course doing both opens a can of worms. The division by zero can > > be cleaned up by (at least) DCE, DSE, and the code sinking passes. > > I've fixed all 3 in the attached (untested) patch. Dunno what y'all > > want to do at this point. > > I think you need to add -fno-delete-dead-exceptions to the testcase. > The sinking > bug looks real, but just > > && (cfun->can_delete_dead_exceptions > || !stmt_could_throw_p (cfun, stmt)) > > is needed there. That change is OK. Did you mean the entire patch (as attached) is OK, or just the sink part? Thanks. Aldy
On Tue, Nov 30, 2021 at 9:51 AM Aldy Hernandez <aldyh@redhat.com> wrote: > > On Tue, Nov 30, 2021 at 8:37 AM Richard Biener > <richard.guenther@gmail.com> wrote: > > > > On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > > > On Mon, Nov 29, 2021 at 3:48 PM Richard Biener > > > <richard.guenther@gmail.com> wrote: > > > > > > > > On Mon, Nov 29, 2021 at 3:39 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > > > > > > As discussed in the PR. The code makes no difference, so whatever test > > > > > > we added this special case for has been fixed or is being papered over. > > > > > > I think we should fix any fall out upstream. > > > > > > > > > > > > [Unless Andrew can remember why we added this and it still applies.] > > > > > > > > > > > > Tested on x86-64 Linux. > > > > > > > > > > > > OK for trunk? > > > > > > > > > > > > PR 103451 > > > > > > > > > > > > gcc/ChangeLog: > > > > > > > > > > > > * range-op.cc (operator_div::wi_fold): Remove > > > > > > can_throw_non_call_exceptions special case. > > > > > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > > > * gcc.dg/pr103451.c: New test. > > > > > I'll defer to Andrew, but it seems wrong to me. The whole point is to > > > > > set the result to varying so that we don't know the result and never > > > > > remove the division which is critical for -fnon-call-exceptions. > > > > > > > > But that has nothing to do with computing the value range for > > > > the result which is only accessible when the stmt does _not_ throw ... > > > > > > > > That is, if we compute non-VARYING here and because of that > > > > remove the stmt then _that's_ the place to fix (IMO) > > > > > > Ughh, I think you're both right. > > > > > > We should fix this upstream AND we should test for the presence of the > > > division by 0 in the optimized dump. > > > > > > Of course doing both opens a can of worms. The division by zero can > > > be cleaned up by (at least) DCE, DSE, and the code sinking passes. > > > I've fixed all 3 in the attached (untested) patch. Dunno what y'all > > > want to do at this point. > > > > I think you need to add -fno-delete-dead-exceptions to the testcase. > > The sinking > > bug looks real, but just > > > > && (cfun->can_delete_dead_exceptions > > || !stmt_could_throw_p (cfun, stmt)) > > > > is needed there. That change is OK. > > Did you mean the entire patch (as attached) is OK, or just the sink part? The DCE and DSE parts are wrong and not needed. The remaining pieces are OK. Thanks, Richard. > Thanks. > Aldy
Will adjust, re-test and commit. Thanks. Aldy On Tue, Nov 30, 2021 at 10:00 AM Richard Biener <richard.guenther@gmail.com> wrote: > > On Tue, Nov 30, 2021 at 9:51 AM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > On Tue, Nov 30, 2021 at 8:37 AM Richard Biener > > <richard.guenther@gmail.com> wrote: > > > > > > On Mon, Nov 29, 2021 at 4:24 PM Aldy Hernandez <aldyh@redhat.com> wrote: > > > > > > > > On Mon, Nov 29, 2021 at 3:48 PM Richard Biener > > > > <richard.guenther@gmail.com> wrote: > > > > > > > > > > On Mon, Nov 29, 2021 at 3:39 PM Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 11/29/2021 7:00 AM, Aldy Hernandez via Gcc-patches wrote: > > > > > > > As discussed in the PR. The code makes no difference, so whatever test > > > > > > > we added this special case for has been fixed or is being papered over. > > > > > > > I think we should fix any fall out upstream. > > > > > > > > > > > > > > [Unless Andrew can remember why we added this and it still applies.] > > > > > > > > > > > > > > Tested on x86-64 Linux. > > > > > > > > > > > > > > OK for trunk? > > > > > > > > > > > > > > PR 103451 > > > > > > > > > > > > > > gcc/ChangeLog: > > > > > > > > > > > > > > * range-op.cc (operator_div::wi_fold): Remove > > > > > > > can_throw_non_call_exceptions special case. > > > > > > > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > > > > > * gcc.dg/pr103451.c: New test. > > > > > > I'll defer to Andrew, but it seems wrong to me. The whole point is to > > > > > > set the result to varying so that we don't know the result and never > > > > > > remove the division which is critical for -fnon-call-exceptions. > > > > > > > > > > But that has nothing to do with computing the value range for > > > > > the result which is only accessible when the stmt does _not_ throw ... > > > > > > > > > > That is, if we compute non-VARYING here and because of that > > > > > remove the stmt then _that's_ the place to fix (IMO) > > > > > > > > Ughh, I think you're both right. > > > > > > > > We should fix this upstream AND we should test for the presence of the > > > > division by 0 in the optimized dump. > > > > > > > > Of course doing both opens a can of worms. The division by zero can > > > > be cleaned up by (at least) DCE, DSE, and the code sinking passes. > > > > I've fixed all 3 in the attached (untested) patch. Dunno what y'all > > > > want to do at this point. > > > > > > I think you need to add -fno-delete-dead-exceptions to the testcase. > > > The sinking > > > bug looks real, but just > > > > > > && (cfun->can_delete_dead_exceptions > > > || !stmt_could_throw_p (cfun, stmt)) > > > > > > is needed there. That change is OK. > > > > Did you mean the entire patch (as attached) is OK, or just the sink part? > > The DCE and DSE parts are wrong and not needed. The remaining pieces > are OK. > > Thanks, > Richard. > > > Thanks. > > Aldy >
diff --git a/gcc/range-op.cc b/gcc/range-op.cc index bbf2924f815..6fe5f1cb4e0 100644 --- a/gcc/range-op.cc +++ b/gcc/range-op.cc @@ -1832,13 +1832,6 @@ operator_div::wi_fold (irange &r, tree type, return; } - // If flag_non_call_exceptions, we must not eliminate a division by zero. - if (cfun->can_throw_non_call_exceptions) - { - r.set_varying (type); - return; - } - // If we're definitely dividing by zero, there's nothing to do. if (wi_zero_p (type, divisor_min, divisor_max)) { diff --git a/gcc/testsuite/gcc.dg/pr103451.c b/gcc/testsuite/gcc.dg/pr103451.c new file mode 100644 index 00000000000..b83646d0b83 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr103451.c @@ -0,0 +1,17 @@ +// { dg-do compile } +// { dg-options "-O2 -w" } + +int func_10_ptr_12; + +void func_10(long li_8) +{ + long *ptr_9 = &li_8; + li_8 &= *ptr_9 / 0 ?: li_8; + for (;;) + func_10_ptr_12 &= 4 ? *ptr_9 : 4; +} + +void func_9_s_8() +{ + func_10(func_9_s_8); +}