Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c -O2 -fno-common -fdump-tree-optimized -S -o ssa-store-ccp-3.s (timeout = 300) PASS: gcc.dg/tree-ssa/ssa-store-ccp-3.c (test for excess errors) FAIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststa ticvariable" 1 # less ssa-store-ccp-3.c.123t.optimized ;; Function f (f) Analyzing Edge Insertions. f () { <bb 2>: return 0; }
AIL? I guess another PIC related issue.
hppa64 is setting __PIC__ because it sets flag_pic and generates PIC code by default but it sets flag_pic to 2 in override_options after we have already checked its value in decode_options and used its value to set flag_shlib. The optimization in this test is determined by flag_shlib. We need to either set flag_shlib in override_options when we set flag_pic (making hppa64 a true PIC platform) or not set flag_pic for PA64 even though it is generating PIC code or xfail the test. IA64 HP-UX does not set flag_pic even though the code is PIC, that is why it does not fail. Setting flag_shlib could make some code slower by preventing inlining so as to allow functions to be overridden which you have to do if the code is in a shared library. David, do you have a prefered fix?
Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1 > David, do you have a prefered fix? For 4.4, I don't think we can not remove the code which sets flag_pic. The code in config/pa would all have to be updated to add checks for TARGET_64BIT where flag_pic is used. There might be other side effects. I'm somewhat concerned about not setting flag_shlib in override options. However, I think flag_shlib will get set if -fpic/-fPIC is specified on the command line. Possibly a note should be added to the documentation. Would adding a dg-options statement for hppa64-*-* fix the test? Dave
A dg-options to set -fpic would fix the test on hppa64 but I think we might want to xfail it instead and fix it after 4.4. Technically, I don't think this is a 4.4 Regression since the test is new and the behaviour of the compiler has not changed so we might want to remove the 4.4 Regression tag from this defect.
Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1 > ------- Comment #4 from sje at cup dot hp dot com 2008-11-18 17:11 ------- > A dg-options to set -fpic would fix the test on hppa64 but I think we might > want to xfail it instead and fix it after 4.4. Technically, I don't think this > is a 4.4 Regression since the test is new and the behaviour of the compiler has > not changed so we might want to remove the 4.4 Regression tag from this defect. Agree with 4.4 Regression tag. With respect to the test, I don't care which fix is selected. The compiler behaves as expected, so I believe the PR can be closed when the test is fixed. The hppa64 target has always set flag_pic. The overloading of flag_shlib on the -fpic/-fPIC options was introduced here: 2003-06-03 Jakub Jelinek <jakub@redhat.com> * configure.in (HAVE_LD_PIE): Check for ld -pie. * config.in: Rebuilt. * configure: Rebuilt. * toplev.c (flag_pie, flag_shlib): New variables. (f_options): Add -fpie and -fPIE. (parse_options_and_default_flags): Set flag_pic if -fpie/-fPIE. Set flag_shlib if flag_pic and not -fpie/-fPIE. ... As you noted, flag_shlib affects inlining, so we don't want this enabled by default. Supplying -fpic on the command line sets flag_shlib and I believe most people use it when building shared libraries on hppa64. Thus, there's no major problem with with setting flag_pic in override options. The documentation indicates that -fpic should be specified to generate position-independent code (PIC) suitable for use in a shared library. The documentation also indicates that the code generated for the IBM RS/6000 is always position-independent. However, this is not mentioned for ia64 or hppa64. Dave
IMHO if a target generates position independent code by default, but not flag_shlib by default, then it should define __pie__ and/or __PIE__ macro, but not __pic__ and/or __PIC__, as the latter implies both flag_pic and flag_shlib, while the former only pic code, which can't be overridden. Clearing "4.4 Regression", as per #c4 and #c5.
Subject: Re: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1 > ------- Comment #6 from jakub at gcc dot gnu dot org 2008-11-18 23:17 ------- > IMHO if a target generates position independent code by default, but not > flag_shlib by default, then it should define __pie__ and/or __PIE__ macro, but > not __pic__ and/or __PIC__, as the latter implies both flag_pic and flag_shlib, > while the former only pic code, which can't be overridden. > Clearing "4.4 Regression", as per #c4 and #c5. Defining __pie__ and/or __PIE__ would appear somewhat misleading as HP-UX ld and dld.sl don't support position-independent executables. All executables are linked to start at a fixed address. On linux, PIE excutables are supported. In the 32-bit runtime, the linker converts memory accesses using the PIC register to accesses using the global pointer when an PIC object is linked into a final executable. The global pointer and the PIC register are the same in the 64-bit runtime, so this isn't needed. However, in both cases, a "PIC" object can be linked into a final executable. Thus, we need to distinguish "PIC" code compiled for linking into a shared library from "PIC" code compiled for linking into a final executable. We also need PIE suport for linux. Dave
Subject: Bug 37326 Author: sje Date: Tue Dec 9 16:57:49 2008 New Revision: 142599 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142599 Log: PR testsuite/37326 * gcc.dg/tree-ssa/ssa-store-ccp-3.c: Skip on hppa*64-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c
Fixed by skipping the test on hppa64.