Message ID | bbef44d3-fc72-ca13-d29c-2635e8b9d7b1@linux.ibm.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 BCF75385B183 for <patchwork@sourceware.org>; Wed, 30 Nov 2022 08:31:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCF75385B183 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669797093; bh=7zgJt9lw1oGDIjo9EyKLtQLtCVs7J/q1gX5c+AComjo=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=D/GPeru1RRDVLFJfmH5tzst2pPevzxCV+oMoc+5pwB+IwScIqN7xucBhbBSBvMFL2 t0vex7GIJ1UGMPNf9cFIBz0F+rpeWqdfrhzNY42qGxhttkItg5AusR2jaQfTMPlzex ucr7FJTq0qr5zqDmQx9ejhDSBaPbRaj/jjJbR4sk= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 7D18C3857BB3 for <gcc-patches@gcc.gnu.org>; Wed, 30 Nov 2022 08:30:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D18C3857BB3 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AU5lmxw020609; Wed, 30 Nov 2022 08:30:54 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m61bfkgn3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Nov 2022 08:30:53 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2AU7x3K6031411; Wed, 30 Nov 2022 08:30:53 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m61bfkgks-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Nov 2022 08:30:52 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2AU8KCga018256; Wed, 30 Nov 2022 08:30:50 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma06ams.nl.ibm.com with ESMTP id 3m3a2hwft7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Nov 2022 08:30:50 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2AU8Um4j4719242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Nov 2022 08:30:48 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 17C4BAE051; Wed, 30 Nov 2022 08:30:48 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9B8CEAE045; Wed, 30 Nov 2022 08:30:45 +0000 (GMT) Received: from [9.197.238.163] (unknown [9.197.238.163]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 30 Nov 2022 08:30:45 +0000 (GMT) Message-ID: <bbef44d3-fc72-ca13-d29c-2635e8b9d7b1@linux.ibm.com> Date: Wed, 30 Nov 2022 16:30:44 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: GCC Patches <gcc-patches@gcc.gnu.org> Cc: Jan Hubicka <hubicka@ucw.cz>, Richard Biener <richard.guenther@gmail.com>, Richard Sandiford <richard.sandiford@arm.com>, Segher Boessenkool <segher@kernel.crashing.org>, Peter Bergner <bergner@linux.ibm.com> Subject: [PATCH v2] predict: Adjust optimize_function_for_size_p [PR105818] Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 23kXA9QapnMjPM8SCg9IaJB5osj8jWwv X-Proofpoint-GUID: S0FBQbMlC20rCKWbk9cTdUkWEx31HjAP Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-30_04,2022-11-29_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 mlxlogscore=890 phishscore=0 malwarescore=0 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211300061 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: "Kewen.Lin via Gcc-patches" <gcc-patches@gcc.gnu.org> Reply-To: "Kewen.Lin" <linkw@linux.ibm.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
[v2] predict: Adjust optimize_function_for_size_p [PR105818]
|
|
Commit Message
Kewen.Lin
Nov. 30, 2022, 8:30 a.m. UTC
Hi, Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO if fun->decl is not null but no cgraph node is available for it. As PR105818 shows, this could cause unexpected consequence. For the case in PR105818, when parsing bar decl in function foo, the cfun is the function structure for foo, for which there is no cgraph node, so it returns OPTIMIZE_SIZE_NO. But it's incorrect since the context is to optimize for size, the flag optimize_size is true. The patch is to make optimize_function_for_size_p to check opt_for_fn (fun->decl, optimize_size) further when fun->decl is available but no cgraph node, it's just like what function cgraph_node::optimize_for_size_p does at its first step. One regression failure got exposed on aarch64-linux-gnu: PASS->FAIL: gcc.dg/guality/pr54693-2.c -Os \ -DPREVENT_OPTIMIZATION line 21 x == 10 - i The difference comes from the macro LOGICAL_OP_NON_SHORT_CIRCUIT used in function fold_range_test during c parsing, it uses optimize_function_for_speed_p which is equal to the invertion of optimize_function_for_size_p. At that time cfun->decl is valid but no cgraph node for it, w/o this patch function optimize_function_for_speed_p returns true eventually, while it returns false with this patch. Since the command line option -Os is specified, there is no reason to interpret it as "for speed". I think this failure is expected and adjust the test case accordingly. v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596628.html Comparing with v1, v2 adopts opt_for_fn (fun->decl, optimize_size) instead of optimize_size as Honza's previous comments. Besides, the reply to Honza's question "Why exactly PR105818 hits the flag change issue?" was at the link: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596667.html Bootstrapped and regtested on x86_64-redhat-linux, aarch64-linux-gnu and powerpc64{,le}-linux-gnu. Is it for trunk? BR, Kewen ----- PR middle-end/105818 gcc/ChangeLog: * predict.cc (optimize_function_for_size_p): Further check optimize_size of fun->decl when it is valid but no cgraph node. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr105818.c: New test. * gcc.dg/guality/pr54693-2.c: Adjust for aarch64. --- gcc/predict.cc | 3 ++- gcc/testsuite/gcc.dg/guality/pr54693-2.c | 2 +- gcc/testsuite/gcc.target/powerpc/pr105818.c | 11 +++++++++++ 3 files changed, 14 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/pr105818.c -- 2.27.0
Comments
Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607527.html BR, Kewen on 2022/11/30 16:30, Kewen.Lin via Gcc-patches wrote: > Hi, > > Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO > if fun->decl is not null but no cgraph node is available for it. > As PR105818 shows, this could cause unexpected consequence. For > the case in PR105818, when parsing bar decl in function foo, the > cfun is the function structure for foo, for which there is no > cgraph node, so it returns OPTIMIZE_SIZE_NO. But it's incorrect > since the context is to optimize for size, the flag optimize_size > is true. > > The patch is to make optimize_function_for_size_p to check > opt_for_fn (fun->decl, optimize_size) further when fun->decl > is available but no cgraph node, it's just like what function > cgraph_node::optimize_for_size_p does at its first step. > > One regression failure got exposed on aarch64-linux-gnu: > > PASS->FAIL: gcc.dg/guality/pr54693-2.c -Os \ > -DPREVENT_OPTIMIZATION line 21 x == 10 - i > > The difference comes from the macro LOGICAL_OP_NON_SHORT_CIRCUIT > used in function fold_range_test during c parsing, it uses > optimize_function_for_speed_p which is equal to the invertion > of optimize_function_for_size_p. At that time cfun->decl is valid > but no cgraph node for it, w/o this patch function > optimize_function_for_speed_p returns true eventually, while it > returns false with this patch. Since the command line option -Os > is specified, there is no reason to interpret it as "for speed". > I think this failure is expected and adjust the test case > accordingly. > > v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596628.html > > Comparing with v1, v2 adopts opt_for_fn (fun->decl, optimize_size) > instead of optimize_size as Honza's previous comments. > > Besides, the reply to Honza's question "Why exactly PR105818 hits > the flag change issue?" was at the link: > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596667.html > > Bootstrapped and regtested on x86_64-redhat-linux, > aarch64-linux-gnu and powerpc64{,le}-linux-gnu. > > Is it for trunk? > > BR, > Kewen > ----- > PR middle-end/105818 > > gcc/ChangeLog: > > * predict.cc (optimize_function_for_size_p): Further check > optimize_size of fun->decl when it is valid but no cgraph node. > > gcc/testsuite/ChangeLog: > > * gcc.target/powerpc/pr105818.c: New test. > * gcc.dg/guality/pr54693-2.c: Adjust for aarch64. > --- > gcc/predict.cc | 3 ++- > gcc/testsuite/gcc.dg/guality/pr54693-2.c | 2 +- > gcc/testsuite/gcc.target/powerpc/pr105818.c | 11 +++++++++++ > 3 files changed, 14 insertions(+), 2 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/powerpc/pr105818.c > > diff --git a/gcc/predict.cc b/gcc/predict.cc > index 1bc7ab94454..ecb4aabc9df 100644 > --- a/gcc/predict.cc > +++ b/gcc/predict.cc > @@ -268,7 +268,8 @@ optimize_function_for_size_p (struct function *fun) > cgraph_node *n = cgraph_node::get (fun->decl); > if (n) > return n->optimize_for_size_p (); > - return OPTIMIZE_SIZE_NO; > + return opt_for_fn (fun->decl, optimize_size) ? OPTIMIZE_SIZE_MAX > + : OPTIMIZE_SIZE_NO; > } > > /* Return true if function FUN should always be optimized for speed. */ > diff --git a/gcc/testsuite/gcc.dg/guality/pr54693-2.c b/gcc/testsuite/gcc.dg/guality/pr54693-2.c > index 68aa6c63d71..14ca94ad37d 100644 > --- a/gcc/testsuite/gcc.dg/guality/pr54693-2.c > +++ b/gcc/testsuite/gcc.dg/guality/pr54693-2.c > @@ -17,7 +17,7 @@ foo (int x, int y, int z) > int i = 0; > while (x > 3 && y > 3 && z > 3) > { /* { dg-final { gdb-test .+2 "i" "v + 1" } } */ > - /* { dg-final { gdb-test .+1 "x" "10 - i" } } */ > + /* { dg-final { gdb-test .+1 "x" "10 - i" { xfail { aarch64*-*-* && { any-opts "-Os" } } } } } */ > bar (i); /* { dg-final { gdb-test . "y" "20 - 2 * i" } } */ > /* { dg-final { gdb-test .-1 "z" "30 - 3 * i" { xfail { aarch64*-*-* && { any-opts "-fno-fat-lto-objects" "-Os" } } } } } */ > i++, x--, y -= 2, z -= 3; > diff --git a/gcc/testsuite/gcc.target/powerpc/pr105818.c b/gcc/testsuite/gcc.target/powerpc/pr105818.c > new file mode 100644 > index 00000000000..679647e189d > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr105818.c > @@ -0,0 +1,11 @@ > +/* { dg-options "-Os -fno-tree-vectorize" } */ > + > +/* Verify there is no ICE. */ > + > +#pragma GCC optimize "-fno-tree-vectorize" > + > +void > +foo (void) > +{ > + void bar (void); > +} > -- > 2.27.0
> > PR middle-end/105818 > > > > gcc/ChangeLog: > > > > * predict.cc (optimize_function_for_size_p): Further check > > optimize_size of fun->decl when it is valid but no cgraph node. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/powerpc/pr105818.c: New test. > > * gcc.dg/guality/pr54693-2.c: Adjust for aarch64. > > diff --git a/gcc/testsuite/gcc.target/powerpc/pr105818.c b/gcc/testsuite/gcc.target/powerpc/pr105818.c > > new file mode 100644 > > index 00000000000..679647e189d > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/powerpc/pr105818.c > > @@ -0,0 +1,11 @@ > > +/* { dg-options "-Os -fno-tree-vectorize" } */ > > + > > +/* Verify there is no ICE. */ > > + > > +#pragma GCC optimize "-fno-tree-vectorize" > > + > > +void > > +foo (void) > > +{ > > + void bar (void); > > +} So the testcase starts with optimize_size set but then it switches to optimize_size==0 due to the GCC optimize pragma. I think this is behaviour Martin wants to change, so perhaps the testcase should be written with explicit -O2. I also wonder what happen when you add the attribute later? /* { dg-options "-Os -fno-tree-vectorize" } */ /* Verify there is no ICE. */ #pragma GCC optimize "-fno-tree-vectorize" void foo (void) { void bar (void); } __attribute__ ((optimize("-fno-tree-vectorize"))) void foo (void); I think we should generally avoid doing decisions about size/speed optimizations so early since the setting may change due to attribtes or profile feedback... Honza
On 12/14/22 14:22, Jan Hubicka via Gcc-patches wrote: >>> PR middle-end/105818 >>> >>> gcc/ChangeLog: >>> >>> * predict.cc (optimize_function_for_size_p): Further check >>> optimize_size of fun->decl when it is valid but no cgraph node. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * gcc.target/powerpc/pr105818.c: New test. >>> * gcc.dg/guality/pr54693-2.c: Adjust for aarch64. >>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr105818.c b/gcc/testsuite/gcc.target/powerpc/pr105818.c >>> new file mode 100644 >>> index 00000000000..679647e189d >>> --- /dev/null >>> +++ b/gcc/testsuite/gcc.target/powerpc/pr105818.c >>> @@ -0,0 +1,11 @@ >>> +/* { dg-options "-Os -fno-tree-vectorize" } */ >>> + >>> +/* Verify there is no ICE. */ >>> + >>> +#pragma GCC optimize "-fno-tree-vectorize" >>> + >>> +void >>> +foo (void) >>> +{ >>> + void bar (void); >>> +} Hi. Next time, please CC me if you cite me. > So the testcase starts with optimize_size set but then it switches to > optimize_size==0 due to the GCC optimize pragma. I think this is > behaviour Martin wants to change, so perhaps the testcase should be > written with explicit -O2. No, the pragma does not modify optimize_size as "optimize" attribute behaves as documented: ``` ... The optimize attribute arguments of a function behave behave as if appended to the command-line. ``` Martin > > I also wonder what happen when you add the attribute later? > /* { dg-options "-Os -fno-tree-vectorize" } */ > > /* Verify there is no ICE. */ > > #pragma GCC optimize "-fno-tree-vectorize" > > void > foo (void) > { > void bar (void); > } > > __attribute__ ((optimize("-fno-tree-vectorize"))) void foo (void); > > I think we should generally avoid doing decisions about size/speed > optimizations so early since the setting may change due to attribtes or > profile feedback... > > Honza
Hi Honza, Thanks for the comments. on 2022/12/14 21:22, Jan Hubicka wrote: >>> PR middle-end/105818 >>> >>> gcc/ChangeLog: >>> >>> * predict.cc (optimize_function_for_size_p): Further check >>> optimize_size of fun->decl when it is valid but no cgraph node. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * gcc.target/powerpc/pr105818.c: New test. >>> * gcc.dg/guality/pr54693-2.c: Adjust for aarch64. >>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr105818.c b/gcc/testsuite/gcc.target/powerpc/pr105818.c >>> new file mode 100644 >>> index 00000000000..679647e189d >>> --- /dev/null >>> +++ b/gcc/testsuite/gcc.target/powerpc/pr105818.c >>> @@ -0,0 +1,11 @@ >>> +/* { dg-options "-Os -fno-tree-vectorize" } */ >>> + >>> +/* Verify there is no ICE. */ >>> + >>> +#pragma GCC optimize "-fno-tree-vectorize" >>> + >>> +void >>> +foo (void) >>> +{ >>> + void bar (void); >>> +} > So the testcase starts with optimize_size set but then it switches to > optimize_size==0 due to the GCC optimize pragma. I think this is > behaviour Martin wants to change, so perhaps the testcase should be > written with explicit -O2. No, both the global context and the function context are to optimize for size, Martin also clarified that. So the issue is the inconsistent information on optimizing for size when parsing bar, at that time cfun->decl is available but no cgraph node, it says OPTIMIZE_SIZE_NO. > > I also wonder what happen when you add the attribute later? > /* { dg-options "-Os -fno-tree-vectorize" } */ > > /* Verify there is no ICE. */ > > #pragma GCC optimize "-fno-tree-vectorize" > // marker A > void > foo (void) > { > void bar (void); > } > > __attribute__ ((optimize("-fno-tree-vectorize"))) void foo (void); There is still one ICE with this additional decl. Same ICE if I moved it to "marker A" above. > > I think we should generally avoid doing decisions about size/speed > optimizations so early since the setting may change due to attribtes or > profile feedback... > Good point, I'll make a separated patch to move optimize_function_for_speed_p uses out of function rs6000_option_override_internal, but I think it's a separated issue which just results in imperfect "optimize for size" decision. Fixing it can cover this exposed ICE, but IMHO this exposed inconsistent information on "optimize for size" exposed here is still an issue, like: all the context is to optimize for size, but it still returns OPTIMIZE_SIZE_NO. Do you agree? BR, Kewen
diff --git a/gcc/predict.cc b/gcc/predict.cc index 1bc7ab94454..ecb4aabc9df 100644 --- a/gcc/predict.cc +++ b/gcc/predict.cc @@ -268,7 +268,8 @@ optimize_function_for_size_p (struct function *fun) cgraph_node *n = cgraph_node::get (fun->decl); if (n) return n->optimize_for_size_p (); - return OPTIMIZE_SIZE_NO; + return opt_for_fn (fun->decl, optimize_size) ? OPTIMIZE_SIZE_MAX + : OPTIMIZE_SIZE_NO; } /* Return true if function FUN should always be optimized for speed. */ diff --git a/gcc/testsuite/gcc.dg/guality/pr54693-2.c b/gcc/testsuite/gcc.dg/guality/pr54693-2.c index 68aa6c63d71..14ca94ad37d 100644 --- a/gcc/testsuite/gcc.dg/guality/pr54693-2.c +++ b/gcc/testsuite/gcc.dg/guality/pr54693-2.c @@ -17,7 +17,7 @@ foo (int x, int y, int z) int i = 0; while (x > 3 && y > 3 && z > 3) { /* { dg-final { gdb-test .+2 "i" "v + 1" } } */ - /* { dg-final { gdb-test .+1 "x" "10 - i" } } */ + /* { dg-final { gdb-test .+1 "x" "10 - i" { xfail { aarch64*-*-* && { any-opts "-Os" } } } } } */ bar (i); /* { dg-final { gdb-test . "y" "20 - 2 * i" } } */ /* { dg-final { gdb-test .-1 "z" "30 - 3 * i" { xfail { aarch64*-*-* && { any-opts "-fno-fat-lto-objects" "-Os" } } } } } */ i++, x--, y -= 2, z -= 3; diff --git a/gcc/testsuite/gcc.target/powerpc/pr105818.c b/gcc/testsuite/gcc.target/powerpc/pr105818.c new file mode 100644 index 00000000000..679647e189d --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/pr105818.c @@ -0,0 +1,11 @@ +/* { dg-options "-Os -fno-tree-vectorize" } */ + +/* Verify there is no ICE. */ + +#pragma GCC optimize "-fno-tree-vectorize" + +void +foo (void) +{ + void bar (void); +}