Re: possible bug on PPC/ GNU/LINUX

Re: possible bug on PPC/ GNU/LINUX

[Mike Stump]

> To: egcs-bugs@egcs.cygnus.com
> Date: Tue, 15 Jun 1999 17:10:24 +0200
> From: Daniel Diaz <Daniel.Diaz@inria.fr>

> I'm the author of GNU Prolog and I discovered a bug (I think) while
> porting my system under PowerPC / GNU/Linux.

See the manual, I'll quote the relevant parts I think might apply to
you below.  Also, doing this is _NOT_ portable.  You will want to find
a way that is portable on all platforms and then tweak this up for
those platforms that can support it.  For example, x86 with -fPIC and
-O0 (or maybe -O9) you may find that there is nothing that you can do
that will make it work (no free registers).

Further, these flags change the ABI of the software, and you will need
to recompile all C code with your flags, this includes things like the
library and friends (or if you are specifically very careful, you
might be able to mix and match compiled C codes).

As to finding a register, oh, might as well pick the first saved one
that is normally allocated.  See gcc/config/*/*.h (REG_ALLOC_ORDER,
REGISTER_NAMES, CALL_USED_REGISTERS).

Now, some ABIs do allocate global registers for programmer use...
and you may be able to do what you want easier on them.


@item -ffixed-@var{reg}
Treat the register named @var{reg} as a fixed register; generated code
should never refer to it (except perhaps as a stack pointer, frame
pointer or in some other fixed role).

@var{reg} must be the name of a register.  The register names accepted
are machine-specific and are defined in the @code{REGISTER_NAMES}
macro in the machine description macro file.

This flag does not have a negative form, because it specifies a
three-way choice.

@item -fcall-used-@var{reg}
Treat the register named @var{reg} as an allocable register that is
clobbered by function calls.  It may be allocated for temporaries or
variables that do not live across a call.  Functions compiled this way
will not save and restore the register @var{reg}.

It is an error to used this flag with the frame pointer or stack pointer.
Use of this flag for other registers that have fixed pervasive roles in
the machine's execution model will produce disastrous results.

This flag does not have a negative form, because it specifies a
three-way choice.

@item -fcall-saved-@var{reg}
Treat the register named @var{reg} as an allocable register saved by
functions.  It may be allocated even for temporaries or variables that
live across a call.  Functions compiled this way will save and restore
the register @var{reg} if they use it.

It is an error to used this flag with the frame pointer or stack pointer.
Use of this flag for other registers that have fixed pervasive roles in
the machine's execution model will produce disastrous results.

A different sort of disaster will result from the use of this flag for
a register in which function values may be returned.

This flag does not have a negative form, because it specifies a
three-way choice.
>From oliva@dcc.unicamp.br Tue Jun 15 08:39:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: egcs-bugs@egcs.cygnus.com
Subject: alphaev56-dec-osf4.0d: still no go :-(
Date: Tue, 15 Jun 1999 08:39:00 -0000
Message-id: <org13tqxqw.fsf@saci.lsd.dcc.unicamp.br>
X-SW-Source: 1999-06/msg00426.html
Content-length: 1549

The latest snapshot still gets:

stage1/xgcc -Bstage1/ -B/n/temp1/gcctest/egcs/alpha-OSF1-V4.0/alphaev56-dec-osf4
.0d/bin/ -c  -DIN_GCC -DHAIFA    -W -Wall -g -O9 -W -Wall  -DHAVE_CONFIG_H    -I
. -I/home/msc/oliva/src/egcs/gcc -I/home/msc/oliva/src/egcs/gcc/config -I/home/msc/oliva/src/egcs/gcc/../include /home/msc/oliva/src/egcs/gcc/gcov.c
/home/msc/oliva/src/egcs/gcc/gcov.c: In function `output_data':
/home/msc/oliva/src/egcs/gcc/gcov.c:1403: fixed or forbidden register 32 ($f0) was spilled for class FLOAT_REGS.
/home/msc/oliva/src/egcs/gcc/gcov.c:1403: This may be due to a compiler bug or to impossible asm
/home/msc/oliva/src/egcs/gcc/gcov.c:1403: statements or clauses.
/home/msc/oliva/src/egcs/gcc/gcov.c:1403: This is the instruction:
(insn 3354 3356 18 (set (reg:DF 594)
        (mem/u:DF (reg:DI 580) 0)) 279 {movsf-2} (insn_list 3350 (nil))
    (expr_list:REG_EQUIV (const_double:DF (mem/u:DF (symbol_ref/u:DI ("*$LC28")) 0) 4636737291354636288 [0x4059000000000000] 0 [0x0] [100])
        (nil)))

Is there any way I could help tracking this one down?  I don't know
much of alpha assembly, and I have never debugged gcc very much, but
if someone would be willing to ``drive'' me, I'd be glad to help.
Just send me e-mail, in private or to the list.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: possible bug on PPC/ GNU/LINUX

[Daniel Jacobowitz]

On Tue, Jun 15, 1999 at 08:35:39AM -0700, Mike Stump wrote:
> See the manual, I'll quote the relevant parts I think might apply to
> you below.  Also, doing this is _NOT_ portable.  You will want to find
> a way that is portable on all platforms and then tweak this up for
> those platforms that can support it.  For example, x86 with -fPIC and
> -O0 (or maybe -O9) you may find that there is nothing that you can do
> that will make it work (no free registers).
> 
> Further, these flags change the ABI of the software, and you will need
> to recompile all C code with your flags, this includes things like the
> library and friends (or if you are specifically very careful, you
> might be able to mix and match compiled C codes).
> 
> As to finding a register, oh, might as well pick the first saved one
> that is normally allocated.  See gcc/config/*/*.h (REG_ALLOC_ORDER,
> REGISTER_NAMES, CALL_USED_REGISTERS).
> 
> Now, some ABIs do allocate global registers for programmer use...
> and you may be able to do what you want easier on them.

If I am not mistaken, he should not have a compatibility problem if he
uses a register which is normally saved by function calls.  Any
function compiled with -ffixed-r15 -should- not touch it except in the
desired capacity; any function compiled without it should save/restore
it on exit.

Although, come to think about it, this would NOT be callback safe. A
library function might clobber r15, call the callback, and not restore
r15 until the function itself returned.  Thus signal handlers (?), etc.
would not be protected.

Right?

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

Re: possible bug on PPC/ GNU/LINUX

[Daniel Diaz]

Hi all,

obviously my command -line is false I used in fact -ffixed-15 (I simply tried 
before an impossible register to see if egcs produced a warning: no :-)).

However even with -ffixed-15 I have the same problem. 

>If I am not mistaken, he should not have a compatibility problem if he
>uses a register which is normally saved by function calls.  Any
>function compiled with -ffixed-r15 -should- not touch it except in the
>desired capacity; any function compiled without it should save/restore
>it on exit.

I expected such a behavior. When I recompile my whole Prolog system (more 
than 60000 of C code) I have no problem using r14 and r15 with -O but I have 
when no using -O. I then suspected a bug. To use global registers I generally 
use nonvolatile registers since each function modifying it should restore it. 
so I can safely call ANY library function (respecting the ABI) and for my own 
code gcc/egcs correctly handles these registers. When it cannot do this a 
warning (something like global clobbered register I don't remember well) is 
emitted.

Since I implement a compiler it is a big advantage to map the registers of my 
abstract machine to real registers... 

Thanks to all people developping and improving gcc...


-- 
===============================================
                 Daniel Diaz
University of Paris 1      INRIA Rocquencourt
   75013 Paris           78153 Le Chesnay Cedex
     FRANCE                     FRANCE
        email: Daniel.Diaz@inria.fr
===============================================

possible bug on PPC/ GNU/LINUX

[Daniel Diaz]

Hello,

I'm the author of GNU Prolog and I discovered a bug (I think) while porting 
my system under PowerPC / GNU/Linux. I need to use a register to store a 
global variable. Since I cannot find any documentation about which registers 
I can use I have tried several ones. In particular I use r15 to store the 
content of a global variable. Since the compiler does not emit an error when 
using this register I suppose it is OK (r15 is a nonvolatile register wrt to 
the ABI). When compiling without any optimization flag the function preamble 
saves (and then restores) the content of r15. Thus I cannot use it. Under 
other architectures the compilers wanr about a global-clobbered register.

architecture (uname -a):
Linux macopine 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999 ppc unknown

Here is the program bug.c

register long *reg_bank asm("15");

void foo(void)
{
 reg_bank=0;
}


1) compiling without -O:

macopine:~/Loews/GNU-Prolog/src/EnginePl$ gcc -v -S -ffixed-8 bug.c
Reading specs from /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
 /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/cpp -lang-c -v -undef 
-D__GNUC__=2 -D__GNUC_MINOR__=91 -DPPC -D__ELF__ -Dunix -Dlinux -Dpowerpc 
-D__PPC__ -D__ELF__ -D__unix__ -D__linux__ -D__powerpc__ -D__PPC -D__unix 
-D__linux -D__powerpc -Asystem(unix) -Asystem(linux) -Acpu(powerpc) 
-Amachine(powerpc) -D__CHAR_UNSIGNED__ -D_CALL_SYSV -D_BIG_ENDIAN 
-D__BIG_ENDIAN__ -Amachine(bigendian) -D_ARCH_PPC -D__unix__ -D__linux__ 
-Dunix -Dlinux -Asystem(unix) -Asystem(linux) bug.c /tmp/ccSiKgqa.i
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (PowerPC GNU/Linux)
#include "..." search starts here:
#include <...> search starts here:
 /usr/ppc-redhat-linux/include
 /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/cc1 /tmp/ccSiKgqa.i -quiet 
-dumpbase bug.c -version -ffixed-8 -o bug.s
GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release) (ppc-redhat-linux) 
compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release).

looking at the assembly file:

        .file   "bug.c"
gcc2_compiled.:
        .section        ".text"
        .align 2
        .globl foo
        .type    foo,@function
foo:
        stwu 1,-80(1)
        stw 15,12(1)
        stw 16,16(1)
        stw 17,20(1)
        stw 18,24(1)
        stw 19,28(1)
        stw 20,32(1)
        stw 21,36(1)
        stw 22,40(1)
        stw 23,44(1)
        stw 24,48(1)
        stw 25,52(1)
        stw 26,56(1)
        stw 27,60(1)
        stw 28,64(1)
        stw 29,68(1)
        stw 30,72(1)
        stw 31,76(1)
        mr 31,1
        li 15,0
.L1:
        lwz 11,0(1)
        lwz 15,-68(11)
        lwz 16,-64(11)
        lwz 17,-60(11)
        lwz 18,-56(11)
        lwz 19,-52(11)
        lwz 20,-48(11)
        lwz 21,-44(11)
        lwz 22,-40(11)
        lwz 23,-36(11)
        lwz 24,-32(11)
        lwz 25,-28(11)
        lwz 26,-24(11)
        lwz 27,-20(11)
        lwz 28,-16(11)
        lwz 29,-12(11)
        lwz 30,-8(11)
        lwz 31,-4(11)
        mr 1,11
        blr
.Lfe1:
        .size    foo,.Lfe1-foo
        .ident  "GCC: (GNU) egcs-2.91.66 19990314 (egcs-1.1.2 release)"


r15 is incorrectly saved/restored.


2) With -O option:
Reading specs from /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
 /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/cpp -lang-c -v -undef 
-D__GNUC__=2 -D__GNUC_MINOR__=91 -DPPC -D__ELF__ -Dunix -Dlinux -Dpowerpc 
-D__PPC__ -D__ELF__ -D__unix__ -D__linux__ -D__powerpc__ -D__PPC -D__unix 
-D__linux -D__powerpc -Asystem(unix) -Asystem(linux) -Acpu(powerpc) 
-Amachine(powerpc) -D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -D_CALL_SYSV 
-D_BIG_ENDIAN -D__BIG_ENDIAN__ -Amachine(bigendian) -D_ARCH_PPC -D__unix__ 
-D__linux__ -Dunix -Dlinux -Asystem(unix) -Asystem(linux) bug.c 
/tmp/cclZMV77.i
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (PowerPC GNU/Linux)
#include "..." search starts here:
#include <...> search starts here:
 /usr/ppc-redhat-linux/include
 /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/ppc-redhat-linux/egcs-2.91.66/cc1 /tmp/cclZMV77.i -quiet 
-dumpbase bug.c -O -version -ffixed-8 -o bug.s
GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release) (ppc-redhat-linux) 
compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release).


The assembly:

        .file   "bug.c"
gcc2_compiled.:
        .section        ".text"
        .align 2
        .globl foo
        .type    foo,@function
foo:
        li 15,0
        blr
.Lfe1:
        .size    foo,.Lfe1-foo
        .ident  "GCC: (GNU) egcs-2.91.66 19990314 (egcs-1.1.2 release)"

Here r15 is correctly handled.

Is it a bug ? Where can I find information on which registers I can use (and 
this for several machines, e.g. ix86, alpha, PPC).


-- 
===============================================
                 Daniel Diaz
University of Paris 1      INRIA Rocquencourt
   75013 Paris           78153 Le Chesnay Cedex
     FRANCE                     FRANCE
        email: Daniel.Diaz@inria.fr
===============================================

Re: possible bug on PPC/ GNU/LINUX

[Mike Stump]

> Date: Tue, 15 Jun 1999 12:26:43 -0400
> From: Daniel Jacobowitz <drow@false.org>

> If I am not mistaken, he should not have a compatibility problem if
> he uses a register which is normally saved by function calls.

Almost, but see the below.

> Although, come to think about it, this would NOT be callback safe.

Bingo.  Unfortunately, C allows pointers to functions, and sometimes
people use them.  gcc typically can't claim to work without them.
Though, an application can promise not to do that.  Though the problem
will just come later, when someone adds a callback to do something,
they don't realize what the previous programmer promised, and they
expect it to work, then they file a bug report, we read it, and after
a little while we say, that's not supposed to work.  :-(
>From law@cygnus.com Tue Jun 15 10:49:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Dave Love <d.love@dl.ac.uk>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: mail lossage 
Date: Tue, 15 Jun 1999 10:49:00 -0000
Message-id: <2552.929468592@upchuck.cygnus.com>
References: <rzqzp21ssfy.fsf@djlvig.dl.ac.uk>
X-SW-Source: 1999-06/msg00434.html
Content-length: 646

  In message < rzqzp21ssfy.fsf@djlvig.dl.ac.uk >you write:
  > I've just realized that things I've tried to post to the egcs list
  > have gone into a black hole.
  > 
  > Somehow I managed to resurrect some old Gnus configuration with the
  > list name as `egcs@cygnus.com'.  Clearly stuff sent there just
  > disappears.  I think it should at least bounce.
  > 
  > Would bug reports have gone the same way?
They should bounce -- at least the first should always bounce.  When you bounce
a message via @cygnus.com you get put into a cache -- when you're in the cache
you don't get bounces until you're flushed out of the cache.

jeff



jeff

Re: possible bug on PPC/ GNU/LINUX

[Daniel Jacobowitz]

[Disclaimer: I Am Not An ABI Lawyer]


On Tue, Jun 15, 1999 at 05:10:24PM +0200, Daniel Diaz wrote:
> Hello,
> 
> I'm the author of GNU Prolog and I discovered a bug (I think) while porting 
> my system under PowerPC / GNU/Linux. I need to use a register to store a 
> global variable. Since I cannot find any documentation about which registers 
> I can use I have tried several ones. In particular I use r15 to store the 
> content of a global variable. Since the compiler does not emit an error when 
> using this register I suppose it is OK (r15 is a nonvolatile register wrt to 
> the ABI). When compiling without any optimization flag the function preamble 
> saves (and then restores) the content of r15. Thus I cannot use it. Under 
> other architectures the compilers wanr about a global-clobbered register.
> 
> architecture (uname -a):
> Linux macopine 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999 ppc unknown
> 
> Here is the program bug.c
> 
> register long *reg_bank asm("15");
> 
> void foo(void)
> {
>  reg_bank=0;
> }

> Is it a bug ? Where can I find information on which registers I can use (and 
> this for several machines, e.g. ix86, alpha, PPC).


Are you so sure that r15 is nonvolatile wrt the ABI?  In
gcc/config/rs6000.c I see this:

  /* Find lowest numbered live register.  */
  for (first_reg = 13; first_reg <= 31; first_reg++)
    if (regs_ever_live[first_reg])
      break;

This implies to me that everything from r13 on up should be
saved/restored.  I noticed you specified -ffixed-r8 on the command
line - what about using asm("8") ?  Without -ffixed-r8 this does
produce a warning, but with it there should be no problem.

What I find somewhat more interesting is that r15 is saved/restored
even if -ffixed-r15 is specified.  Something must be wrong with that -
either those registers should not be allowed to be fixed, or they
should be correctly fixed.  The prologue most definitely generates code
which refers to them.

Also from rs6000.c, in output_prolog:

      for ( ; regno < 32; regno++, loc += reg_size)
        asm_fprintf (file, store_reg, reg_names[regno], loc, reg_names[sp_reg]);

The comparable section of config/alpha/alpha.c, in alpha_sa_mask, does
this test to decide whether to actually save the register:

      for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
        if (! fixed_regs[i] && ! call_used_regs[i]
            && regs_ever_live[i] && i != REG_RA)

Should we be doing this also?  It would seem so.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/
>From drow@false.org Tue Jun 15 09:25:00 1999
From: Daniel Jacobowitz <drow@false.org>
To: Mike Stump <mrs@wrs.com>
Cc: Daniel.Diaz@inria.fr, egcs-bugs@egcs.cygnus.com
Subject: Re: possible bug on PPC/ GNU/LINUX
Date: Tue, 15 Jun 1999 09:25:00 -0000
Message-id: <19990615122643.A15648@drow.res.cmu.edu>
References: <199906151535.IAA22336@kankakee.wrs.com> <199906151535.IAA22336@kankakee.wrs.com>
X-SW-Source: 1999-06/msg00431.html
Content-length: 1941

On Tue, Jun 15, 1999 at 08:35:39AM -0700, Mike Stump wrote:
> See the manual, I'll quote the relevant parts I think might apply to
> you below.  Also, doing this is _NOT_ portable.  You will want to find
> a way that is portable on all platforms and then tweak this up for
> those platforms that can support it.  For example, x86 with -fPIC and
> -O0 (or maybe -O9) you may find that there is nothing that you can do
> that will make it work (no free registers).
> 
> Further, these flags change the ABI of the software, and you will need
> to recompile all C code with your flags, this includes things like the
> library and friends (or if you are specifically very careful, you
> might be able to mix and match compiled C codes).
> 
> As to finding a register, oh, might as well pick the first saved one
> that is normally allocated.  See gcc/config/*/*.h (REG_ALLOC_ORDER,
> REGISTER_NAMES, CALL_USED_REGISTERS).
> 
> Now, some ABIs do allocate global registers for programmer use...
> and you may be able to do what you want easier on them.

If I am not mistaken, he should not have a compatibility problem if he
uses a register which is normally saved by function calls.  Any
function compiled with -ffixed-r15 -should- not touch it except in the
desired capacity; any function compiled without it should save/restore
it on exit.

Although, come to think about it, this would NOT be callback safe. A
library function might clobber r15, call the callback, and not restore
r15 until the function itself returned.  Thus signal handlers (?), etc.
would not be protected.

Right?

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/
>From Daniel.Diaz@inria.fr Tue Jun 15 09:39:00 1999
From: Daniel Diaz <Daniel.Diaz@inria.fr>
To: Daniel Jacobowitz <drow@false.org>
Cc: Mike Stump <mrs@wrs.com>, egcs-bugs@egcs.cygnus.com
Subject: Re: possible bug on PPC/ GNU/LINUX 
Date: Tue, 15 Jun 1999 09:39:00 -0000
Message-id: <199906151639.SAA10200@margaux.inria.fr>
References: <19990615122643.A15648@drow.res.cmu.edu>
X-SW-Source: 1999-06/msg00432.html
Content-length: 1541

Hi all,

obviously my command -line is false I used in fact -ffixed-15 (I simply tried 
before an impossible register to see if egcs produced a warning: no :-)).

However even with -ffixed-15 I have the same problem. 

>If I am not mistaken, he should not have a compatibility problem if he
>uses a register which is normally saved by function calls.  Any
>function compiled with -ffixed-r15 -should- not touch it except in the
>desired capacity; any function compiled without it should save/restore
>it on exit.

I expected such a behavior. When I recompile my whole Prolog system (more 
than 60000 of C code) I have no problem using r14 and r15 with -O but I have 
when no using -O. I then suspected a bug. To use global registers I generally 
use nonvolatile registers since each function modifying it should restore it. 
so I can safely call ANY library function (respecting the ABI) and for my own 
code gcc/egcs correctly handles these registers. When it cannot do this a 
warning (something like global clobbered register I don't remember well) is 
emitted.

Since I implement a compiler it is a big advantage to map the registers of my 
abstract machine to real registers... 

Thanks to all people developping and improving gcc...


-- 
===============================================
                 Daniel Diaz
University of Paris 1      INRIA Rocquencourt
   75013 Paris           78153 Le Chesnay Cedex
     FRANCE                     FRANCE
        email: Daniel.Diaz@inria.fr
===============================================