Re: Split Stacks proposal
comments below, On Thu, 2009-02-26 at 14:05 -0800, Ian Lance Taylor wrote: > I've put a project proposal for split stacks on the wiki at > http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack > of a single thread to be split into discontiguous segments, thus > permitting many more threads to be active at one time without worrying > about stack overflow or about wasting lots of stack space for inactive > threads. The compiler would have to generate code to support detecting > when new stack space is needed, and to deal with some of the > consequences of moving to a new stack. It would be totally awesome to do this if you could provide an option to delegate to a user-provided function the allocation and deallocation of the stack blobs needed by threads. i.e., the problem I run into is that I create a lot of user-space threads and I need to allocate at the very least 2 pages (1 normal page, 1 guard page) for each thread: - 2 pages of address space is a lot if you have a lot of threads: it's easy to run out of address space (physical memory is less of a concern for me) - 2 pages is not enough for a lot of threads and if one of my threads hits the 2-page limit, I have to stop my program and restart it with a bigger stack space for the offending thread which can be quickly "annoying". So, ideally, I would be able to not allocate statically any address space for my threads and defer stack space allocation only when needed. Ideally, I would even be able to use heap memory for that stack space if I wanted to. Another use-case I could foresee for this would be to be able to profile the runtime stack-usage of an application/set of threads to optimize it. > I would be interested in hearing comments about this. > > I'm not currently working on this, but I may start working on it at some > point. I looked a bit at the page you pointed. A couple of questions: - if you want to use the stack protector and split stacks, it should be fairly trivial to extend the data structure which contains the stack protector with a new field, no ? - what would be a typical size for the stack space slop ? (for example, on i386 ?) - I understand that you need to copy the function parameters from the old stack to the new stack, but, why would you need to invoke the C++ copy or move constructors for this ? Would a memcpy not be sufficient to ensure proper C++ semantics in this case ? An example which shows how a memcpy would break might be interesting. Mathieu
Re: load large immediate
2009/2/27 Joern Rennecke : > Quoting daniel tian : > >> 2009/2/26 Joern Rennecke : the address label "common_reg " used many times. I think it will load one time. But after optimized with '-Os' or '-O2', it still loads the label "common_reg " six times.. >>> >>> Previously, you could define LEGITIMIZE_ADDRESS and >>> LEGITIMIZE_RELOAD_ADDRESS >>> to get reasonable code. However, that no longer works in gcc 4.4, see >>> PR38785. >>> >>> I have a patch set; if you like, I can it to you. Note, however, that it >>> is >>> not known if the FSF have a relevant valid Copyright assignment on file. >>> >> >> I port the gcc with 4.0.2 version. But How to add the code in >> LEGITIMIZE_RELOAD_ADDRESS. Do you have any example? Thank you very >> much. > > Yes, there are a number of examples in config/*/*.h - just doing a > grep should give you a goo selection. The port where this macro > has been added first, in order to avoid unnecessary repetition of > stack slot address additions, was the SH port. > The SFmode part is a later addition, which is different because the > SH3E (and the later 32 bit SH family members with hardware floating > point) don't have REG+offset addressing for floating point registers, > but they have REG+index addressing. > The basic operation of the macro is explained in doc/tm.texi . > In order to handle pseudos that are equivalent to a constant, > you need to allow registers that are not suitable as a base > for REG_OK_STRICT_P (because pseudos aren't), which have > reg_equiv_constant set. > You'll have to take the value in reg_equiv_constant and > do necessary arithmetic with plus_constant in order to compute > the value to be used in push_reload. > Thank you for your reply. I read some documents. That seems to solving a address mode problem. My problem is that while loading a large immediate data or SYMBOL_REF, the destination is a specified general register (register 0:R0). So I don't how to let the define_expand "movsi" pattern to generate destination register in R0. I read some document about "reload" which was a issue that I missed in former working. Does this problem obstruct the problem ? Your guys give me some greate advices. I will keep working. Thank you very much again.
Re: Please block henry2000 from the wiki
Please go ahead. I do not have much time for gcc lately but I will be more than happy to clean up whatever spam I find in the wiki or ban spammers. Cheers, Manuel. 2009/2/26 Daniel Berlin : > If you want to help admin the wiki, I am more than happy to make you a > super user. > That goes for Steven, etc. > > > > On Thu, Feb 26, 2009 at 12:31 PM, Manuel López-Ibáñez > wrote: >> 2009/2/25 Gerald Pfeifer : >>> On Tue, 24 Feb 2009, Steven Bosscher wrote: Can someone *please* ban this nutcase from the wiki? There is almost weekly spam added to the wiki from this account. Thanks, >>> >>> Let me forward this to the overseers team... >>> >> >> A solution for only this particular case is not useful. We have a lot >> of trusted users that use and take care of the wiki but they do not >> have privileges to mark content as spam or ban spammers. I think this >> is unfortunate because putting the burden of this solely on the admin >> of the wiki is frustrating for everybody. >> >> If it is technically possible, there should be a list of trusted users >> that are allowed to handle spam. >> >> Cheers, >> >> Manuel. >> >
Re: Split Stacks proposal
Ian Lance Taylor wrote: > Joel Sherrill writes: > >> Ian Lance Taylor wrote: >>> I've put a project proposal for split stacks on the wiki at >>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack >>> of a single thread to be split into discontiguous segments, thus >>> permitting many more threads to be active at one time without worrying >>> about stack overflow or about wasting lots of stack space for inactive >>> threads. The compiler would have to generate code to support detecting >>> when new stack space is needed, and to deal with some of the >>> consequences of moving to a new stack. >>> >>> I would be interested in hearing comments about this. >>> >>> I'm not currently working on this, but I may start working on it at some >>> point. >>> >> How would this work on an embedded system which normally >> has fixed task stacks? >> >> How would you know if a single task had consumed too much >> of its stack space? > > I wasn't really envisioning using it in that way, but, yes, it could do > that. The general goal is for use on systems where there is a lot of > available memory, but there isn't enough memory to support peak stack > usage for all threads. I've seen a technique work beautifully on ARM which kept a full chain of stack frames. Returning from a call was just LDMEA fp, {fp,sp,pc} which works regardless of whether the frames are are contiguous or not. So, there was little wastage of memory for stacks and not much overhead. Andrew.
Re: New no-undefined-overflow branch
On Fri, 27 Feb 2009, Zdenek Dvorak wrote: > Hi, > > in general, I like this proposal a lot. However, > > > As a start there will be no-overflow variants of NEGATE_EXPR, > > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR. > > > > The sizetypes will simply be operated on in no-overflow variants > > by default (by size_binop and friends). > > > > Naming suggestions welcome, at the moment I consider NEGATEV_EXPR > > (thus appending V to the first part). First, for the bikeshedding part I agree that NV is probably a better idea. > introducing new codes seems like a bad idea to me. There are many > places that do not care about the distinction between PLUS_EXPR and > PLUSV_EXPR, and handling both cases will complicate the code (see eg. > the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR > distinction). Why not just use a flag to mark the operation as > non-overflowing? I obviously thought about this. The issue with using a flag is that there is no convenient place to stick it and that it makes the distinction between the two variants less visible. Consider the folding routines that take split trees for a start. IMHO using new tree-codes is much less complicated than carrying around flags. I did consider putting flags on the tree code itself, but that isn't going to make the changes easier either. Richard.
RE: Constant folding and Constant propagation
> - If I patch in this code, actually I get the same results I did > before where the constants are propagated. It seems that in 4.3.2, > every part of the compiler is trying to do that. There are at least two forward propagation passes, one before and another after GCSE. I haven't tried to tackle those passes, but I believe they already have a cost model in place. This patch will prevent partial sums involving registers and constants from being combined during GCSE. > - Just for testing I turned off the GCSE pass and it still > propagated and folded the constants... GCSE won't help with your trimmed down example int main(void) { long a = 0xcafecafe; printf("Final: %lx %lx %lx\n", a, a+5, a+15); return EXIT_SUCCESS; } I believe Paolo's canon_reg solution together with tweaking rtx_cost of constants with outer code PLUS might help. Any luck with that pass?
Re: load large immediate
daniel tian wrote: > That seems to solving a address mode problem. My problem is that while > loading a large immediate data or SYMBOL_REF, the destination is a > specified general register (register 0:R0). So I don't how to let the > define_expand "movsi" pattern to generate destination register in R0. Well, the RTL that you emit in your define_expand has to match an insn pattern in the end, so you could make an insn for it that uses a predicate and matching constraint to enforce only accepting r0. If you use a predicate that only accepts r0 you'll get better codegen than if you use a predicate that accepts general regs and use an r0-only constraint to instruct reload to place the operand in r0. cheers, DaveK
Re: Split Stacks proposal
Mathieu Lacage wrote: > It would be totally awesome to do this if you could provide an option to > delegate to a user-provided function the allocation and deallocation of > the stack blobs needed by threads. > Ideally, I would even be able to use heap memory for that stack space if > I wanted to. I believe that's at least _implicit_ in the description of the project already! Once the stack can be discontiguous, all of a sudden there's nothing special about the memory area that the OS allocated to be your thread's stack any more. cheers, DaveK
Re: New no-undefined-overflow branch
Richard Guenther wrote: > On Fri, 27 Feb 2009, Zdenek Dvorak wrote: >> introducing new codes seems like a bad idea to me. There are many >> places that do not care about the distinction between PLUS_EXPR and >> PLUSV_EXPR, and handling both cases will complicate the code (see eg. >> the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR >> distinction). Why not just use a flag to mark the operation as >> non-overflowing? > > I obviously thought about this. The issue with using a flag is > that there is no convenient place to stick it and that it makes > the distinction between the two variants less visible. Consider > the folding routines that take split trees for a start. > > IMHO using new tree-codes is much less complicated than carrying > around flags. I did consider putting flags on the tree code > itself, but that isn't going to make the changes easier either. I think it's probably a far safer design too. If you suddenly introduce a new semantic for an existing code, suddenly every current check for that tree code becomes a potential bug site that has to be manually inspected to see if it's overflow-sensitive or not and therefore whether it needs to test the new flag or not; people who don't know about the new flag will carry on adding code that processes those tree codes without knowing to test the flag; and the bugs that do arise will be hard to find and result in silent bad codegen. If OTOH you add new tree codes, the meaning will be explicit, nobody using them can be under any misapprehension about the overflow semantics, nobody can forget to check the flag, and any places where they should be handled but aren't will very quickly draw themselves to our attention by ICEing, or if they don't will simply fall back to the safe option of not doing any processing on a tree code that they don't recognize; that might lead to pessimal code, but it shouldn't generate incorrect code. cheers, DaveK
Re: New no-undefined-overflow branch
On Fri, 27 Feb 2009, Dave Korn wrote: > Richard Guenther wrote: > > On Fri, 27 Feb 2009, Zdenek Dvorak wrote: > > >> introducing new codes seems like a bad idea to me. There are many > >> places that do not care about the distinction between PLUS_EXPR and > >> PLUSV_EXPR, and handling both cases will complicate the code (see eg. > >> the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR > >> distinction). Why not just use a flag to mark the operation as > >> non-overflowing? > > > > I obviously thought about this. The issue with using a flag is > > that there is no convenient place to stick it and that it makes > > the distinction between the two variants less visible. Consider > > the folding routines that take split trees for a start. > > > > IMHO using new tree-codes is much less complicated than carrying > > around flags. I did consider putting flags on the tree code > > itself, but that isn't going to make the changes easier either. > > I think it's probably a far safer design too. > > If you suddenly introduce a new semantic for an existing code, suddenly > every current check for that tree code becomes a potential bug site that has > to be manually inspected to see if it's overflow-sensitive or not and > therefore whether it needs to test the new flag or not; people who don't know > about the new flag will carry on adding code that processes those tree codes > without knowing to test the flag; and the bugs that do arise will be hard to > find and result in silent bad codegen. > > If OTOH you add new tree codes, the meaning will be explicit, nobody using > them can be under any misapprehension about the overflow semantics, nobody can > forget to check the flag, and any places where they should be handled but > aren't will very quickly draw themselves to our attention by ICEing, or if > they don't will simply fall back to the safe option of not doing any > processing on a tree code that they don't recognize; that might lead to > pessimal code, but it shouldn't generate incorrect code. It's definitely safer. Still we have to carefully modify existing code to deal with the new tree codes as most of it carelessly transitiones old codes to new trees. For example re-associating (a +/nv b) + c to a +/nv (b + c) is wrong. Richard.
GNAT vs DW2/ZCX EH.
Hello all, and ADA hackers in particular :-) I've been having a hard time bootstrapping GNAT 4.3.2 lately, and now I think I've found the problem. Or /a/ problem, but I'm not sure exactly why it's a problem in the first place. Let me explain: As mentioned in an earlier thread, you can't bootstrap GCC > 4.X (where x is probably '1') with GCC-3.anything; the build process these days makes use of new gnat (?gnatmake?) command-line options that the old compiler doesn't understand. Fair enough, no problem. However the main issues I've been having trouble with show up when I try and run the testsuite. The first problem I ran into was total failure to throw and catch exceptions in ADA, failing with a SEGV every time. It wasn't enough to just set EH_MECHANISM=-gcc in the target-specific section of gcc/ada/Makefile.in; I found that lots of the ada runtime had been compiled without EH frame data, so the unwinder couldn't throw through them and just blew up at runtime. So I added "T_ADA_CFLAGS=-fexceptions" to the target clause in Makefile.in as well, but that seems wrong to me: surely the build system ought to do that already? I found a couple of lines in one of the source files that appear to set the global variables corresponding to -fexceptions (and -fnon-call-exceptions), but I'm not sure if they should be coming into play here. I also tried manually setting ZCX_By_Default to true in the system-$target.ads, and even then I was getting similar crashes to the above, because some of the library .o files still contained no DW2 eh_frame tables, which blows up at runtime when you throw. Next problem I ran into was this: === acats support === Generating support files...error: "macrosub.adb" must be recompiled ("system.ads" has been modified) error: "defs.ads" must be recompiled ("system.ads" has been modified) error: "getsubs.adb" must be recompiled ("system.ads" has been modified) error: "parsemac.adb" must be recompiled ("system.ads" has been modified) error: "s-stalib.adb" and "macrosub.adb" compiled with different exception handling mechanisms error: "a-except.adb" and "macrosub.adb" compiled with different exception handling mechanisms [ ... snip many more ... ] I think it might be that this arises because the GNAT I'm using to bootstrap was configured for sjlj EH, and I'm trying to build one configured for ZCX. The test script gcc/testsuite/ada/run_all.sh contains these lines: # These tools are used to preprocess some ACATS sources # they need to be compiled native on the host. host_gnatmake -q -gnatws macrosub.adb if [ $? -ne 0 ]; then display " Failed to compile macrosub" exit 1 fi ./macrosub > macrosub.out 2>&1 gcc -c cd300051.c host_gnatmake -q -gnatws widechr.adb if [ $? -ne 0 ]; then display " Failed to compile widechr" exit 1 fi ./widechr > widechr.out 2>&1 It seems to me as if possibly that doesn't work right when host and target gnat have different EH models. I don't know enough about ada to know if preprocessing is like C and there is some equivalent of a #define that's being expanded differently, but I do know that I had to change that flag in system.adb in order to enable ZCX, and I'm guessing that's what conflicts between the modules compiled with the two compilers. (One of the things that seemed to be going on when I was trying to bootstrap with 3.x is that the build system was using the native and newly-built compilers at different and unexpected times.) However, I am guessing there, and I don't know whether it's actually the preprocessing that causes the conflict, or if that should work fine and there's a problem somewhere else causing it. And the fourth problem I had is that there are a whole load of builds in gcc/ada/Makefile.in that didn't pick up the -fexceptions flag, so they still didn't have eh frame data. That turns out to be because the make rules that build them refer to $(ADA_CFLAGS), which is generated by AC_SUBST at configure time. Most other compilations in the same makefile don't ue ADA_CFLAGS but ALL_ADA_CFLAGS, which contains both ADA_CFLAGS and the cross- and target- specific X_ADA_CFLAGS and T_ADA_CFLAGS, and I found a changelog entry by JDA from back in 2001 which suggests that this was a new scheme that should be used anywhere: 2001-05-02 John David Anglin * ada/Makefile.in (X_ADA_CFLAGS, T_ADA_CFLAGS): New fragment overrides. (ALL_ADA_CFLAGS): Define. Replace ADA_CFLAGS with ALL_ADA_CFLAGS in ALL_ADAFLAGS, MOST_ADAFLAGS, and all compilations using CC. ---
Re: __builtin_return_address for ARM
On Thu, 26 Feb 2009 15:54:14 + Andrew Haley wrote: > Paul Brook wrote: > >> Well, but wouldn't it still be nice if > >> __builtin_return_address(N) was implemented for N>0 by libcalling > >> into the unwinder for you? Obviously this would still have to > >> return NULL at runtime when you're running on a DW2 target without > >> any EH frame data present in memory (and I guess it wouldn't work > >> on SjLj targets either), but wouldn't it still be a nice > >> convenience feature for users? > > > > There are sufficiently many caveats and system specific bits of > > weirdness that you probably just have to know what you're doing (or > > rely on backtrace(3) to do it for you). > > > > IMHO builtins are for things that you can't do in normal C. So > > __builtin_return_address(0) makes a lot of sense. Having it start > > guessing how to do N>0 much less so. > > I suggest we could contribute a version of backtrace.c for ARM to > glibc. An example to follow is libc/sysdeps/ia64/backtrace.c. GLIBC already knows how to do backtracing if the ARM-specific unwind tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace. Unfortunately backtraces don't currently terminate cleanly if code without unwind data is reached: CodeSourcery are currently working on fixing the linker so that non-unwindable regions are marked properly, which we consider essential to making this feature usable. Of course, you'll need to compile all your code with -funwind-tables for this to work. We haven't measured the size impact of this yet: we're planning on optimising the unwind tables by merging duplicate entries whenever possible, so hopefully it won't be too bad. Just a heads-up to avoid duplicate effort! Cheers, Julian
Re: New no-undefined-overflow branch
Richard Guenther wrote: > It's definitely safer. Still we have to carefully modify existing > code to deal with the new tree codes as most of it carelessly > transitiones old codes to new trees. For example re-associating > (a +/nv b) + c to a +/nv (b + c) is wrong. Yes, of course we have to take care when processing the new codes, but the wonderful thing that I was pointing out is that none of the current fold/simplify code will attempt to reassociate the new codes at first, until it's been explicitly taught about them, whereas if we had used a flag it would plough straight ahead under the misapprehension that it understood the semantics of the tree code, that's all. Anyway, your plan gets a big thumbs-up from me. The noobs will be endlessly glad when signed ints start overflowing in the way they'd hoped, and the fortran-wielding-heavy-duty-massive-array-number-crunching-academic types can use a commandline option to make sure they still get their "loop optimiser assumes your index won't overflow so loop must terminate" optimisations, won't they? cheers, DaveK
Re: New no-undefined-overflow branch
On Fri, 27 Feb 2009, Dave Korn wrote: > Richard Guenther wrote: > > > It's definitely safer. Still we have to carefully modify existing > > code to deal with the new tree codes as most of it carelessly > > transitiones old codes to new trees. For example re-associating > > (a +/nv b) + c to a +/nv (b + c) is wrong. > > Yes, of course we have to take care when processing the new codes, but the > wonderful thing that I was pointing out is that none of the current > fold/simplify code will attempt to reassociate the new codes at first, until > it's been explicitly taught about them, whereas if we had used a flag it would > plough straight ahead under the misapprehension that it understood the > semantics of the tree code, that's all. Correct. > Anyway, your plan gets a big thumbs-up from me. The noobs will be endlessly > glad when signed ints start overflowing in the way they'd hoped, and the Heh - this will only happen if the frontend does not indicate there isn't overflow with signed operations. Which of course it will unless you specify -fwrapv. > fortran-wielding-heavy-duty-massive-array-number-crunching-academic types can > use a commandline option to make sure they still get their "loop optimiser > assumes your index won't overflow so loop must terminate" optimisations, won't > they? Yes. -fwrapv also shouldn't be as bad as we can re-instantiate the no-wrapping operation codes during value-range analysis. Richard.
Re: load large immediate
2009/2/27 Dave Korn : > daniel tian wrote: > >> That seems to solving a address mode problem. My problem is that while >> loading a large immediate data or SYMBOL_REF, the destination is a >> specified general register (register 0:R0). So I don't how to let the >> define_expand "movsi" pattern to generate destination register in R0. > > Well, the RTL that you emit in your define_expand has to match an insn > pattern in the end, so you could make an insn for it that uses a predicate and > matching constraint to enforce only accepting r0. If you use a predicate that > only accepts r0 you'll get better codegen than if you use a predicate that > accepts general regs and use an r0-only constraint to instruct reload to place > the operand in r0. Well, I have already done this. There is insn pattern that the predicate limits the operand in R0. But if in define_expand "movsi" do not put the register in R0, the compiler will crashed because of the unrecognized RTL(load big immediate or Symbol). Like the below: (define_insn "load_imm_big" [(set (match_operand:SI 0 "zero_register_operand" "=r") (match_operand:SI 1 "rice_imm32_operand" "i")) (clobber (reg:SI 0))] "TARGET_RICE" { return rice_output_move (operands, SImode); } ) PS:rice_output_move is function to output assemble code. Thanks.
Re: Split Stacks proposal
On Fri, Feb 27, 2009 at 09:10:10AM +0100, Mathieu Lacage wrote: > - if you want to use the stack protector and split stacks, it should > be fairly trivial to extend the data structure which contains the stack > protector with a new field, no ? The stack protector is just a word, not a pointer. It's held in a highly magic location on some platforms, e.g. relative to the thread base register. There's not a lot of space there. It might be possible to reserve more in coordination with glibc, for glibc targets. > - I understand that you need to copy the function parameters from the > old stack to the new stack, but, why would you need to invoke the C++ > copy or move constructors for this ? Would a memcpy not be sufficient to > ensure proper C++ semantics in this case ? An example which shows how a > memcpy would break might be interesting. I haven't written C++ in a while, so forgive any obvious gaffes. class X { int x, *y; X() { y = &x; } X(X &obj) { x = obj.x; y = &x; } } Memcpy that somewhere else and the internal pointer is invalid. -- Daniel Jacobowitz CodeSourcery
Re: __builtin_return_address for ARM
On Fri, 27 Feb 2009 13:32:11 + Julian Brown wrote: > GLIBC already knows how to do backtracing if the ARM-specific unwind > tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace. I'm told this probably isn't true for upstream GLIBC -- but we definitely have a patch somewhere to make GLIBC backtrace use _Unwind_Backtrace, which we'll submit upstream in due course. Sorry for the misinformation! Cheers, Julian
Re: __builtin_return_address for ARM
Julian Brown wrote: > On Thu, 26 Feb 2009 15:54:14 + > Andrew Haley wrote: > >> Paul Brook wrote: Well, but wouldn't it still be nice if __builtin_return_address(N) was implemented for N>0 by libcalling into the unwinder for you? Obviously this would still have to return NULL at runtime when you're running on a DW2 target without any EH frame data present in memory (and I guess it wouldn't work on SjLj targets either), but wouldn't it still be a nice convenience feature for users? >>> There are sufficiently many caveats and system specific bits of >>> weirdness that you probably just have to know what you're doing (or >>> rely on backtrace(3) to do it for you). >>> >>> IMHO builtins are for things that you can't do in normal C. So >>> __builtin_return_address(0) makes a lot of sense. Having it start >>> guessing how to do N>0 much less so. >> I suggest we could contribute a version of backtrace.c for ARM to >> glibc. An example to follow is libc/sysdeps/ia64/backtrace.c. > > GLIBC already knows how to do backtracing if the ARM-specific unwind > tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace. I was about to say "On no it doesn't!" but I read your subsequent email. :-) > Unfortunately backtraces don't currently terminate cleanly if code > without unwind data is reached: CodeSourcery are currently working on > fixing the linker so that non-unwindable regions are marked properly, > which we consider essential to making this feature usable. Yeah, I noticed that when I implemented _Unwind_Backtrace. It didn't matter to me at the time because full unwind info is required for everything linked with gcj. Andrew.
Re: Please block henry2000 from the wiki
On Thu, Feb 26, 2009 at 04:08:03PM -0500, Daniel Berlin wrote: >If you want to help admin the wiki, I am more than happy to make you a >super user. >That goes for Steven, etc. Wait. Are we talking about giving people root access on sourceware just to clean up a wiki? Hopefully this is not the case. cgf
Re: GNAT vs DW2/ZCX EH.
> Hello all, and ADA hackers in particular :-) Ada, not ADA, that's not an acronym but a name, see http://www.adaic.org > However the main issues I've been having trouble with show up when I try > and run the testsuite. > > The first problem I ran into was total failure to throw and catch > exceptions in ADA, failing with a SEGV every time. It wasn't enough to > just set EH_MECHANISM=-gcc in the target-specific section of > gcc/ada/Makefile.in; I found that lots of the ada runtime had been compiled > without EH frame data, so the unwinder couldn't throw through them and just > blew up at runtime. Yes, an annoying merge glitch. The safest approach is probably to revert the EH_MECHANISM change, on the 4.3 branch at least. This change is pre-approved if you get a working Ada compiler with it. > So I added "T_ADA_CFLAGS=-fexceptions" to the target clause in > Makefile.in as well, but that seems wrong to me: surely the build system > ought to do that already? Neither, this is done automatically by the compiler, like in C++. > I also tried manually setting ZCX_By_Default to true in the > system-$target.ads, and even then I was getting similar crashes to the > above, because some of the library .o files still contained no DW2 eh_frame > tables, which blows up at runtime when you throw. Yes, ZCX_By_Default would have needed to be set to true in conjunction with the EH_MECHANISM change, the settings are coupled. > Next problem I ran into was this: > > - >--- === acats support === > Generating support files...error: "macrosub.adb" must be recompiled > ("system.ads" has been modified) > error: "defs.ads" must be recompiled ("system.ads" has been modified) > error: "getsubs.adb" must be recompiled ("system.ads" has been modified) > error: "parsemac.adb" must be recompiled ("system.ads" has been modified) > error: "s-stalib.adb" and "macrosub.adb" compiled with different exception > handling mechanisms > error: "a-except.adb" and "macrosub.adb" compiled with different exception > handling mechanisms >[ ... snip many more ... ] > - >--- > > I think it might be that this arises because the GNAT I'm using to > bootstrap was configured for sjlj EH, and I'm trying to build one > configured for ZCX. Yes, very likely. > 1. Is it supposed to work to bootstrap gnat with a compiler using a > different EH model from the one you're trying to build? Yes, I think so. > 2. Where it uses the host compiler, would it be ok to use the newly-built > target one instead if host==target, i.e. not a cross compiler? Yes, probably. > 3. Should I have needed to add -fexceptions, and if not, why not? No, see above. -- Eric Botcazou
Re: Announce: MPFR 2.4.1 is released
On Thu, 26 Feb 2009, Vincent Lefevre wrote: > After a buffer overflow has been found (and fixed) in the > mpfr_snprintf and mpfr_vsnprintf functions of MPFR 2.4.0, > it has been decided to release MPFR 2.4.1 immediately. > It is available for download from the MPFR web site: > > http://www.mpfr.org/mpfr-2.4.1/ > > Changes from version 2.4.0 to version 2.4.1: > - Security fix in mpfr_snprintf and mpfr_vsnprintf (buffer overflow). Hi Vincent, Thanks for the note. I grep'ed the gcc sources and I don't see any uses of mpfr_snprintf or mpfr_vsnprintf. So I don't believe any change in the minimum mpfr version checks (either "required" version or "recommended" version) is necessary in gcc due to this issue in mpfr. Thanks, --Kaveh
Re: GCC at Google Summer of Code'2009
On Thu, Feb 26, 2009 at 05:57, Grigori Fursin wrote: > I am fine to mentor a few of them (particularly from 1-3) but would like to > see if someone > is interested to help with that ?.. I added these topics to the GCC GSOC page: > http://gcc.gnu.org/wiki/SummerOfCode > and would be happy if you modify it or tell me if you are interested ... I am interested in 1-3. I expect to be spending some more time on the plugins branch in the near future. As Manuel pointed out, it's the student's responsibility for coming up with a project. We do publish those projects that we would be interested in seeing completed. But it's ultimately up to the student. Diego.
Re: query automaton
Dear Vladimir, > Not really. There is no requirement for "the units > part of the alternatives of a reservation must belong to the > same automaton". Querying should also work in this > case because function cpu_unit_reservation_p checks all > automata for an unit reservation. Indeed it checks all automata but Im afraid that according to my pipeline description this check is not enough to guarantee a correct scheduling decision, e.g., suppose the following insn reservation: (define_reservation "move" "( (unit1_aut1, unit1_aut2) | (*) (unit2_aut1, unit2_aut2) ) ,where unitN_autM refers to unit N from automata M. In this case there are 2 automata. Now supose a scheduling state S made of the individual states of the two automatons S=. According to what I see happening in insn-automata.c (and target.dfa), from S_aut1 there is a transition for unit1_aut1 and from S_aut2 there is a transition for unit2_aut2. It seems that the automata do not communicate with each other. As a consequence, A scheduling decision which results in the resource reservation (unit1_aut1, unit2_aut2) would not be rejected, while it should. In my opinion, the current implementation sees the reservation defined in (*) As equivalent to the following one (define_reservation "move" "( (unit1_aut1| unit2_aut1) , (unit1_aut2| unit2_aut2) ) Which does not seem true to me. Is there a way for automatons to communicate so that the alternative (unit1_aut1, unit2_aut2) would be rejected? regards, Alex
Re: __builtin_return_address for ARM
Julian Brown wrote: > Unfortunately backtraces don't currently terminate cleanly if code > without unwind data is reached: CodeSourcery are currently working on > fixing the linker so that non-unwindable regions are marked properly, > which we consider essential to making this feature usable. I don't understand this. Sorry if I'm being slow, but isn't it just a matter of returning instead of calling abort when the search for the parent frame's FDE fails in uw_update_context (or whatever it's called, didn't check)? Marking bits in the linker doesn't enable you to unwind past them somehow, does it? cheers, DaveK
Re: __builtin_return_address for ARM
Dave Korn wrote: > Julian Brown wrote: > >> Unfortunately backtraces don't currently terminate cleanly if code >> without unwind data is reached: CodeSourcery are currently working on >> fixing the linker so that non-unwindable regions are marked properly, >> which we consider essential to making this feature usable. > > I don't understand this. Sorry if I'm being slow, but isn't it just a > matter of returning instead of calling abort when the search for the parent > frame's FDE fails in uw_update_context (or whatever it's called, didn't > check)? Marking bits in the linker doesn't enable you to unwind past them > somehow, does it? Err, no. We don't want to abort, but instead cleanly terminate the backtrace. ATM it can just go into an infinite loop. Andrew.
Re: __builtin_return_address for ARM
On Friday 27 February 2009, Dave Korn wrote: > Julian Brown wrote: > > Unfortunately backtraces don't currently terminate cleanly if code > > without unwind data is reached: CodeSourcery are currently working on > > fixing the linker so that non-unwindable regions are marked properly, > > which we consider essential to making this feature usable. > > I don't understand this. Sorry if I'm being slow, but isn't it just a > matter of returning instead of calling abort when the search for the parent > frame's FDE fails in uw_update_context (or whatever it's called, didn't > check)? Marking bits in the linker doesn't enable you to unwind past them > somehow, does it? ARM unwind tables are series of open ranges (only the start address is specified for each region). i.e. your assumption that the search will fail is incorrect. It will actually find the entry for the preceding function. The new linker bits automatically add cantunwind entries for code/objects that do not have unwind information. Paul
RE: GCC at Google Summer of Code'2009
Sure, Diego! By the way, we just finished preparing the small patch for the high-level plugin API (that includes pass manipulation and parameter tuning) synchronized with the current plugin branch (on top of Le-Chun's patch) and should be able to send it tonight ... Cheers, Grigori > -Original Message- > From: Diego Novillo [mailto:dnovi...@google.com] > Sent: Friday, February 27, 2009 4:42 PM > To: Grigori Fursin > Cc: gcc@gcc.gnu.org; Basile STARYNKEVITCH; Taras Glek; Zbigniew Chamski; Sean > Callanan; > Cupertino Miranda; Joseph S. Myers; Le-Chun Wu; Sebastian Pop; Albert Cohen; > Michael O'Boyle; > Paul H J Kelly; Olivier Temam; Chengyong Wu; Ayal Zaks; Bilha Mendelson; > Mircea Namolaru; > Erven Rohou; Cosmin Oancea; David Edelsohn; Kenneth Zadeck > Subject: Re: GCC at Google Summer of Code'2009 > > On Thu, Feb 26, 2009 at 05:57, Grigori Fursin wrote: > > > I am fine to mentor a few of them (particularly from 1-3) but would like to > > see if someone > > is interested to help with that ?.. I added these topics to the GCC GSOC > > page: > > http://gcc.gnu.org/wiki/SummerOfCode > > and would be happy if you modify it or tell me if you are interested ... > > I am interested in 1-3. I expect to be spending some more time on the > plugins branch in the near future. As Manuel pointed out, it's the > student's responsibility for coming up with a project. We do publish > those projects that we would be interested in seeing completed. But > it's ultimately up to the student. > > > Diego.
RE: GCC at Google Summer of Code'2009
Sure, I moved my project suggestions to "other projects" section and added contact info ... Cheers, Grigori > -Original Message- > From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com] > Sent: Thursday, February 26, 2009 8:41 PM > To: Grigori Fursin > Cc: Sebastian Pop; gcc@gcc.gnu.org > Subject: Re: GCC at Google Summer of Code'2009 > > 2009/2/26 Grigori Fursin : > > Hi Manuel, > > > I have been talking to a few mentors and students (not GCC related) > > who got their proposals accepted in the last year's Google Summer of Code > > and they basically told me that the mentors listed many different proposals > > so that students could have a choice and then they submitted proposals > > together. But maybe it was the wrong way to do :( ... > > You got it right but this is not what it looked like when you wrote a > table called "2009 Proposals" with a blank column "Students?" > separated from a section called "Project Ideas". > > Also, as I said, if you want students to contact you (or someone) > directly, then you should give contact information. I think having > contact information (obfuscated email, link to wiki user page, IRC > name at #gcc, whatever) could be very useful to track who proposed > what. That is why I did not delete it. > > > So, my idea was to sync on the potential proposals with GCC community > > so that students could have a choice. So, I converted the table to the > > bullet > > list format ... > > This is perfectly fine. The only problem is that there were already > proposals in that page. > > Table or bullet points, I do not care, but both things are a bit > confusing. Nonetheless, there could be a list/table of specific > projects and another list/table of "general" ideas. I think it would > be useful to separate the two, if you wish to do so. > > Cheers, > > Manuel.
Re: GNAT vs DW2/ZCX EH.
Eric Botcazou wrote: >> Hello all, and ADA hackers in particular :-) > > Ada, not ADA, that's not an acronym but a name, see http://www.adaic.org Yes, of course, I knew that really. My most humble apologies to the late Ms. Lovelace :-) >> The first problem I ran into was total failure to throw and catch >> exceptions in ADA, failing with a SEGV every time. It wasn't enough to >> just set EH_MECHANISM=-gcc in the target-specific section of >> gcc/ada/Makefile.in; I found that lots of the ada runtime had been compiled >> without EH frame data, so the unwinder couldn't throw through them and just >> blew up at runtime. > > Yes, an annoying merge glitch. The safest approach is probably to revert the > EH_MECHANISM change, on the 4.3 branch at least. This change is pre-approved > if you get a working Ada compiler with it. Ah, thanks, I'll have to research this change, I don't know about it yet. I'm not sure if I'll find time to investigate reverting it on the branch: my priorities are focussed around maintaining the Cygwin distro compiler and improving the Cygwin backend on trunk, so I'd prefer to make it work on 4.3 rather than revert it, involving local patches that won't be suitable for the branch but will be suitable for contributing to trunk for 4.5. (I've actually got it working beautifully now, tests still running but an order of magnitude better than anything I've seen before on Cygwin. There's a bunch of other stuff I patched to get it going that I didn't mention in this thread, in initialize.c and sysdep.c). >> So I added "T_ADA_CFLAGS=-fexceptions" to the target clause in >> Makefile.in as well, but that seems wrong to me: surely the build system >> ought to do that already? > > Neither, this is done automatically by the compiler, like in C++. It may in fact be that this change made no difference and the other things I did later are what resolved my problems. > Yes, ZCX_By_Default would have needed to be set to true in conjunction with > the EH_MECHANISM change, the settings are coupled. Great, thanks, that's good to have confirmed. Incidentally, if I understand rightly what's going on here, have you guys managed to make a compiler that's runtime-switchable between SjLj and DW2 EH? That would be sch a nice feature to have in the core GCC! I was expecting to have to distribute two entire sets of compilers (along with two sets of libgcc, etc.) configured differently; do you know if the approach taken by GNAT would be capable of porting to the main compiler? >> I think it might be that this arises because the GNAT I'm using to >> bootstrap was configured for sjlj EH, and I'm trying to build one >> configured for ZCX. > > Yes, very likely. > >> 1. Is it supposed to work to bootstrap gnat with a compiler using a >> different EH model from the one you're trying to build? > > Yes, I think so. > >> 2. Where it uses the host compiler, would it be ok to use the newly-built >> target one instead if host==target, i.e. not a cross compiler? > > Yes, probably. > >> 3. Should I have needed to add -fexceptions, and if not, why not? > > No, see above. Right. So I suspect that the critical bits were setting EH_MECHANISM, changing ZCX_By_Default, and the ADA_CFLAGS -> ALL_ADA_CFLAGS patching, and that adding the -fexceptions flag was superfluous - but harmless, no? I'd prefer not to respin this whole release YA time if I don't have to! Thanks for your advice Eric, you've been a great help :) cheers, DaveK
Re: __builtin_return_address for ARM
Paul Brook wrote: > ARM unwind tables are series of open ranges (only the start address is > specified for each region). i.e. your assumption that the search will fail is > incorrect. It will actually find the entry for the preceding function. > The new linker bits automatically add cantunwind entries for code/objects > that > do not have unwind information. I see, thanks (and Andrew); this is a platform-specific quirk of the file format. cheers, DaveK
Re: Split Stacks proposal
Andi Kleen writes: > Ian Lance Taylor writes: > >> I've put a project proposal for split stacks on the wiki at >> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack >> of a single thread to be split into discontiguous segments, thus >> permitting many more threads to be active at one time without worrying >> about stack overflow or about wasting lots of stack space for inactive >> threads. The compiler would have to generate code to support detecting >> when new stack space is needed, and to deal with some of the >> consequences of moving to a new stack. > > This is mainly for 32bit systems with tight address space right? On a > 64bit system you could just do it through the MMU by reserving enough > free VM space for the stack in advance and then handling the page fault. I am thinking mainly of systems with limited address space, right (if one can call 32 bits limited). However, it is somewhat useful even on 64-bit systems, in that you don't have to actually do all that MMU programming, and you don't have to worry about maximal stack sizes. That is, on a 64-bit system other approaches can be used, but this one is simpler. >> I would be interested in hearing comments about this. > > In the wiki: Possible strategies 1. > > Should that be "Each function with a _large_ stack frame" ? No. A function with a large stack frame needs a slightly more complicated instruction sequence to start. It needs to incorporate the size of the stack frame in the comparison. > How about alloca() in your scheme? There is a brief mention in the list of implementation steps. alloca and dynamic arrays will have to be implemented to check if there is enough space on the current stack. If there is not, they will have to be allocated on the heap, and the space released when the function returns. (This is painful to do outside the compiler, but inside the compiler it's a straightforward use of TRY_FINALLY_EXPR.) Ian
Re: Split Stacks proposal
Mathieu Lacage writes: > On Thu, 2009-02-26 at 14:05 -0800, Ian Lance Taylor wrote: >> I've put a project proposal for split stacks on the wiki at >> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack >> of a single thread to be split into discontiguous segments, thus >> permitting many more threads to be active at one time without worrying >> about stack overflow or about wasting lots of stack space for inactive >> threads. The compiler would have to generate code to support detecting >> when new stack space is needed, and to deal with some of the >> consequences of moving to a new stack. > > It would be totally awesome to do this if you could provide an option to > delegate to a user-provided function the allocation and deallocation of > the stack blobs needed by threads. Yes, this would be a goal. > i.e., the problem I run into is that I create a lot of user-space > threads and I need to allocate at the very least 2 pages (1 normal page, > 1 guard page) for each thread: > - 2 pages of address space is a lot if you have a lot of threads: it's > easy to run out of address space (physical memory is less of a concern > for me) > - 2 pages is not enough for a lot of threads and if one of my threads > hits the 2-page limit, I have to stop my program and restart it with a > bigger stack space for the offending thread which can be quickly > "annoying". Yes, this is the kind of issue the project is intended to address. > So, ideally, I would be able to not allocate statically any address > space for my threads and defer stack space allocation only when needed. > Ideally, I would even be able to use heap memory for that stack space if > I wanted to. Right. > Another use-case I could foresee for this would be to be able to profile > the runtime stack-usage of an application/set of threads to optimize it. Right. >> I would be interested in hearing comments about this. >> >> I'm not currently working on this, but I may start working on it at some >> point. > > I looked a bit at the page you pointed. A couple of questions: > > - if you want to use the stack protector and split stacks, it should > be fairly trivial to extend the data structure which contains the stack > protector with a new field, no ? No, as Daniel mentioned this is part of glibc on GNU/Linux systems, and is difficult to change. > - what would be a typical size for the stack space slop ? (for > example, on i386 ?) At this point I really don't know. > - I understand that you need to copy the function parameters from the > old stack to the new stack, but, why would you need to invoke the C++ > copy or move constructors for this ? Would a memcpy not be sufficient to > ensure proper C++ semantics in this case ? An example which shows how a > memcpy would break might be interesting. Daniel showed how this can fail for objects with internal pointers. This includes __gnu_cxx::__vstring, which is likely to be the default std::string class in libstdc++ 7, so this is not an unlikely occurrence. Ian
Re: GNAT vs DW2/ZCX EH.
> Ah, thanks, I'll have to research this change, I don't know about it yet. Hidden in http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00267.html > I'm not sure if I'll find time to investigate reverting it on the branch: > my priorities are focussed around maintaining the Cygwin distro compiler > and improving the Cygwin backend on trunk, so I'd prefer to make it work on > 4.3 rather than revert it, involving local patches that won't be suitable > for the branch but will be suitable for contributing to trunk for 4.5. The compiler was working before the change so just reverting it should make it work again. The change was totally accidental. > (I've actually got it working beautifully now, tests still running but an > order of magnitude better than anything I've seen before on Cygwin. > There's a bunch of other stuff I patched to get it going that I didn't > mention in this thread, in initialize.c and sysdep.c). Right, that's why the change should be reverted on the 4.3 branch. On the other hand, if you can get the ZCX support to work on the mainline before 4.4.0 is released, we could try there. > Great, thanks, that's good to have confirmed. Incidentally, if I > understand rightly what's going on here, have you guys managed to make a > compiler that's runtime-switchable between SjLj and DW2 EH? That would be > sch a nice feature to have in the core GCC! The GNAT SJLJ mechanism is not the standard GCC SJLJ mechanism, it's a custom one. Yes, it's runtime-switchable but this SJLJ mechanism is inferior to the GCC SJLJ mechanism (and to the ZCX one). > Right. So I suspect that the critical bits were setting EH_MECHANISM, > changing ZCX_By_Default, and the ADA_CFLAGS -> ALL_ADA_CFLAGS patching, and > that adding the -fexceptions flag was superfluous - but harmless, no? I'd > prefer not to respin this whole release YA time if I don't have to! Superfluous changes are never harmless in a compiler. :-) > Thanks for your advice Eric, you've been a great help You're welcome. Thanks for trying to fiddle with GNAT on Windows. :-) -- Eric Botcazou
Re: New no-undefined-overflow branch
Hi, > > introducing new codes seems like a bad idea to me. There are many > > places that do not care about the distinction between PLUS_EXPR and > > PLUSV_EXPR, and handling both cases will complicate the code (see eg. > > the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR > > distinction). Why not just use a flag to mark the operation as > > non-overflowing? > > I obviously thought about this. The issue with using a flag is > that there is no convenient place to stick it and that it makes > the distinction between the two variants less visible. Consider > the folding routines that take split trees for a start. > > IMHO using new tree-codes is much less complicated than carrying > around flags. I did consider putting flags on the tree code > itself, but that isn't going to make the changes easier either. OK, then what about this: introduce accessor functions like tree_code get_operation_semantics (tree_code) -- returns PLUS_EXPR for PLUS_EXPR and PLUSNV_EXPR, etc. bool get_operation_overflow (tree_code) -- obvious tree_code operation_code (tree_code, bool) -- PLUS_EXPR, false -> PLUS_EXPR -- PLUS_EXPR, true -> PLUSNV_EXPR -- PLUSNV_EXPR, * -> abort etc. (possibly with more clear names), and change the code to always use them? Zdenek
Re: New no-undefined-overflow branch
Hi, > > I obviously thought about this. The issue with using a flag is > > that there is no convenient place to stick it and that it makes > > the distinction between the two variants less visible. Consider > > the folding routines that take split trees for a start. > > > > IMHO using new tree-codes is much less complicated than carrying > > around flags. I did consider putting flags on the tree code > > itself, but that isn't going to make the changes easier either. > > I think it's probably a far safer design too. > > If you suddenly introduce a new semantic for an existing code, suddenly > every current check for that tree code becomes a potential bug site that has > to be manually inspected to see if it's overflow-sensitive or not and > therefore whether it needs to test the new flag or not; people who don't know > about the new flag will carry on adding code that processes those tree codes > without knowing to test the flag; and the bugs that do arise will be hard to > find and result in silent bad codegen. > > If OTOH you add new tree codes, the meaning will be explicit, nobody using > them can be under any misapprehension about the overflow semantics, nobody can > forget to check the flag, and any places where they should be handled but > aren't will very quickly draw themselves to our attention by ICEing, or if > they don't will simply fall back to the safe option of not doing any > processing on a tree code that they don't recognize; that might lead to > pessimal code, but it shouldn't generate incorrect code. you are way too optimistic. Regardless of whether you introduce the new codes or represent the new information in another way, the fact is that this changes semantics of PLUS_EXPR in some cases, and it will lead to a wave of bugs from places that you forgot to update or updated incorrectly. Also, adding new codes usually will not lead to ICEs on places that do not handle them, just to missed optimizations (most places that handle expressions have some kind of "default" -- if this is not any of the operations that we handle specially, do something generic). Using special codes is in no way safer than having an extra flag -- even with the extra flag, the default behavior for the newly created operations would be that they may wrap, so there is really no difference, Zdenek
Re: Split Stacks proposal
On Fri, 2009-02-27 at 08:54 -0800, Ian Lance Taylor wrote: > > It would be totally awesome to do this if you could provide an option to > > delegate to a user-provided function the allocation and deallocation of > > the stack blobs needed by threads. > > Yes, this would be a goal. The main reason I asked about this is that it is not obvious to me how this could be done: yes, you can call any function from your compiler-generated code but, what would the user need to do to change which address is called ? 1) specify a function name for allocation on the command-line during compilation and link statically into every binary an object file which contains the specified symbol ? This would allow you to have one allocation function per generated binary (shared library or executable) which might not be very desirable from a user-perspective. 2) generate code which uses a well-known name, calls this symbol through the PLT (on ELF systems), and, relies on the ELF loader to resolve that symbol in each binary to a single user-provided function. The libc could provide its own default implementation which is overridden either with LD_PRELOAD or by linking the function into the main executable. I don't care much about which option is chosen but it would be nice to know how you intend to deal with this aspect of the project. Mathieu
Re: New no-undefined-overflow branch
On Fri, 27 Feb 2009, Zdenek Dvorak wrote: > Hi, > > > > introducing new codes seems like a bad idea to me. There are many > > > places that do not care about the distinction between PLUS_EXPR and > > > PLUSV_EXPR, and handling both cases will complicate the code (see eg. > > > the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR > > > distinction). Why not just use a flag to mark the operation as > > > non-overflowing? > > > > I obviously thought about this. The issue with using a flag is > > that there is no convenient place to stick it and that it makes > > the distinction between the two variants less visible. Consider > > the folding routines that take split trees for a start. > > > > IMHO using new tree-codes is much less complicated than carrying > > around flags. I did consider putting flags on the tree code > > itself, but that isn't going to make the changes easier either. > > OK, then what about this: introduce accessor functions like > > tree_code get_operation_semantics (tree_code) > -- returns PLUS_EXPR for PLUS_EXPR and PLUSNV_EXPR, etc. > bool get_operation_overflow (tree_code) > -- obvious > tree_code operation_code (tree_code, bool) > -- PLUS_EXPR, false -> PLUS_EXPR > -- PLUS_EXPR, true -> PLUSNV_EXPR > -- PLUSNV_EXPR, * -> abort > etc. > > (possibly with more clear names), and change the code to always > use them? Yes. In playing with an initial patch I see the need for these kind of helpers. Sofar I tried to limit myself to PLUS_EXPR_P () covering both kinds, but that certainly is not enough. So I see the need for at least tree_code strip_nv (tree_code); -- returns PLUS_EXPR for PLUS_EXPR and PLUSNV_EXPR, etc. I didn't yet come along a need for your last one. Maybe similar to the second one is the requirement to somehow have a test when we want to emit strict-overflow warnings - which we want for the NV codes operating on signed types, possibly using TREE_NO_WARNING for avoiding warnings for NV codes that value-range analysis inserted (and, unfortunately there's no suitable place to put TREE_NO_WARNING on fold arguments ... :/). As of using them always - I will see how it works out. For a start I am able to miscompile gcc after just minimal fold surgery... :/ Thanks, Richard.
Your Beta Test status has been approved
Please do not forward this to anyone else. This offer is valid for the recipient only. You have been selected to try our new games. Get £20 and walk away with your returns. Click here to play! www.temptative.com/go Kind regards, Tempative Offers www.temptative.com/go
Re: Split Stacks proposal
Mathieu Lacage writes: > On Fri, 2009-02-27 at 08:54 -0800, Ian Lance Taylor wrote: > >> > It would be totally awesome to do this if you could provide an option to >> > delegate to a user-provided function the allocation and deallocation of >> > the stack blobs needed by threads. >> >> Yes, this would be a goal. > > The main reason I asked about this is that it is not obvious to me how > this could be done: yes, you can call any function from your > compiler-generated code but, what would the user need to do to change > which address is called ? > > 1) specify a function name for allocation on the command-line during > compilation and link statically into every binary an object file which > contains the specified symbol ? This would allow you to have one > allocation function per generated binary (shared library or executable) > which might not be very desirable from a user-perspective. > > 2) generate code which uses a well-known name, calls this symbol through > the PLT (on ELF systems), and, relies on the ELF loader to resolve that > symbol in each binary to a single user-provided function. The libc could > provide its own default implementation which is overridden either with > LD_PRELOAD or by linking the function into the main executable. I would use option 2. There could also be a hook function, along the lines of std::set_terminate. Ian
Re: Split Stacks proposal
This effort is relevant: http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf John Regehr
Re: Split Stacks proposal
John Regehr writes: > This effort is relevant: > > http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf Yes. Unfortunately, their analysis which lets them avoid testing at the entry to each function requires a complete call graph, which is not something gcc can assume in practice. Even when using LTO a genuinely complete call graph is not the normal case. It's true that we can use an analysis along these lines to avoid some checks in file-static functions (or, with LTO, in functions which get hidden visibility for whatever reason). However, I suspect that in practice this will be a minor optimization--worth doing, but only when everything else is working. Ian
Re: GNAT vs DW2/ZCX EH.
Eric Botcazou wrote: >> Ah, thanks, I'll have to research this change, I don't know about it yet. > > Hidden in http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00267.html > The compiler was working before the change so just reverting it should make > it > work again. The change was totally accidental. Gotcha. Accidental hunk, happens to the best of us! > Right, that's why the change should be reverted on the 4.3 branch. On the > other hand, if you can get the ZCX support to work on the mainline before > 4.4.0 is released, we could try there. Do we have time (and release-managerial leeway)? I probably couldn't start sending patches until the other side of the weekend. > The GNAT SJLJ mechanism is not the standard GCC SJLJ mechanism, it's a custom > one. Yes, it's runtime-switchable but this SJLJ mechanism is inferior to the > GCC SJLJ mechanism (and to the ZCX one). Oh well, shame but nevermind. > Superfluous changes are never harmless in a compiler. :-) Well... I think that whatever kind of harm it could possibly do in this case would be limited to adding eh tables where not needed, so a bit of image bloat is probably the worst that could happen. >> Thanks for your advice Eric, you've been a great help > > You're welcome. Thanks for trying to fiddle with GNAT on Windows. :-) 'sok, I'm quite keen to get all languages working well on Windows :) cheers, DaveK
Re: Please block henry2000 from the wiki
No, there is a list of wiki users considered superusers (IE able to become other people on the wiki, remove spam, etc). It requires no underlying permissions or accounts on sourceware itself. On Fri, Feb 27, 2009 at 10:08 AM, Christopher Faylor wrote: > On Thu, Feb 26, 2009 at 04:08:03PM -0500, Daniel Berlin wrote: >>If you want to help admin the wiki, I am more than happy to make you a >>super user. >>That goes for Steven, etc. > > Wait. Are we talking about giving people root access on sourceware > just to clean up a wiki? Hopefully this is not the case. > > cgf >
Re: GNAT vs DW2/ZCX EH.
> Do we have time (and release-managerial leeway)? I probably couldn't > start sending patches until the other side of the weekend. I think we can take the (small) risk for 4.4.0; it's only the Ada compiler and only on Windows. > Well... I think that whatever kind of harm it could possibly do in this > case would be limited to adding eh tables where not needed, so a bit of > image bloat is probably the worst that could happen. I can assure you that -fexceptions is strictly a no-op for the Ada compiler in ZCX mode, see misc.c:gnat_init_gcc_eh. No point in taking any risks fiddling with the complex Makefile machinery on all platforms. -- Eric Botcazou
Re: Constant folding and Constant propagation
"Rahul Kharche" writes: > GCSE won't help with your trimmed down example > > int main(void) > { > long a = 0xcafecafe; > > printf("Final: %lx %lx %lx\n", a, a+5, a+15); > return EXIT_SUCCESS; > } > > I believe Paolo's canon_reg solution together with tweaking > rtx_cost of constants with outer code PLUS might help. Any > luck with that pass? As I understand Paolo's change is to move some of the functionality from cse.c to a new LCM pass. However cse.c does not handle the above yet. I am actually looking at something similar for PR33699 for MIPS. My plan is to experiment extending cse.c with putting "anchor" constants to the available expressions along with the original constant and then querying those later for constant expressions. Adam
Re: New no-undefined-overflow branch
> To support languages that have undefined semantics on overflowing > operations the middle-end gets new unary and binary operators > that implicitly encode value-range information about their operands > noting that the operation does not overflow. These does-not-overflow > operators transform the undefined behavior into a valid assumption > and thus make the GIMPLE IL fully defined. >From an optimisation pass's point of view, what's the difference between: 1. a PLUS expression that gives an undefined result on overflow, and 2. a PLUS expression with a guarantee that the result won't overflow. I can't see how they will be handled any differently in practice. Thanks, Jay.
Re: GNAT vs DW2/ZCX EH.
> > Do we have time (and release-managerial leeway)? I probably couldn't > > start sending patches until the other side of the weekend. > > I think we can take the (small) risk for 4.4.0; it's only the Ada compiler and > only on Windows. It's too late for that in my mind, this feature should first be developed on trunk in stage 1, get proper testing, and then potentially back ported if it makes sense. Arno
Re: GNAT vs DW2/ZCX EH.
Right, that's why the change should be reverted on the 4.3 branch. On the other hand, if you can get the ZCX support to work on the mainline before 4.4.0 is released, we could try there. FYI, I have just succeeded in building gcc-4.3.3 including Ada for MinGW by setting ZCX_By_Default: constant Boolean := True; in system-mingw.ads as suggested by Danny Smith. The ACATS tests show quite some failures, though. I don't know if they are due to the EH or if there are other causes. Rolf
Re: GNAT vs DW2/ZCX EH.
> It's too late for that in my mind, this feature should first be developed > on trunk in stage 1, get proper testing, and then potentially back ported > if it makes sense. IMO you cannot backport such an incompatible change to a release branch. If the Windows maintainers are confident enough with it and given that we know there is no fundamental issue as far as GNAT is concerned, why not try? -- Eric Botcazou
Broken optimization of pow (x, 1.5) and other halfs of integers..
Hi folks. While optimizing some of my code I replaced powf (x, 1.5f) with x * sqrt(x). Out of couriosity I checked if GCC does this optimization and found it in the code. It's in expand_builtin_pow in the file builtin.c (gcc 4.3.1 source). However, GCC does not apply this optimization for a reason or another. If I change the constant to 3.0f I get optimized code from another special case expansion branch in that function (whole integers). Any ideas what's wrong here? The test-code, compiled with gcc (4.3.1) test.c -funsafe-math-optimizations -O3 -S #include float test (float arg) { return powf (arg, 1.5f); } If the optimization is triggered the disassembly shouldn't have a call to _powf anymore. Should I file a bug-report? Cheers, Nils
Re: GNAT vs DW2/ZCX EH.
> FYI, I have just succeeded in building gcc-4.3.3 including Ada for MinGW > by setting >ZCX_By_Default: constant Boolean := True; > in system-mingw.ads as suggested by Danny Smith. The ACATS tests show > quite some failures, though. I don't know if they are due to the EH or > if there are other causes. Thanks for reporting this. Can you try with the attached patch instead, i.e. without the system-mingw.ads change? This should restore the previous state and you could then compare the ACATS results. -- Eric Botcazou Index: Makefile.in === --- Makefile.in (revision 16) +++ Makefile.in (working copy) @@ -1353,7 +1353,6 @@ ifeq ($(strip $(filter-out cygwin32% min mlib-tgt-specific.adb
type promotion for fixed point types
Hi, I just added support for printf and scanf of fixed point types to avr libc. I wanted to handle: Currently "accum" and "fract" work, but not "short accum" or "short fract" This is not a problem for integers currently since they get type promoted when passed with stdarg. There is nothing in the fixed-point standard that is for or against this.. it seems logical that "short accum" be promoted to "accum" and "short fract" be promoted to "fract" in this case. Does anyone have any opinions on this? Thanks, Sean
Re: Broken optimization of pow (x, 1.5) and other halfs of integers..
On Fri, Feb 27, 2009 at 12:51 PM, Nils Pipenbrinck wrote: > Hi folks. > > While optimizing some of my code I replaced powf (x, 1.5f) with x * sqrt(x). > Out of couriosity I checked if GCC does this optimization and found it in > the code. It's in expand_builtin_pow in the file builtin.c (gcc 4.3.1 > source). > > However, GCC does not apply this optimization for a reason or another. If I > change the constant to 3.0f I get optimized code from another special case > expansion branch in that function (whole integers). Any ideas what's wrong > here? It works for me in 4.3.3 on i386-darwin and in 4.3.2 on powerpc64-linux-gnu so I don't know why you are not getting this optimization. Thanks, Andrew Pinski
Re: type promotion for fixed point types
On Fri, 27 Feb 2009, Sean D'Epagnier wrote: > Hi, > > I just added support for printf and scanf of fixed point types to avr > libc. I wanted to handle: > > Currently "accum" and "fract" work, but not "short accum" or "short fract" > > This is not a problem for integers currently since they get type > promoted when passed with stdarg. > > There is nothing in the fixed-point standard that is for or against > this.. it seems logical that "short accum" be promoted to "accum" and > "short fract" be promoted to "fract" in this case. > > Does anyone have any opinions on this? The promotion of "float" to "double" when passed to a variadic function is considered a legacy anomaly. Thus, the default argument promotions (applied to variable arguments) should be considered to be the "integer promotions", float to double, and nothing else. (In particular, it is deliberate that float _Complex does not promote to double _Complex - see DR#206 - and likewise float _Imaginary (not supported by GCC) does not promote to double _Imaginary.) Unless your promotion is defined as being one of the "integer promotions", it should thus not occur. Your printf implementation should call va_arg with the correct unpromoted type when it is passed an appropriate one of the fixed-point printf formats defined in the fixed-point TR. -- Joseph S. Myers jos...@codesourcery.com
Re: GNAT vs DW2/ZCX EH.
On Fri, 2009-02-27 at 21:04 +0100, Rolf Ebert wrote: > > Right, that's why the change should be reverted on the 4.3 branch. On the > > other hand, if you can get the ZCX support to work on the mainline before > > 4.4.0 is released, we could try there. > > FYI, I have just succeeded in building gcc-4.3.3 including Ada for MinGW > by setting >ZCX_By_Default: constant Boolean := True; > in system-mingw.ads as suggested by Danny Smith. The ACATS tests show > quite some failures, though. I don't know if they are due to the EH or > if there are other causes. Sometimes from the list of failures it's possible to identify what's broken. Did you send your test results to gcc-testresu...@? I couldn't find them. Thanks in advance, Laurent
Re: New no-undefined-overflow branch
On Fri, 27 Feb 2009, Jay Foad wrote: > > To support languages that have undefined semantics on overflowing > > operations the middle-end gets new unary and binary operators > > that implicitly encode value-range information about their operands > > noting that the operation does not overflow. These does-not-overflow > > operators transform the undefined behavior into a valid assumption > > and thus make the GIMPLE IL fully defined. > > From an optimisation pass's point of view, what's the difference between: > > 1. a PLUS expression that gives an undefined result on overflow, and > 2. a PLUS expression with a guarantee that the result won't overflow. > > I can't see how they will be handled any differently in practice. There is no difference in practice other than that we do a consistent interpretation of undefined. Note that the whole point of the branch is to make overflow behavior explicit per operation, not globally set per flag and for signed types only. Richard.
[ANN]: Redundancy remover
Hello everybody, the idea I presented last year [1], and which I said in January that I thought how to realize [2], has come true. I'd like to show you a tool that removes a bit of redundancy off your binaries, without needing to change the sources, by identifying repeated code blocks, and substituting them in the assembler listing by jumps to a common block. This is certainly not finished; depending on the AI that's put in here it could even write completely new functions, that combine small differences in the callers by using parameters. I have a prototype, which can prove the principle. I'm just inserting the README here; before more people join in hacking that, I'd like to ask whether I should open a new project for this at some OSS portal, or whether that should live in the GCC tree. Depending on that answer I'd put the code somewhere, and post the link here; I'd like to avoid having people sending me patches, because they're certain to conflict sooner or later, and I'm already a bit short on time anyway. Regards, Phil 1: http://gcc.gnu.org/ml/gcc/2008-03/msg00410.html 2: http://marc.info/?l=gcc&m=123272618027709&w=2 -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!Redundancy Remover == (C)opyright 2009 by Ph. Marek, philipp <%40> marek.priv.at Released under the GPLv3. What is this? = RR is a set of scripts to find duplicated code in binary files (like executables and shared objects), and to eliminate them by translating the assembler output of gcc before it's being converted to object code. And this works? === Yes, it does. See test results below. I chose to test FSVS because - it's my pet project, and so I know exactly how to compile it; - it has extensive tests, which I can use to verify the translation; - it's of a representative size. A bigger (partly done) test is with libgcj9; see below, too. How does this work? === Please see the POD documentation in the rr-translate perl script. Note about the savings == The values given by the script are just predictions for perfect translations, which won't be really seen. FSVS results The compilation took a bit more than twice as long; without translation 14.8 sec to 35.2 sec. The prediction was 2424 bytes, the real size difference 2128 bytes (0.8%): size: textdata bss dec hex filename 2598247960 11136 278920 44188 fsvs 2576967960 11136 276792 43938 fsvs.translated Linux kernel results I ran this on my custom linux kernel: text data bss dec hex filename 4651138 2149868 6551208 13352214 cbbd16 /usr/src/linux/vmlinux and got a prediction of about 37kB: max savings: 159513 real savings approximate 37917 bytes. Writing files to /tmp. 645 files written. In real life a bit less is to be expected; but 32kB should be possible. libgcj9 results === As I didn't have the sources available (at this moment), I only looked at the analyse results. I took /usr/lib/libgcj.so.90 from debian: libgcj9-0 4.3.3-3 Java runtime library for use with gcj -rw-r--r-- 1 root root 46903400 31. Jän 05:23 /usr/lib/libgcj.so.90 which, I believe, is one of the best cases, because it includes a high number of functions, where tail packing (;-) can be done. Analysing takes about 500MB RAM, and runs on a 800MHz machine for real 1m36.873s user 1m36.426s sys 0m3.636s The (unbelieveable) output is (surely wrong; but a straight compile of this library would give real hard numbers, so I stopped my bug hunting) max savings: 736313 real savings approximate 1561073 bytes. As an example of an output dump: # Redundancy Remover generated file. # This code part was originally seen at 0x016a9750 # got 129 hits in /usr/lib/libgcj.so.90, and was 158 bytes long. .globl RRGh7K3nv6Ocjw48SB5SACg .type RRGh7K3nv6Ocjw48SB5SACg, @function mov $0x4,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x5,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x6,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x7,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x8,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0x9,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0xa,%edi callq _Jv_ThrowBadArrayIndex nopw 0x0(%rax,%rax,1) mov $0xb,%edi callq _Jv_ThrowBadArrayIndex mov $0xc,%edi callq _Jv_ThrowBadArrayIndex mov $0xd,%edi callq _Jv_ThrowBadArrayIndex xchg %ax,%ax sub $0x8,%rsp callq _ZN4java4util18ListResourceBundleC1Ev add $0x8,%rsp retq
gcc-4.4-20090227 is now available
Snapshot gcc-4.4-20090227 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090227/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 144476 You'll find: gcc-4.4-20090227.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090227.tar.bz2 C front end and core compiler gcc-ada-4.4-20090227.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090227.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090227.tar.bz2 C++ front end and runtime gcc-java-4.4-20090227.tar.bz2 Java front end and runtime gcc-objc-4.4-20090227.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090227.tar.bz2The GCC testsuite Diffs from 4.4-20090220 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: New no-undefined-overflow branch
Jay Foad writes: >From an optimisation pass's point of view, what's the difference between: > > 1. a PLUS expression that gives an undefined result on overflow, and > 2. a PLUS expression with a guarantee that the result won't overflow. > > I can't see how they will be handled any differently in practice. I don't think that's the right way to describe the alternatives. The choices are: 1. A PLUS expression which gives an undefined result on overflow; 2. A PLUS expression which wraps on overflow. Those two cases can be optimized differently. For example, (a +undef-overflow C1) < C2 where C1 and C2 are constants, may be optimized to a < C2 - C1 That is not true of (a +wrapping-overflow C1) < C2 Ian
Re: New no-undefined-overflow branch
On Thu, Feb 26, 2009 at 06:05, Richard Guenther wrote: > There shall be no construct in the GIMPLE IL that invokes > undefined behavior. Excellent! Thanks for starting this branch. > Thus, from now on integer overflow is defined and will wrap with > the usual twos-complement semantics. Thus, for the middle-end > -fwrapv is always in effect. This extends to pointer overflow. You mean that -fwrapv is always in effect for the *V_EXPR operations, right? PLUS_EXPR will always be defined as not overflowing. It's up to the front end to emit one or the other. How should we define merging two different TUs compiled with different -fwrapv settings? This is something that may be common in the context of LTO: $ gcc -flto -fwrapv f1.c $ gcc -flto f2.c $ gcc -o f -O2 f1.o f2.o We will be reading IL containing both overflow and non-overflow operations. We should define the combination rules for them. > Naming suggestions welcome, at the moment I consider NEGATEV_EXPR > (thus appending V to the first part). As good a convention as any. Diego.
Re: New no-undefined-overflow branch
On Fri, 27 Feb 2009, Diego Novillo wrote: > We will be reading IL containing both overflow and non-overflow > operations. We should define the combination rules for them. The rules are simple: * No transformation (of arithmetic operations, which is what we are discussing here) may change defined behavior for given inputs to undefined behavior for those same inputs. (The reverse transformation is permitted. For example, a mixed set of addition/subtraction operations might usefully be converted to all overflow-defined operations to allow the operands to be rearranged and cancellation to take place. For example, if both versions of a+b with the same operands are in use at some point, the overflow-undefined version need not be computed, only the overflow-wraps version.) * No transformation may change defined behavior for given inputs to different, defined behavior for those inputs. -- Joseph S. Myers jos...@codesourcery.com
Old GCC-on-Tru64 bugfix needs applying
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300 This bug was originally reported against 3.4.0. It is still present in 4.3.3. Giovanni Bajo came up with a patch to fixincludes to take care of it. Bruce Korb was supposed to apply it, but he seems to have gone AWOL. To whoever is currently maintaining fixincludes: Please apply this fix, and let this bug die with dignity. --Daniel P.S.: Please Cc: me on any replies, as I am not subscribed to this list. -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = sk...@iskunk.org## don't smell bad---(/o|o\) / EMAIL2 = sk...@alum.mit.edu ## it's the people who < (^),> WWW= http://www.**.org/ ## annoy them that do!/ \ -- (** = site not yet online)