11–17 of 17 posts
Here's another horrid gcc inline asm bug: http://robertoconcerto.blogspot.co.uk/2013/03/my-hardest-bug... As a general rule, to which the usual caveats for general rules apply, when it comes to gcc-style inline asm, just say no. Demand more from your tools.
We were quite surprised to find a bug in some common code for the NIOS II architecture: we were assuming it would have already been tested on enough platforms and with enough compilers/situations to not have such issues. I'm betting on the vast majority of memset() uses being to zero memory, so it might've not been tested much with other fill patterns. Compared to MSVC, I've found GCC's inline-assembler feature a hug…
Fortunately there are still some people doing development on UNIX and sharing their software tools.
Here's another horrid gcc inline asm bug: http://robertoconcerto.blogspot.co.uk/2013/03/my-hardest-bug... As a general rule, to which the usual caveats for general rules apply, when it comes to gcc-style inline asm, just say no. Demand more from your tools.
That said, for longer pieces of code, I definitely avoid inline-asm and just use a separate assembly file. There's no debating it's a cleaner solution when you have more then one or a few lines of assembly. And really, besides those obscure CPU instructions, your written assembly is usually not much different, then the stuff generated from some C code. It's worth using C wherever it's viable.
It's been my experience that it's easy to write GCC inline asm that works the first few times you use it, but subtly breaks depending on what the optimizer does with the code around it. Those input/output/clobber arguments can be tricky to get right and wrongness can be hard to spot.
Yeah, and as one of the comments to that blog post says, for bit twiddling operations like this, modern compilers are good enough to generate the optimal assembler the vast majority of the time: If you write the equivalent C code uint32 fill16 = (fill (copied from the comment, so hopefully correct!) you get the benefit of a) not having to fiddle with abstruse register allocation semantics but b) you’re letting gcc us…
Using the intrinsic provided significant performance improvements, and we got still more when the rest of the inner loop was rewritten purely in assembly.
We were quite surprised to find a bug in some common code for the NIOS II architecture: we were assuming it would have already been tested on enough platforms and with enough compilers/situations to not have such issues. I'm betting on the vast majority of memset() uses being to zero memory, so it might've not been tested much with other fill patterns. Compared to MSVC, I've found GCC's inline-assembler feature a hug…
There was exactly this bug in Android for a long time - memset always cleared the memory to zero. I can't find a good link to this, but try maybe https://review.source.android.com/#patch,sidebyside,14699,1,... , not that Firefox will let me connect to check. As for the rules for VC++, they are conservative - see https://msdn.microsoft.com/en-us/library/k1a8ss06.aspx . In general, you're right that it's much nicer to…
The inline Assembly syntax of PC compilers always felt natural and easy to remember.
Every time I look at gcc inline Assembly, I get this feeling it is impossible to get right without having the manual page always open.
Isn't this exactly the kind of function that you would want thoroughly covered with unit tests?