Re: [Gcl-devel] Gcc 3.4 and GCL

[Camm Maguire]

Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi there.
> 
> MinGW32 gcc 3.4 was released yesterday so I ran a quick check with GCL which
> fails on gmp3 due to type errors like this one:
> 
> ============================================================================
> ========
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -fomit-frame
> -poi
> nter -mcpu=i486 -march=i386 -c cfdiv_q_2exp.c
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> cfdiv_q_2exp.c:34: error: conflicting types for '__gmpz_cfdiv_q_2exp'
> cfdiv_q_2exp.c:29: error: previous declaration of '__gmpz_cfdiv_q_2exp' was
> here
> 
> cfdiv_q_2exp.c:34: error: conflicting types for '__gmpz_cfdiv_q_2exp'
> cfdiv_q_2exp.c:29: error: previous declaration of '__gmpz_cfdiv_q_2exp' was
> here
> ============================================================================
> ========
> 
> Also Camm, in relation to our test with "-fvolatile" I see this comment in
> the gcc 3.4 release notes at http://gcc.gnu.org/gcc-3.4/changes.html :
> 
> "GCC no longer accepts the options -fvolatile, -fvolatile-global
> and -fvolatile-static. It is unlikely that they worked correctly in any 3.x
> release."
> 

OK.  The volatile keywords in the code should still work, I take it,
and I cannot conceive of why two different OS targets (Linux and
mingw32) on the same cpu could have different register clobbering
issues.  As a double check, make sure you are getting the gcc warning
output from -Wall on all the compiled lisp files -- you should be
explicitly warned of variable clobbering possibilities.

Further, your results do not (obviously at least) appear to be
(immediately) triggered by a GC, and the register flushing mechanism
of recursive setjmps to flush the regs onto the stack for GC appears
to be working.  See the following comment from h/sun4.h:

/* setjmp does not lay down the other register windows registers,
   and so we must recurse some to make sure that all registers are
   forced onto the stack.
*/   
#define N_RECURSION_REQD 8
  
You might try increasing this just for interest sake.  In fact, I
might also on hppa, where all opts greater than -O0 prevent an acl2
build with very similar filename corrpution symptoms.  In you case,
though, we see this with -g only, so this expalnation does not look
likely.

I understand that gdb backtracing is difficult, as it makes the issue
go away.  Perhaps it is just intermittent?  It would be good to run
several builds in sequence under gdb to see if any error whatsoever
can be trapped.

Take care,

> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah