On Thu, 15 Jun 2006, Andrew Pinski wrote: | > | > Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > | > while looking into a recent mismatch between GCC-4.x and a C dialect | > | > EH implemented as setjmp/longjmp, I recalled there was a talk about | > | > extending GNU C with __try/__finally construct: | > | > | > | > http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00239.html | > | > | > | > What happened to that project? Is it dead for good? | > | | > | Doesn't the cleanup attribute to a variable do close to the same thing? | > | > The front-end in question has stopped working because the traditional | > setjmp/longjmp translation of try/catch constructs is no longer | > working correctly with versions of GCC higher than 4.0. What is | > important for the front-end is that the try-block part is handled | > correctly; that I don't see the cleanup attributes provides. | | How is it no longer working? I don't understand how it could break.
"no longer working" in the sense of simple evidence from user perspective: things that used to work before no longer works when they go to GCC-4.x. The compiler no longer bootstraps, for reasons traced to the handling of setjmp/longjmp's translation of try/catch. I'm investigating the translation, but my sentiment is that it is correct. | Now if the front-end was converting the functions with marking some live | variables with violatile, it would have caused problems with GCC before 3.4.x | also. from all empirical data gathered, the compiler is working with versions of GCC prior to GCC 4.x. The compiler is not marking live variable as volatile -- it can't aford that if my understanding of the language/translation is correct. The project currently recommends against GCC 4.x -- which is the main reason why I'm investigating way to make the path to GCC-4.x. -- Gaby
