On Jun 16, 2006, at 12:47 AM, Paolo Bonzini wrote:
I think that every variable you do "weird" things with in C, must
be declared volatile.
The C++/Objective-C/Objective-C++ language standards ensures that you
don't have to mark all variables volatile in the presence of EH.
These builtins
On Jun 16, 2006, at 5:54 AM, Gabriel Dos Reis wrote:
For the bootstrapping problem I mentioned earlier, they added volatile
to variables in the scope but it did not change anything.
For the problem I am thinking of, volatile should go a long way in
working around the compiler bug, assuming no
> The discussion kind of wandered off, but I'd like to note that I am in
> favor of adding __try/__finally as a GNU extension for both C and C++.
> It's true, of course, that it's just syntactic sugar which can be
> implemented in other ways, but sometimes sugar is sweet.
How would this mesh with
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
| On 6/16/06, Mike Stump <[EMAIL PROTECTED]> wrote:
| > foo() {
| >int i = 99;
| >__builtin_setjmp(A)
| >if (i) {
| > print i
| > --i;
| > __builtin_longjump(A);
| >}
| >
| > It used to not infinite loop, now it does.
| >
Steven Bosscher wrote:
On 6/16/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> foo() {
>int i = 99;
>__builtin_setjmp(A)
>if (i) {
> print i
> --i;
> __builtin_longjump(A);
>}
>
> It used to not infinite loop, now it does.
We had an example just like this on IRC only a
Gabriel Dos Reis <[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.
On 6/16/06, Mike Stump <[EMAIL PROTECTED]> wrote:
foo() {
int i = 99;
__builtin_setjmp(A)
if (i) {
print i
--i;
__builtin_longjump(A);
}
It used to not infinite loop, now it does.
We had an example just like this on IRC only a few weeks ago. ISTR it
was decided that
On Jun 15, 2006, at 4:47 PM, Andrew Pinski wrote:
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.
How is it no longer working? I don't understand how i
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 co
>
> 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-p
On Thu, 15 Jun 2006, Andrew Pinski wrote:
| >
| > On Thu, Jun 15, 2006 at 07:21:03PM -0400, Andrew Pinski wrote:
| > > > 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 _
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/ms
>
> On Thu, Jun 15, 2006 at 07:21:03PM -0400, Andrew Pinski wrote:
> > > 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://gc
On Thu, Jun 15, 2006 at 07:21:03PM -0400, Andrew Pinski wrote:
> > 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/gc
> 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 i
Hi,
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 f
16 matches
Mail list logo