From: <ber...@be...> - 2002-12-28 18:13:50
|
> > I confirm, that this is a bug. I don't think, that this is intended by > > the developers, because SDCC should always be ANSI-compliant. > > But I'm afraid, that this bug won't be fixed in the near future. > > Sorry, you'r wrong :). Fixed in SDCCast.c:1.150 (I think). Nice :-) But atoi.c now fails to compile: sdcc -S sdcc/device/lib/atoi.c _atoi.c:28: error: Pointer required _atoi.c:28: error: code not generated for 'atoi' due to previous errors Bernhard |
From: Johan K. <joh...@id...> - 2002-12-29 10:39:19
|
> Nice :-) But atoi.c now fails to compile: > sdcc -S sdcc/device/lib/atoi.c > > _atoi.c:28: error: Pointer required Ok, that was for the multiply as in: long foo (int a, int b) { return a*b; // used to be (long)((int)(a*b)) } but that fooled long foo (int *b) { return *b; } Fixed in SDCCast.c:1.151 Anyway, are the regression tests still valid? I can't seem to make them work anymore. Anything changed? Johan |
From: Bernhard H. <ber...@be...> - 2002-12-29 13:47:10
|
> > Nice :-) But atoi.c now fails to compile: > > sdcc -S sdcc/device/lib/atoi.c > > > > _atoi.c:28: error: Pointer required > > Ok, that was for the multiply as in: > > long foo (int a, int b) { > return a*b; // used to be (long)((int)(a*b)) > } > > but that fooled > > long foo (int *b) { > return *b; > } > > Fixed in SDCCast.c:1.151 Thanks. > Anyway, are the regression tests still valid? I can't seem to make them > work anymore. Anything changed? No. It works for me. What's your problem? Bernhard |
From: Johan K. <joh...@id...> - 2002-12-29 18:10:07
|
> > Anyway, are the regression tests still valid? I can't seem to make them > > work anymore. Anything changed? > No. It works for me. What's your problem? I smoke, I am lazy, and some others that are off-topic. For bug #1 I am going to be acupunctured tomorrow at 13.15h (please pray with me that she doesn't drink too much tonight :). Bug #2 is a fresh checkout of sdcc and sdcc-extra. Sdcc configures, makes and installs nicely. But sdcc-extra's make complains: g++ -fdollars-in-identifiers -ggdb -c -o disasm.o disasm.cc disasm.cc: In function `int mon_sprintf(SFILE*, const char*, ...)': disasm.cc:174: `strlen' undeclared (first use this function) disasm.cc:174: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [disasm.o] Error 1 make[2]: Leaving directory `/home/johan/sdcc-extra/emu/rrz80' and regression tests are (although of crucial importance!) not my point of interest. Johan |
From: Bernhard H. <ber...@be...> - 2002-12-29 21:05:04
|
> g++ -fdollars-in-identifiers -ggdb -c -o disasm.o disasm.cc > disasm.cc: In function `int mon_sprintf(SFILE*, const char*, ...)': > disasm.cc:174: `strlen' undeclared (first use this function) > disasm.cc:174: (Each undeclared identifier is reported only once for each > function it appears in.) > make[2]: *** [disasm.o] Error 1 > make[2]: Leaving directory `/home/johan/sdcc-extra/emu/rrz80' Works for me. > and regression tests are (although of crucial importance!) not my point of > interest. I didn't run the tests for a long time. But they still look quite ok. Bernhard |
From: Bernhard H. <ber...@be...> - 2002-12-29 22:42:35
|
> > > Nice :-) But atoi.c now fails to compile: > > > sdcc -S sdcc/device/lib/atoi.c > > > > > > _atoi.c:28: error: Pointer required > > > > Ok, that was for the multiply as in: > > > > long foo (int a, int b) { > > return a*b; // used to be (long)((int)(a*b)) > > } > > > > but that fooled > > > > long foo (int *b) { > > return *b; > > } > > > > Fixed in SDCCast.c:1.151 > > Thanks. void _printf (const char code *fmt, ...); void foo (unsigned char ub) { _printf ("%c", ub + 1); } Another one, which bites me: ub + 1 is casted to long instead of int. Bernhard |
From: Johan K. <joh...@id...> - 2002-12-30 11:14:08
|
So, my fix wasn't that good afterall, now it's needless instead of missing ;-( However: e.g. "long = int + int" was always done in 16bits. I wonder why that has never been noticed. I found a more general fix but will only commit it when it passes the regression tests once I get them up and running again. In the meantime I undid the fix. Johan |
From: Johan K. <joh...@id...> - 2002-12-30 17:30:57
|
> > However: e.g. "long = int + int" was always done in 16bits. I wonder why > > that has never been noticed. > > Because it is correct. 'int' is the smallest common type for (int,int), and > the fact that it is being assigned to a long really doesn't matter! Hmm. Than how about "int = char + char" or "int = short + short". Gcc does promote the operands and not the result. Johan > > You'd need: lval = (long) i + j; > or: lval = i + (long) j; > Note that (long)(i+j) does not work (the addition is still done as int). > > Bob Ammerman > RAm Systems > IANAL but, IAA language L > > > I found a more general fix but will only commit it when it passes the > > regression tests once I get them up and running again. In the meantime I > > undid the fix. > > > > > > Johan > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > sdcc-devel mailing list > > sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > > > > > |
From: Michael H. <mic...@ju...> - 2002-12-30 18:37:11
|
On Monday, December 30, 2002, at 06:31 AM, Johan Knol wrote: >>> However: e.g. "long = int + int" was always done in 16bits. I wonder >>> why >>> that has never been noticed. >> >> Because it is correct. 'int' is the smallest common type for >> (int,int), > and >> the fact that it is being assigned to a long really doesn't matter! > > Hmm. Than how about "int = char + char" or "int = short + short". Gcc > does > promote the operands and not the result. Out of K&R, page 44: * If either operand is a long double, convert the other to long double. * Otherwise, if either operand is a double, convert the other to double. * Otherwise, if either operand is a float convert the other to a float. * Otherwise, convert char and short to int. * Then, if either operand is long, convert the other to long. So the rules promote operands to int, but do not automatically promote past that. I guess the logic is that an int fits into a machine word, so it's cheap to promote up to it. However, promoting any further is expansive and should not be done implicitly. -- Michael |