Jump to content

Bugs In Boostc++

Recommended Posts

Hi there!



I have tried out the newest version of BoostC++ (v6.80) and it's a great improvement of an already great compiler.

But I may have stumbled upon some bugs. Four bugs, or at least 3 bugs and an annoyance :-)


There is a saying that "it's never the compilers' fault", and I may be wrong, but I think these are real bugs.


My evaluation system is:

* A standard XP SP2 laptop

* SourceBoost v6.80, specifically BoostC++ (not registered yet)

* PicKit 1

* A 12F675 (internally clocked)






Optimization removes unused functions, which is really good. But when a function, which is never used and thus removed,

declares a "rom unsigned char *" (or likely even a similar) array, the array itself is still included in the *.asm.


In my case, none of the code in the module which contained the function in question was ever used, so I could remove the

#include, but that was just luck.






In v6.80 we don't have to say "this->" in front of every method in the "current" class, which is very nice, so I removed all "this->" in my

test program, but ran into problems. Sometimes (but maybe not always) the resulting *.asm will be altered, as it was in in my case.


My C++ method (hardly optimal) is (byte being an unsigned char):

byte DS1302::read_s(void) {
byte ss = (this->execCmdAndRead(DS1302_READ_S, 8) & 0x7f);
return ((ss >> 4) * 10) + (ss & 0x0f);


This works as expected and results in an assembly section beginning like this:

	ORG 0x0000024E
; { read_s; function begin
MOVF read_s_00000_arg_this, W
MOVWF execCmdAnd_00018_arg_this
MOVF read_s_00000_arg_this+D'1', W
MOVWF execCmdAnd_00018_arg_this+D'1'
MOVLW 0x81


After removing the "this->" the program doesn't work anymore, and the assembly looks like this:

	ORG 0x0000024E
; { read_s; function begin
MOVF execCmdAnd_00018_arg_this, W
MOVWF execCmdAnd_00018_arg_this
MOVF execCmdAnd_00018_arg_this+D'1', W
MOVWF execCmdAnd_00018_arg_this+D'1'
MOVLW 0x81

Notice the 2 lines that have been changed (the MOVF's).

These are the only two lines in the entire assembly that have been changed.






Several posters have complained about the slow compile, and Pavel/Dave(?) has said that one should split a project to facilitate separate compilation,

which of course is a good idea. Unfortunately, at least in my setup, all files are compiled every time regardless of being altered or not.


Splitting the code into separate files is still a good idea since it simplifies maintenance and reuse, but unfortunately, at least in my case,

it doesn't speed up the compilation process. Does this really work for others?






Not neccessarily to be classified as a bug, but one has to write "class DS1302 rtc();" instead of just "DS1302 rtc();" which would look cleaner.




I wrote this before reading the preferred structure of a bug report, but I think it's clear enough.

I will gladly answer any questions you might have.


Best regards, and thanks for making a great compiler collection.



Link to post
Share on other sites

Thanks for reporting. #1,2,3 are definetly problems and will work on them. #4 is one we are aware about but it's a really tricky one so it likely won't be fixed any time soon.




Link to post
Share on other sites
  • 3 weeks later...

#2 is now fixed. Fix will be available in the next release.


Could not reproduce #3. Tried on a project that consists of 2 source files. When only one was changed the build command recompiler only that changed file.


#1 will be fixed later.




Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...