Small Device C Compiler suite

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 29.11.2011 23:00, schrieb Maarten Brock:
> Hi,
> 
> SDCC is currently totally broken.
> - Regression test bug3440327.c fails

This one was not tested with all ports (since bug #3440327 was a Z80
port I didn't expect it to cause truble on ports unrelated to the z80).
I'll take a look at it tomorrow.

> - MSVC fails to build: sdcc.y:179: type clash (`' `sym') on default 
> action

I have no idead about this one, but it is probably caused by my merge of
the addrspacequal branch.

> - gcc issues: SDCCsymt.c:1712:2: warning: #warning check address space
> 

I've removed the warning. It was a leftover from the addrspacequal merge
(the checking of address spaces is done in lines 1824-1831).

Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7VaQwACgkQbtUV+xsoLppjogCfQcgkToszkgGQxuXwopq/ta+S
ZVcAniSZ17fpxVXLZuMJSOZw2i1PsOg0
=3lV2
-----END PGP SIGNATURE-----

Hi again,

> > SDCC is currently totally broken.
> > - Regression test bug3440327.c fails
> 
> This one was not tested with all ports (since bug #3440327 was a Z80
> port I didn't expect it to cause truble on ports unrelated to the z80).
> I'll take a look at it tomorrow.

Philipp 'fixed' this by disabling the test for mcs51. My initial 
preference was to keep it and use the __reentrant keyword.
But the error surprised me, because the first parameter is always 
passed in registers for mcs51 regardless of reentrancy. Looking into 
it deeper there are two checks that can generate this error in 
SDCCast.c and the first seems wrong to me. It checks for EX_VALUE to 
identify a function pointer and does not consider parameters passed in 
registers. I also think the second check covers all so I'm going to remove the 
first check.

> > - MSVC fails to build: sdcc.y:179: type clash (`' `sym') on default 
> > action
> 
> I have no idead about this one, but it is probably caused by my merge of
> the addrspacequal branch.

I have a very old bison (1.28) from unxutils (as recommended by the 
manual). This version seems to have a bug that can generate this 
error. If I use bison 2.4.2 from cygwin it passes ok.

> > - gcc issues: SDCCsymt.c:1712:2: warning: #warning check address space
> > 
> 
> I've removed the warning. It was a leftover from the addrspacequal merge
> (the checking of address spaces is done in lines 1824-1831).
> 
> Philipp

After the above bug3440327.c was solved another problem appeared in 
logic.c and a warning arose from bug3444293.c. So please, before 
doing a commit check that regression tests pass locally.

Regarding bug3440327.c, can the value be changed to 0 as it was in 
the bug report? Any 0 value equals the null pointer and is ok, but 
other values need to qualify their memory space on mcs51 and ds390.

Greets,
Maarten

Am 03.12.2011 12:26, schrieb Maarten Brock:

> Regarding bug3440327.c,

Do you mean bug3444293.c?

> can the value be changed to 0 as it was in 
> the bug report? Any 0 value equals the null pointer and is ok, but 
> other values need to qualify their memory space on mcs51 and ds390.

Philipp

> Am 03.12.2011 12:26, schrieb Maarten Brock:
> 
> > Regarding bug3440327.c,
> 
> Do you mean bug3444293.c?

Yes, sorry. I copied the wrong name from the paragraph 
above it.
> 
> > can the value be changed to 0 as it was in 
> > the bug report? Any 0 value equals the null pointer and is ok, but 
> > other values need to qualify their memory space on mcs51 and ds390.
> 
> Philipp

Maarten

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 03.12.2011 12:39, schrieb Maarten Brock:
>> Am 03.12.2011 12:26, schrieb Maarten Brock:
>>
>>> Regarding bug3440327.c,
>>
>> Do you mean bug3444293.c?
> 
> Yes, sorry. I copied the wrong name from the paragraph 
> above it.
>>
>>> can the value be changed to 0 as it was in 
>>> the bug report? Any 0 value equals the null pointer and is ok, but 
>>> other values need to qualify their memory space on mcs51 and ds390.
>>
>> Philipp
> 
> Maarten

Well, in lines 11 and 12, the pointers are set to 0. That's were the bug
occoured (resulting in the lower byte of s[1] not being set to zero and
the lower byte of s[3] being set to zero instead). To detect it in the
assertion we therefore need the pointers to be nonzero (and preferably,
to be all bytes of the pointers to be nonzero). That's why I did set
them to 0xffff.

Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7aDDwACgkQbtUV+xsoLpoIIwCg8UwqMr0tUZ56qZVpei0DBSaD
AQ0AnRA3pwTTk9IMlOGr9qDV10ooN3bO
=IdG9
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 03.12.2011 12:47, schrieb Philipp Klaus Krause:
> Am 03.12.2011 12:39, schrieb Maarten Brock:
>>> Am 03.12.2011 12:26, schrieb Maarten Brock:
>>>
>>>> Regarding bug3440327.c,
>>>
>>> Do you mean bug3444293.c?
> 
>> Yes, sorry. I copied the wrong name from the paragraph 
>> above it.
>>>
>>>> can the value be changed to 0 as it was in 
>>>> the bug report? Any 0 value equals the null pointer and is ok, but 
>>>> other values need to qualify their memory space on mcs51 and ds390.
>>>
>>> Philipp
> 
>> Maarten
> 
> Well, in lines 11 and 12, the pointers are set to 0. That's were the bug
> occoured (resulting in the lower byte of s[1] not being set to zero and
> the lower byte of s[3] being set to zero instead). To detect it in the

This was meant to read s[2].

> assertion we therefore need the pointers to be nonzero (and preferably,
> to be all bytes of the pointers to be nonzero). That's why I did set
> them to 0xffff.
> 
> Philipp

Would it be OK if Il just disable warning 88 for this test?

Philipp


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7aDMUACgkQbtUV+xsoLpou3wCeLmWT5HBj7YGn3AGi9r2DWgNL
hWQAoMw4n7zxGe0ebSFJeXZce99y0YHw
=n789
-----END PGP SIGNATURE-----

> Am 03.12.2011 12:47, schrieb Philipp Klaus Krause:
> > Am 03.12.2011 12:39, schrieb Maarten Brock:
> >>> Am 03.12.2011 12:26, schrieb Maarten Brock:
> >>>
> >>>> Regarding bug3440327.c,
> >>>
> >>> Do you mean bug3444293.c?
> > 
> >> Yes, sorry. I copied the wrong name from the paragraph 
> >> above it.
> >>>
> >>>> can the value be changed to 0 as it was in 
> >>>> the bug report? Any 0 value equals the null pointer and is ok, but 
> >>>> other values need to qualify their memory space on mcs51 and ds390.
> >>>
> >>> Philipp
> > 
> >> Maarten
> > 
> > Well, in lines 11 and 12, the pointers are set to 0. That's were the bug
> > occoured (resulting in the lower byte of s[1] not being set to zero and
> > the lower byte of s[3] being set to zero instead). To detect it in the
> 
> This was meant to read s[2].
> 
> > assertion we therefore need the pointers to be nonzero (and preferably,
> > to be all bytes of the pointers to be nonzero). That's why I did set
> > them to 0xffff.
> > 
> > Philipp
> 
> Would it be OK if Il just disable warning 88 for this test?

If you want all bytes to be non-zero, no. A generic 
pointer on mcs51 is 3 bytes. I propose to use a (void 
__code *) cast. This will solve the warning (used to be 
an error in the past btw.) and sets the third byte to 
0x80. For targets without __code keyword this is defined 
empty in testfwk.h.

> 
> Philipp

Maarten