- "The weirdest compiler bug" by Scott Rasmussen - 6 Updates
- Poor Mans RCU... - 1 Update
- Looking for the tgaimg exe/code - 2 Updates
| red floyd <no.spam.here@its.invalid>: Feb 09 10:31PM -0800 On 2/9/2021 1:28 AM, Juha Nieminen wrote: > when I finally found it (and was able to circumnavigate it by changing > the code in such a manner that it didn't trigger the bug). > (If you are curious, the compiler in question was sdcc.) That's a "Heisenbug". Observing the bug affects its behavior. |
| red floyd <no.spam.here@its.invalid>: Feb 09 10:35PM -0800 On 2/9/2021 12:14 PM, Chris M. Thomasson wrote: > are pretty damn hard to debug. > There are a lot of smart people commenting on that thread. Heck, even I > am there. ;^) Not quite a compiler bug, but a library bug. We were using a vendor provided library for the TI 34020, and had to compile it ourselves. Unfortunately, it only worked when compiled without optimization. The issue was that registers were memory-mapped, and they were being optimized out of polling loops. e.g: const char *const register = (const char *) 0x12345678L; // ... while ((register & SOMEBIT) == 0) /* spin */ ; The fix was to declare it const volatile: const volatile char *const register = (const char *) 0x12345678L; That one took a while to find. |
| David Brown <david.brown@hesbynett.no>: Feb 10 11:52AM +0100 On 10/02/2021 07:35, red floyd wrote: > The fix was to declare it const volatile: > const volatile char *const register = (const char *) 0x12345678L; > That one took a while to find. Vendor supplied libraries and code regularly have bugs, and even more regularly have limitations on the optimisation that lets them work (that is, of course, a kind of bug in the code - the vendor's viewpoint might be that it is just using the code outside of specifications. Undocumented specifications, of course). I've seen vendor code that fails to compile in C99 mode, and is only usable in C90 mode. (It takes a special kind of imaginative cock-up to achieve that.) I've seen vendor code that is pointlessly written in assembly, when simple clear C code would have been much more efficient - and would not fail to build due to small changes in the compiler flags. A lot of vendor-supplied code seems to be written by students on summer jobs. And a lot seems to be hacks and patches built on decades-old code written for a different type of processor. But it is IMHO more annoying when it is bugs in the compiler or compiler-supplied libraries, from suppliers that normally have very high quality. One that I find particularly irritating is that the gcc-supplied atomics library for the ARM (I think it is more general than that, but I use gcc on embedded ARMs) is totally wrong. Spin locks are /not/ a good idea on single processor systems! |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 10 08:33AM -0500 On 2/10/21 5:52 AM, David Brown wrote: ... > I've seen vendor code that fails to compile in C99 mode, and is only > usable in C90 mode. (It takes a special kind of imaginative cock-up to > achieve that.) Not really - relying upon implicit int or implicit function definition would be sufficient. |
| David Brown <david.brown@hesbynett.no>: Feb 10 02:41PM +0100 On 10/02/2021 14:33, James Kuyper wrote: >> achieve that.) > Not really - relying upon implicit int or implicit function definition > would be sufficient. A sufficiently lax C99 compiler will accept these, perhaps with warnings (and like gcc, this compiler was pretty lax by default - far too lax, IMHO). No, the problem here was caused by an incomprehensible jungle of conditional compilations that were there to support different compilers and different microcontrollers - most of which were no longer even produced. This mess had errors, leading to compilation faults with certain perfectly reasonable compiler flags. (Bart would have had a field day if he saw that code!) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 10 09:48PM On Wed, 2021-02-10, David Brown wrote: > and different microcontrollers - most of which were no longer even > produced. This mess had errors, leading to compilation faults with > certain perfectly reasonable compiler flags. Sounds like my experience with programmable network controllers. We got this multi-megabyte SDK, and you couldn't use it as a library: you had to use it as a framework, and submit to their build tools and everything[1]. We mostly wanted to add some filters to make different packets end up on different Rx queues. I could never figure out if it was hard on purpose (an obfuscation layer so you couldn't learn how the hardware worked?) or if it was due to incompetence. But wouldn't it be good for a hardware vendor if the hardware was easy to integrate with software? > (Bart would have had a field day if he saw that code!) I think I felt like Bart a lot in those days. /Jorgen [1] Which was a problem, because we were already submitting, BDSM-style, to a number of other build chains. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Feb 10 12:46PM -0800 On Wednesday, 10 February 2021 at 01:04:40 UTC+2, Chris M. Thomasson wrote: > > .0.0.2...\n"; > > std::cout << "_______________________________________\n\n"; > Add a std::cout.flush(); right here. Or add << std::endl instead of << "\n" wherever you want to flush text streams. |
| Mike Garcia <mike@mgarcia.nospam>: Feb 10 01:34AM On Mon, 08 Feb 2021 22:53:26 +0000, Mike Garcia wrote: > Anyone got a win32 exe or the source code to tga2img? > Cheers Mike. Turns out it was a Sony PS1 specific tool, that converts TGA to TIM then to a C char array. I found it on an old hard drive, if anyone is interested I posted it here (it works in winXP): https://archive.org/details/tga2img_TIM2C -- Mike Garcia http://mgarcia.org |
| Anton Shepelev <anton.txt@g{oogle}mail.com>: Feb 10 08:39PM +0300 Mike Garcia: > If I find I'll upload it to archive.org and drop a link in > the thread. Thanks for making Usenet and Internet better. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment