[ros-dev] [ros-diffs] [hyperion] 38461: modified tests/pseh2/psehtest.c finally_13 test re-enabled, as it doesn't crash anymore finally_14 test fixed. Now we know how exceptions thrown in a __finally are supposed to be handled PSEH test suite now has 91 tests and passes all of them with both GCC and Visual C++

[Timo Kreuzer]

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 ;-)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20081231/1cc59953/attachment.html