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 amyl...@spamcop.net: Quoting daniel tian daniel.xnt...@gmail.com: 2009/2/26 Joern Rennecke amyl...@spamcop.net: 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 dber...@dberlin.org: 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 lopeziba...@gmail.com wrote: 2009/2/25 Gerald Pfeifer ger...@pfeifer.com: 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 joel.sherr...@oarcorp.com 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: 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: snip === 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 ... ] snip 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: snip # 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 21 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 21 snip 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: snip 2001-05-02 John David Anglin d...@hiauly1.hia.nrc.ca * 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 a...@redhat.com wrote: Paul Brook wrote: Well, but wouldn't it still be nice if __builtin_return_address(N) was implemented for N0 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 N0 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 dave.korn.cyg...@googlemail.com:
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 jul...@codesourcery.com 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 a...@redhat.com wrote: Paul Brook wrote: Well, but wouldn't it still be nice if __builtin_return_address(N) was implemented for N0 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 N0 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: snip- --- === 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 ... ] snip- --- 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: GCC at Google Summer of Code'2009
On Thu, Feb 26, 2009 at 05:57, Grigori Fursin grigori.fur...@inria.fr 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=S_aut1,S_aut2. 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 grigori.fur...@inria.fr 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 grigori.fur...@inria.fr: 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 g 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 a...@firstfloor.org writes: Ian Lance Taylor i...@google.com 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 mathieu.lac...@sophia.inria.fr 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 mathieu.lac...@sophia.inria.fr 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 reg...@cs.utah.edu 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 cgf-use-the-mailinglist-ple...@gnu.org 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 ra...@icerasemi.com 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 math.h
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.adbmlib-tgt-mingw.adb \ indepsw.adbindepsw-mingw.adb - EH_MECHANISM=-gcc GMEM_LIB = gmemlib PREFIX_OBJS = $(PREFIX_REAL_OBJS) EXTRA_GNATTOOLS = ../../gnatdll$(exeext)
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 n.pipenbri...@cubic.org 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=gccm=123272618027709w=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 jay.f...@gmail.com 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 rguent...@suse.de 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)
[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)
--- Comment #6 from janus at gcc dot gnu dot org 2009-02-27 09:01 --- On x86_64-unknown-linux-gnu I *do* get the ICE when I compile with -ffast-math -mfpmath=387. Cf. http://gcc.gnu.org/ml/fortran/2008-11/msg00250.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39314
[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)
--- Comment #7 from janus at gcc dot gnu dot org 2009-02-27 09:13 --- Note that the problem also appears for log, while it does not for acosh and atanh: real :: x = -5.0 ! FPE is not thrown print *, log(x) print *, log10(x) print *, acos(x) print *, asin(x) ! FPE is thrown !print *, sqrt(x) !print *, atanh(x) !print *, acosh(x) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39314
[Bug ada/38832] Main program runs fine but hangs on exit when linked with Ada shared lib
--- Comment #2 from oliver dot kellogg at eads dot com 2009-02-27 09:28 --- FWIW, pressing Ctrl-C in gdb when the program blocks shows following trace: Program received signal SIGINT, Interrupt. 0x0805bbd1 in system.soft_links.task_lock_nt () at s-soflin.adb:295 295procedure Task_Lock_NT is (gdb) bt #0 0x0805bbd1 in system.soft_links.task_lock_nt () at s-soflin.adb:295 #1 0x08053104 in system.file_io.close (file_ptr=0xbfffea7c, file_ptrF=2) at s-fileio.adb:220 #2 0x080532db in system.file_io.finalize (v=(prev = 0x0, next = 0x8076b60)) at s-fileio.adb:379 #3 0x0805461f in system.finalization_implementation.finalize_list (l=0x8076b94) at s-finimp.adb:361 #4 0x080546d9 in system.finalization_implementation.finalize_global_list () at s-finimp.adb:327 #5 0x0804ad12 in main (argc=1, argv=(system.address) 0xbfffed54, envp=(system.address) 0xbfffed5c) at /home/kellogg/ada/shared_lib/testuser/b~appl_main.adb:188 #6 0xb7ea2fe0 in __libc_start_main () from /lib/libc.so.6 #7 0x0804a951 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38832
[Bug ada/39172] libada parsing of multilib options
--- Comment #10 from schwab at suse dot de 2009-02-27 09:57 --- Fixed. -- schwab at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39172
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #21 from pluto at agmk dot net 2009-02-27 10:29 ---
(In reply to comment #20)
Same issue. Only possible fix is to not apply TBAA pruning to escaped
symbols, which will - well - basically disable TBAA. Testcase:
waht about this testcase?
the bug is marked as fixed but warnings are still present?
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
struct Y {
Y() {}
int i;
};
struct X {
X() {}
void construct(const Y y)
{
new (m_data[0]) Y(y);
}
template class T
Y get() { return reinterpret_castY(m_data); }
bool initialized;
char m_data[sizeof (Y)];
};
X x;
void bar(const X);
void foo(Y y)
{
x.getY() = y;
x.initialized = true;
bar(x);
}
t.cpp: In member function 'Y X::get() [with T = Y]':
t.cpp:25: instantiated from here
t.cpp:15: warning: dereferencing type-punned pointer will break strict-aliasing
rules
t.cpp: In function 'void foo(Y)':
t.cpp:25: warning: dereferencing pointer 'anonymous' does break
strict-aliasing rules
t.cpp:25: note: initialized from here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #22 from rguenther at suse dot de 2009-02-27 10:33 ---
Subject: Re: [4.4 regression] warnings from -isystem
headers strikes back.
On Fri, 27 Feb 2009, pluto at agmk dot net wrote:
--- Comment #21 from pluto at agmk dot net 2009-02-27 10:29 ---
(In reply to comment #20)
Same issue. Only possible fix is to not apply TBAA pruning to escaped
symbols, which will - well - basically disable TBAA. Testcase:
waht about this testcase?
the bug is marked as fixed but warnings are still present?
The original reported problem is gone. The testcase below is unfixable.
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
struct Y {
Y() {}
int i;
};
struct X {
X() {}
void construct(const Y y)
{
new (m_data[0]) Y(y);
}
template class T
Y get() { return reinterpret_castY(m_data); }
bool initialized;
char m_data[sizeof (Y)];
};
X x;
void bar(const X);
void foo(Y y)
{
x.getY() = y;
x.initialized = true;
bar(x);
}
t.cpp: In member function 'Y X::get() [with T = Y]':
t.cpp:25: instantiated from here
t.cpp:15: warning: dereferencing type-punned pointer will break
strict-aliasing
rules
t.cpp: In function 'void foo(Y)':
t.cpp:25: warning: dereferencing pointer 'anonymous' does break
strict-aliasing rules
t.cpp:25: note: initialized from here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug fortran/39309] [4.4 Regression] .mod file versioning causes error instead of overwritting the file
--- Comment #5 from burnus at gcc dot gnu dot org 2009-02-27 10:47 --- FIXED on the trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39309
[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)
--- Comment #8 from burnus at gcc dot gnu dot org 2009-02-27 10:49 --- Note that the problem also appears for log, while it does not for acosh and atanh: If it works with some but not all libm routines, it sounds more like a GLIBC than like a GCC problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39314
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #23 from pluto at agmk dot net 2009-02-27 11:04 --- (In reply to comment #22) The original reported problem is gone. The testcase below is unfixable. so what users can do now? the -isystem feature doesn't work as expected with this unfixable diagnostics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-02-27 11:07 --- The user can use -Wno-strict-aliasing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #25 from pluto at agmk dot net 2009-02-27 11:22 --- (In reply to comment #24) The user can use -Wno-strict-aliasing. naturally, but -O2 turns on -fstrict-aliasing, so using strict-aliasing without warnings about aliasing violations is a bit horrible :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #26 from rguenther at suse dot de 2009-02-27 12:04 --- Subject: Re: [4.4 regression] warnings from -isystem headers strikes back. On Fri, 27 Feb 2009, pluto at agmk dot net wrote: --- Comment #25 from pluto at agmk dot net 2009-02-27 11:22 --- (In reply to comment #24) The user can use -Wno-strict-aliasing. naturally, but -O2 turns on -fstrict-aliasing, so using strict-aliasing without warnings about aliasing violations is a bit horrible :) On IRC we agreed that turning strict-aliasing warnings off for system-headers is not a good idea. So -Wno-strict-aliasing is the only thing I can offer. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug fortran/39314] -ffpe-trap=invalid gives no FPE for acos(-5.0)
--- Comment #9 from janus at gcc dot gnu dot org 2009-02-27 13:15 --- (In reply to comment #8) If it works with some but not all libm routines, it sounds more like a GLIBC than like a GCC problem. Can someone reproduce this with C code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39314
[Bug ada/36939] Build Failure Ada SH2e
--- Comment #11 from joel at gcc dot gnu dot org 2009-02-27 16:24 --- Laurent.. what Makefile magic is needed to select this file on sh Ada targets and not on others? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #12 from aesok at gcc dot gnu dot org 2009-02-27 16:25 --- 2007-04-05 Anatoly Sokolov ae...@post.ru PR target/25448 * config/avr/avr.c (avr_handle_fndecl_attribute): Use the DECL_ASSEMBLER_NAME, not the DECL_NAME. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug ada/38349] Error Building Ada (h8300)
--- Comment #2 from joel at gcc dot gnu dot org 2009-02-27 16:26 --- Ping.. still broken gcc (GCC) 4.4.0 20090226 (experimental) [trunk revision 144455] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38349
[Bug ada/38349] Error Building Ada (h8300)
--- Comment #3 from joel at gcc dot gnu dot org 2009-02-27 16:28 --- Laurent.. would it make sense to have a low memory alternate version of the file in question and swap it in on some targets like the sh2e issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38349
[Bug middle-end/39308] ICE when compiling with -O[s123] -floop-interchange
--- Comment #14 from spop at gcc dot gnu dot org 2009-02-27 16:42 --- Subject: Bug 39308 Author: spop Date: Fri Feb 27 16:42:38 2009 New Revision: 144470 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144470 Log: 2009-02-27 Sebastian Pop sebastian@amd.com PR middle-end/39308 * graphite.c (graphite_loop_normal_form): Do not call number_of_iterations_exit from a gcc_assert. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39308
[Bug middle-end/39308] ICE when compiling with -O[s123] -floop-interchange
--- Comment #15 from spop at gcc dot gnu dot org 2009-02-27 16:43 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39308
[Bug ada/38349] Error Building Ada (h8300)
--- Comment #4 from laurent at guerby dot net 2009-02-27 17:42 --- First you need to find out which stack_size works on your target. An obvious patch would be something like that: Default_Env_Stack_Size : constant Size_Type := Size_Type'Min (8_192_000, Size_Type'Last / 1024 ); Otherwise since the only used of Default_Env_Stack_Size is s-stchop.adb I think replacing the constant by a function would be acceptable, then you could customize the return value it in s-parame-rtems.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38349
[Bug ada/36939] Build Failure Ada SH2e
--- Comment #12 from laurent at guerby dot net 2009-02-27 17:50 --- There is no need for Makefile magic here, this is a bug in s-scaval.adb logic. As I said this file is used for only one ACATS test and one specific and not widely used feature, so for the purpose of testing RTEMS you can just replace unconditionally s-scaval.adb by the empty version you won't loose anything important. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939
[Bug fortran/39318] New: internal compiler error: verify_stmts failed
The attached code produce an ICE (below) with cuurent trunk when the compiler option includes all of '-fno-second-underscore -fexceptions -O3'. The code compiles fine with gfortran-4.3.2. .. [d...@logos gemclim33]$ gfc -c -m64 -fPIC -fcray-pointer -fconvert=big-endian -fopenmp -fno-second-underscore -fexceptions -O3 adw_trajsp.f adw_trajsp.f: In function adw_trajsp_.omp_fn.0: adw_trajsp.f:459: error: Dead STMT in EH table D.3244_455 = __builtin_sqrtf (D.3243_454); adw_trajsp.f:459: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. .. -- Summary: internal compiler error: verify_stmts failed Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deji_aking at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug fortran/39318] internal compiler error: verify_stmts failed
--- Comment #1 from deji_aking at yahoo dot ca 2009-02-27 18:03 --- Created an attachment (id=17371) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17371action=view) Fortran file that produce the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug fortran/39318] internal compiler error: verify_stmts failed
--- Comment #2 from dominiq at lps dot ens dot fr 2009-02-27 18:24 --- Confirmed oni686-apple-darwin9 with gfc -c -fcray-pointer -fexceptions -O2 -ftree-vectorize adw_trajsp.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug c++/39319] New: sigsegv occurs when an exception handler rethrows an excpetion and tries to return from the catch
The sample program fails to run on Linux x86_64.
I'm using ...
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
... and compiling with command line ...
g++ -Os catch.cpp -o catch.exe
=== Program Output ===
./catch.exe
file = catch.cpp
Segmentation fault
=== SAMPLE Program ===
#include stdexcept
#include exception
#include iostream
void MyExceptionHandler(const char* p_file)
{
try
{
throw;
}
catch (std::exception stdexc)
{
std::cerr file = p_file std::endl;
}
}
int main(int argc, char** argv)
{
try
{
throw std::runtime_error(Throw some error, this should get caught.);
}
catch(...)
{
MyExceptionHandler(__FILE__);
}
printf(RETURNED SAFELY\n);
return 0;
}
--
Summary: sigsegv occurs when an exception handler rethrows an
excpetion and tries to return from the catch
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phamorsky at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39319
[Bug c++/39319] sigsegv occurs when an exception handler rethrows an excpetion and tries to return from the catch
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-27 18:31 --- 3.4.6 is old and 3.4.x to 4.1.x are no longer maintained.This is most likely a duplicate of bug 26530. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39319
[Bug ada/38832] Main program runs fine but hangs on exit when linked with Ada shared lib
--- Comment #3 from oliver dot kellogg at eads dot com 2009-02-27 18:42 --- Expanding on comment #2, there seems to be an endless loop around s-fileio.adb:377ff. 376 Fptr1 := Open_Files; 377 while Fptr1 /= null loop 378 Fptr2 := Fptr1.Next; 379 Close (Fptr1'Access); 380 Fptr1 := Fptr2; 381 end loop; Setting a breakpoint at 376, Breakpoint 1, system.file_io.finalize (v=(prev = 0x0, next = 0x8078b60)) at s-fileio.adb:376 376 Fptr1 := Open_Files; (gdb) n 377 while Fptr1 /= null loop (gdb) p Fptr1 $28 = (access system.file_control_block.afcb) 0x8078a60 (gdb) p Fptr1.next $29 = (access system.file_control_block.afcb) 0x8078a00 (gdb) p Fptr1.next.next $30 = (access system.file_control_block.afcb) 0x80789a0 (gdb) p Fptr1.next.next.next $31 = (access system.file_control_block.afcb) 0x8078a60 (gdb) p Fptr1.next.next.next.next $32 = (access system.file_control_block.afcb) 0x8078a00 (gdb) p Fptr1.next.next.next.next.next $33 = (access system.file_control_block.afcb) 0x80789a0 .. and so on, indefinitely, where (gdb) p Fptr1.name.all $34 = *stderr[00] (gdb) p Fptr1.next.name.all $35 = *stdout[00] (gdb) p Fptr1.next.next.name.all $36 = *stdin[00] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38832
[Bug middle-end/39318] internal compiler error: verify_stmts failed
--- Comment #3 from dominiq at lps dot ens dot fr 2009-02-27 19:03 --- Forgot to say that it is a [4.4 Regression]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug target/39320] New: Regression: ICE: : in gen_add2_insn, at optabs.c:4733
This occurred during the build. I would expect it to happen on m32c-elf also. $ /home/joel/test-gcc/b-gcc1-m32c/./gcc/xgcc -B/home/joel/test-gcc/b-gcc1-m32c/./gcc/ --version xgcc (GCC) 4.4.0 20090226 (experimental) [trunk revision 144455] /home/joel/test-gcc/install/m32c-rtems4.10/include -isystem /home/joel/test-gcc/install/m32c-rtems4.10/sys-include -c -DHAVE_CONFIG_H -g -O2-mcpu=m32cm -I. -I/home/joel/test-gcc/gcc-svn/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic /home/joel/test-gcc/gcc-svn/libiberty/strdup.c -o strdup.o /home/joel/test-gcc/gcc-svn/libiberty/random.c: In function 'srandom': /home/joel/test-gcc/gcc-svn/libiberty/random.c:243: internal compiler error: in gen_add2_insn, at optabs.c:4733 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: Regression: ICE: : in gen_add2_insn, at optabs.c:4733 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: m32c-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39320
[Bug debug/39267] gdb testusite regressions
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-02-27 19:49 --- Subject: Bug 39267 Author: hubicka Date: Fri Feb 27 19:49:42 2009 New Revision: 144474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144474 Log: PR debug/39267 * tree.h (TREE_PROTECTED): Fix comment. (BLOCK_HANDLER_BLOCK): Remove. (struct tree_block): Remove handler_block add body_block. (inlined_function_outer_scope_p): New. (is_body_block): Remove. * dbxout.c (dbxout_block): Remove BLOCK_HANDLER_BLOCK. * dwarf2out.c (is_inlined_entry_point): Remove. (add_high_low_attributes): Use inlined_function_outer_scope_p. (gen_block_die): Use is_inlined_entry_point check; remove body block code. * langhooks.h (struct lang_hooks): Remove no_bodu_blocks. * gimplify.c (gimplify_expr): Gimplify body blocks. * tree-ssa-live.c (remove_unused_scope_block_p): Allow removing wrapper block with multiple subblocks. (dump_scope_block): Prettier output; dump more flags and info. (dump_scope_blocks): New. (remove_unused_locals): Use dump_scope_blocks. * tree-flow.h (dump_scope_blocks): Declare. * tree-cfg.c (execute_build_cfg): Dump scope blocks. * stmt.c (is_body_block): Remove. * tree-inline.c (remap_block): Copy BODY_BLOCK info. * langhooks-def.h (LANG_HOOKS_NO_BODY_BLOCKS): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-objc-common.h trunk/gcc/dbxout.c trunk/gcc/dwarf2out.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.h trunk/gcc/stmt.c trunk/gcc/tree-cfg.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-live.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39267
[Bug middle-end/39318] internal compiler error: verify_stmts failed
--- Comment #4 from dominiq at lps dot ens dot fr 2009-02-27 19:59 --- Reduced test: subroutine adw_trajsp ( F_lon, F_lat, F_x, F_y, F_z, %F_u, F_v, F_dt,i0,in,j0,jn) implicit none real F_lon(*),F_lat(*),F_x(*),F_y(*),F_z(*),F_u(*),F_v(*),F_dt integer i0,in,j0,jn integer n, ij, nij,vnij, i,j,k real*8 xsin(i0:in,j0:jn) !$omp parallel do private(xsin) do j=j0,jn do i=i0,in xsin(i,j) = sqrt( F_u(n) ** 2 + F_v(n) ** 2 ) * F_dt end do end do !$omp end parallel do return end ibook-dhum] f90/bug% gfc -c -fopenmp -fexceptions -O2 -ftree-vectorize adw_trajsp_red.f adw_trajsp_red.f: In function 'adw_trajsp_.omp_fn.0': adw_trajsp_red.f:8: error: Dead STMT in EH table D.1679_46 = __builtin_sqrtf (D.1678_45); adw_trajsp_red.f:8: internal compiler error: verify_stmts failed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39318
[Bug c++/39321] New: G++ remove cv qualifiers from typedefs during template instantiation
The following program should compile, but current g++ from trunk compiles it.
Please read the comments in the code:
~=~
templatetypename T
struct do_typedef
{
typedef T type;
};
templatetypename T struct is_function;
// Let's name this template partial specialization #1
templatetypename T
struct is_function T ()
{
};
templatetypename T struct is_member_func;
templatetypename T, typename C
struct is_member_funcT C::*
{
//[1] okay, the following line should not compile. Here is why.
//After the type substitution that happens at instantiation time,
//the value of the argument that matches the T parameter is
//'void () () const'.
//In that context, the result of the substitution of T in the expression
//do_typedefT::type _should_ be 'void () () const' as well.
//So will be the argument of the is_function template.
//'void () () const' is not compatible with 'T ()', so the
//partial template specialization #1 should be instantiated.
//So we should get a compilation error.
is_functiontypename do_typedefT::type t;
};
struct A;
// Should not compile because of the comment [1] above.
is_member_funcvoid (A::*) (void) const t;
~=~
What happens is that during the type substitution of
do_typedefT::type, g++ removes the const qualifier from the 'void () ()
const' function. And that is a bug.
I'll attach below a patch that fixes it.
--
Summary: G++ remove cv qualifiers from typedefs during template
instantiation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dodji at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39321
[Bug c++/39321] G++ remove cv qualifiers from typedefs during template instantiation
--- Comment #1 from dodji at gcc dot gnu dot org 2009-02-27 20:06 --- Created an attachment (id=17372) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17372action=view) Don't remove cv quals from typedefs during type substitution -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39321
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #2 from dodji at gcc dot gnu dot org 2009-02-27 20:08 --- I have filed bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39321 that describes the gcc bug. It also has a patch that should fix it. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug tree-optimization/39129] The meaning of 'BB' in too many BBs in loop
--- Comment #3 from lanurmi at iki dot fi 2009-02-27 20:15 --- Well yes, the meaning of basic block is not self-explanatory either. But at least it is a much better search term than just 'BB'. And if someone comes up with something even better, I'm certainly not against it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39129
[Bug target/39320] Regression: ICE: : in gen_add2_insn, at optabs.c:4733
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-27 20:25 --- *** This bug has been marked as a duplicate of 39182 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39320
[Bug target/39182] ICE in gen_add2_insn, at optabs.c:4884
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-27 20:25 --- *** Bug 39320 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
[Bug c/36839] struct with only anonymous unions plus flexible array member
--- Comment #3 from vegard dot nossum at gmail dot com 2009-02-27 20:27
---
I'm hitting this as well :-(
[veg...@damson ~/programming 0]
$ cat flexible-array-empty-struct.c
struct x {
union {
int x;
};
int array[];
};
[veg...@damson ~/programming 0]
$ gcc -c flexible-array-empty-struct.c
flexible-array-empty-struct.c:6: error: flexible array member in otherwise
empty struct
[veg...@damson ~/programming 1]
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
--
vegard dot nossum at gmail dot com changed:
What|Removed |Added
CC||vegard dot nossum at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36839
[Bug c/36839] struct with only anonymous unions plus flexible array member
--- Comment #4 from vegard dot nossum at gmail dot com 2009-02-27 20:32
---
Workaround:
Install an empty dummy member between the union and the array, like this:
struct x {
union {
int x;
};
int _dummy[0]; // workaround
int array[];
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36839
[Bug c/36839] struct with only anonymous unions plus flexible array member
--- Comment #5 from joseph at codesourcery dot com 2009-02-27 20:58 --- Subject: Re: struct with only anonymous unions plus flexible array member Anonymous unions are outside the scope of C99, so this issue is purely about what is most useful for GNU C right now. However, there have been discussions of including some form of anonymous structs and unions in C1x, and if that goes in we'd want to follow whatever that may say about whether this is valid (along with other aspects of anonymous structs/unions - hopefully C1x would follow C++). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36839
