Menu
▾
▴
gcc4cli-devel
|
From: Erven R. <erv...@in...> - 2010-02-19 08:00:01
|
Ciao, Many benchmarks (unfortunately) use setjmp and longjmp, which we do not support. However, longjmp is often used to handle exceptional situations, mostly errors. Here is a proposal: we could define setjmp to return 0, and longjmp to abort (or print a message and abort,...) We could compile and run benchmarks that do not have errors. Probably we keep a warning in the header file. What do you think? -- Erven. |
|
From: Gabriele S. <gab...@gm...> - 2010-02-19 08:04:02
|
2010/2/19 Erven Rohou <erv...@in...>: > Ciao, > > Many benchmarks (unfortunately) use setjmp and longjmp, which we do not support. > However, longjmp is often used to handle exceptional situations, mostly errors. > Here is a proposal: we could define setjmp to return 0, and longjmp to abort (or > print a message and abort,...) We could compile and run benchmarks that do not > have errors. Probably we keep a warning in the header file. > What do you think? Sounds like a good idea, I believe most of the stuff will work well under normal conditions. Gabriele |
|
From: Erven R. <erv...@in...> - 2010-02-19 10:38:56
Attachments:
patch.setjmp
|
Gabriele Svelto a écrit : > 2010/2/19 Erven Rohou <erv...@in...>: >> Ciao, >> >> Many benchmarks (unfortunately) use setjmp and longjmp, which we do not support. >> However, longjmp is often used to handle exceptional situations, mostly errors. >> Here is a proposal: we could define setjmp to return 0, and longjmp to abort (or >> print a message and abort,...) We could compile and run benchmarks that do not >> have errors. Probably we keep a warning in the header file. >> What do you think? > > Sounds like a good idea, I believe most of the stuff will work well > under normal conditions. > > Gabriele > Here is a patch for libstd. Please let me know if you have any comment. As usual I am having problems with automake/autoconf/etc. I modified Makefile.am to add the file setjmp.c. autoreconf generated lots of stuff that breaks my build. So I patched Makefile.in by hand. It seems that some tool also modified config.h.in and configure. Anyway, if somebody has an idea, I am willing do it properly. :-) -- Erven. |
|
From: Andrea C. O. <and...@gm...> - 2010-03-22 16:29:15
|
It changes a lot of files because there is a change in the autotools version you are using. Originally we used autoconf 2.59 (quite old) you are using 2.63 It probably changes all Makefile.in configure and config.h and aclocal.m4 It's fine. I think we can move to a new version. I even use 2.65 now :) Andrea On Fri, Feb 19, 2010 at 11:38 AM, Erven Rohou <erv...@in...> wrote: > Gabriele Svelto a écrit : >> >> 2010/2/19 Erven Rohou <erv...@in...>: >>> >>> Ciao, >>> >>> Many benchmarks (unfortunately) use setjmp and longjmp, which we do not >>> support. >>> However, longjmp is often used to handle exceptional situations, mostly >>> errors. >>> Here is a proposal: we could define setjmp to return 0, and longjmp to >>> abort (or >>> print a message and abort,...) We could compile and run benchmarks that >>> do not >>> have errors. Probably we keep a warning in the header file. >>> What do you think? >> >> Sounds like a good idea, I believe most of the stuff will work well >> under normal conditions. >> >> Gabriele >> > > Here is a patch for libstd. Please let me know if you have any comment. > As usual I am having problems with automake/autoconf/etc. > I modified Makefile.am to add the file setjmp.c. autoreconf generated lots > of stuff that breaks my build. So I patched Makefile.in by hand. It seems > that some tool also modified config.h.in and configure. > Anyway, if somebody has an idea, I am willing do it properly. :-) > > -- > Erven. > |
|
From: Andrea C. O. <and...@gm...> - 2010-03-22 16:20:08
|
Hi all, I think we should do the ci and solve the problems for the time being. The real point here is that we have just one target description. My initial idea was to have different machine types: 32bit vs 64bit targeting a VM vs using cil as intermediate representation something like cil32-ir cil64-ir cil32-vm cil64-vm and even more variants if we consider endianness 32 vs 64 changes the machine description and gimple_to_cil IR vs VM changes mostly the runtime environment: what do we do with setjump/longjump, signals, (in C++ exceptions), and so on when targetting a VM we map them on the CLI runtime services when using it as an IR we may keep them as calls that are recognized properly by the users of the code produced. Andrea On Fri, Feb 19, 2010 at 11:38 AM, Erven Rohou <erv...@in...> wrote: > Gabriele Svelto a écrit : >> >> 2010/2/19 Erven Rohou <erv...@in...>: >>> >>> Ciao, >>> >>> Many benchmarks (unfortunately) use setjmp and longjmp, which we do not >>> support. >>> However, longjmp is often used to handle exceptional situations, mostly >>> errors. >>> Here is a proposal: we could define setjmp to return 0, and longjmp to >>> abort (or >>> print a message and abort,...) We could compile and run benchmarks that >>> do not >>> have errors. Probably we keep a warning in the header file. >>> What do you think? >> >> Sounds like a good idea, I believe most of the stuff will work well >> under normal conditions. >> >> Gabriele >> > > Here is a patch for libstd. Please let me know if you have any comment. > As usual I am having problems with automake/autoconf/etc. > I modified Makefile.am to add the file setjmp.c. autoreconf generated lots > of stuff that breaks my build. So I patched Makefile.in by hand. It seems > that some tool also modified config.h.in and configure. > Anyway, if somebody has an idea, I am willing do it properly. :-) > > -- > Erven. > |
|
From: Erven R. <erv...@in...> - 2010-03-22 18:46:57
|
Andrea Carlo Ornstein a écrit : > Hi all, > > I think we should do the ci and solve the problems for the time being. Just committed. > The real point here is that we have just one target description. > My initial idea was to have different machine types: > 32bit vs 64bit > targeting a VM vs using cil as intermediate representation > > something like > cil32-ir > cil64-ir > cil32-vm > cil64-vm This is a good idea! We should work on it sometime... ;-) Ciao, -- Erven. > > and even more variants if we consider endianness > > 32 vs 64 changes the machine description and gimple_to_cil > > IR vs VM changes mostly the runtime environment: > what do we do with setjump/longjump, signals, (in C++ exceptions), and so on > > when targetting a VM we map them on the CLI runtime services > when using it as an IR we may keep them as calls that are recognized > properly by the users of the code produced. > > Andrea > > On Fri, Feb 19, 2010 at 11:38 AM, Erven Rohou <erv...@in...> wrote: >> Gabriele Svelto a écrit : >>> 2010/2/19 Erven Rohou <erv...@in...>: >>>> Ciao, >>>> >>>> Many benchmarks (unfortunately) use setjmp and longjmp, which we do not >>>> support. >>>> However, longjmp is often used to handle exceptional situations, mostly >>>> errors. >>>> Here is a proposal: we could define setjmp to return 0, and longjmp to >>>> abort (or >>>> print a message and abort,...) We could compile and run benchmarks that >>>> do not >>>> have errors. Probably we keep a warning in the header file. >>>> What do you think? >>> Sounds like a good idea, I believe most of the stuff will work well >>> under normal conditions. >>> >>> Gabriele >>> >> Here is a patch for libstd. Please let me know if you have any comment. >> As usual I am having problems with automake/autoconf/etc. >> I modified Makefile.am to add the file setjmp.c. autoreconf generated lots >> of stuff that breaks my build. So I patched Makefile.in by hand. It seems >> that some tool also modified config.h.in and configure. >> Anyway, if somebody has an idea, I am willing do it properly. :-) >> >> -- >> Erven. >> > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X