C++ exception handling on PPC with gcc 6.4.0 doesn't work

[Dave Horsfall]

In this case, I was running Unify (an old RDBMS) on a 386, and it kept 
failing in mysterious ways.  So, I bought a book on programming the 386 
(ugh!), inspected the assembler code before and after "-O", and noticed 
that a crucial instruction had been optimised right out of existence...

Hey, who needs that floating point ADD instruction?  I've already done it!

I've never trusted optimisers since...

On Wed, 26 Jun 2024, Richard L. Hamilton wrote:

> Optimizers definitely are not perfect. Making alterations for efficiency that are always identical in well defined meaning to the original code is bound to be difficult to get right. Think of it as a challenge on the order of  translating poetry in a way that preserves all of meaning, tension/pacing, and rhyme; sometimes that's not possible because poetry overloads language with all those attributes at once, and you may have to degrade one in translation to preserve the others.
> 
> And in your example, I think it probably is the optimizer at fault (I didn't read up on everything necessary to be sure, but it's such a simple example that it seems likely).
> 
> But C and C++ have situations where something is not strictly a syntax error in the language but results in undefined (and possibly inconsistent!) behavior, that the compiler may not even warn you about. You may tend to get away with more of that without the optimizer than with; but that sort of issue, if you track it down and rewrite to avoid the undefined behavior, is likely to work properly with or without optimizer. At least some of these are arguably faults in the standard(s), but some may be allowed to keep compiler implementations from being prohibitively difficult.
> 
> There is some interesting discussion of related subjects out there.
> 
> https://stackoverflow.com/questions/7237963/is-there-a-c-implementation-that-detects-all-undefined-behavior#:~:text=However%2C%20it%20is%20possible%20to,the%20code%20has%20undefined%20behavior.
> 
> has some, and some links to promising resources. I haven't investigated deeply, nor am sure I even understand it all, but its something to think about.
> 
> Ancient CPUs had less issues. But modern CPUs for efficiency and capability have multiprocessing, multithreading, memory caches (which in combination with multiple CPU chips may require extra hardware effort to be kept consistent), branch prediction, sometimes out-of-order execution, and other behaviors that if care is not taken, lead to inconsistent results.
> 
> If you need absolutely exact behavior, you probably need to understand your CPU and code in assembler; esp. if you need exact timing (insofar as that's even possible on a modern CPU, where instruction times may depend on whether an addressed value is in cache). Or at the very least, have read not only the relevant language standard but any implementation specific compiler notes.
>  
> > On Jun 25, 2024, at 23:01, Dave Horsfall <dave at horsfall.org> wrote:
> > 
> > On Tue, 25 Jun 2024, Andreas Falkenhahn wrote:
> > 
> > [...]
> > 
> >> So the good news is that I've found a workaround. Turning the optimizer 
> >> off will make exceptions work again but the bad news is that of course 
> >> it looks like there is some major issue in the optimizer because 
> >> enabling it seems to break exceptions...
> > 
> > I've overcome all sorts of obscure problems by simply turning off the 
> > optimiser; face it: do you really want some unknown third party mucking 
> > around with your carefully-crafted algorithm?
> > 
> > -- Dave
> > 
> 
> 
> 

-- Dave