SDCC Compiler User Guide

SDCC Compiler User Guide

Chapter 7


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


You’ll find the complete set of mailing lists, forums, bug reporting system, patch submission system, download area and cvs code repository there.


Reporting Bugs

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 "

sdcc -v

"), 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:



Requesting Features

Like bug reports feature requests are forwarded to the developer mailing list. This is the link for requesting features:





Submitting patches

Like bug reports contributed patches are forwarded to the developer mailing list. This is the link for submitting patches:


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”

will do.


Getting Help

These links should take you directly to the Mailing lists

1 and the Forums , 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*checkout*/sdcc/sdcc/ChangeLog?rev=HEAD&content-type=text/plain .


Release policy

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

, and you can always build the very last version (hopefully with many bugs fixed, and features added) from the source code available at 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.




Quality control

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.

”make test-mcs51”

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)


Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF


Table of contents