From: Frieder F. <Fri...@we...> - 2007-05-07 15:39:35
|
Hi Maarten, "Maarten Brock" <sou...@ds...> schrieb am 07.05.2007 15:40:47: > Why is it surprising this test fails? It generates a warning about integer > overflow in expression. If you change 19200 to 19200L it's allright. Fine. The surprising part (to me) was that apparently some of the tests were not executed because the white spaces around the function definition did not match. I noticed with regtrack.c and then looked for other tests that wouldn't be executed either and found longlit.c. I didn't investigate further but I should have noticed the missing L. > Or did SDCC in the past detect that 12*19200 does not fit in an int and > automatically upcast the result to a long? I don't know, as I was not > using SDCC back in 2001 when this test was added. What was this regression > test exactly supposed to check? Sorry I don't know why it was added. Greetings, Frieder _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 |
From: Maarten B. <sou...@ds...> - 2007-05-08 07:09:58
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head> <title></title> <meta http-equiv="content-type" content="text/html;charset=utf-8"/> <meta http-equiv="Content-Style-Type" content="text/css"/> </head> <body> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt">Borut,</span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt">I think you forgot the minus:</span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt">(u8)((2*11059200) / (u16)(32*12*19200)) =</span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt">(u8)(22118400 / 32768) = (u8)675 = 163</span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt">Anyway, it uses 16 bit arithmatic for computing 32*12*19200.</span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt">But without the L the test will have different outcomes on different architectures. The host will fail the test because an int is at least 32 bit there.</span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Courier New" size="2"><span style="font-size:10pt">Maarten</span></font></div> <div align="left"><font face="Arial" size="2"><span style="font-size:10pt"><br /> </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> Maarten Brock wrote:</span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> >> Just as an additional info: I tried it with 16 bit watcom compiler and I </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> >> got the expected result 263 (0xfd) with 19200L.</span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> ></span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> > Sure, but what does it give without the L? Is it still </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> > 0xFD?</span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> Yes, my report was incomplete: without L the result is 163.</span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> If we can trust the watcom C, the longlit.c regtest test is wrong: there </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> should be a L after 19200.</span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> Maybe we could add an other test without the L and change the assertion </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> value. The problem here is that I don't know how the watcom C calculated </span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> 163...</span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">></span></font></div> <div align="left"><font face="Arial" color="#7f0000" size="2"><span style="font-size:10pt">> Borut</span></font></div> <div align="left"></div> </body> </html> |
From: Erik P. <epe...@iv...> - 2007-05-08 14:03:14
|
On Tue, 8 May 2007, Maarten Brock wrote: > Borut, > > I think you forgot the minus: > > (u8)((2*11059200) / (u16)(32*12*19200)) = > (u8)(22118400 / 32768) = (u8)675 = 163 > > Anyway, it uses 16 bit arithmatic for computing 32*12*19200. 32, 12, and 19200 all fit into the range of a signed int, so their product would be of type signed int. Since the high bit is set, 32768 would actually be evaluated as -32768, and thus the final stage of computation is actually (u8)(-22118400 / -32768) = (u8)675 = 163 The initial minus sign hasn't been forgotten. Erik |
From: Borut R. <bor...@si...> - 2007-05-08 16:37:11
|
Maarten Brock wrote: > Borut, > > I think you forgot the minus: > > (u8)((2*11059200) / (u16)(32*12*19200)) = > (u8)(22118400 / 32768) = (u8)675 = 163 > > Anyway, it uses 16 bit arithmatic for computing 32*12*19200. > > But without the L the test will have different outcomes on different > architectures. The host will fail the test because an int is at least > 32 bit there. > Maarten and Erik, thank you to help me in arithmetics. I used the same logic as Erik, but somehow couldn't get the same result :-[ The assert for the version without L could be #ifdef-ed depending of the architecture: ASSERT(T1==0xfd); for 16 bit int architecture and ASSERT(T1==0xa3); for 32 bit int architectures. Borut > Maarten > > > Maarten Brock wrote: > > >> Just as an additional info: I tried it with 16 bit watcom compiler > and I > > >> got the expected result 263 (0xfd) with 19200L. > > > > > > Sure, but what does it give without the L? Is it still > > > 0xFD? > > > > Yes, my report was incomplete: without L the result is 163. > > > > If we can trust the watcom C, the longlit.c regtest test is wrong: there > > should be a L after 19200. > > > > Maybe we could add an other test without the L and change the assertion > > value. The problem here is that I don't know how the watcom C calculated > > 163... > > > > Borut > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Maarten B. <sou...@ds...> - 2007-05-08 17:11:06
|
Gentlemen, > Maarten and Erik, thank you to help me in arithmetics. I used the same > logic as Erik, but somehow couldn't get the same result :-[ Like Jan already noticed: it was late at night ;) > The assert for the version without L could be #ifdef-ed depending of the > architecture: > > ASSERT(T1==0xfd); > > for 16 bit int architecture and > > ASSERT(T1==0xa3); > > for 32 bit int architectures. > > > Borut The other way around I guess. For now I have changed the test to be performed and only check with the L appended. If anyone wants the test without the L too, fell free to adapt some more. Maarten |
From: Borut R. <bor...@si...> - 2007-05-07 19:08:12
|
Frieder Ferlemann wrote: > Hi Maarten, > > "Maarten Brock" <sou...@ds...> schrieb am 07.05.2007 15:40:47: > >> Why is it surprising this test fails? It generates a warning about integer >> overflow in expression. If you change 19200 to 19200L it's allright. >> > > Fine. The surprising part (to me) was that apparently some of the > tests were not executed because the white spaces around the function > definition did not match. The rule for function names is '^test\w+\(\w+\)' (from support/regression/generate-cases.py), which is not enough flexible by my opinion. Better option would be '^\W*test\w*\W*\(\W*void\W*\)', which allows spaces around the function definition and a void parameter list, optionally surrounded by spaces. This is probably a small enhancement to be implemented after the 2.7.0 release... Borut |
From: Maarten B. <sou...@ds...> - 2007-05-07 19:35:12
|
Borut, I don't really care about the regex for the tests. But I do like to get an answer from someone if the test is supposed to pass or fail (w/o the L). After that adaptation is easy. Maybe I should have asked for it more explicitly. Is Johan Knol still around? Or a word on this by Bernhard Held maybe? Maarten > Frieder Ferlemann wrote: > > Hi Maarten, > > > > "Maarten Brock" <sou...@ds...> schrieb am 07.05.2007 15:40:47: > > > >> Why is it surprising this test fails? It generates a warning about integer > >> overflow in expression. If you change 19200 to 19200L it's allright. > >> > > > > Fine. The surprising part (to me) was that apparently some of the > > tests were not executed because the white spaces around the function > > definition did not match. > > The rule for function names is '^test\w+\(\w+\)' (from > support/regression/generate-cases.py), which is not enough flexible by > my opinion. Better option would be '^\W*test\w*\W*\(\W*void\W*\)', which > allows spaces around the function definition and a void parameter list, > optionally surrounded by spaces. > > This is probably a small enhancement to be implemented after the 2.7.0 > release... > > Borut > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Borut R. <bor...@si...> - 2007-05-07 21:48:47
|
Maarten Brock wrote: > Borut, > > I don't really care about the regex for the tests. I know that my observation was not related to the original problem, but more an answer to Frieder's finding of tests which were not executed. I also saw that you used a function name test() in bug1714204.c, which would be probably better to rename to something else (something not starting with 'test'), to avoid potential problems if the regex will change in the future... > But I > do like to get an answer from someone if the test is > supposed to pass or fail (w/o the L). After that > adaptation is easy. Maybe I should have asked for it > more explicitly. > > My opinion is that L is required in combination of at least one of numbers in the denominator in order to promote the denominator result to long. But I might be wrong... BTW, what is your opinion about the following one? >>This one is still be open "[ 1618050 ] badly optimized xdata pointer" >> http://sourceforge.net/tracker/index.php?func=detail&aid=1618050&group_id=599&atid=100599 Borut |
From: Borut R. <bor...@si...> - 2007-05-07 21:56:32
|
Borut Razem wrote: > Maarten Brock wrote: > > But I >> do like to get an answer from someone if the test is >> supposed to pass or fail (w/o the L). After that >> adaptation is easy. Maybe I should have asked for it >> more explicitly. >> >> >> > > My opinion is that L is required in combination of at least one of > numbers in the denominator in order to promote the denominator result to > long. But I might be wrong... > Just as an additional info: I tried it with 16 bit watcom compiler and I got the expected result 263 (0xfd) with 19200L. Borut |
From: Maarten B. <sou...@ds...> - 2007-05-07 22:05:33
|
> Just as an additional info: I tried it with 16 bit watcom compiler and I > got the expected result 263 (0xfd) with 19200L. Sure, but what does it give without the L? Is it still 0xFD? |
From: Borut R. <bor...@si...> - 2007-05-08 05:17:16
|
Maarten Brock wrote: >> Just as an additional info: I tried it with 16 bit watcom compiler and I >> got the expected result 263 (0xfd) with 19200L. >> > > Sure, but what does it give without the L? Is it still > 0xFD? > > Yes, my report was incomplete: without L the result is 163. If we can trust the watcom C, the longlit.c regtest test is wrong: there should be a L after 19200. Maybe we could add an other test without the L and change the assertion value. The problem here is that I don't know how the watcom C calculated 163... Borut |
From: Maarten B. <sou...@ds...> - 2007-05-07 22:07:11
|
Borut, > I also saw that you used a function name test() in bug1714204.c, which > would be probably better to rename to something else (something not > starting with 'test'), to avoid potential problems if the regex will > change in the future... Oops, that's a leftover from the code in the bug report. I'll change it. > > But I > > do like to get an answer from someone if the test is > > supposed to pass or fail (w/o the L). After that > > adaptation is easy. Maybe I should have asked for it > > more explicitly. > > My opinion is that L is required in combination of at least one of > numbers in the denominator in order to promote the denominator result to > long. But I might be wrong... Then shall we remove the test or add the L and enable it? > BTW, what is your opinion about the following one? > > >>This one is still be open "[ 1618050 ] badly optimized xdata pointer" > >> http://sourceforge.net/tracker/index.php?func=detail&aid=1618050&group_id=599&atid=100599 This needs to be solved at the AST or Icode level. Not my strongest area of expertise, so "I" would leave it till after the release. But if anyone else wants to have a go, that's fine with me. Maarten |
From: Jan W. <we...@ef...> - 2007-05-07 22:12:31
|
> > >>This one is still be open "[ 1618050 ] badly optimized xdata pointer" > > >> http://sourceforge.net/tracker/index.php?func=detail&aid=1618050&group_id=59 9&atid=100599 > > This needs to be solved at the AST or Icode level. Not > my strongest area of expertise, so "I" would leave it > till after the release. But if anyone else wants to have > a go, that's fine with me. Hey, that's MY obscure error... :-) I don't think it is more important than any of the other X open errors in the Tracker, is it... Jan Waclawek |