[Gcl-devel] Re: gcc-3.3 bugs Debian unstable hppa

[Camm Maguire]

Greetings, and thanks for your reply!  

OK you've triggered one possibility in my mind -- for some time we
have had hppa specific assembler in our garbage collector to make sure
the registers are flushed when marking the C stack.  The bug in
question has the markings of a possible gbc bug in which some string
object, possibly on the C stack, was not marked.  You're mentioning of
volatile variables brought this to mind.

Here is the assembler:

=============================================================================
#if defined(__hppa__) /* Courtesy of Lamont Jones */
/* the calling sequence */
struct regs {
        void *callee_saves[16];
};
void hppa_save_regs(struct regs);

/* the code */

        asm(".code");
        asm(".export hppa_save_regs, entry");
        asm(".proc");
        asm(".callinfo");
        asm(".label     hppa_save_regs");
        asm(".entry");

        asm("stw        %r3,0(%arg0)");
        asm("stw        %r4,4(%arg0)");
        asm("stw        %r5,8(%arg0)");
        asm("stw        %r6,12(%arg0)");
        asm("stw        %r7,16(%arg0)");
        asm("stw        %r8,20(%arg0)");
        asm("stw        %r9,24(%arg0)");
        asm("stw        %r10,28(%arg0)");
        asm("stw        %r11,32(%arg0)");
        asm("stw        %r12,36(%arg0)");
        asm("stw        %r13,40(%arg0)");
        asm("stw        %r14,44(%arg0)");
        asm("stw        %r15,48(%arg0)");
        asm("stw        %r16,52(%arg0)");
        asm("stw        %r17,56(%arg0)");
        asm("bv 0(%rp)");
        asm("stw        %r18,60(%arg0)");

        asm(".exit");
        asm(".procend");
        asm(".end");
#endif

static void
mark_c_stack(jmp_buf env1, int n, void (*fn)(void *,void *,int)) {

#if defined(__hppa__)
  struct regs hppa_regs;
#endif
  jmp_buf env;
  int where;
  if (n== N_RECURSION_REQD)
    c_stack_where = (long *) (void *) &env;
  if (n > 0 ) {  
#if defined(__hppa__)
    hppa_save_regs(hppa_regs);
#else    
    setjmp(env);
#endif
=============================================================================

Apparently setjmp did not flush the regs on hppa when we put this in.

Can you spot a possible problem here, perhaps one that might have been
introduced with newer kernels?

Take care,

On Fri, Feb 20, 2004 at 11:49:35AM -0500, Camm Maguire wrote:
> Base switches required: -fPIC -ffunction-sections
> 
>        -O0    -O1  -O2
> gcl    PASS  PASS  PASS
> maxima PASS  PASS  FAIL
> acl2   PASS  FAIL
> axiom        PASS


Intersting.
 
> The acl2 failure at -O1 was intermittently reproducible:  some test
> runs with the same executable would pass, some would fail in precisely
> the same place, failing to find a / character when searching through a
> directory string. 

Could you narrow down the failure? I find most of the time the code is
to blame, usually because you forget to mark a variable as volatile,
modified it globally, but gcc optimized it out of a loop. I know the
compiler has bugs, but they aren't horrible bad bugs.

> We're about to finalize the stable 2.6.2 gcl release.  Any
> recommendations on what the default flags should be?  I'm thinking
> there are few enough users that would care about the performance hit
> that -O0 by default for all programs might be best.

If you have to release, then you have to release, it's best to get
users. What worries me is the "blank" in your diagram, does that mean
that axiom doesn't compile in -O0? I compile glibc with -O2 without
problems, and *everything* relies on glibc. I'm *almost* guaranteed that
the code is probably wrong. 

> BTW, is it worth filing a bug against gcc, or are people already
> actively working on the hppa backend anyway?  I'm a bit short on time,
> so a very detailed report by me is probably not feasible right now.

It's definately worth investigating, can you find out why? Perhaps
narrow it down a little. Even a smaller context would allow me to
suggest something, or perhaps I've already seem a similar bug.

Cheers,
c.