Re: C++ exception handling on PPC with gcc 6.4.0 doesn't work
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 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
Re: C++ exception handling on PPC with gcc 6.4.0 doesn't work
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 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 >
Re: C++ exception handling on PPC with gcc 6.4.0 doesn't work
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
Re: C++ exception handling on PPC with gcc 6.4.0 doesn't work
I've done some more investigation and actually, generally speaking C++
exceptions do seem to work on PPC but for some reason not always. I experienced
some rather strange behaviour, e.g.
// this throw() worked correctly
throw(0);
if (_config->isInited) return {};
// this throw() didn't work and caused a program freeze
if (_config->isInited) return {};
throw(0);
The next thing I tried was turning the optimizer off (previously I was always
compiling with -O2). Interestingly, turning the optimizer off solved the
problem. When compiling without -O2 exceptions seem to work fine and there is
no strange behaviour any longer but even using the lowest level of
optimization, i.e. just -O, will bring the problems back.
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...
FWIW, I've also tried gcc-mp-7 (MacPorts gcc7 7.5.0_4) which AFAICS is the most
recent gcc available for PPC but it shows the same behaviour.
On 27.05.2024 at 18:46 Ken Cunningham wrote:
> do exceptions work with the default gcc7 compiler?
Re: C++ exception handling on PPC with gcc 6.4.0 doesn't work
do exceptions work with the default gcc7 compiler? K
C++ exception handling on PPC with gcc 6.4.0 doesn't work
I'm using gcc-mp-6 (MacPorts gcc6 6.4.0_0) from 2017 on a PowerPC MacOS system 10.5. For some reason, using C++ exceptions doesn't seem to work with the compiler. Whenever my program tries to throw an exception, it just hangs and I need to use Ctrl-C to kill it. Are C++ exceptions generally unsupported by the gcc-mp-6 version I'm using or is there any special compiler or linker flag that needs to be used to make C++ exceptions work with my gcc-mp-6 version? Any ideas? -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
