Re: Porting problem again

Anders Magnusson <ragge <at> ludd.ltu.se> writes:

> 
> Peter Kuschnerus wrote:
> > Hello,
> >
> >   
> 
> Hi,
> 
> you sent your mail from a not-subscribed-address, and I didn't see it
> until now.  Anyway;
> 
> > In my ISA the concept of function-linkage is that way,
> > that cleanup of args is not done by the caller,
> > but by the called function at return.
> >
> > For fixed number of args, there is no problem.
> > For variable number of args, a hidden argument is to be added,
> > which contains the number of actual args,
> > so that the called function has the information 
> > to do the cleanup correctly.
> >
> > I try to implement the adding of that hidden argument
> > in the routine "funcode" of module code.c.
> > But there I have the problem to findout,
> > whether the call is with ellipsis or without.
> >
> > Is there an easy way to check this in this routine ?
> > Please, any hint would help !

Re: attribute(section())

Michael Shalayeff wrote:
> On Sat, Nov 28, 2009 at 10:04:03PM +0000, Michael Shalayeff wrote:
>   
>> re
>> this fixes the section attribute although (imho) in a slightely
>> ugly way. perhaps setaarg() should know better how to set args
>> (that would avoid a quirke` switch later also).
>> but this works at least (;
>>     
>
> oops (:
> slightely better diff that does not crash (;
> cu
>   
I've fixed it now, thanks.  Strings as attribute args was actually 
broken, (treated
as names), but now fixed in an more general way.

-- Ragge

Error allocating TEMP in local frame

Hello,

I get the error, that whenever the allocated offset
of a temp in local frame should be zero,
at first the allocation is correct, 
but any further use of the same temp gets an other offset.

When AUTOINIT is defined as 0 and BACKTEMP is not defined, 
then the offset zero is a valid offset.

In my search, I found in reader.c the routines deltemp and freetemp.
The first call to freetemp returns correctly an offset of 0.
At later use of that temp, the routine deltemp confuses that 0
as not yet allocated, and calls freetemp again.

Imho the value 0 should not be used as indication for allocaion.

Regards
Peter Kuschneus

pcc-libs: build errors in Linux i386

PCC complains about bad include in /usr/include/limits.h, line 125.

123:#if defined __GNUC__ && !defined _GCC_LIMITS_H_
124:/* `_GCC_LIMITS_H_' is what GCC's file defines.  */
125:# include_next <limits.h>
126:#endif

PCC was compiled w/o the --disable-gcc-compat option.
GCC is 4.1.2 20080704 (Red Hat 4.1.2-46), Linux i386 (Fedora)

---
.alt.

Re: Error allocating TEMP in local frame

Peter Kuschnerus <peter.kuschnerus <at> gmx.de> writes:

> 
> Imho the value 0 should not be used as indication for allocaion.
> 
> 

Hi,
I think instead of 0, the value -1 can be used.
This is never a used value.

To fix that problem, I propose the following changes:

In reader.c in pass2compile, I propose to replace the line
        addrp = tmpcalloc(      ....
by
        addrp = tmpalloc(       ....
        memset(addrp, -1,       ....

In reader.c in deltemp, I propose to replace the line
        if (aor[regno(p)] == 0) {
by
        if (aor[regno(p)] == -1) {

I think this would work for all arch.

Regards
Peter Kuschneus

Build errors under Ubuntu 9.10 i386

GCC is gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1

Command line is

$ CC=gcc CFLAGS='-g -O2 -DPCC_DEBUG' YACC=byacc LEX=flex sh -c
'./configure --disable-gcc-compat && make all'

Build log is as follows:

--- cut here --- cut here ---
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc accepts -Wall... yes
checking whether gcc accepts -Wmissing-prototypes... yes
checking whether gcc accepts -Wstrict-prototypes... yes
checking whether gcc accepts -Wshadow... yes
checking whether gcc accepts -Wsign-compare... yes
checking whether gcc accepts -Wtruncate... no
checking for a C compiler for mkext... not cross compiling
checking how to run the C preprocessor... gcc -E

Re: Build errors under Ubuntu 9.10 i386

Re: Build errors under Ubuntu 9.10 i386

I must admit that I haven't put much effort in ensuring that the 
compiler can be compiled
without gcc-compat, mainly because it need to exclude rules in yacc to 
really be without
gcc stuff and there is no nice way to preprocess the yacc grammar.

I may do that some thay though, but it has low priority.

-- Ragge

Janne Johansson wrote:
> I got the same using
> ./configure --disable-gcc-compat
> on openbsd testing the 091230 snap.
>
> 2009/12/29 Alt <alt <at> altamiranus.info <mailto:alt <at> altamiranus.info>>
>
>     GCC is gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1
>
>     Command line is
>
>     $ CC=gcc CFLAGS='-g -O2 -DPCC_DEBUG' YACC=byacc LEX=flex sh -c
>     './configure --disable-gcc-compat && make all'
>
> <some parts cut>
>
>     gcc  -DPCC_DEBUG -Dos_linux -Dmach_i386 -D_ISOC99_SOURCE -I. -I.
>     -I../.. -I../../mip -I../../arch/i386 -I../../os/linux  -g -O2
>     -DPCC_DEBUG  -Wall -Wmissing-prototypes -Wstrict-prototypes -Wshadow
>     -Wsign-compare -c -o pftn.o pftn.c
>     pftn.c: In function ‘defid’:
>     pftn.c:352: warning: implicit declaration of function ‘gcc_get_attr’
>     pftn.c:352: error: ‘GCC_ATYP_GNU_INLINE’ undeclared (first use in
>     this function)
>     pftn.c:352: error: (Each undeclared identifier is reported only once
>     pftn.c:352: error: for each function it appears in.)
>
>
>
> -- 
> To our sweethearts and wives.  May they never meet. -- 19th century toast

Re: Porting problem again

Peter Kuschnerus wrote:
> Anders Magnusson <ragge <at> ludd.ltu.se> writes:
>
>   
>> Peter Kuschnerus wrote:
>>     
>>> Hello,
>>>
>>>   
>>>       
>> Hi,
>>
>> you sent your mail from a not-subscribed-address, and I didn't see it
>> until now.  Anyway;
>>
>>     
>>> In my ISA the concept of function-linkage is that way,
>>> that cleanup of args is not done by the caller,
>>> but by the called function at return.
>>>
>>> For fixed number of args, there is no problem.
>>> For variable number of args, a hidden argument is to be added,
>>> which contains the number of actual args,
>>> so that the called function has the information 
>>> to do the cleanup correctly.
>>>
>>> I try to implement the adding of that hidden argument
>>> in the routine "funcode" of module code.c.
>>> But there I have the problem to findout,
>>> whether the call is with ellipsis or without.
>>>
>>> Is there an easy way to check this in this routine ?
>>> Please, any hint would help !
>>>   
>>>       
>> It's not so easy as just a flag set, but the code stuff below does what 
>> you want.
>> It's cut from bfcode() in amd64.  The prototype argument types are stored in
>> an array al, and if the last entry is TELLIPSIS it is varargs.  Note 
>> that it skips
>> extra args in the case of structs/unions/arrays.
>>
>>     
> Hi,
> this codefragment accesses the prototype information of
> the function being within.
>
> But the prototype of a function to be called,
> is another issue.
>   
> I need that data in lastcall and zzzcode.
> But I have the impression that this data is not avalable there.
>   
You can use the same principle for finding the prototype info, just 
search for
a CALL node late in pass1.  Then use the field n_flags in the CALL node to
send info about this to pass2.   This must be done last in pass1, look 
at how the
mangle() function in i386/local.c is implemented.

> Instead I did find it in clocal case CALL
> al = p->n_df[0].dfun
>
> But there I must save it for later use in lastcall.
> For saving I used the field of call-node: n_qual
> It seems to be unused.
> I saw it only used in some other arch for counting of arg space.
> If unused is true, it is a solution of my problem.
The n_qual field stores information about const/volatile and should not be
(re-)used until after all optimizing code is called.  Use the flags 
field instead.

-- Ragge

Re: Error allocating TEMP in local frame

Hi Peter,

you are correct!  The current code will not work if if the stack is 
growing upwards
and start at offset 0.  ...but since no targets so fas has this design 
this bug hasn't been
exposed until now.

Your fix also seems to be correct, but I want to think a little about it 
to see if there
are other implications.  I think that some parts of this should be 
rewritten.

Thanks for finding this bug!

-- Ragge

Peter Kuschnerus wrote:
> Peter Kuschnerus <peter.kuschnerus <at> gmx.de> writes:
>
>   
>> Imho the value 0 should not be used as indication for allocaion.
>>
>>
>>     
>
> Hi,
> I think instead of 0, the value -1 can be used.
> This is never a used value.
>
> To fix that problem, I propose the following changes:
>
> In reader.c in pass2compile, I propose to replace the line
>         addrp = tmpcalloc(      ....
> by
>         addrp = tmpalloc(       ....
>         memset(addrp, -1,       ....
>
> In reader.c in deltemp, I propose to replace the line
>         if (aor[regno(p)] == 0) {
> by
>         if (aor[regno(p)] == -1) {
>
> I think this would work for all arch.
>
>
> Regards
> Peter Kuschneus
>
>
>
>
>
>
>
>