[Bug regression/32398] New: checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[Bug regression/32398] New: checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[danglin at gcc dot gnu dot org]

checking for hppa64-hp-hpux11.11-gcc... /test/gnu/gcc/objdir/./gcc/xgcc
-B/test/
gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt
/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-4.3.0/
hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.1
1/sys-include
checking for suffix of object files... configure: error: cannot compute suffix
o
f object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage2-target-libgcc] Error 1
make[2]: Leaving directory `/test/gnu/gcc/objdir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/test/gnu/gcc/objdir'
make: *** [bootstrap] Error 2
Mon Jun 18 21:08:30 EDT 2007


-- 
           Summary: checking for suffix of object files... configure: error:
                    cannot compute suffix of f object files: cannot compile
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug regression/32398] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[danglin at gcc dot gnu dot org]

------- Comment #1 from danglin at gcc dot gnu dot org  2007-06-19 02:39 -------
This appears to be another problem in handling return pointer:

0x40000000003e5644 <lshift_significand+148>:    extrd,u ret0,63,32,rp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug regression/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Keywords|                            |build
            Summary|checking for suffix of      |[4.3 Regression] checking
                   |object files... configure:  |for suffix of object
                   |error: cannot compute suffix|files... configure: error:
                   |of f object files: cannot   |cannot compute suffix of f
                   |compile                     |object files: cannot compile
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug regression/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[danglin at gcc dot gnu dot org]

------- Comment #2 from danglin at gcc dot gnu dot org  2007-06-21 23:49 -------
The patch mentioned in PR 32296 fixes the return pointer breakage reported
in comment #2.  However, configure still fails at exactly the same point
due to a segmentation fault in def_fn_type():

(gdb) ignor 5 156
Will ignore next 156 crossings of breakpoint 5.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /test/gnu/gcc/objdir/gcc/cc1 -iprefix
/test/gnu/gcc/objdir/gcc/../lib/gcc/hppa64-hp-hpux11.11/4.3.0/ -isystem
./include -isystem ./include-fixed xxx.c -dumpbase xxx.c -auxbase-strip xxx.s
-version -o xxx.s
Breakpoint 3 at 0xc00000000000b310
Breakpoint 4 at 0x800000010000bbf0
Breakpoint 3 at 0x800003fffef4f620
Breakpoint 4 at 0x800003fffefa7a78
GNU C version 4.3.0 20070621 (experimental) (hppa64-hp-hpux11.11)
        compiled by GNU C version 4.3.0 20070621 (experimental), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed:  -iprefix
 /test/gnu/gcc/objdir/gcc/../lib/gcc/hppa64-hp-hpux11.11/4.3.0/ -isystem
 ./include -isystem ./include-fixed xxx.c -auxbase-strip xxx.s
options enabled:  -fPIC -falign-loops -fargument-alias -fauto-inc-dec
 -fbranch-count-reg -fcommon -fearly-inlining
 -feliminate-unused-debug-types -femit-class-debug-always -ffunction-cse
 -fgcse-lm -fident -finline-functions-called-once -fivopts
 -fkeep-static-consts -fleading-underscore -fmath-errno
 -fmove-loop-invariants -fpeephole -freg-struct-return -fsched-interblock
 -fsched-spec -fsched-stalled-insns-dep -fshow-column -fsigned-zeros
 -fsplit-ivs-in-unroller -ftoplevel-reorder -ftrapping-math -ftree-loop-im
 -ftree-loop-ivcanon -ftree-loop-optimize -ftree-scev-cprop
 -ftree-vect-loop-version -fvar-tracking -fzero-initialized-in-bss
 -mbig-switch -mgas -mspace-regs

Breakpoint 5, 0x4000000000185a14 in def_fn_type (
    def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT,
    var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384
3384          t = builtin_types[a];
(gdb) p i
$25 = 4
(gdb) p/x $ret0
$26 = 0x20
(gdb) p/x $r7
$27 = 0x8000000100058728
(gdb) c
Continuing.

Breakpoint 5, 0x4000000000185a14 in def_fn_type (
    def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT,
    var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384
3384          t = builtin_types[a];
(gdb) p i
$28 = 5
(gdb) p/x $ret0
$29 = 0xfeda2c60
(gdb) p/x $r7
$30 = 0x8000000100058728
(gdb) p/x $pc
$31 = 0x4000000000185a14
(gdb) disass 0x4000000000185a04 0x4000000000185a24
Dump of assembler code from 0x4000000000185a04 to 0x4000000000185a24:
0x4000000000185a04 <def_fn_type+156>:   ldo -30(sp),r5
0x4000000000185a08 <def_fn_type+160>:   ldd -c8(sp),r31
0x4000000000185a0c <def_fn_type+164>:   ldd 0(r6),r26
0x4000000000185a10 <def_fn_type+168>:   ldw 4(r31),ret0
0x4000000000185a14 <def_fn_type+172>:   ldd,s ret0(r7),r25
0x4000000000185a18 <def_fn_type+176>:   cmpb,*= r25,r26,0x4000000000185a84
<def_fn_type+284>
0x4000000000185a1c <def_fn_type+180>:   ldo 8(r31),r19
0x4000000000185a20 <def_fn_type+184>:   std r19,-c8(sp)
End of assembler dump.
(gdb) bt
#0  0x4000000000185a14 in def_fn_type (
    def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT,
    var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384
#1  0x400000000018c1a4 in c_common_nodes_and_builtins ()
    at builtin-types.def:403
#2  0x400000000014dda4 in c_init_decl_processing ()
    at ../../gcc/gcc/c-decl.c:2772
#3  0x40000000001b2034 in c_objc_common_init ()
    at ../../gcc/gcc/c-objc-common.c:128
#4  0x400000000046f264 in toplev_main (argc=<value optimized out>,
    argv=<value optimized out>) at ../../gcc/gcc/toplev.c:2037
#5  0x40000000001d7af4 in main (argc=-19249376, argv=0x0)
    at ../../gcc/gcc/main.c:35
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x4000000000185a14 in def_fn_type (
    def=BT_FN_INT_STRING_SIZE_INT_SIZE_CONST_STRING_VALIST_ARG, ret=BT_INT,
    var=0 '\0', n=6) at ../../gcc/gcc/c-common.c:3384
3384          t = builtin_types[a];
(gdb) p/x &builtin_types
$32 = 0x8000000100058728
(gdb) p n
$33 = 6


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug regression/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug regression/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[danglin at gcc dot gnu dot org]

------- Comment #3 from danglin at gcc dot gnu dot org  2007-07-02 18:12 -------
Here's a small test case from Steve Ellcey:

f (int n, ...)
{
  int i, j;
  long x;

  __builtin_va_list ap;
  __builtin_va_start(ap,n);

  for (i = 0; i < n; i++)
      j = __builtin_va_arg(ap,int);

  x = __builtin_va_arg(ap,long);
  if (x != 123)
    abort();

  __builtin_va_end(ap);
}

main ()
{
  f (1, 2, (long) 123);
  exit(0);
}

This test fails with a non-bootstrap PA64 GCC compiler.  Steve says it
looks like a scheduling problem because it doesn't fail when compiled
with -fno-schedule-insns.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-07-02 18:17 -------
Can you send me, the dump produced by -fdump-rtl-expand with the trunk and also
revision 125754.  I am 99% sure this was exposed by pointer plus.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|regression                  |middle-end
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-02 18:17:14
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-02 20:07 -------
Subject: Re:  [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO

> Can you send me, the dump produced by -fdump-rtl-expand with the trunk and also
> revision 125754.  I am 99% sure this was exposed by pointer plus.

The problem doesn't appear to be in expand.  This is the difference
between the assembly code generated with and without -fno-schedule-insns,
respectively:

--- pr32398.s1  Mon Jul  2 15:08:11 2007
+++ pr32398.s   Mon Jul  2 15:06:55 2007
@@ -9,24 +9,24 @@ f:
        .ENTRY
        std %r2,-16(%r30)
        ldo 144(%r30),%r30
+       extrd,s %r26,63,32,%r31
        std %r4,-128(%r30)
-       std %r26,-64(%r29)
-       extrd,s %r26,63,32,%r26
        std %r25,-56(%r29)
+       ldo -56(%r29),%r29
        std %r24,-48(%r29)
        std %r23,-40(%r29)
        std %r22,-32(%r29)
        std %r21,-24(%r29)
        std %r20,-16(%r29)
        std %r19,-8(%r29)
-       ldo -56(%r29),%r29
-       cmpib,>= 0,%r26,L$0002
+       std %r26,-64(%r29)
+       cmpib,>= 0,%r31,L$0002
        std %r29,-136(%r30)
        ldi 0,%r28
 L$0003:
        ldo 1(%r28),%r28
        extrd,s %r28,63,32,%r28
-       cmpb,< %r28,%r26,L$0003
+       cmpb,< %r28,%r31,L$0003
        ldo 8(%r29),%r29
        std %r29,-136(%r30)
 L$0002:

The problem is the "ldo -56(%r29),%r29" insn has been moved forward
before the argument saves to the stack.  r29 is the incoming argument
pointer.

This occurs in the sched1 pass where the following rtl is generated:

(insn 13 8 21 2 pr32398.c:7 (set (mem:DI (plus:DI (reg/f:DI 29 %r29)
                (const_int -56 [0xffffffffffffffc8])) [0 S8 A64])
        (reg:DI 25 %r25)) 124 {*pa.md:4572} (expr_list:REG_DEAD (reg:DI 25
%r25)
        (nil)))

(insn 21 13 7 2 pr32398.c:7 (set (reg/f:DI 78)
        (plus:DI (reg/f:DI 29 %r29)
            (const_int -56 [0xffffffffffffffc8]))) 164 {*pa.md:5412}
(expr_list:REG_DEAD (reg/f:DI 29 %r29)
        (nil)))

(insn 7 21 14 2 pr32398.c:2 (set (reg/v:DI 75 [ n ])
        (sign_extend:DI (reg:SI 26 %r26 [ n+-4 ]))) 143 {extendsidi2}
(expr_list:REG_DEAD (reg:SI 26 %r26 [ n+-4 ])
        (nil)))

(insn 14 7 15 2 pr32398.c:7 (set (mem:DI (plus:DI (reg/f:DI 29 %r29)
                (const_int -48 [0xffffffffffffffd0])) [0 S8 A64])
        (reg:DI 24 %r24)) 124 {*pa.md:4572} (expr_list:REG_DEAD (reg:DI 24
%r24)
        (nil)))

The problem is the REG_DEAD note for r29.  r19 isn't dead after insn 21.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-07-02 20:23 -------
(In reply to comment #5)
> Subject: Re:  [4.3 Regression] checking for suffix of object files...
> configure: error: cannot compute suffix of f objeRO
> 
> > Can you send me, the dump produced by -fdump-rtl-expand with the trunk and also
> > revision 125754.  I am 99% sure this was exposed by pointer plus.
> 
> The problem doesn't appear to be in expand.  This is the difference
> between the assembly code generated with and without -fno-schedule-insns,
> respectively:

Now I am 99% sure that this was not caused by pointer plus (though it could
have been exposed by it but I doubt it since REG_DEAD is done by df which means
this is more likely a DF issue).

Thanks,
Andrew Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[danglin at gcc dot gnu dot org]

------- Comment #7 from danglin at gcc dot gnu dot org  2007-07-07 20:30 -------
There is some dependency on the pointer plus merge.  After the merge,
Steve's testcase fails with the stage1 compiler as previously shown.
Before the merge, the test doesn't fail.  However, the GCC build still
fails at the same point.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at naturalbridge dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-07 22:02 -------
Subject: Re:  [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO

The REG_DEAD problem is a red herring.  The notes are recomputed
after the sched1 dump.

The real problem is that the argument point register isn't marked
as being alive on entry.  On hppa64, the argument pointer isn't a
fixed register, it's not the same as the frame pointer, and it
can't be eliminated.

I'm trying the fix below.  However, I think df-scan.c needs fixing.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: config/pa/pa.c
===================================================================
--- config/pa/pa.c      (revision 126442)
+++ config/pa/pa.c      (working copy)
@@ -156,8 +156,8 @@
 static enum reg_class pa_secondary_reload (bool, rtx, enum reg_class,
                                           enum machine_mode,
                                           secondary_reload_info *);
+static void pa_extra_live_on_entry (bitmap);

-
 /* The following extra sections are only used for SOM.  */
 static GTY(()) section *som_readonly_data_section;
 static GTY(()) section *som_one_only_readonly_data_section;
@@ -313,6 +313,9 @@
 #undef TARGET_SECONDARY_RELOAD
 #define TARGET_SECONDARY_RELOAD pa_secondary_reload

+#undef TARGET_EXTRA_LIVE_ON_ENTRY
+#define TARGET_EXTRA_LIVE_ON_ENTRY pa_extra_live_on_entry
+
 struct gcc_target targetm = TARGET_INITIALIZER;

 /* Parse the -mfixed-range= option string.  */
@@ -5735,6 +5738,17 @@
   return NO_REGS;
 }

+/* Implement TARGET_EXTRA_LIVE_ON_ENTRY.  The argument pointer
+   isn't a fixed register in the 64-bit runtime and we need to
+   record it as live on entry.  */
+
+static void
+pa_extra_live_on_entry (bitmap regs)
+{
+  if (TARGET_64BIT)
+    bitmap_set_bit (regs, ARG_POINTER_REGNUM);
+}
+
 /* In the 32-bit runtime, arguments larger than eight bytes are passed
    by invisible reference.  As a GCC extension, we also pass anything
    with a zero or variable size by reference.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[zadeck at naturalbridge dot com]

------- Comment #9 from zadeck at naturalbridge dot com  2007-07-07 22:40 -------
Subject: Re:  [4.3 Regression] checking for suffix of
 object files... configure: error: cannot compute suffix of f object files:
 cannot compile

dave at hiauly1 dot hia dot nrc dot ca wrote:
> ------- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-07 22:02 -------
> Subject: Re:  [4.3 Regression] checking for suffix of object files...
> configure: error: cannot compute suffix of f objeRO
>
> The REG_DEAD problem is a red herring.  The notes are recomputed
> after the sched1 dump.
>
> The real problem is that the argument point register isn't marked
> as being alive on entry.  On hppa64, the argument pointer isn't a
> fixed register, it's not the same as the frame pointer, and it
> can't be eliminated.
>
> I'm trying the fix below.  However, I think df-scan.c needs fixing.
>
> Dave
>   
suggest a way that we could accommodate this?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-07 23:30 -------
Subject: Re:  [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje

> suggest a way that we could accommodate this?

Prior to reload being completed, I don't see that it matters whether
the argument pointer is fixed or not.  See df_get_entry_block_def_set().
After reload, I believe that we also need to mark the register in
entry_block_defs.

There may be refinements to this depending on whether the argument
pointer is used or not.  This might improve register allocation.
The argument pointer is always copied when it isn't fixed.  See
default_internal_arg_pointer().

For now, I would suggest being conservative.  For example, we aren't
fussy as to whether argument registers are actually used or not.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[zadeck at naturalbridge dot com]

------- Comment #11 from zadeck at naturalbridge dot com  2007-07-08 00:57 -------
Subject: Re:  [4.3 Regression] checking for suffix of
 object files... configure: error: cannot compute suffix of f object files:
 cannot compile

dave at hiauly1 dot hia dot nrc dot ca wrote:
> ------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-07 23:30 -------
> Subject: Re:  [4.3 Regression] checking for suffix of object files...
> configure: error: cannot compute suffix of f obje
>
>   
>> suggest a way that we could accommodate this?
>>     
>
> Prior to reload being completed, I don't see that it matters whether
> the argument pointer is fixed or not.  See df_get_entry_block_def_set().
> After reload, I believe that we also need to mark the register in
> entry_block_defs.
>   
Why can't you put something in the prologue that sets the reg and has an
unspec as the lhs to make this reg live?  I thought that the purpose of
the unspecs was to be used in this manner since the unspec does not have
actually map to any real insns.
> There may be refinements to this depending on whether the argument
> pointer is used or not.  This might improve register allocation.
> The argument pointer is always copied when it isn't fixed.  See
> default_internal_arg_pointer().
>
> For now, I would suggest being conservative.  For example, we aren't
> fussy as to whether argument registers are actually used or not.
>
> Dave
>
>
>   


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-08 02:29 -------
Subject: Re:  [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO

> Why can't you put something in the prologue that sets the reg and has an
> unspec as the lhs to make this reg live?  I thought that the purpose of
> the unspecs was to be used in this manner since the unspec does not have
> actually map to any real insns.

I believe that's too late.  The prologue expansion occurs after the
greg pass.  The problem is the arg pointer gets used in the greg pass
since it isn't alive at entry.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[zadeck at naturalbridge dot com]

------- Comment #13 from zadeck at naturalbridge dot com  2007-07-08 02:41 -------
Subject: Re:  [4.3 Regression] checking for suffix of
 object files... configure: error: cannot compute suffix of f object files:
 cannot compile

dave at hiauly1 dot hia dot nrc dot ca wrote:
> ------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-08 02:29 -------
> Subject: Re:  [4.3 Regression] checking for suffix of object files...
> configure: error: cannot compute suffix of f objeRO
>
>   
>> Why can't you put something in the prologue that sets the reg and has an
>> unspec as the lhs to make this reg live?  I thought that the purpose of
>> the unspecs was to be used in this manner since the unspec does not have
>> actually map to any real insns.
>>     
>
> I believe that's too late.  The prologue expansion occurs after the
> greg pass.  The problem is the arg pointer gets used in the greg pass
> since it isn't alive at entry.
>
> Dave
>
>
>   
why can't you generate a set of a pseudo from an unspec at the top of
the function during rtl generation time.  (or perhaps at one of the time
of one of the expansions)

There is nothing magical about the entry block defs except that they are
all fixed regs. 
There really is not a mechanism to support a psuedo, or a varying
register there. 

kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-08 05:12 -------
Subject: Re:  [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO

> There is nothing magical about the entry block defs except that they are
> all fixed regs. 

That's not true for argument registers.

> There really is not a mechanism to support a psuedo, or a varying
> register there. 

Before the dataflow merge, the argument pointer was always included
in "Registers live at start".  I don't really see how an unspec insn
helps if there is no mechanism to support a varying argument pointer.
I pointed previously to the copy mechanism that handles varying
argument pointers in function.c.  I don't understand why a varying
argument pointer can't be handled.

I doubt an unspec by itself is sufficient since I think regrename is
affected.

The patch that I posted resolves the bootstrap issue but the documentation
states that it shouldn't be necessary for various registers including
ARG_POINTER_REGNUM.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[bonzini at gnu dot org]

------- Comment #15 from bonzini at gnu dot org  2007-07-09 16:31 -------
Note that this:

> Before the dataflow merge, the argument pointer was always included
> in "Registers live at start".

... was because uninitialized registers always showed up as live at start
before DF merge.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[bonzini at gnu dot org]

------- Comment #16 from bonzini at gnu dot org  2007-07-09 21:04 -------
Looking out of the box, why can't we add it always, the same as we do with the
frame and stack pointer??  I wonder if the fixed/variable thing is a red
herring.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-09 22:01 -------
Subject: Re:  [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje

> ------- Comment #16 from bonzini at gnu dot org  2007-07-09 21:04 -------
> Looking out of the box, why can't we add it always, the same as we do with the
> frame and stack pointer??  I wonder if the fixed/variable thing is a red
> herring.

>From an ABI standpoint, the stack and argument pointers are equivalent.
They are both passed in hardware registers and they both point to places
on the stack on function entry.  The argument pointer is *always* live
when a function is entered and this never changes, even if it isn't used.
So, from my standpoint, it seems reasonable to add it always (at least
for hppa64).

However, I believe Kenny would like a solution that avoids having to
set the register as live in the entry defs (i.e., he would like to move
away from having entry defs, etc).

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[zadeck at naturalbridge dot com]

------- Comment #18 from zadeck at naturalbridge dot com  2007-07-09 22:28 -------
Subject: Re:  [4.3 Regression] checking for suffix of
 object files... configure: error: cannot compute suffix of f object files:
 cannot compile

dave at hiauly1 dot hia dot nrc dot ca wrote:
> ------- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-09 22:01 -------
> Subject: Re:  [4.3 Regression] checking for suffix of object files...
> configure: error: cannot compute suffix of f obje
>
>   
>> ------- Comment #16 from bonzini at gnu dot org  2007-07-09 21:04 -------
>> Looking out of the box, why can't we add it always, the same as we do with the
>> frame and stack pointer??  I wonder if the fixed/variable thing is a red
>> herring.
>>     
>
> From an ABI standpoint, the stack and argument pointers are equivalent.
> They are both passed in hardware registers and they both point to places
> on the stack on function entry.  The argument pointer is *always* live
> when a function is entered and this never changes, even if it isn't used.
> So, from my standpoint, it seems reasonable to add it always (at least
> for hppa64).
>
> However, I believe Kenny would like a solution that avoids having to
> set the register as live in the entry defs (i.e., he would like to move
> away from having entry defs, etc).
>
> Dave
>
>   
The problem that i have is it the argument pointer does not have a fixed
value.  it is assigned to a hard register sometimes during reload.

kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2007-07-10 00:04 -------
Subject: Re:  [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje

> The problem that i have is it the argument pointer does not have a fixed
> value.  it is assigned to a hard register sometimes during reload.

Function.c generates an insn to copy it to a pseudo during rtl
expansion.  This is the so called internal argument pointer.  It
is assigned a hard register during reload.

A copy is needed because the incoming argument pointer is a call
clobbered register.  The register used for the incoming argument
pointer never changes.  After the copy is made, the compiler is
free to make whatever use it wants of the argument pointer register.

If the internal argument pointer was removed, we would have to copy
the incoming argument pointer to a fixed register in the prologue,
or save and restore the argument pointer register across calls.
I'm not sure either of these approaches is an improvement over what
we have now.

When a call is made, the pa call expander emits insns to load the
argument pointer suitably for the call using virtual_outgoing_args_rtx.
We don't restore the argument pointer after a call.  However,
we do this for the PIC register.

The thinking behind the current approach is that accesses to the
argument block are much less frequent than accesses using the
PIC register.  Typically, the argument pointer is only needed for
calls which have more than eight arguments or for va_args.  The
generic copy method has always worked reasonably well although
there are some tail call optimizations that don't occur when it is
used.

It probably would be possible to handle the argument pointer in
a manner similar to the way we handle the PIC register.  This is
a bit tricky.  The details of regarding the handling of the argument
pointer would have to be hidden until after reload.  We have some
ugly post-reload splitters to handle this for the PIC register.
The downside is we lose the use of a register when we don't need
an argument pointer.

I have the impression that you are confused about the reason the
argument pointer isn't fixed.  Reload doesn't modify its incoming
value.  Reload also can't eliminate it because it there isn't a
fixed relationship to the stack pointer (or the frame pointer).
So, reload doesn't affect its liveness.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[danglin at gcc dot gnu dot org]

------- Comment #20 from danglin at gcc dot gnu dot org  2007-07-15 17:19 -------
Subject: Bug 32398

Author: danglin
Date: Sun Jul 15 17:19:13 2007
New Revision: 126657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126657
Log:
        PR middle-end/32398
        PR middle-end/32769
        * pa-protos.h (pa_eh_return_handler_rtx): Declare.
        * pa.c (pa_extra_live_on_entry, rp_saved): Declare.
        (TARGET_EXTRA_LIVE_ON_ENTRY): Define.
        (pa_output_function_prologue): Use rp_saved and
current_function_is_leaf
        to generate .CALLINFO statement.
        (hppa_expand_prologue): Set rp_saved.
        (hppa_expand_epilogue): Use rp_saved.
        (pa_extra_live_on_entry, pa_eh_return_handler_rtx): New functions.
        * pa.h (EH_RETURN_HANDLER_RTX): Use pa_eh_return_handler_rtx.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/pa/pa-protos.h
    trunk/gcc/config/pa/pa.c
    trunk/gcc/config/pa/pa.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

[danglin at gcc dot gnu dot org]

------- Comment #21 from danglin at gcc dot gnu dot org  2007-07-15 17:23 -------
Fixed by change.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398