Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Colm O' Flaherty]

Does anyone have any ideas about what gcc support is like for targets with 
no data stack?  The 14 bit cores (16F) mostly have a 2-8 level hardware 
stack, which is not part of the program or data memory, and is not 
addressable.  There is no data stack.


I'm hoping that there is an existing backend architecture where there is no 
stack, so that I can have a peep to see how the code fakes stack support, 
but so far, all the obvious candidates (the microcontrollers) seem to have a 
stack.


Ideas, anyone?

Colm

Re: Qemu and GCC-3.4 on powerpc

[Gabriel Paubert]

On Sun, Apr 09, 2006 at 02:45:04PM +0200, Dieter Schuster wrote:
> Tach auch!
> 
> Am Fr, den 31 März 2006, schrieb Alan Modra:
> > On Tue, Mar 28, 2006 at 12:00:47PM +0200, Gabriel Paubert wrote:
> > > On Tue, Mar 28, 2006 at 12:56:13AM +0200, Dieter Schuster wrote:
> > > > If I try to compile qemu with GCC 3.4 without the patch I get the 
> > > > following error:
> > > > 
> > > > qemu-0.8.0/linux-user/elfload.c: In function `load_elf_binary':
> > > > qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an 
> > > > `asm'
> > > > qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an 
> > > > `asm'
> > > 
> > > Weird. CC'ed to gcc list despite the fact that the 3.4 branch
> > > is definitely closed. I've not found anything remotely similar
> > > from bugzilla.
> > > 
> > > > 
> > > > But if I copy the function stl_le_p to a seperate file, the function
> > > > will compile with GCC 3.4. 
> > 
> > Check preprocessor output.  My guess is that you have some unexpected
> > substitution.
> > 
> 
> I had now more time, to investigate the error. It seems to be a
> optimization problem. With -O2 -fno-gcse the error disappeared. I have
> made a bug report to gcc. 

Yes, but you sent it to gnats-gcc, which is completely obsolete. You
should use bugzilla. Now the testcase looks really minimal:

http://lists.debian.org/debian-gcc/2006/04/msg00135.html

even if the code looks strange (redundant cast, if without 
braces which confused me at first). This may be the result
of normal macro expansion.

However, I believe that the most serious problem is that you 
use uninitialized local variables (which makes the code invalid). 
I have changed the testcase to the attached file by declaring 
these variables extern (the code is also reformatted to be more 
readable).

Testing here with recent Debian versions of gcc-3.4, 4.0 and 4.1
show that I can' trigger any problem with 4.0 and 4.1, and that 
for gcc-3.4:
- -O1 always works (regardless of -fgcse), which is surprising 
  since I have exactly the same compiler as you.
- -O2 -fno-gcse works
- -O2 (implies -fgcse) fails

In the failure case, the generated code (attached) does not make 
sense: one stwbrx disappears and is mysteriously replaced by an 
stw, the source of which is a register which has never been 
initialized (r8), while I don't see any uninitialized variable
in the source after the small changes I've made.

Regards,
Gabriel
static inline void stl(void *ptr, int v) {
__asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*(unsigned long *)ptr) : "r" 
(v), "r" (ptr));
}

int main () {
  extern unsigned long *sp, *u_platform;
  extern char *k_platform;

  stl(sp, (unsigned long)(0)); 
  stl(sp+1, (unsigned long)(0));

  if (k_platform)
stl(sp, (unsigned long)(15)); 

  stl(sp+1, (unsigned long)((unsigned long) u_platform));
  return 0;
}
.file   "bug.i"
.section".text"
.align 2
.globl main
.type   main, @function
main:
lis 11,[EMAIL PROTECTED]
lis 9,[EMAIL PROTECTED]
lwz 0,[EMAIL PROTECTED](11)
lwz 10,[EMAIL PROTECTED](9)
li 9,15
cmpwi 7,0,0
beq- 7,.L7
#APP
stwbrx 9,0,10
#NO_APP
lis 9,[EMAIL PROTECTED]
addi 11,10,4
lwz 0,[EMAIL PROTECTED](9)
#APP
stwbrx 0,0,11
#NO_APP
li 3,0
blr
.L7:
lis 9,[EMAIL PROTECTED]
stw 8,0(10)
addi 11,10,4
lwz 0,[EMAIL PROTECTED](9)
#APP
stwbrx 0,0,11
#NO_APP
li 3,0
blr
.size   main,.-main
.section.note.GNU-stack,"",@progbits
.ident  "GCC: (GNU) 3.4.6 (Debian 3.4.6-1)"

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[François Poulain]

Ok I was wrong. Maybe you could contact John Elliott
([EMAIL PROTECTED]), because I 'm not an English native speaker
and I don't understand all the juridic terms. I also think that the
goodness of the question often makes the goodness of the answer.

Best regards,

Francois Poulain

Le dimanche 09 avril 2006 à 21:49 -0500, Aaron W. LaFramboise a écrit :
> François Poulain wrote:
> 
> > If I'm right, here are copyright assignments to FSF for the Microchip's
> > contributions for GCC.
> 
> Unfortunately, this is not good enough.  A copyright assignment is a 
> formal contract that must be physically signed and sent to the FSF.  See 
>  for details.
> 
> Since as far as I can tell John Elliot has not attempted to include his 
> changes in the official FSF GCC, it is very that he has a copyright 
> assignment.  Any work based on work by him would require an assignment 
> from him also--and most likely his employer, Microchip.
> 
> There is an official list somewhere of who has copyright assignments on 
> file.  Alternately, whatever work he has done were thought to be 
> valuable, someone could just email him and ask. :)
> 

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Rask Ingemann Lambertsen]

On Mon, Apr 10, 2006 at 07:54:24AM +, Colm O' Flaherty wrote:
> I'm hoping that there is an existing backend architecture where there is no 
> stack, so that I can have a peep to see how the code fakes stack support, 
> but so far, all the obvious candidates (the microcontrollers) seem to have 
> a stack.

The PowerPC (look in config/rs6000) has no stack.

All GCC needs is that you define a register to be the stack pointer
(STACK_POINTER_REGNUM) and this register doesn't have to be a base register
(see "Addressing modes" in the GCC Internals manual). Even a pushm1 pattern
(see "Standard Pattern Names for Generation") is not necessary if you are
happy with the code that GCC itself comes up with.

-- 
Rask Ingemann Lambertsen

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Colm O' Flaherty]

Happy days.. That wasn't obvious to me.  I'll check out the details later.

Thanks.

Colm


The PowerPC (look in config/rs6000) has no stack.

All GCC needs is that you define a register to be the stack pointer
(STACK_POINTER_REGNUM) and this register doesn't have to be a base register
(see "Addressing modes" in the GCC Internals manual). Even a pushm1 pattern
(see "Standard Pattern Names for Generation") is not necessary if you are
happy with the code that GCC itself comes up with.

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Robert Dewar]

Colm O' Flaherty wrote:

Happy days.. That wasn't obvious to me.  I'll check out the details later.


In fact many RISC chips have no specific hardware support for
a stack (MIPS is another example of such an architecture).

Reloading Problems and Memory Addressing

[Frank Riese]

Hi!

Im writing a backend for GCC 4.0-2 for a simple machine with a rather limited 
instruction set. With the kind help of Ian Lance Taylor I was already able to 
solve a few big problems I had earlier. Now I am stuck on another problem 
that IMHO concerns reloading. 

Most of the instructions of the target machine only support registers as 
operands. E.g., a store to a memory location (STO) must always take a 
register containing the address of the memory location and another register 
with the data to be written to that location as arguments. The assembler does 
not support any arithmetic expressions. The only way to get a constant 
directly into a register is to load the high and low part of it with two 
instructions (LDH/LDL).

However, GCC kept generating instructions like these:

;#(insn 9 7 95 (set (mem/i:HI (plus:HI (reg/f:HI 6 BP)
;#(const_int -6 [0xfffa])) [0 x+0 S2 A16])
;#(const_int 0 [0x0])) 13 {movhi} (nil)
;#(nil))

I needed GCC to put "BP-6" into a register first and then do sth. like (set 
(mem (reg REG)) (const_int 0)).

From what I understood when reading the GCC internals 
docs "GO_IF_LEGITIMATE_ADDRESS" might be the right place to tackle this 
problem. I took that macro from the PDP-11 backend and tried to adjust it to 
my needs. There was a part that looked like this:

[...]
if (GET_CODE (operand) == PLUS  \
&& GET_CODE (XEXP (operand, 0)) == REG  \
&& REG_OK_FOR_BASE_P (XEXP (operand, 0))\
&& CONSTANT_ADDRESS_P (XEXP (operand, 1)))  \
  goto ADDR;\
[...]

I removed those lines so that it now rejects "PLUS" operands. When I compile 
GCC I now get the following message:

[...]
make[2]: Entering directory `/usr/local/src/gcc-4.0-4.0.2/objdir-zykluno/gcc'
/usr/local/src/gcc-4.0-4.0.2/objdir/gcc/xgcc 
-B/usr/local/src/gcc-4.0-4.0.2/objdir/gcc/ 
-B/usr/local/zykluno/bin/ -B/usr/local/zykluno/lib/ -isystem 
/usr/local/zykluno/include 
-isystem /usr/local/zykluno/sys-include -O2  -DIN_GCC -DCROSS_COMPILE   -W 
-Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
 
-isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc 
-I. -I. -I../../gcc-4.0.2/gcc -I../../gcc-4.0.2/gcc/. 
-I../../gcc-4.0.2/gcc/../include 
-I../../gcc-4.0.2/gcc/../libcpp/include  -DL_muldi3 -c 
../../gcc-4.0.2/gcc/libgcc2.c -o 
libgcc/./_muldi3.o

cc1: warning: target system does not support debug output
../../gcc-4.0.2/gcc/libgcc2.c: In function '__muldi3':
../../gcc-4.0.2/gcc/libgcc2.c:533: error: unable to find a register to spill 
in class 'GENERAL_REGS'
../../gcc-4.0.2/gcc/libgcc2.c:533: error: this is the insn:

(insn 260 259 266 4 ../../gcc-4.0.2/gcc/libgcc2.c:533 (set (reg/f:HI 5 R[5] 
[+6 ])
(subreg:HI (reg:SI 102) 2)) 14 {movhi} (nil)
(expr_list:REG_DEAD (reg:SI 102)
(nil)))

../../gcc-4.0.2/gcc/libgcc2.c:533: confused by earlier errors, bailing out
[...]


If it helps, I have eight registers of which half of them need to be fixed 
(first 2 fixed by hardware, last 2 BP/SP):

#define FIXED_REGISTERS  {1, 1, 0, 0, 0, 0, 1, 1}
#define REGISTER_NAMES 
{"R[0]", "R[1]", "R[2]", "R[3]", "R[4]", "R[5]", "BP", "SP"}

#define REG_CLASS_NAMES {"NO_REGS", "GENERAL_REGS", "ALL_REGS" }
#define REG_CLASS_CONTENTS {{0x00}, {0xfc}, {0xff}}

However, it built gcc-cross, I tried it out and it seems to do just what I 
want it to now:

;#(insn 136 7 10 (set (reg:HI 3 R[3])
;#(const_int -6 [0xfffa])) 14 {movhi} (nil)
;#(nil))
LDH R[3], 65280 ;# 136  movhi/4
LDL R[3], 250
;#(insn 10 136 137 (set (reg/f:HI 2 R[2] [25])
;#(plus:HI (reg/f:HI 6 BP)
;#(reg:HI 3 R[3]))) 19 {addhi3} (nil)
;#(nil))
ADD R[2], BP, R[3]  ;# 10   addhi3
;#(insn 137 10 11 (set (reg:HI 4 R[4])
;#(const_int 0 [0x0])) 14 {movhi} (nil)
;#(nil))
LDH R[4], 0 ;# 137  movhi/4
LDL R[4], 0
;#(insn 11 137 133 (set (mem/i:HI (reg/f:HI 2 R[2] [25]) [0 x+0 S2 A16])
;#(reg:HI 4 R[4])) 14 {movhi} (nil)
;#(nil))
STO R[2], R[4]  ;# 11   movhi/3

The generated code seems to be still correct.

So, I am wondering: how does that error affect the generated compiler and what 
is the reason for it? 

>From what I understood, the problem is related to realoading. IMHO the 
compiler needs additional registers for the constants that it previously 
directly used as operands and now has to store into registers before passing 
one as an argument to an instructions. I'm not sure though and I would 
appreciate any thoughts on that. 

If the reason really is the pressure on the already scarce registers, would it 
be a good idea to get GCC to use the stack in order to temporarily free up 
registers for such things? If so, could somebody point me into the right 
di

Re: Reloading Problems and Memory Addressing

[Rask Ingemann Lambertsen]

On Mon, Apr 10, 2006 at 03:23:43PM +0200, Frank Riese wrote:
> 
> Most of the instructions of the target machine only support registers as 
> operands. E.g., a store to a memory location (STO) must always take a 
> register containing the address of the memory location and another register 
> with the data to be written to that location as arguments. The assembler does 
> not support any arithmetic expressions. The only way to get a constant 
> directly into a register is to load the high and low part of it with two 
> instructions (LDH/LDL).

Can it at least add (small) immediates to registers?

> From what I understood when reading the GCC internals 
> docs "GO_IF_LEGITIMATE_ADDRESS" might be the right place to tackle this 
> problem. I took that macro from the PDP-11 backend and tried to adjust it to 
> my needs.

IIRC, the PDP-11 is famous for accepting complex addresses, i.e. quite the
opposite of your target machine, which is so simple I would suggest you write
it from scratch. Does it need to be more than

#define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL)   \
if (REG_P (X))  \
goto LABEL;

?

A subtle detail of GCC is that (call ) expressions have an extra (mem )
around the function address. I.e. (call (mem:HI (symbol_ref "foobar")))
or (call (mem:HI (reg:HI 4))) instead of just (call (symbol_ref "foobar"))
or (call (reg:HI 4)). However, even if GO_IF_LEGITIMATE_ADDRESS() rejects
(mem:HI (symbol_ref "foobar")) then it can show up in a (call ) expression.

> ../../gcc-4.0.2/gcc/libgcc2.c: In function '__muldi3':
> ../../gcc-4.0.2/gcc/libgcc2.c:533: error: unable to find a register to spill 
> in class 'GENERAL_REGS'
> ../../gcc-4.0.2/gcc/libgcc2.c:533: error: this is the insn:
> 
> (insn 260 259 266 4 ../../gcc-4.0.2/gcc/libgcc2.c:533 (set (reg/f:HI 5 R[5] 
> [+6 ])
> (subreg:HI (reg:SI 102) 2)) 14 {movhi} (nil)
> (expr_list:REG_DEAD (reg:SI 102)
> (nil)))

Try to add -fdump-rtl-greg or -fdump-rtl-greg-details when compiling
__muldi3(). This will generate a libgcc2.c.*.greg file which will say
exactly which reloads insn 260 has and which one is failing.

1) Does BP really have to be fixed? You are sufficiently desparate for
registers than you'll not fix BP unless the hardware itself mandates this.

2) GCC generally doesn't handle multi-word registers well. Even if you ask
for a subreg, it will either load it all into registers or nothing at all.
Richard Henderson posted a "multi-word subreg lowering" patch a while ago,
which might help. See
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html>. The patch
needs to be updated to work on current mainline, though.

3) Reload sometimes fritters away registers. DJ Delorie recently submitted a
patch to allow chaining of reloads, which reduces the number of registers
needed in some cases. This will only help you if you upgrade your code base
to mainline, though.

If you can, develop against mainline rather than an old version of GCC.

> So, I am wondering: how does that error affect the generated compiler and 
> what 
> is the reason for it? 

It means that the compiler is unable to generate code is some cases. It
doesn't mean that the code it does generate is wrong.

> I read in other posts that reloading is supposed to be one of the trickiest 
> parts to get right with an initial port.

If you have few (meaning less than about 8) free registers, they are
small (say, 16 bits or less each), maybe not even the same size and/or some
instructions require the operands to be in specific registers, then yes,
definitely.

> I still have a hard time understanding how reloading works.

I've been single stepping through various parts of reload over the last five
months and still don't understand many parts of it, but I'll help you with
those parts that I do understand.

> The information I found in the gcc 
> internals docs and other parts of the inet are pretty widespread. I would be 
> glad if someone knows a page that specifically discusses reloading.
> 
> I tried to post everything of relevance to the problem. If you need anything 
> else, please ask and I will post it.

-- 
Rask Ingemann Lambertsen

Re: GCC Compiler Engineer job (I am not a recruiter)

[Mark Mitchell]

Rick Edwards wrote:

> We are a strong and growing company working in some very advanced DSP
> silicon.

We have (had) a policy against these kinds of recruiting messages on the
GCC lists.  Instead, it was suggested that people work through the FSF's
job-listing service.  Unfortunately, I can't find the messages (from
back in the EGCS days, IIRC) where that policy was discussed.  It also
used to be part of a FAQ on the web site, but I can't find it there
either.  So, I can't see how you could possibly have known about this
policy, and no criticism is intended!

Recently, there has your message, and Benjamin Kosnik's message about
internships -- so we need to either reconfirm the earlier policy, or
decide that it's obsolete.

Clearly, CodeSourcery has an interest in the outcome.  Either resolution
is OK by me, but if it's now considered OK to advertise job listings on
the lists, then we're certainly going to do it too, and if it's still
not OK, then we ought to try to find some way to make clear to people
that this is not an appropriate use of the lists.  Otherwise, we're in
the situation where people who know the history can't use the lists to
advertise job listings, but new players can.

Thoughts?

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Mike Stump]

On Apr 9, 2006, at 3:39 AM, Aaron W. LaFramboise wrote:
Just as a reminder, even though the Microchip code is covered by  
the GPL, code based on it won't be acceptable for inclusion into  
FSF GCC unless you can get Microchip to sign a copyright  
assignment, which seems unlikely.


Would seem to be easy enough to do, just, one cannot count on it.   
People that want to start from that code should open a dialogue now,  
before they start.

Use of VARRAY in alias analysis

[Kazu Hirata]

Hi Daniel and Diego,

Several months ago, you mentioned that the alias analysis in gcc would
be overhauled.  Has this happened yet?  If not, I am thinking about
working on alias.c and tree-ssa-alias.c as there are only a handful of
VARRAY uses left.

Thanks,

Kazu Hirata

Re: Use of VARRAY in alias analysis

[Daniel Berlin]

On Apr 10, 2006, at 3:23 PM, Kazu Hirata wrote:


Hi Daniel and Diego,

Several months ago, you mentioned that the alias analysis in gcc would
be overhauled.  Has this happened yet?  If not, I am thinking about
working on alias.c and tree-ssa-alias.c as there are only a handful of
VARRAY uses left.



Any varray's left in those two are fair game for removal, as far as i  
am concerned.

Re: Use of VARRAY in alias analysis

[Diego Novillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/10/06 15:23, Kazu Hirata wrote:

> Several months ago, you mentioned that the alias analysis in gcc would
> be overhauled.  Has this happened yet?  If not, I am thinking about
> working on alias.c and tree-ssa-alias.c as there are only a handful of
> VARRAY uses left.
> 
It's happening in the mem-ssa branch.  But switching from VARRAY to VEC
will probably not affect my work, so go ahead.  I guess that's what you
have in mind?  Switching VARRAY to VEC?


Cheers.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEOrQdUTa2oAUaiwQRAn75AJ47cnQzKKYf69VrrL04GrA53q0TyQCfVz7A
UwlwZ6xaB4HiaQI3TSIPATc=
=Wcf2
-END PGP SIGNATURE-

Re: GCC Compiler Engineer job (I am not a recruiter)

[Mike Stump]

On Apr 10, 2006, at 11:48 AM, Mark Mitchell wrote:

Thoughts?


We don't want to open the flood gates to random recruiters for random  
software, however, I never saw the harm in solicitations from gcc  
contributors for people to work on gcc.  If we were to relax the  
current policy, we can have a policy of only write-after or better  
people can advertise.  Also, the FSF will require that the job  
advertised be for free-software and free of non-free things (see  
http://www.fsf.org/jobs/).  So, one cannot say, Word experience  
required, or wanted people to work on gcc and Visual Studio.


I think that maybe a section in the wiki might be an interesting  
compromise and allowing just a pointer to it on the list.


Back in the 97-99 timeframe I was the one asking, and I was directed  
to comp.compilers and the FSF's jobs site (http://www.fsf.org/ 
jobs/).  I looked on the wayback machine, and couldn't narrow the date.

Re: Use of VARRAY in alias analysis

[Kazu Hirata]

Hi Diego,


Several months ago, you mentioned that the alias analysis in gcc would
be overhauled.  Has this happened yet?  If not, I am thinking about
working on alias.c and tree-ssa-alias.c as there are only a handful of
VARRAY uses left.



It's happening in the mem-ssa branch.  But switching from VARRAY to VEC
will probably not affect my work, so go ahead.  I guess that's what you
have in mind?  Switching VARRAY to VEC?


Yes, thanks!

Kazu Hirata

Re: GCC Compiler Engineer job (I am not a recruiter)

[Joe Buck]

On Mon, Apr 10, 2006 at 11:48:55AM -0700, Mark Mitchell wrote:
> We have (had) a policy against these kinds of recruiting messages on the
> GCC lists...
> 
> Recently, there has your message, and Benjamin Kosnik's message about
> internships -- so we need to either reconfirm the earlier policy, or
> decide that it's obsolete.

I'm inclined to think that it serves gcc if the list can be used to
recruit people to work on gcc for pay.  Of course an FSF list cannot
sanction offers for proprietary software development, and I wouldn't want
to see offers for unrelated software work.

But I don't see the merit in banning offers to work on GCC (or related
parts of the toolchain like binutils and gdb), assuming that the work is
to be contributed back at some point.  And if someone is seeking talent
to port gcc to a new processor, it would seem that this list is an ideal
mechanism to reach the right audience.

Since it is an FSF list, I suppose we need to clear a policy change with
RMS.  But I would argue that it's a good idea, and if we're suddenly
overwhelmed with people offering money to GCC developers for GCC work,
well, I can think of worse problems to have. :-)

Re: GCC Compiler Engineer job (I am not a recruiter)

[Mark Mitchell]

Joe Buck wrote:

> I'm inclined to think that it serves gcc if the list can be used to
> recruit people to work on gcc for pay.  Of course an FSF list cannot
> sanction offers for proprietary software development, and I wouldn't want
> to see offers for unrelated software work.

You and Mike have suggested that recruiting GCC developers is a
reasonable use of the list.  Before we go to the SC, asking for approval
to change the policy, we should address some other issues:

1. What do we do if people do advertise jobs that are not free software
jobs, or not purely free software jobs?  How pure is pure?  Does "Port
GCC to proprietary OS" count as free or not?

2. What frequency of posting do we want to allow?

3. How do we enforce any of these rules?

We already have problem (3) for the existing policy, but if we're going
to codify this, we might try to make it more formal.

The history behind the current policy was that we decided that since
these lists are about development, and since effective development
depends on competing companies working together, we'd try to avoid
potentially polarizing commercial commentary and recruiting, e.g. "Come
work at Foo.  We've got the world's best GCC peopl; much better than
those at Bar."  That kind of thing is perfectly reasonable for normal
hiring ads, but obviously inappropriate here.

I'm not opposed to opening up our policy, but I rather wonder if we
shouldn't just use the FSF's job board (which already meets FSF
requirements and is policed by the FSF), and then just allow people to
post links here, when a new job is posted there, or some such.  In that
model, I don't know how to solve the enforcement issue, but we could
post a policy next to the descriptions of the lists.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC Compiler Engineer job (I am not a recruiter)

[Jeffrey A Law]

On Mon, 2006-04-10 at 13:29 -0700, Mark Mitchell wrote:
> You and Mike have suggested that recruiting GCC developers is a
> reasonable use of the list.  Before we go to the SC, asking for approval
> to change the policy, we should address some other issues:
> 
> 1. What do we do if people do advertise jobs that are not free software
> jobs, or not purely free software jobs?  How pure is pure?  Does "Port
> GCC to proprietary OS" count as free or not?
> 
> 2. What frequency of posting do we want to allow?
> 
> 3. How do we enforce any of these rules?
> 
> We already have problem (3) for the existing policy, but if we're going
> to codify this, we might try to make it more formal.
> 
> The history behind the current policy was that we decided that since
> these lists are about development, and since effective development
> depends on competing companies working together, we'd try to avoid
> potentially polarizing commercial commentary and recruiting, e.g. "Come
> work at Foo.  We've got the world's best GCC peopl; much better than
> those at Bar."  That kind of thing is perfectly reasonable for normal
> hiring ads, but obviously inappropriate here.
> 
> I'm not opposed to opening up our policy, but I rather wonder if we
> shouldn't just use the FSF's job board (which already meets FSF
> requirements and is policed by the FSF), and then just allow people to
> post links here, when a new job is posted there, or some such.  In that
> model, I don't know how to solve the enforcement issue, but we could
> post a policy next to the descriptions of the lists.
I'd rather not open the door to job postings, even for GCC or
other free software work.  There's more appropriate venues for
such communication.  Plus I really don't want to have to sort
out the issues you've noted above.

The no job postings on gcc lists is clear, simple and easy to 
understand.  If abused we have the ability to block postings
and with the easy to understand policy, abuse is easy to identify.

Now, if we want to have a pointer to the FSF job board, that might
be a reasonable thing to do.  We could even have an automated 
monthly (or whatever frequency) message to point folks to the FSF
job board and remind everyone of the policy.

jeff

Re: GCC Compiler Engineer job (I am not a recruiter)

[Perry Smith]

On Apr 10, 2006, at 3:39 PM, Jeffrey A Law wrote:


On Mon, 2006-04-10 at 13:29 -0700, Mark Mitchell wrote:



I'd rather not open the door to job postings, even for GCC

  

I see myself as a consumer of this list and not a producer so it is  
hard to see myself as having a "vote".  But if I do, I agree with  
Jeff.  Keep it simple.


The one thing I was going to suggest but I don't know how hard it is  
to implement is to have a once a month note sent to this list that  
says "there are N GCC jobs on the FSF Job site." with a pointer to  
the job site.


Perry

Re: GCC Compiler Engineer job (I am not a recruiter)

[Mike Stump]

On Apr 10, 2006, at 1:29 PM, Mark Mitchell wrote:
1. What do we do if people do advertise jobs that are not free  
software

jobs


Ask them not to, ultimately the same thing we do with spammers.  :-)


or not purely free software jobs?


If on the wiki, edit out all the parts that aren't and tell them to  
re-read the guidelines.



How pure is pure?


I'd propose not differing from http://www.fsf.org/jobs/ 
guidelines.html (due to laziness, and because I know that the FSF  
will be more accepting of them on our list, if we follow those  
guidelines).



Does "Port GCC to proprietary OS" count as free or not?


Free, this is why gcc entertains accepting patches of gcc for such  
platforms and why the FSF's job's list advertises such positions.



2. What frequency of posting do we want to allow?


Once, I like wiki.


3. How do we enforce any of these rules?


Shame on those that violate them.


I'm not opposed to opening up our policy, but I rather wonder if we
shouldn't just use the FSF's job board


I don't see the harm in just deferring to them.  We could link it  
from the web/wiki to it, if we wanted, to encourage people to go that  
direction when they want to advertise.

Re: GCC Compiler Engineer job (I am not a recruiter)

[Mark Mitchell]

Mike Stump wrote:

>> 3. How do we enforce any of these rules?
> 
> Shame on those that violate them.

I think we need to do better than that.

If there's no viable enforcement mechanism, then people following the
policy are at a disadvantage to those who are not.  Traditional spam and
things better suited to gcc-help do not have this same impact.  Here, if
Company A and Company B both want to recruit, but A adheres to the
policy while B does not, A loses.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC Compiler Engineer job (I am not a recruiter)

[DJ Delorie]

> Here, if Company A and Company B both want to recruit, but A adheres
> to the policy while B does not, A loses.

I think that's a compelling reason to keep it at "no ads".  We've got
enough stress just developing gcc; we don't need the extra stress of
corporate pressure to act against our fellow developers.  The
existence of the FSF jobs list mitigates any remaining reason why we'd
want to have our own recruiting.

Thus, I vote with Jeff.

Re: GCC Compiler Engineer job (I am not a recruiter)

[Diego Novillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/10/06 17:35, DJ Delorie wrote:

> Thus, I vote with Jeff.
>
Likewise.  Companies ought to send job ads to comp.compilers or use the
FSF listing service.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEOtFpUTa2oAUaiwQRAjH9AKCafCNmwnSXOJDuLy5yIepgM7/DWQCfXPLi
gZN7eKZXPTVwgS9/GFdVIe8=
=HX0w
-END PGP SIGNATURE-

duplicate_block weirdness

[Sean Callanan]

Dear mailing list,

is there something wrong with the following code?
--
basic_block my_basic_block;
basic_block dup_basic_block;

FOR_EACH_BB(my_basic_block)
  {
dup_basic_block = duplicate_block(bb, NULL);
  }
--
I get an ICE in get_indirect_ref_operands, with the backtrace:
--
#0  0x000100175688 in get_indirect_ref_operands  
(stmt=0x7ea0c640, expr=0x7eaf8100, flags=0)

at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1417
#1  0x000100173dcc in get_expr_operands (stmt=0x7ea0c640,  
expr_p=0x7ea0c3f8, flags=0)

at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1091
#2  0x00010017406c in get_expr_operands (stmt=0x7ea0c640,  
expr_p=0x7ea0c680, flags=0)

at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1134
#3  0x000100172f94 in build_ssa_operands  
(stmt=0x7ea0c640, ann=0x7eaf6850,  
old_ops=0x7fffcd90,
new_ops=0x7eaf6878) at ../../gcc-4.0.1/gcc/tree-ssa- 
operands.c:906
#4  0x000100173b20 in get_stmt_operands (stmt=0x7ea0c640)  
at ../../gcc-4.0.1/gcc/tree-ssa-operands.c:1021
#5  0x00010010ca18 in tree_duplicate_bb (bb=0x7eafbe10)  
at ../../gcc-4.0.1/gcc/tree-cfg.c:4684
#6  0x000100591ea8 in duplicate_block (bb=0x7eafbe10,  
e=0x0) at ../../gcc-4.0.1/gcc/cfghooks.c:717

...
--
The context is a tree optimization pass, with PROP_gimple_any |  
PROP_ssa | PROP_cfg | PROP_referenced_vars required.


Sincerely,
Sean Callanan

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Alan Lehotsky]

Again, the GCC3 distribution has a port of the IP2K microcontroller.

It has a hardware call stack, but the data stack is implemented  
entirely in software.


You will have to dedicate a register to act as the data-stack  
pointer.  I suppose if you limit yourself to
writing functions with NO stack-local data you might be able to keep  
the SP as a virtual register and make sure
that code generation never tries to actually use it.  You will also  
be severely limited in the ability to
pass parameters if you only allow register parameters with no  
parameter saving.


At this point, why bother writing a C compiler


On Apr 10, 2006, at 03:54, Colm O' Flaherty wrote:

Does anyone have any ideas about what gcc support is like for  
targets with no data stack?  The 14 bit cores (16F) mostly have a  
2-8 level hardware stack, which is not part of the program or data  
memory, and is not addressable.  There is no data stack.


I'm hoping that there is an existing backend architecture where  
there is no stack, so that I can have a peep to see how the code  
fakes stack support, but so far, all the obvious candidates (the  
microcontrollers) seem to have a stack.


Ideas, anyone?

Colm

Re: GCC Compiler Engineer job (I am not a recruiter)

[Mark Mitchell]

DJ Delorie wrote:
>> Here, if Company A and Company B both want to recruit, but A adheres
>> to the policy while B does not, A loses.
> 
> I think that's a compelling reason to keep it at "no ads". 

It seems like we're getting consensus around that approach, despite the
initial sentiment in the other direction from Mike and Joe.  Mike, Joe,
do either of you care to argue the point?  If not, I'll volunteer to
write some text for the web pages, and ask Gerald to find a place to put it.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC Compiler Engineer job (I am not a recruiter)

[Daniel Berlin]

On Apr 10, 2006, at 5:23 PM, Mark Mitchell wrote:


Mike Stump wrote:


3. How do we enforce any of these rules?


Shame on those that violate them.


I think we need to do better than that.

If there's no viable enforcement mechanism, then people following the
policy are at a disadvantage to those who are not.  Traditional  
spam and
things better suited to gcc-help do not have this same impact.   
Here, if

Company A and Company B both want to recruit, but A adheres to the
policy while B does not, A loses.

I can IP block them from the new wiki software (i think the current  
software, too).
Unless you think they are going to hop from host to host just to post  
their jobs.

[ping] dwarf2out vs DWARF_DEBUG bug?

[DJ Delorie]

[note subject change, since I suspect it's not v850-specific]

There are 18 target directories that define DWARF2_DEBUGGING_INFO (not
counting all those that get it from elfos.h et al) but only 8 that
define DWARF2_UNWIND_INFO (both from just a simple grep).

> Date: Tue, 4 Apr 2006 16:41:25 -0400
> 
> The v850 is a dwarf-debug target, but not a dwarf-unwind target.  In
> dwarf2out.c we first calculate the "fp to fb offset" in
> compute_frame_pointer_to_fb_displacement.  The frame pointer is not
> needed, so note that we include the fp-sp elimination offset in
> frame_pointer_fb_offset.
> 
>  \/ 
> 
> /* Compute a displacement from the "steady-state frame pointer" to the
>frame base (often the same as the CFA), and store it in
>frame_pointer_fb_offset.  OFFSET is added to the displacement
>before the latter is negated.  */
> 
> static void
> compute_frame_pointer_to_fb_displacement (HOST_WIDE_INT offset)
> {
>   rtx reg, elim;
> 
> #ifdef FRAME_POINTER_CFA_OFFSET
>   reg = frame_pointer_rtx;
>   offset += FRAME_POINTER_CFA_OFFSET (current_function_decl);
> #else
>   reg = arg_pointer_rtx;
>   offset += ARG_POINTER_CFA_OFFSET (current_function_decl);
> #endif
> 
>   elim = eliminate_regs (reg, VOIDmode, NULL_RTX);
>   if (GET_CODE (elim) == PLUS)
> {
>   offset += INTVAL (XEXP (elim, 1));
>   elim = XEXP (elim, 0);
> }
>   gcc_assert (elim == (frame_pointer_needed ? hard_frame_pointer_rtx
>  : stack_pointer_rtx));
> 
>   frame_pointer_fb_offset = -offset;
> }
> 
>  /\ 
> 
> Later, when we calculate function parameter locations, we end up in
> based_loc_descr().  We call eliminate_regs again, adjust for the
> elimination offset, then adjust for frame_pointer_fb_offset, which
> *also* includes the elimination offset:
> 
>  \/ 
> 
> static dw_loc_descr_ref
> based_loc_descr (rtx reg, HOST_WIDE_INT offset)
> {
>   unsigned int regno;
> 
>   /* We only use "frame base" when we're sure we're talking about the
>  post-prologue local stack frame.  We do this by *not* running
>  register elimination until this point, and recognizing the special
>  argument pointer and soft frame pointer rtx's.  */
>   if (reg == arg_pointer_rtx || reg == frame_pointer_rtx)
> {
>   rtx elim = eliminate_regs (reg, VOIDmode, NULL_RTX);
> 
>   if (elim != reg)
>   {
> if (GET_CODE (elim) == PLUS)
>   {
> offset += INTVAL (XEXP (elim, 1));
> elim = XEXP (elim, 0);
>   }
> gcc_assert (elim == (frame_pointer_needed ? hard_frame_pointer_rtx
> : stack_pointer_rtx));
>   offset += frame_pointer_fb_offset;
> 
>   return new_loc_descr (DW_OP_fbreg, offset, 0);
>   }
> }
> 
>  /\ 
> 
> The net result is that the dwarf2 debug information is off by the
> fp-sp offset.  My question is: which of these adjustments isn't
> supposed to happen in this case?
> 
> Thanks,
> DJ
> 

Posts don't appear on the gcc mailing list...

[Mark Cuss]

Hello

I've subscribed to the gcc mailing list from my work account 
([EMAIL PROTECTED]) but none of my posts appear on the mailing 
list...  The mail doesn't get bounced back so I assume it's getting 
delivered, but nonetheless my posts don't show up on the list...  Is 
there someone who can give me a hand with this?


Thanks!
Mark

Updating a ssh key

[Steve Kargl]

What is the procedure for updating my public key
on gcc.gnu.org?  Note, I long ago forgot the 
passwd (if I even had one) for my account, so 
using scp is out of the question because I no longer
have ssh access (for some reason).

To make a long story short, my hard drive decided to
scramble itself beyond repair.  After installing a
new hard drive, re-installing the OS, and grabbing my
gcc hacking account off of backup tape, I can no longer
access the repository?

-- 
Steve

traverse the gimple tree

[sean yang]

I want to write a pass to walk the gimple tree and add some intrumentation 
code. I read the chapter 9 of "GCC Internals" document, and it seems not to 
describe the Macros to do so.


Can I get some information about this? Specifically, if someone can show me 
which .h file I should look at to find the Macros, that would be great. Or, 
Is there any other pass do the similar thing(traverse the gimple tree) that 
I can read (--I did not find)?



//in gcc.4.0.2, tree-optimize.c
   323 void
   324 init_tree_optimization_passes (void)
   325 {
   326   struct tree_opt_pass **p;
   327
   328 #define NEXT_PASS(PASS)  (p = next_pass_1 (p, &PASS))
   329
   330   p = &all_passes;
   331   NEXT_PASS (pass_gimple);
   332
   333   NEXT_PASS (MYPASS_code_instrument); //this is what I want to do
   334   //the reason I want to add the pass here is: both C/C++(any other 
front end, later) can use this;

   335   NEXT_PASS (pass_remove_useless_stmts);
   336   NEXT_PASS (pass_mudflap_1);
   337   NEXT_PASS (pass_lower_cf);
   338   NEXT_PASS (pass_lower_eh);
   339   NEXT_PASS (pass_build_cfg);
..
}


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Updating a ssh key

[Daniel Jacobowitz]

On Mon, Apr 10, 2006 at 08:47:26PM -0700, Steve Kargl wrote:
> What is the procedure for updating my public key
> on gcc.gnu.org?  Note, I long ago forgot the 
> passwd (if I even had one) for my account, so 
> using scp is out of the question because I no longer
> have ssh access (for some reason).
> 
> To make a long story short, my hard drive decided to
> scramble itself beyond repair.  After installing a
> new hard drive, re-installing the OS, and grabbing my
> gcc hacking account off of backup tape, I can no longer
> access the repository?

Easy: ask overseers@ to install a new key for you.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC Compiler Engineer job (I am not a recruiter)

[Florian Weimer]

* Mark Mitchell:

> 1. What do we do if people do advertise jobs that are not free software
> jobs, or not purely free software jobs?  How pure is pure?  Does "Port
> GCC to proprietary OS" count as free or not?

And: Does porting GCC to a new processor, to run on a free operating
system, without ever publishing the port qualify as free software?