Re: [9fans] pcc problem compiling assumed to be correct C file

Re: [9fans] pcc problem compiling assumed to be correct C file

[rob pike]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

Here is the fix Sean Dorward settled on.

-rob

; yesterday -d dcl.c cc.h
diff /n/dump/2001/0430/sys/src/cmd/cc/dcl.c dcl.c
117c117
< 	snprint(symb, NSYMB, "%s$%d", s->name, (char)s->block);
---
> 	snprint(symb, NSYMB, "%s$%d", s->name, s->block);
diff /n/dump/2001/0430/sys/src/cmd/cc/cc.h cc.h
83,84c83,84
< 	char	block;
< 	char	sueblock;
---
> 	ushort	block;
> 	ushort	sueblock;
98a99
> 	ushort	block;
100d100
< 	char	block;


[-- Attachment #2: Type: message/rfc822, Size: 4189 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pcc problem compiling assumed to be correct C file
Date: Sat, 28 Apr 2001 13:06:53 +0200
Message-ID: <200104281106.NAA20008@copernicus.cs.utwente.nl>

> no, it shouldn't.  it's the first bug i've seen in the port part
> of the compiler for some time.  it's cc/dcl.c:/^mkstatic

I tried two solutions suggested by forsyth in private mail.
 1 changing mkstatic to generate unique symbol names
 2 changing block to be of ushort instead of char
Unfortunately I tried 1) at work and 2) at home, in slightly different ways.
Having just successfully applied 2) and having to email from linux
and already having rebooted linux I did not want to go back to plan9
to retry 1) in exactely the same way as the succesfull 2).

1) did succeed to compile the code, but the result committed suicide.
   It did _not_ commit suicide when I just run it to print a version
   number, but _did_ suicide when those static variables where
   initialised.
   The suicide could also be explained by the fact that I tried to combine
   ape-'mode' source with a plan9 yacc-generated y.tab.c and therefore
   had to fiddle with fprint and sprint not being available in ape
   (I did not think in time of -Dalloca=malloc)

2) succeeded and also the result works
   To be sure I also changed sueblock, because I had the impression
   of seeing some assignments from block, I think.
   however, here I used bison-generated y.tab.c and used -Dalloca=malloc
   diff of the change follows.

diff Old/cc.h ./cc.h
83,84c83,84
< 	char	block;
< 	char	sueblock;
---
> 	ushort	block;		// was char
> 	ushort	sueblock;		// was char
100c100
< 	char	block;
---
> 	ushort	block;		// was char
diff Old/dcl.c ./dcl.c
117c117
< 	snprint(symb, NSYMB, "%s$%d", s->name, (char)s->block);
---
> 	snprint(symb, NSYMB, "%s$%d", s->name, (ushort)s->block);	// was (char)


Regards,
Axel (who still very much wants his plan9 ppp to (finally?) work :-/

Re: [9fans] pcc problem compiling assumed to be correct C file

[Axel Belinfante]

> no, it shouldn't.  it's the first bug i've seen in the port part
> of the compiler for some time.  it's cc/dcl.c:/^mkstatic

I tried two solutions suggested by forsyth in private mail.
 1 changing mkstatic to generate unique symbol names
 2 changing block to be of ushort instead of char
Unfortunately I tried 1) at work and 2) at home, in slightly different ways.
Having just successfully applied 2) and having to email from linux
and already having rebooted linux I did not want to go back to plan9
to retry 1) in exactely the same way as the succesfull 2).

1) did succeed to compile the code, but the result committed suicide.
   It did _not_ commit suicide when I just run it to print a version
   number, but _did_ suicide when those static variables where
   initialised.
   The suicide could also be explained by the fact that I tried to combine
   ape-'mode' source with a plan9 yacc-generated y.tab.c and therefore
   had to fiddle with fprint and sprint not being available in ape
   (I did not think in time of -Dalloca=malloc)

2) succeeded and also the result works
   To be sure I also changed sueblock, because I had the impression
   of seeing some assignments from block, I think.
   however, here I used bison-generated y.tab.c and used -Dalloca=malloc
   diff of the change follows.

diff Old/cc.h ./cc.h
83,84c83,84
< 	char	block;
< 	char	sueblock;
---
> 	ushort	block;		// was char
> 	ushort	sueblock;		// was char
100c100
< 	char	block;
---
> 	ushort	block;		// was char
diff Old/dcl.c ./dcl.c
117c117
< 	snprint(symb, NSYMB, "%s$%d", s->name, (char)s->block);
---
> 	snprint(symb, NSYMB, "%s$%d", s->name, (ushort)s->block);	// was (char)


Regards,
Axel (who still very much wants his plan9 ppp to (finally?) work :-/

Re: [9fans] pcc problem compiling assumed to be correct C file

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]

no, it shouldn't.  it's the first bug i've seen in the port part of the compiler for
some time.  it's cc/dcl.c:/^mkstatic


[-- Attachment #2: Type: message/rfc822, Size: 1713 bytes --]

To: cse.psu.edu!9fans
Subject: Re: [9fans] pcc problem compiling assumed to be correct C file
Date: Fri, 27 Apr 2001 15:00:03 GMT
Message-ID: <3AE9827D.C931CA6F@arl.army.mil>

For what it's worth, Sun's FORTE C compiler 6.1 doesn't generate
any warnings when compiling the preprocessed source.

Re: [9fans] pcc problem compiling assumed to be correct C file

[Douglas A. Gwyn]

For what it's worth, Sun's FORTE C compiler 6.1 doesn't generate
any warnings when compiling the preprocessed source.

[9fans] pcc problem compiling assumed to be correct C file

[Axel Belinfante]

Hello,
I'm having a problem compiling a pretty huge C file, using pcc.
The file is generated, and contains lots of the same/similar functions.
Most of those functions are not complained about, but a few of them are.
Can it be that I have too many functions, and that a table is overflowing?
There are quite a number of simular functions that have a local variable
named kc_x  (either defined static or register, and of many different types)
and it looks very much like pcc is confusing one kc_x with another one).
I tried to look at the -d debugging output, but got confused about the
block numbering: they go up to 127, and then down from -128, and up again,
but indeed showing the same decl line etc.

In case anyone wants to reproduce, I have made both the original file and
the output of running the C preprocessor on it available as resp.
<URL:http://www.cs.utwente.nl/~belinfan/kcproblem/k.c.gz>
<URL:http://www.cs.utwente.nl/~belinfan/kcproblem/k..i.gz>
The pcc -v flag shows (split at \ by me):
  cpp -D__STDC__=1 -N -I/386/include/ape -I/sys/include/ape k.c | \
    8c  -F -V -w -o k.8

pcc error messages:

k.c:7601[stdin:43627] incompatible types: "IND STRUCT kc_tag_productionblock"
 and "IND STRUCT kc_tag_outmostpatterns" for op "EQ"
k.c:7603[stdin:43629] incompatible types: "IND STRUCT kc_tag_productionblock"
 and "IND STRUCT kc_tag_outmostpatterns" for op "AS"
k.c:7606[stdin:43632] incompatible types: "IND STRUCT kc_tag_outmostpatterns"
 and "IND STRUCT kc_tag_productionblock" for op "RETURN"

for a few of the functions like this:
(I know the code could be cleaner, but still that doesn't explain the errors)

outmostpatterns Niloutmostpatterns
#ifdef KC_USE_PROTOTYPES
(void)
#else
()
#endif
{	static outmostpatterns kc_x = (outmostpatterns)0;
	KC_COLLECT_STATS0(KC_CREATE_STATS(sel_Niloutmostpatterns));
	if (kc_x == (outmostpatterns)0) {
		KC_COLLECT_STATS0(KC_EXISTINGNOTFOUND_STATS(sel_Niloutmostpatterns ));
		kc_x = (outmostpatterns)(*kc_hashtables[(int)kc_uniq_nullary_operator]->
malloc)(
			(kc_size_t)sizeof(struct kc_tag_outmostpatterns),
			kc_hashtables[(int)kc_uniq_nullary_operator]->malloc_private_data);
		kc_x->prod_sel = sel_Niloutmostpatterns;
	}
	return kc_x;
}


Thanks,
Axel.