KJK::Hyperion schrieb:
Every test tests a real situation I encountered during development of
both PSEH 1 and PSEH 2 (infinite loops, stack misalignment, compilation
failures, faulty logic, paths in library code that were never executed,
compile-time constants with vs without side effects). Hypothetical
situations are only situations that haven't happened yet

If you have tests to propose, propose tests
Ok these test are fine to test that everything works as it should under some save assumptions.
I suggest adding tests that cover fully optimized code. Non-volatile variables, constants, lots of code needing multiple registers in the try and except block, inline functions, inline assembly, etc... Everything that might be used anywhere in our code and might be totally clobbered by the optimizer.


  

    

      
The return value of return_positive() is not stored anywhere, and ret
remains uninitialized. Congratulations! you found a compiler bug
      

    

    
No, it's a valid optimisation:
    

  

  

_SEH2EnterFrame is marked returns_twice, GCC should ensure all register
variables to be "dead" (i.e. copied to the stack frame) before calling
it, and warn if they could be clobbered. Trusting the contents of a
register after a call to _SEH2EnterFrame is a bug. Either that, or the
gotos must be confusing GCC's flow control analysis. But the gotos are
necessary for the pretty syntax, so we'll have to pay with yet more
redundant code
  



The gotos are not "confusing" gcc. SEH2EnterFrame isn't called in the 
first except branch, so the compiler is free to keep ret in any
register it likes during that branch. The try branch has no need to
keep ret in any memory location or register at all, because it's not
referenced any more. It's only set to the result of return_zero(). It
wouldn't make sense to store the old result as it will be droped
anyway. In other words the register *is dead* on entering the try
branch. Sorry, but you still didn't find a compiler bug.





  
  

  

    

      

        
After replacing the return_x, ... functions with macros I got 3 errors:
        

      

      
I don't. Send me your modifications
      

    

    
I attached 2 patches.
    

  

  

I believe this is what younger, ruder team members would refer to as
"epic fail". Not me, of course. Me, I just wish I wasn't expected to
find bugs in my bug reports
  



Lol, ok, I'd call it a typo ;-)