Re: [cc65] testsuite results ...

On Montag 07 September 2009, Ullrich von Bassewitz wrote:
> fields.c should now work but there are still differences between gcc and
> cc65 output. This is because ISO/IEC 9899:1999 (E) says in 6.7.2.1
> "Structure and union specifiers", footnote 104:
>
>   "As specified in 6.7.2 above, if the actual type specifier used is int or
> a typedef-name defined as int, then it is implementation-defined whether
> the bit-field is signed or unsigned."
>
> gcc chooses signed bit-fields, while cc65 implements unsigned bit-fields
> for obvious reasons. This causes a difference in two numbers of the output.
> If you want the same output, you may change the code to declare the
> bit-fields as unsigned (instead of int).

aaaaah ok. good to know :) yes, i will change the test so it doesnt fail 
anymore (or rather, add some option for this behaviour)

> > > I had already a look at yacc.c, but for the test, the input file
> > > yacc.in is missing, so I cannot run it here. So I hoped this was fixed
> > > when I fixed the other errors, which was seemingly wrong. Can you send
> > > me the file in private mail or point me to a download link?
> >
> > the input file contains a single line: (i'll add links to them on the
> > report pages... :))
>
> I still cannot get it running with the error message in your report. For
> me, it just hangs, and the code is somewhat wicked (means: I do not
> understand it:-)

yes, it doesnt produce that error here either with versin 4120 - i added 
a "start of test here" message because of it :) and yes, the code (and 
especially the generated asm) is kinda horrible =D

> > apropos... cc65090726.c contains some passing of struct pointers to
> > functions which take a different type - cc65 errors out on them. i have
> > now made it skip those 3, i assumed that this behavior (giving an error
> > instead of just a warning) is completely "legal" ... am i correct?
>
> The C standard doesn't talk about "errors" and "warnings", all it knows are
> "diagnostics". It is up to the compiler writer to specify what is a
> "diagnostic". Passing a pointer of the wrong type is in my eyes such a
> strong sign for an error in the program, that I decided, not to generate
> output in this case. The gcc creators decided that it is worth generating
> an executable for reasons unknown to me. Both approaches are correct
> according to the C standard, since both compilers output a "diagnostic".

ok, thats exactly what i thought, written out more precisely =)

so well, i did another quick check with 4130, it shows same results as 
before ... i am going through a bunch of oooold things i have written when 
cc65 still was quite bugged and add more tests to the testsuite (i might have 
found one case that still doesnt work right, have to recheck... :)) ... 
trying to update the webpage later tonite :)

ps: btw, are you interisted in the output generated when compiling cc65 
itself... like the warnings it produces? (i am running on amd64 here, and i 
am seeing one or two related warnings)

pps:

in the runtime: (4130)

../../../include/geos/gstruct.h(123): Error: Size of data type is unknown
../../../include/geos/gstruct.h(136): Error: Size of data type is unknown
../../../include/geos/gstruct.h(142): Error: Size of data type is unknown

all of them failing because of

sometype_t  arg[];

it works if replaced by

sometype_t  *arg;

ppps:

sidenote: one of my little test programs that dont fit into the testsuite (i 
should put those online too ...), which is a simple mandelbrot calculated in 
16 bit fixedpoint, runs in ~1800 seconds now, as opposed to ~2500 seconds 
with the older compiler. quite a nice improvement =)

-- 

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ftp.pokefinder.org

It is more profitable for your congressman to support the tobacco industry 
than your life. 
<Jackie Mason>

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.