![]() |
GCC bug or am I doing something wrong?
I am fiddling with Qt and, as always, writing and compiling the code on the phone itself. All was hunky-dory for many edit-and-compile iterations until I suddenly out of the blue started receiving this error:
Code:
{standard input}: Assembler messages: Code:
void WaveForm::on_comboFreqPeriod_currentIndexChanged (int index) Now here comes the interesting part. Various vays of editing the code got rid of the error:
All this points me in the direction of code size. In all cases that fixed the problem, a significant amount of additional code was generated or removed. My theory is that the compiler generates the code in multiples of X bytes and adds padding as necessary, and that the orn r3,r3,#127 instruction is somehow involved in that. Adding or removing enough code changes the padding and avoids using the instruction. Does anyone have a better explanation or, better still, a solution? I am using gcc 4.6.1 from extras-devel, if that makes any difference, and am using the CFLAGS trick suggested here to build Qt on the phone. Perhaps another flag is required? |
Re: GCC bug or am I doing something wrong?
Quote:
Can you provide some info as to how FREQUENCY and PERIOD are defined? Are they #defines, enums, variables? What are their values? (GCC might be utilizing the raw values in its jump tables, which is why their values could be interesting.) I haven't personally done any assembler or compiler stuff in a very, very long time, so take anything I say with a grain of salt. :) But, I just did a quick google search to refresh my memory on the subject; here's an interesting description of why to be wary of the switch statement: http://embeddedgurus.com/stack-overf...ch-statements/ On another topic, if there are only two possible values, it might be easier to just skip the switch statement altogether. :) An if/else statement should be just as efficient, if not more so: Code:
if (index == FREQUENCY) |
Re: GCC bug or am I doing something wrong?
I don't believe any compiler would add padding to a program. Sounds like perhaps a bug with the optimizer maybe, and changing the code enough causes the optimizer to do something differently that doesn't provide the error. Do you get the same error compiling with different levels of optimization?
|
Re: GCC bug or am I doing something wrong?
Hmm, haven't tried varying the optimization level, a good point. But I have seen an assembly output of various C and C++ programs (not this one yet though) and there often was a few bytes of padding with NOPs before or after the final RET from the subroutine.
Copernicus, FREQUENCY and PERIOD are enums with values 0 and 1, respectively. You are right, there are only those two values so I could have used an if instead of a switch but I think the latter communicates the intention more clearly. FWIW. the code has been completely refactored since last night and no longer exhibits the problem. |
Re: GCC bug or am I doing something wrong?
Quote:
Maybe this is interesting. http://schneide.wordpress.com/2010/1...itch-use-enum/ |
Re: GCC bug or am I doing something wrong?
Try -march=armv7-a or -march=native
|
Re: GCC bug or am I doing something wrong?
Quote:
Besides, we've got C++ here. :) I think it'd be better to go all the way and create a set of sibling classes. Something like this: Code:
class indexType |
Re: GCC bug or am I doing something wrong?
@Copernicus,
Thanks, that is a nice way to do it but I have already refactored it even further. As I have quite a bunch of combo boxes that change contents each time one of the other combos change, I thought it made sense to write a single function: Code:
static void refillComboBox (QComboBox *combo, Code:
#define ITEMS(x) sizeof x / sizeof x[0] @Halftux, I happen to agree with Copernicus. A cute way of (ab)using an enum but I would not go there. @pali, Of course I am using -march=armv7-a. That is the CFAGS trick mentioned in the OP. Without it, nothing works. |
All times are GMT. The time now is 21:44. |
vBulletin® Version 3.8.8