SDCC Compiler User Guide | Support
SDCC has grown to be a large project. The compiler alone (without the preprocessor, assembler and linker) is well over 100,000 lines of code (blank stripped). The open source nature of this project is a key to its continued growth and support. You gain the benefit and support of many active software developers and end users. Is SDCC perfect?
No, that’s why we need your help. The developers take pride in fixing reported bugs. You can help by reporting the bugs and helping other SDCC users. There are lots of ways to contribute, and we encourage you to take part in making SDCC a great software package.
The SDCC project is hosted on the SDCC sourceforge site at http://sourceforge.net/projects/sdcc
You’ll find the complete set of mailing lists, forums, bug reporting system, patch submission system, download area and cvs code repository there.
The recommended way of reporting bugs is using the infrastructure of the sourceforge site. You can follow the status of bug reports there and have an overview about the known bugs.
Bug reports are automatically forwarded to the developer mailing list and will be fixed ASAP. When reporting a bug, it is very useful to include a small test program (the smaller the better) which reproduces the problem. If you can isolate the problem by looking at the generated assembly code, this can be very helpful. Compiling your program with the --dumpall option can sometimes be useful in locating optimization problems. When reporting a bug please maker sure you:
1. Attach the code you are compiling with SDCC.
2. Specify the exact command you use to run SDCC, or attach your Makefile.
3. Specify the SDCC version (type "
"), your platform, and operating system.
4. Provide an exact copy of any error message or incorrect output.
5. Put something meaningful in the subject of your message.
Please attempt to include these 5 important parts, as applicable, in all requests for support or when reporting any problems or bugs with SDCC. Though this will make your message lengthy, it will greatly improve your chance that SDCC users and developers will be able to help you. Some SDCC developers are frustrated by bug reports without code provided that they can use to reproduce and ultimately fix the problem, so please be sure to provide sample code if you are reporting a bug!
Please have a short check that you are using a recent version of SDCC and the bug is not yet known. This is the link for reporting bugs: http://sourceforge.net/tracker/?group_id=599&atid=100599
Like bug reports feature requests are forwarded to the developer mailing list. This is the link for requesting features: http://sourceforge.net/tracker/?group_id=599&atid=350599
7.3. SUBMITTING PATCHES CHAPTER 7. SUPPORT
Like bug reports contributed patches are forwarded to the developer mailing list. This is the link for submitting patches: http://sourceforge.net/tracker/?group_id=599&atid=300599
You need to specify some parameters to the diff command for the patches to be useful.
If you modified more than one file a patch created f.e.
”diff -Naur unmodified_directory modified_directory
will be fine, otherwise
”diff -u sourcefile.c.orig sourcefile.c >my_changes.patch”
These links should take you directly to the Mailing lists http://sourceforge.net/mail/?group_id=599
1 and the Forums http://sourceforge.net/forum/?group_id=599 , lists and forums are archived and searchable so if you are lucky someone already had a similar problem. While mails to the lists themselves are delivered promptly their web front end on sourceforge sometimes shows a severe time lag (up to several weeks), if you’re seriously using SDCC please consider subscribing to the lists.
You can follow the status of the cvs version of SDCC by watching the Changelog in the cvs-repository http://cvs.sf.net/cgi-bin/viewcvs.cgi/*checkout*/sdcc/sdcc/ChangeLog?rev=HEAD&content-type=text/plain .
Historically there often were long delays between official releases and the sourceforge download area tends to get not updated at all. Excuses in the past might have referred to problems with live range analysis, but as this was fixed a while ago, the current problem is that another excuse has to be found. Kidding aside, we have to get better there!
On the other hand there are daily snapshots available at snap http://sdcc.sourceforge.net/snap.php
, and you can always build the very last version (hopefully with many bugs fixed, and features added) from the source code available at Source http://sdcc.sourceforge.net/snap.php#Source
You’ll find some small examples in the directory sdcc/device/examples/. More examples and libraries are available at The SDCC Open Knowledge Resource
web site or at http://www.pjrc.
The compiler is passed through nightly compile and build checks. The so called regression tests check that SDCC itself compiles flawlessly on several platforms and checks the quality of the code generated by SDCC by running the code through simulators. There is a separate document test_suite.pdf about this.
You’ll find the test code in the directory sdcc/support/regression. You can run these tests manually by running make in this directory (or f.e.
if you don’t want to run the complete tests). The test code might also be interesting if you want to look for examples checking corner cases of SDCC or if you plan to submit patches.
The pic port uses a different set of regression tests, you’ll find them in the directory sdcc/src/regression.
Traffic on sdcc-devel and sdcc-user is about 100 mails/month each not counting automated messages (mid 2003)
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project