From: <Rag...@in...> - 2011-06-02 08:40:59
|
Dear Developers, Kudos to all the team behind this wonderful tool chain. In order to improve the SDCC test framework, I suggest the following: Since GCC & SDCC are both open source tool chains, is it possible to consider adding applicable GCC C-torture tests to SDCC test suite? This is because the torture tests are more in number and could cover those missing in SDCC test suite. I hope licensing should not be an issue. If I am wrong, let me know. I would be happy to correct myself. My personal observation is that a few tests on type conversions, optimizations involving pointers, loops, built-in library routines are failing when SDCC 3.0.2 is tested with GCC C-torture suite. If you are open to include these, I am ready to contribute to this topic ( I understand that some modifications needs to be done to these test cases to incorporate them into SDCC test suite). In any case, please let me know your opinions on this. Thanks & Best Regards, Raghunath Raghunath Lolur, IFIN ATV DEV DAvE, Infineon Technologies India Pvt Ltd, 3rd Floor, Phase I, Kalyani Platina Tech Park, EPIP ZONE, Whitefield, Bangalore 560066, INDIA * Tel. + (91) (80) 2513 1057 * Fax. + (91) (80) 2513 1212 * Email Rag...@in...<mailto:Sur...@in...> Visit us at: www.infineon.com<http://www.infineon.com/> __________________________________________________________________________________________________________________________________________________________________________ This email and any attachments are confidential and may be subject to legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). If you are not the named addressee(s) you must not use, disclose, retain or reproduce all or any part of the information contained in this email or any attachments. Any unauthorised use or disclosure may be unlawful. If you have received this email by mistake, please inform the sender immediately and delete it and all copies from your system and destroy any hard copies of it. |
From: Philipp K. K. <pk...@sp...> - 2011-06-02 20:18:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.06.2011 10:05, schrieb Rag...@in...: > Dear Developers, > > Kudos to all the team behind this wonderful tool chain. > > In order to improve the SDCC test framework, I suggest the > following: > > Since GCC & SDCC are both open source tool chains, is it possible to > consider adding applicable GCC C-torture tests to SDCC test suite? > This is because the torture tests are more in number and could cover > those missing in SDCC test suite. I hope licensing should not be an > issue. If I am wrong, let me know. I would be happy to correct > myself. My personal observation is that a few tests on type > conversions, optimizations involving pointers, loops, built-in > library routines are failing when SDCC 3.0.2 is tested with GCC > C-torture suite. If you are open to include these, I am ready to > contribute to this topic ( I understand that some modifications needs > to be done to these test cases to incorporate them into SDCC test > suite). > > In any case, please let me know your opinions on this. Sound like a good idea to me. The license should be OK, since it's only regression tests, where GPLv3 or whatever the gcc people use is OK (unlike e.g. the library). Just be careful that the tests 1) really test against the C standard and not against some particular behaviour gcc considers good practice. 2) don't depend on C features not yet implemented in sdcc, such as variable-length arrays or aggregate assignment. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3n7/kACgkQbtUV+xsoLprHCACg4kLxe3bYunbp53f3SlBzZizu MTcAn0TSP10SrmYNyBKHD/JAwn5r6Hxj =QxDf -----END PGP SIGNATURE----- |
From: Philipp K. K. <pk...@sp...> - 2011-12-22 08:00:32
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.06.2011 10:05, schrieb Rag...@in...: > Dear Developers, > > Kudos to all the team behind this wonderful tool chain. > > In order to improve the SDCC test framework, I suggest the > following: > > Since GCC & SDCC are both open source tool chains, is it possible to > consider adding applicable GCC C-torture tests to SDCC test suite? > This is because the torture tests are more in number and could cover > those missing in SDCC test suite. I hope licensing should not be an > issue. If I am wrong, let me know. I would be happy to correct > myself. My personal observation is that a few tests on type > conversions, optimizations involving pointers, loops, built-in > library routines are failing when SDCC 3.0.2 is tested with GCC > C-torture suite. If you are open to include these, I am ready to > contribute to this topic ( I understand that some modifications needs > to be done to these test cases to incorporate them into SDCC test > suite). Yesterday I had a look at the named tests (as opposed to the numbered ones, which are far more) tests in the execute part of the gcc c torture tests, excluding the builtin and ieee tests. About half of them were suitable for use with sdcc (the others depend on functionality missing in sdcc, or gcc-specific extensions or gcc-specific implementation-defined behaviour). I added those 60 to the sdcc regression test suite and opened 9 bug reports. The modifictions are rather basic for most tests: * Add header: /* scope-1.c from the execute part of the gcc torture tests. */ #include <testfwk.h> #ifdef SDCC #pragma std_c99 #endif * Replace calls to abort () by ASSERT (0) * Replace calls to exit () by return in main() * Replace return (0) by return in main() * Rename main() to void testTortureExecute (void) IMO the experience with these tests shows, that it probably would be worthwile to have a look at the other ones as well. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7y45cACgkQbtUV+xsoLponCgCfSKKn7PvoHTAg2/VOG1HKwzuj RiQAn3SK24L3Klxy5hICpXwA25ou/cOl =qz/y -----END PGP SIGNATURE----- |
From: Maarten B. <sou...@ds...> - 2011-12-22 22:00:04
|
Philipp, Can we please use a bit shorter names for these tests? Currently they are all truncated to the same "gcc- torture-execute-" in the output. This makes it impossible to see what passes or fails. Maybe just "gcc- exe-" as prefix is enough? Maarten > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 02.06.2011 10:05, schrieb Rag...@in...: > > Dear Developers, > > > > Kudos to all the team behind this wonderful tool chain. > > > > In order to improve the SDCC test framework, I suggest the > > following: > > > > Since GCC & SDCC are both open source tool chains, is it possible to > > consider adding applicable GCC C-torture tests to SDCC test suite? > > This is because the torture tests are more in number and could cover > > those missing in SDCC test suite. I hope licensing should not be an > > issue. If I am wrong, let me know. I would be happy to correct > > myself. My personal observation is that a few tests on type > > conversions, optimizations involving pointers, loops, built-in > > library routines are failing when SDCC 3.0.2 is tested with GCC > > C-torture suite. If you are open to include these, I am ready to > > contribute to this topic ( I understand that some modifications needs > > to be done to these test cases to incorporate them into SDCC test > > suite). > > Yesterday I had a look at the named tests (as opposed to the numbered > ones, which are far more) tests in the execute part of the gcc c torture > tests, excluding the builtin and ieee tests. About half of them were > suitable for use with sdcc (the others depend on functionality missing > in sdcc, or gcc-specific extensions or gcc-specific > implementation-defined behaviour). I added those 60 to the sdcc > regression test suite and opened 9 bug reports. > The modifictions are rather basic for most tests: > > * Add header: > /* > scope-1.c from the execute part of the gcc torture tests. > */ > > #include <testfwk.h> > > #ifdef SDCC > #pragma std_c99 > #endif > > > * Replace calls to abort () by ASSERT (0) > > * Replace calls to exit () by return in main() > > * Replace return (0) by return in main() > > * Rename main() to > void > testTortureExecute (void) > > IMO the experience with these tests shows, that it probably would be > worthwile to have a look at the other ones as well. > > Philipp > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk7y45cACgkQbtUV+xsoLponCgCfSKKn7PvoHTAg2/VOG1HKwzuj > RiQAn3SK24L3Klxy5hICpXwA25ou/cOl > =qz/y > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Philipp K. K. <pk...@sp...> - 2011-12-23 15:22:44
|
Am 22.12.2011 22:59, schrieb Maarten Brock: > Philipp, > > Can we please use a bit shorter names for these tests? > Currently they are all truncated to the same "gcc- > torture-execute-" in the output. This makes it > impossible to see what passes or fails. Maybe just "gcc- > exe-" as prefix is enough? > > Maarten > I prefer Erik's solution of making the name field wider, since it allows to have names that better correspond to their equivalent in gcc, which doesn't matter much now, but could become useful when we add further tests from gcc, e.g. from parts of the testsuite other than torture. In the long term, maybe we can use a directory structure for the tests, like gcc does? However, if the wider output causes some problems, abbreviating would be ok with me. Philipp |