This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
optimization/6028: libcall handling breaks 173.applu with -Os on ia64
- From: janis187 at us dot ibm dot com
- To: gcc-gnats at gcc dot gnu dot org
- Date: 22 Mar 2002 02:05:28 -0000
- Subject: optimization/6028: libcall handling breaks 173.applu with -Os on ia64
- Reply-to: janis187 at us dot ibm dot com
>Number: 6028
>Category: optimization
>Synopsis: libcall handling breaks 173.applu with -Os on ia64
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Thu Mar 21 18:06:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Janis Johnson
>Release: gcc version 3.1 20020321 (prerelease)
>Organization:
>Environment:
Itanium, Red Hat Linux release 7.1.94 (Roswell)
>Description:
The SPEC CPU2000 test 173.applu gets incorrect results when
compiled with -Os on ia64-unknown-linux-gnu with the 3.1
prerelease compiler.
This is a regression from GCC 3.0.4 that begins with this
change:
Sun Dec 23 00:49:37 CET 2001 Jan Hubicka <jh@suse.cz>
* calls.c (ECF_LIBCALL_BLOCK): New constant.
(emit_call_1, initialize_argument_information,
precompute_arguments, expand_call,
emit_library_call_value_1): Use ECF_LIBCALL_BLOCK
instead of ECF_PURE | ECF_CONST. Honnor LCT_CONST/LCT_PURE.
I have not yet put together a test case to include with
this PR, but I can continue to work on that if necessary.
The subroutine that is compiled incorrectly with -Os is
jaclf.f, which has three nested DO loops with lots of math,
four calls to __divdf3, and no other calls. This test
passes with all other optimization options I've tried.
I used SPEC's test (small) input.
>How-To-Repeat:
Build and run 173.applu from SPEC CPU2000 with -Os.
>Fix:
Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: