Re: try/finally in GNU C
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.html > > What happened to that project? Is it dead for good? 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. Ian
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
Hi, On Wed, 14 Jun 2006, Joe Buck wrote: > On Wed, Jun 14, 2006 at 11:34:33AM -0700, Mike Stump wrote: > > I'd welcome the issue be addressed by the SC. I'd favor more timely > > reviews. Maybe auto approval for a patch that sits for more than a > > week? :-) > > I see your smilie, Mike, but GCC would rapidly decay into a pile of > random bytes, unable to build itself, much less anything else, under such a > policy. Not necessarily. There are other (bigger but perhaps not as complicated) open source projects, which work under a much more open scheme. It doesn't need to be an everything-goes. It could be something like trusted people can commit after some time, even without formal review. If it breaks something it goes out again. Trusted people would basically be long time committers. I.e. a mix of maintainers and perhaps active write-after-approvals. The special thing would be that they can write to the whole tree by default, if nobody cares enough to prevent that. It's not like the patch authors are a bunch of unresponsible people randomly hacking crap together ;-) (I know that nobody is saying that) I would predict that GCC would gain quality by a much more open and accepting policy. > I know it's frustrating for people when their hard work doesn't get > reviewed for long periods of time. But GCC is a mature compiler, it's > stable, and while it has bugs and could be better, I'm not sure I *want* > GCC to start changing much more rapidly than it changes today. Bugs > will be fixed, yes. New features will be introduced, yes. But will the > quality level be maintained? That's the whole reason we insist on patch > review, so any process that speeds it up has to guarantee that will > still get a decent review of all patches (other than the truly obvious > ones). All patches still would have to be sent to [EMAIL PROTECTED] We have version control systems to back out whole patches at once. For some things reviewing can also happen after applying the patch (for most self-contained things I would argue). When the patch author is not sure about his way of tackling the problem he still is able to not check in without review or discussion. Trust is the key. Ciao, Michael.
Re: Top-level bootstrap question
Richard Kenner wrote:
I haven't had to to do this with the new mechanism for a while, but now I
need to do the equivalent of the old "make unstage1" and can't find
any documentation on how to do that (I thought this would be discussed
inside Makefile.tpl).
No, Makefile.tpl only discusses a few technical issues. The
documentation is in doc/makefile.texi.
I basically had something blow up in stage2, so I want to go back and
rebuild stage1 and start over. What target do I use?
If you want exactly what make unstage1 did, "make stage1-start". There
is also "make restrap" as in the old scheme. From the aforementioned docs:
@item [EMAIL PROTECTED] (@var{N} = [EMAIL PROTECTED])
For each package that is bootstrapped, rename directories so that,
for example, @file{gcc} points to the [EMAIL PROTECTED] GCC, compiled
with the [EMAIL PROTECTED] GCC.
You will invoke this target if you need to test or debug the
[EMAIL PROTECTED] GCC. If you only need to execute GCC (but you need
not run @samp{make} either to rebuild it or to run test suites),
you should be able to work directly in the @[EMAIL PROTECTED]
directory. This makes it easier to debug multiple stages in
parallel.
A side note: I've always been extremely confused by the "unstageN" and
"stageN" targets in the gcc directory. The double usage of "stage" as
noun and verb was complicating things, also because I'm not a native
speaker and the meaning of "to stage" as "to set aside" is not in my
dictionary. So I kept thinking that "stageN" brought back stage N,
while instead its purpose was to "stage" stage N. So I chose to name
the targets "stageN-start" (i.e. start working on stage N) and
"stageN-end" (i.e. put stage N away, I don't need it anymore), using two
verbs and removing the overloading of "stage". The choice was more or
less arbitrary and can be easily changed if there are better options.
Those better options could even be "unstageN" and "stageN", but I'd
rather have two verbs instead.
Paolo
Re: try/finally in GNU C
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 few weeks ago. ISTR it
was decided that this triggers undefined behavior by C99 7.13.2.1 sub
3.
I think that every variable you do "weird" things with in C, must be
declared volatile.
Paolo
Re: Generator programs can only be built with optimization enabled?
I actually like the existing behaviour, which I'm pretty sure hasn't changed for many years. I often find myself typing Hum, I think I need another patch. Paolo
What assertions to use in libcpp?
Hi, I'm somewhat stuck with debugging GCC+Boehm's GC bootstrap failure. At one point cpplib starts producing cpp_string objects with len = 0. They crash cpp_interpret_string. I'd like to add some assertions to the code to catch zero-length cpp_strings as early as possible, but I don't see any assertions in libcpp - neither assert nor gcc_assert. What could I use there? -- Laurynas
gcc-4.1.0 cross-compile for MIPS
hi, I'm trying to cross compile gcc-4.1.0 for mipsel platform.Following is the sequence of commands which i'm using ../gcc-4.1.0/configure --target=mipsel --without-headres --prefix=/home/shahzad/install/ --with-newlib --enable-languages=c make But following error is generated /home/shahzad/mips_gcc/./gcc/xgcc -B/home/shahzad/mips_gcc/./gcc/ -B/home/shahzad/install//mipsel/bin/ -B/home/shahzad/install//mipsel/lib/ -isystem /home/shahzad/install//mipsel/include -isystem /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or directory ../../../gcc-4.1.0/libssp/ssp.c: In function '__guard_setup': ../../../gcc-4.1.0/libssp/ssp.c:70: warning: implicit declaration of function 'open' ../../../gcc-4.1.0/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in this function) ../../../gcc-4.1.0/libssp/ssp.c:70: error: (Each undeclared identifier is reported only once ../../../gcc-4.1.0/libssp/ssp.c:70: error: for each function it appears in.) ../../../gcc-4.1.0/libssp/ssp.c:73: error: 'ssize_t' undeclared (first use in this function) ../../../gcc-4.1.0/libssp/ssp.c:73: error: expected ';' before 'size' . I'm using fedora 5 as development platform and version of gcc installed on system is 4.1.0 thanks, shahzad
Re: Top-level bootstrap question
If you want exactly what make unstage1 did, "make stage1-start". There is also "make restrap" as in the old scheme. Thanks. A side note: I've always been extremely confused by the "unstageN" and "stageN" targets in the gcc directory. The double usage of "stage" as noun and verb was complicating things, also because I'm not a native speaker and the meaning of "to stage" as "to set aside" is not in my dictionary. Interesting. In all the years I've been using those targets, I never even thought about the verb meaning of "stage". I wonder if the folks who named those targets ever did.
Re: try/finally in GNU C
"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.
| >
|
| We had an example just like this on IRC only a few weeks ago. ISTR it
| was decided that this triggers undefined behavior by C99 7.13.2.1 sub
| 3.
For the bootstrapping problem I mentioned earlier, they added volatile
to variables in the scope but it did not change anything. [ They
tried that despite the uncertainty of "volatile" semantics in GCC/gcc
in the past, and despite they could not afford to do it in general ]
-- Gaby
Re: try/finally in GNU C
> 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 a possible implementation of __try and __finally (and friends) as implemented by Visual Studio on win32? Having those keywords implemented on the win32 port of GCC (and working exactly like/being compatible with Visual Studio) would be nice :) (no, I am not offering to write the patch :) If anyone knows of any reason why implementing MS compatible exception handling in GCC on win32 would not be possible, that would be great to know :)
RE: What assertions to use in libcpp?
On 16 June 2006 09:38, Laurynas Biveinis wrote: > Hi, > > I'm somewhat stuck with debugging GCC+Boehm's GC bootstrap failure. At > one point cpplib starts producing cpp_string objects with len = 0. > They crash cpp_interpret_string. I'd like to add some assertions to > the code to catch zero-length cpp_strings as early as possible, but I > don't see any assertions in libcpp - neither assert nor gcc_assert. > What could I use there? Define a macro, call it libcpp_assert, then it doesn't matter if you equate it to assert or gcc_assert; you're working on a branch, you can worry about how to properly define it when you merge back to mainline and in the meantime you can make it work however you like to be getting on with. cheers, DaveK -- Can't think of a witty .sigline today
RE: c99 VLA semantics
On 16 June 2006 02:02, Mike Stump wrote:
> Here are just a few more issues I was wondering about for VLAs:
>
> static int i;
> static int new_i() { i++; return i; }
> static int bar(int a[new_i()][new_i()]);
If that isn't a sequence point violation, it probably ought to be, shouldn't
it?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Generator programs can only be built with optimization enabled?
> Eric Botcazou writes: >> I actually like the existing behaviour, which I'm pretty sure hasn't >> changed for many years. Eric> It has, at least for "make quickstrap". Yes, exactly. Prior to the top-level bootstrap changes, I explicitly would need to use "make CFLAGS=-g" to recompile a particular object file without optimization to enhance debugging. David
Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes: Dan> It can also tell you who to copy on a ping email to make sure it Dan> actually goes to a maintainer. Dan> the interface is under construction, but "okay" for casual use. Dan> http://www.dberlin.org/patches/patches/maintainer_list/745 would be the Dan> one for this patch. This one is funny because many of the maintainers on that list are very inactive. I think we ought to retire inactive maintainers, by moving them to a "Maintainer Emeritus" section -- they wouldn't lose any rights, but at the same time we wouldn't be giving patch submitters false hope that there is a large number of maintainers available. Dan> I could try generating the ping mails for single patches automatically, Dan> and try to randomly disperse them so that you can't just ignore some Dan> email bomb of ping emails, but this seems like it should be unnecessary. This would help me, except that java folks don't seem to use the patch queue. For Classpath we're much more aggressive about giving people patch approval status. Of course, our situation is a bit different, since Classpath is more modular than GCC. A look through the write-after-approval list to see if anybody there really could be "promoted" would help... if nobody there stands out, then our problem is just lack of developers, which requires a different sort of solution. Tom
Re: gcc-4.1.0 cross-compile for MIPS
kernel coder wrote: hi, I'm trying to cross compile gcc-4.1.0 for mipsel platform.Following is the sequence of commands which i'm using ../gcc-4.1.0/configure --target=mipsel --without-headres --prefix=/home/shahzad/install/ --with-newlib --enable-languages=c Perhaps you should try to disable libssp. Try adding (untested) --disable-libmudflap --disable-libssp David Daney.
RE: gcc-4.1.0 cross-compile for MIPS
On 16 June 2006 16:47, David Daney wrote: > kernel coder wrote: >> hi, >>I'm trying to cross compile gcc-4.1.0 for mipsel >> platform.Following is the sequence of commands which i'm using >> >> ../gcc-4.1.0/configure --target=mipsel --without-headres >> --prefix=/home/shahzad/install/ --with-newlib --enable-languages=c >> > > Perhaps you should try to disable libssp. Try adding (untested) > --disable-libmudflap --disable-libssp > You should also probably use --without-headers, instead of the typo'd --without-headres. cheers, DaveK -- Can't think of a witty .sigline today
MIPS RDHWR instruction reordering
The RDHWR instruction is used to support TLS on Linux/MIPS. For now
it is always emulated by kernel (on Reserved Instruction exception
handler), the instruction will be quite expensive.
If I compile this code with gcc 4.1.1 (-O2),
extern __thread int x;
int foo(int arg)
{
if (arg)
return x;
return 0;
}
I got this output.
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.cpload $25
.setnomacro
lw $2,%gottprel(x)($28)
.setpush
.setmips32r2
rdhwr $3,$29
.setpop
addu$2,$2,$3
beq $4,$0,$L4
move$3,$0
lw $3,0($2)
$L4:
j $31
move$2,$3
The RDHWR is executed _before_ evaluating the "arg" value. For arg ==
0 case, the RDHWR has no point but just a overhead. Without -O2, the
RDHWR is executed _after_ the evaluation, so gcc's optimizer reorder
the RDHWR instruction.
I want to make the RDHWR called only if really required. Is it
possible to prevent such a reording for RDHWR ?
This is very common case in libc. On returning from system call, libc
checks the result and write to the "errno" which is thread-local. On
successful syscall, we do not need to access "errno" at all, but gcc
sometimes put RDHWR _before_ checking the result of the syscall. This
add an additional exception for the syscall for usual case.
I do not know much about gcc's internal. Any help are welcome. Thank
you.
---
Atsushi Nemoto
Re: c99 VLA semantics
On Thu, 15 Jun 2006, Mike Stump wrote:
> Here are just a few more issues I was wondering about for VLAs:
>
> static int i;
> static int new_i() { i++; return i; }
> static int bar(int a[new_i()][new_i()]);
Same as static int bar(int a[*][*]);. (In a definition, the two calls to
new_i() happen in an unspecified order, but do not overlap and there is a
sequence point between them, namely that at the end of the first call of
new_i(). Both calls happen even though one array dimension disappears in
the array-to-pointer parameter adjustment; GCC correctly handles
side-effects in array dimensions lost by this adjustment and there's at
least one old test in the testsuite to that effect.)
> void foo(int n) {
> /* Presently an error, but, should it be (due to bar having a VM type and bar
> having other than no linkage)? */
> extern int bar(int a[new_i()][new_i()]);
> /* Same question. */
> extern void foo2(int i[n][n]);
I don't think it can be intended that functions with VM arguments
themselves have VM type (otherwise you'd have problems declaring them at
all since they don't have no linkage and may have file scope). But the
definition in terms of contained declarators hardly makes things clear. I
would say, however, that while VM-ness shouldn't propagate out from
function argument types to the type of the function, it should so
propagate from the function return type to the type of the function.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: c99 VLA semantics
Ok, good, you gave the same answers I was hoping for. :-) On Jun 16, 2006, at 10:51 AM, Joseph S. Myers wrote: But the definition in terms of contained declarators hardly makes things clear. I would say, however, that while VM-ness shouldn't propagate out from function argument types to the type of the function, it should so propagate from the function return type to the type of the function. :-) I agree, though, the standard should contain wording to directly support this, long term. I do think it is what they meant, even if they might not have known it. This would be my request for a DR on the issue... Thanks.
Re: c99 VLA semantics
On Jun 16, 2006, at 6:57 AM, Dave Korn wrote: static int bar(int a[new_i()][new_i()]); If that isn't a sequence point violation, it probably ought to be, shouldn't it? No, the text has no meaning (in this case (non (const int))), read it as `'*' and you'll have a better mental model for C I think.
Re: try/finally in GNU C
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 other bugs in volatile oh course. Certainly recently (4.0.1), we've seen bugs in volatile, but in top of tree, the offenders I knew about had all been fixed.
Re: try/finally in GNU C
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 where for the purpose of implementing EH, and as such, can't mandate users mark variable as volatile just to work. Further, temporary values in play by the optimizer are `harder' to mark volatile.
Coroutines
I'm pretty sure this is stepping into deep quicksand, but I'll ask anyway...I'm interested in writing an FE for a language that has stackable coroutines (Lua-style, where you can yield and resume arbitrarily far down the call stack). I'm trying to wrap my head around what would be involve and how awful it would be. There are a few "coroutines in C" packages packages laying around, but they don't seem to be stackable (I'm sure the ones based on Duff's device aren't). Since you can't switch call stacks from C I think what I want is impossible at that level. So I'd appreciate any comments or info on the following possibilities, or any others I didn't think of: 1. Build with pthreads. This has to be doable and even straightforward, but it seems like full threading machinery is very heavyweight for this. Most coroutines are conceptually a strictly user-space control structure and would be much faster implemented that way. Also, that would make the FE depend on pthreads, which I bet is undesirable. 2. Build with a purely user-space threads package. This ought to eliminate a bunch of locking and context switching overhead, so it seems like a plausible idea. But it may still be too general and in any case it has the disadvantage of importing the package into GCC itself when I get to building the FE. 3. Non-portable library. Perhaps yield() and friends can be made to work with a bit of in-line assembly to set and restore the stack pointer and registers to/from a chunk of heap (obtained with malloc or mmap I guess, if you can get the right access bits). This seems plausible, but it has the disadvantage of requiring an implementation for every architecture. Nasty for a GCC FE if avoidable, unless it made it into glibc (seems unlikely). (For a few seconds it seems like longjmp() hackery would be sufficient, but you oughtn't think about jumping back down the stack with longjmp() and you still haven't answered the question of how you're going to allow the caller to call other functions and coroutines in between resume() calls.) 4. GCC extension. Perhaps there is a way to do this in RTL, I just don't know nearly enough to say. If so, then the non-portable code is confined to things that already have to be maintained. It also would allow fully stackable C coroutines as a GCC extension, though I don't know if anyone but me would care about such a thing. Perhaps the absence of such an extension is a subtle hint of how deep that quicksand is. :-) OTOH if it is possible I'd consider trying to write it, if my GCC-fu ever reaches the requisite level (my rank is somewhere below "pale piece of pigs ear" right now). Any enlightenment is most welcome, even if only to tell me what a stupid idea it is. :-) Dustin pgp1SC2KnaMUl.pgp Description: PGP signature
Re: Coroutines
On Jun 16, 2006, at 1:41 PM, Dustin Laurence wrote: I'm pretty sure this is stepping into deep quicksand No, just hard work. It is only quicksand, if you start, but never finish. The mechanism I might favor would be to handle all the fun inside the language front end. Objective-C does this for example for method calls and just passes the backend a normal C call with certain data, that calls into a run time library to do the heavy lifting. This way, you preserve the notion of the backend and all its semantics, this saves you from having to fight against them, but it does have limitations (no full and complete interoperability with C). You can just add a language runtime library (well established idea) to handle the harder bits. The runtime library can be as complex as C ++'s or Ada's without any sense of violation of the model gcc uses. If every language were going to have the feature, then, moving it down into the mid-end or back-end might make sense, but I don't think it does in this case. I wouldn't start with pthreads I don't think.
Re: MIPS RDHWR instruction reordering
Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> If I compile this code with gcc 4.1.1 (-O2),
>
> extern __thread int x;
> int foo(int arg)
> {
> if (arg)
> return x;
> return 0;
> }
>
> I got this output.
>
> foo:
> .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
> .mask 0x,0
> .fmask 0x,0
> .setnoreorder
> .cpload $25
> .setnomacro
>
> lw $2,%gottprel(x)($28)
> .setpush
> .setmips32r2
> rdhwr $3,$29
> .setpop
> addu$2,$2,$3
> beq $4,$0,$L4
> move$3,$0
>
> lw $3,0($2)
> $L4:
> j $31
> move$2,$3
>
> The RDHWR is executed _before_ evaluating the "arg" value. For arg ==
> 0 case, the RDHWR has no point but just a overhead. Without -O2, the
> RDHWR is executed _after_ the evaluation, so gcc's optimizer reorder
> the RDHWR instruction.
The computation of the address of x was moved outside the
conditional--that is, both the rdhwr and the addu moved. You'll have
to figure out why. gcc shouldn't move instructions outside of a
conditional unless they are cheap and don't trap. This instruction
doesn't trap, but it's not cheap.
Ian
Re: Coroutines
On 6/16/06, Dustin Laurence <[EMAIL PROTECTED]> wrote: I'm pretty sure this is stepping into deep quicksand, but I'll ask anyway...I'm interested in writing an FE for a language that has stackable coroutines (Lua-style, where you can yield and resume arbitrarily far down the call stack). I'm trying to wrap my head around what would be involve and how awful it would be. ... is. :-) OTOH if it is possible I'd consider trying to write it, if my GCC-fu ever reaches the requisite level (my rank is somewhere below "pale piece of pigs ear" right now). Wow. How many is that in kyu? As the quicksand closes in above our heads I'll try to answer: I don't have any GCC credibility either but I once got an approving off-list reply from Damian Conway while discussing coroutines in the context of Perl 6 features -- which had me reading the university library's dusty copy of Knuth's Art of Computer Programming -- so I have done a little homework in this problem domain, although my ideas about GCC internals are rough and possibly naive and/or incorrect. That said, my thoughts on the question of how to implement coroutines using the GCC system are that it would best be done by abandoning the idea of using the "native" stack for your program's "logical" stack. Your target language has some concept of multiple stacks, and recursion, so you will have to implement these stacks some how, unlike TAOCP's coroutines that manipulated global variables in a stackless environment. Why not implement your stacks as linked lists of dynamically allocated stack frame objects, and coerce your language into primitives that operate on those objects instead of trying to force things to be C-like? This apprach might not make sense -- I am sure if I search the archives I will find out why, for instance, GNU Lisp is a separate project from GCC instead of merging. GCC might not be the best back end for your project. At some point someone asked the perl 6 people why they were designing Parrot when the scheme48 internals were available -- here is scheme48's documentation on threading http://s48.org/1.3/manual/manual-Z-H-8.html#node_chap_6 and the answer was "because nobody knew about it" So the other thought, or the rest of the thought, is, why try to force your language into GCC when it might be easier to force it into something else? -- David L Nicol "you couldn't bullshit [Bill Gates] for a minute because he was a programmer. A real, actual, programmer." -- Joel Spolsky
gcc-4.1-20060616 is now available
Snapshot gcc-4.1-20060616 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060616/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 114729 You'll find: gcc-4.1-20060616.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060616.tar.bz2 C front end and core compiler gcc-ada-4.1-20060616.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060616.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060616.tar.bz2 C++ front end and runtime gcc-java-4.1-20060616.tar.bz2 Java front end and runtime gcc-objc-4.1-20060616.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060616.tar.bz2The GCC testsuite Diffs from 4.1-20060609 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Coroutines
Dustin Laurence <[EMAIL PROTECTED]> writes: > I'm pretty sure this is stepping into deep quicksand, but I'll ask > anyway...I'm interested in writing an FE for a language that has > stackable coroutines (Lua-style, where you can yield and resume > arbitrarily far down the call stack). I'm trying to wrap my head around > what would be involve and how awful it would be. > > There are a few "coroutines in C" packages packages laying around, but > they don't seem to be stackable (I'm sure the ones based on Duff's > device aren't). Since you can't switch call stacks from C I think what > I want is impossible at that level. You might want to look at the SUS functions getcontext/setcontext/makecontext/swapcontext. They allow you to switch call stacks in C, although maybe not quite in the way you were hoping. However, they're obsolescent; SUS suggests using threads instead.
Usage of -ftrapv
Hi all,
I'd like to catch automatically over/underflows on floating point and
integer arithmetic. I thought -ftrapv would do the trick but I don't
really understand how it works. From the latest manual online:
-ftrapv
This option generates traps for signed overflow on addition,
subtraction, multiplication operations.
I don't understand what's _a trap_. Does it send a signal or something
I can catch?
My idea in C++ is to catch whatever this sends and through a custom
exception. A little after in the manual I have:
-fnon-call-exceptions
Generate code that allows trapping instructions to throw
exceptions. Note that this requires platform-specific runtime support
that does not exist everywhere. Moreover, it only allows trapping
instructions to throw exceptions, i.e. memory references or floating
point instructions. It does not allow exceptions to be thrown from
arbitrary signal handlers such as SIGALRM.
Does it mean that if I use this, exceptions are thrown when I have an
over/underflow? Could someone please explain me what happens inside
g++?
Another issue is if you think this is better than implementing a new
number type (consider it well implemented) which overloads all
arithmetic operators and throws exceptions when needed.
for example,
#include
#include
int main() {
unsigned int maxi = std::numeric_limits::max();
maxi++;
std::cerr << "Value of maxi after sum: " << maxi << std::endl;
return 0;
}
after compiled with or with -ftrapv g++ generates binary executables
which are exactly the same:
[EMAIL PROTECTED] ~ $ g++ -o ftrapvw ftrapv.cc
[EMAIL PROTECTED] ~ $ g++ -ftrapv -o ftrapv ftrapv.cc
[EMAIL PROTECTED] ~ $ md5sum ftrapv
fa2b15c2dccf7d721ae883cea1e5190e ftrapv
[EMAIL PROTECTED] ~ $ md5sum ftrapvw
fa2b15c2dccf7d721ae883cea1e5190e ftrapvw
Thanks in advance for your comments,
--
Paulo Jorge Matos - pocm at sat inesc-id pt
Web: http://sat.inesc-id.pt/~pocm
Computer and Software Engineering
INESC-ID - SAT Group
GCC 4.2 Status Report (2006-06-16)
[Jakub, see below for question.] There are presently 200 P3 or higher regressions open against 4.2. We remain in regression-only mode on the mainline. I have half a mind to see if I can bribe AJH to lock everyone in the conference hall until they have fixed at least 1 PR. :-) I'm not sure the number above is in and of itself terribly meaningful, in part because Volker has been filing many ICE-on-invalid-after-error-message PRs against the C++ front end. These don't really even show up for users in releases, due to the "confused by earlier errors" trick, so, although I've been marking these as P2, that might actually be an overly high priority. It offends my sensibilities that we crash in these cases, but it's hard to argue there's a lot of impact on users. What I do consider meaningful is that there are 37 P1s. Several of these (25938, 26175, 26477, 27890, 27984) are low-hanging fruit regarding to installation. Jakub, I thought that you and I worked out a plan for the libgomp configuration issues; did that patch get checked in? Can any of these PRs be closed? Would folks please tackles some of the other P1s? There are a number of 4.2-only regressions involving wrong-code and ICEs on valid code. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Usage of -ftrapv
On Jun 16, 2006, at 5:43 PM, Paulo J. Matos wrote:
int main() {
unsigned int maxi = std::numeric_limits::max();
maxi++;
This is well defined as unsigned overflow is defined as wrapping.
-- Pinski
Re: Coroutines
On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote: > On Jun 16, 2006, at 1:41 PM, Dustin Laurence wrote: > >I'm pretty sure this is stepping into deep quicksand > > No, just hard work. It is only quicksand, if you start, but never > finish. It's quicksand if it turns out to vastly exceed the time allotted. Especially if the estimated time to completion not only increases as time goes on but diverges. :-) > The mechanism I might favor would be to handle all the fun inside the > language front end > this saves you from having to fight against them, but it does have > limitations (no full and complete interoperability with C). Interoperability is good, but you have a point. > If every language were going to have the feature, then, moving it > down into the mid-end or back-end might make sense, but I don't think > it does in this case. Personally, I'd like, and use, decent coroutines in C. But perhaps I am the only one. > I wouldn't start with pthreads I don't think. That was my thought--I played with it some but I intended it as a bit of threads practice. Using threads to emulate a synchronous construct just seems *wrong.* Dustin pgpWS1UE2GMgg.pgp Description: PGP signature
Re: Coroutines
On Fri, Jun 16, 2006 at 05:34:41PM -0500, David Nicol wrote: > On 6/16/06, Dustin Laurence <[EMAIL PROTECTED]> wrote: > >... > >is. :-) OTOH if it is possible I'd consider trying to write it, if my > >GCC-fu ever reaches the requisite level (my rank is somewhere below > >"pale piece of pigs ear" right now). > > Wow. How many is that in kyu? Hmm. Somewhere between eight thousand and the continuum. It's hard to remember after all the beatings. Still, I hope with enough work I can get promoted to "beef-smelling big-nosed barbarian" rank and lord it over the peons. :-) > I don't have any GCC credibility either but I once got an approving off-list > reply from Damian Conway while discussing coroutines in the context of > Perl 6 features -- which had me reading the university library's dusty > copy of Knuth's Art of Computer Programming IIRC the problem with Knuth's discussion is it's a bit opaque (quelle surprise). Also I think his are symmetric, and I'm afraid I've drunk the kool-aid in terms of asymmetric ones being simpler and clearer. However, they should require equivalent magic. > That said, my thoughts on the question of how to implement coroutines > using the GCC system are that it would best be done by abandoning the > idea of using the "native" stack for your program's "logical" stack. > ... > Why not implement your stacks as linked lists of dynamically allocated > stack frame objects, and coerce your language into primitives that > operate on those objects instead of trying to force things to be C-like? Hmm. Very good point. The biggest problem is probably the lack of interoperability with C. I think Lua may do exactly this, come to think of it, since I think it doesn't allow yields when there is a C function on the call sequence. > GCC might not be the best back end for your project. True. You can't beat it's market share, though. :-) > So the other thought, or the rest of the thought, is, why try to force > your language into GCC when it might be easier to force it into something > else? Well, aside from a possibly irrational fondness for GCC, I guess I didn't find something that was clearly better. Dustin pgpE8Y3O3Yga7.pgp Description: PGP signature
Re: Usage of -ftrapv
On Jun 16, 2006, at 5:43 PM, Paulo J. Matos wrote: I'd like to catch automatically over/underflows on floating point Wrong list. You want gcc-help... Does it mean that if I use this, exceptions are thrown when I have an over/underflow? No, it it meant that, the documentation would say that the flag causes exceptions to be thrown. There is no such option. You can write your own code to throw exceptions, but I think you'd want to study FP on modern processors and just when exactly it is known that something is exceptional. Hint, it happens really late, and you have to add machine instructions to get them to be not deferred, but, if you do that, you throw performance out the window. You'll have to refer to your OS documentation on just how exactly to do this, it you can at all. man signal is the usual entry into this world.
