Re: birthpoints in rtl.
> The two complications are: > 1) libcalls I am probably dense here, but why we can't just ignore existence of libcalls for dataflow framework? This exist so we can effectivly remove blocks of code in dead code removal and do some other changes, but I don't see how they can be less friendly to FUD than they are to DU/UD. Sure the optimization has to care to not break the extra invariant that libcalls stay independent, but that is. Overall yes, I certainly would hope they can go. Just I don't see direct dependency with this project. > 2) how do you merge different types of subregs stores. > > We have our best people working on (1) and the hope is that unless > someone adds a killer reason to enhancement bugzilla 35413, we should be > able to make that abomination go away forever. I plan to clear > enhancement bugzilla 35404 this weekend. > > I am still hoping for one of the subreg elite to volunteer to help me > with (2). Subregs don't seem to be too different here. The reads of subregs are equivalent with any other use. The stores are bit funnier since some cases (subregs of multiword pseudos or STRICT_LOW_PART) behave as read write operations. Only problem here seems to be that wihtout lowering the multiword operation we have some extra uses of undefined variables but this conservative handling should be good enough for most cases. For introducing the PHI operations you do not need to worry if the value originated in SUBREG or not. Honza > > Then my plan is to "adapt" as much of the tree ssa code (there is no > reason for me to write dominance frontier code for the 4 time from > scratch) as possible to inserting the noop moves where the phi would > normally go and adapt the renaming step to build the chains. I have not > read the fud papers closely, but reif's trick of using for using the > birthpoints means that you can actually avoid having to solve reaching > defs, and can just adapt the ssa stack based renaming algorithm to build > the chains rather than rename the vars. I have no idea if wolfe ever > figured this part out or not. > > Kenny
Re: birthpoints in rtl.
> Diego, > > I am leaning to just adding noop moves at the birthpoints (dominance > frontiers) as real noop move insns in the streams in the passes that use > ud or du chains. The back end is tolerant of noop moves and without Hi, while I am with Diego that would preffer PHI nodes on side especially in FUD chain where rest of your SSA is on side too. But if we go with the extra instruction scheme, I think you are much better to use RTL USE instruction. The moves are generated by target machinery and can do funny things, like clobbering flags or whatever. USEs are transparent this way. Honza
Re: birthpoints in rtl.
On Sat, Mar 1, 2008 at 11:03 AM, Jan Hubicka <[EMAIL PROTECTED]> wrote: > > The two complications are: > > 1) libcalls > > I am probably dense here, but why we can't just ignore existence of > libcalls for dataflow framework? Not libcalls, but libcall *notes*. > This exist so we can effectivly remove > blocks of code in dead code removal and do some other changes, but I > don't see how they can be less friendly to FUD than they are to DU/UD. > Sure the optimization has to care to not break the extra invariant that > libcalls stay independent, but that is. The extra care is the problem. To be fair, the problem is manageable (see the whole DCE vs. libcall notes thread from last year) but it adds a lot of complexity and defeats the benefits of having FUD chains. Basically the same problem as the issues we had for RTL SSA. See these threads: http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01152.html http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01174.html). I could also start a rant here about how tree-ssa was supposed to make libcall notes obsolete, how much better things already would be today even without libcall notes if you compare it to the pre-tree-ssa era, and how GCC once again chooses irrational conservatism over reaping the fruits of all the tree-ssa work -- but that's *really* orthogonal to this thread, so I won't ;-) By the way, I still don't understand how birth points would work. Can someone give an example of what the insn stream would look like with birth points, and what the DU/UD chains would look like? Gr. Steven
Re: [PATCH][4.3] Deprecate -ftrapv
> > Ada currently has to do this itself, precisely because -ftrapv doesn't > > work, so it's not the case that Ada "needs" it. > > Well no one "needs" anything in this sense, any interfaced is Turing > complete so there is *always* a work around deficiencies in the back > end. But right now, the "do this itself" is really horribly inefficient: Clearly. My point was that Ada doesn't need a *broken* -ftrapv. So if there's no hope of fixing it, we might as well deprecate it.
Re: birthpoints in rtl.
> > Not libcalls, but libcall *notes*. > > > This exist so we can effectivly remove > > blocks of code in dead code removal and do some other changes, but I > > don't see how they can be less friendly to FUD than they are to DU/UD. > > Sure the optimization has to care to not break the extra invariant that > > libcalls stay independent, but that is. > > The extra care is the problem. To be fair, the problem is manageable > (see the whole DCE vs. libcall notes thread from last year) but it > adds a lot of complexity and defeats the benefits of having FUD I see. This should not get that worse with FUD. > chains. Basically the same problem as the issues we had for RTL SSA. > See these threads: > > http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01152.html > http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01174.html). The point I wanted to make is that FUD is more firendly to RTL than true rewriting SSA and it general it should not be any worse than DU/UD. In particular the read-write constructs, like subregs, are not issue and neither are the unssa problems related to libcalls disucssed in the thread you point to. This does not imply that it would not be great to eliminate those issues too. In the CFG branch time, I had working FUD implementation on RTL and updated the existing constant propagation and dead code RTL pass of that time. The plan was given up in favor of midlevel RTL idea since it didn't seem to had chance to get to mainline and it was clear we needed some sort of higher level IL. I also got midlevel RTL working with both FUD and/or rewriting SSA form on i386 but I am happy it is gone in favour of tree-SSA. > > I could also start a rant here about how tree-ssa was supposed to make > libcall notes obsolete, how much better things already would be today > even without libcall notes if you compare it to the pre-tree-ssa era, > and how GCC once again chooses irrational conservatism over reaping > the fruits of all the tree-ssa work -- but that's *really* orthogonal > to this thread, so I won't ;-) Yes, it is. I fully agree and I would love to see libcalls going even if it would mean some degradation in side corners. I will try to patch periodic testers to see how much real life difference they make. Honza
4.3.0-rc2 available
GCC 4.3.0 release candidate 2 is now available at: ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.0-RC-20080301/ Please test the tarballs there and report any problems to Bugzilla. CC me on the bugs if you believe they are regressions from previous releases severe enough that they should block the 4.3.0 release.
Re: [PATCH][4.3] Deprecate -ftrapv
On Fri, 29 Feb 2008, Mark Mitchell wrote: > Richard Guenther wrote: > > > The tree optimizers do not recognize +-* of singed integers as > > possibly trapping which causes functions to become const/pure that > > should not and causes 'dead' code to be removed that should not. > > Thanks for the explanations. It seems like tree-ssa should in theory make it > easier to implement this; for example, at the point of gimplification one > could insert checks, and then just let everything else do its thing. I don't > see how libcalls and such would matter in that scheme. I'm not denying that > this is a project, though. I missed once point noticed by Joseph also, that the libgcc implementation uses signed types in the implementation of the trapping arithmetics. Where we of course optimize away the overflow check, so the libgcc routines will never trap. (if it does work in some cases then this would be a missed optimization, so sooner or later it is going to break more) I agree that all the problems can be fixed, but it's been several years that they didn't get fixed and we still advertise that feature as working. > I fully agree that claiming things work when they don't is bad -- we don't > want to lie to the users! But, is the failure mode that we issue run-time > errors when we shouldn't, or that we don't issue run-time errors when we > should? The latter is much less severe than the former. I believe it's both, as some optimizations still can introduce signed overflow, especially in the view of our interesting middle-end sizetype semantics. > I guess you've withdrawn the deprecation request, so maybe this is something > of a moot point now? I certainly agree that we shouldn't let a non-working > feature stand in the way of improvements in 4.4. Yes, removing the libcall notes around these calls will actually improve "workiness" of -ftrapv, so removing libcall notes will not make the situation worse here. Richard.
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Joseph S. Myers wrote: > On Fri, 29 Feb 2008, Mark Mitchell wrote: > > > Thanks for the explanations. It seems like tree-ssa should in theory make > > it > > easier to implement this; for example, at the point of gimplification one > > could insert checks, and then just let everything else do its thing. I > > don't > > see how libcalls and such would matter in that scheme. I'm not denying that > > this is a project, though. > > Obviously you need to keep the functions in libgcc in any event for the > sake of old object code (just as we keep __eprintf there), even if you > make GCC generate inline code rather than libcalls or remove the option > entirely. > > You also need to deal with fold, which will optimize away potentially > trapping computations with -ftrapv and runs before gimplification > (possibly in association with making fold run at gimplification time and > not before). It should not - at least we have various tests in place to ensure fold does not remove traps nor insert traps. Of course this is a very badly tested part of the compiler, so possibly both may happen. Richard.
Re: [PATCH][4.3] Deprecate -ftrapv
On Fri, 29 Feb 2008, Robert Dewar wrote: > Richard Guenther wrote: > > This is a request to depcrecate -ftrapv which has numerous problems > > making it not work as expected since a long time. As nobody seems > > to have the energy to ensure it is working I propose to deprecate it > > for GCC 4.3 to make it possible to remove it during 4.4 (and not > > block removing libcall notes by it). > > Seems a pity, this feature is really needed for Ada, which requires > efficient overflow checking for signed arithmetic, and it seems > useful for C, where signed overflow is undefined, and it would be > nice to enable trapping. > > Right now, Ada uses really horrible double length arithmetic to > do trapping. > > So I would hestitate to deprecate it so quickly Maybe you should organize some resources to fix its implementation then? Richard.
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Guenther wrote: So I would hestitate to deprecate it so quickly Maybe you should organize some resources to fix its implementation then? Richard. It's been on the list for over a decade, it's always harder to find resources to fix performance problems that don't specifically show up as blocking bugs. But we will see what we can do!
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Richard Guenther wrote:
> > You also need to deal with fold, which will optimize away potentially
> > trapping computations with -ftrapv and runs before gimplification
> > (possibly in association with making fold run at gimplification time and
> > not before).
>
> It should not - at least we have various tests in place to ensure fold
> does not remove traps nor insert traps. Of course this is a very badly
> tested part of the compiler, so possibly both may happen.
But arbitrary arithmetic expressions aren't marked as potentially trapping
/ having side-effects with -ftrapv, so cases such as
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
(If we go with converting trapping arithmetic at gimplification time, we
could also avoid doing much folding before gimplification with -ftrapv,
and so maybe avoid needing to treat all arithmetic as having
side-effects.)
--
Joseph S. Myers
[EMAIL PROTECTED]
Re: [PATCH][4.3] Deprecate -ftrapv
On Fri, 29 Feb 2008, Robert Dewar wrote: > > If it were done at gimplification time I imagine something like the libgcc > > code would be used, but with conversions to/from unsigned inserted as > > needed. It would be possible to do optimizations at gimplification time if > > one argument is constant (converting to a range check). > > Well presumably one would want to use target dependent stuff for > detecting overflow where it exists (sticky overflow bits on > power, O flag on PC, trapping add on MIPS etc). On the whole I think you'd want to benefit from tree-ssa optimizing overflow checks where possible (including optimizing them away with VRP), if you hope for a -ftrapv that could be turned on by default for Ada with performance impact as small as possible. That would suggest back ends matching overflow-check patterns (including any that might have been written manually in the user's code) and converting them into such instructions. (Or expand or a late tree-ssa pass doing so.) But you could choose to use built-in functions corresponding to the present libgcc functions to represent overflow-checking operations, rather than expanding inline, and you could make the choice of whether to do so target-dependent. (One possibility is also using such builtins at gimplification time and then optimizing them later in tree-ssa - for example, converting a built-in checked multiplication to a range check if other optimizers make one argument into a constant.) The only targets defining the v insn patterns at present appear to be alpha and pa. -- Joseph S. Myers [EMAIL PROTECTED]
Re: [PATCH][4.3] Deprecate -ftrapv
Joseph S. Myers wrote:
But arbitrary arithmetic expressions aren't marked as potentially trapping
/ having side-effects with -ftrapv, so cases such as
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Interestingly enough, Ada semantics allow the overflow in this case. The
rule in Ada is that if an arithmetic operation overflows, it must either
raise an exception or yield the correct value. Now if you say:
A := B + C;
Then even if you allow an overflowed value for B+C it will be caught
by the normal required range check on the assignment to A, so this rule
is really only relevant for intermediate results. A canonical example
where this rule is likely to be useful is
A := B * C / D;
where it is fine to do a double length multiply followed by a division
that brings the result back in range, even if B*C is out of range.
Given that there are no predefined semantics requiring exceptions in
C, it would not be terrible to have the same semantics in C if there
are some cases where this is unavoidable (I agree it would be preferable
to avoid these kinds of "optimizations", even in Ada, it's probably
cleaner to catch the intermediate overflow. It's hard to believe the
performance degradation is significant, and if you are really concerned
about this in Ada, you can turn off checks (locally or globally).
(If we go with converting trapping arithmetic at gimplification time, we
could also avoid doing much folding before gimplification with -ftrapv,
and so maybe avoid needing to treat all arithmetic as having
side-effects.)
Sounds better if it works
Re: birthpoints in rtl.
By the way, I still don't understand how birth points would work. Can someone give an example of what the insn stream would look like with birth points, and what the DU/UD chains would look like? With a big IIUC, and using a high-level IR for simplicity if (a < 5) goto BB1; else goto BB2; BB1: b = 3; goto BB3; BB2: b = c; goto BB3; BB3: return b * b; DF info for b: insn has def D1 insn has def D2 insn has use U1 (use-def chain [D1,D2]) and use U2 (use-def chain [D1,D2]) becomes if (a < 5) goto BB1; else goto BB2; BB1: b = 3; goto BB2; BB2: b = c; goto BB3; BB3: b = b; return b * b; DF info for b: insnhas def D1 insnhas def D2 birthpoint has use U1 (use-def chain [D1,D2]) and def D3 insnhas use U2 (use-def chain [D3]) and use U3 (use-def chain [D3]) Basically the only non-singleton UD chains are for a birthpoint's RHS, and the UD chains of birthpoints correspond to PHI operands. The singleton UD chains correspond to subscripted SSA variables. I think this is isomorphic to FUD chains. Paolo
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
> > > You also need to deal with fold, which will optimize away potentially
> > > trapping computations with -ftrapv and runs before gimplification
> > > (possibly in association with making fold run at gimplification time and
> > > not before).
> >
> > It should not - at least we have various tests in place to ensure fold
> > does not remove traps nor insert traps. Of course this is a very badly
> > tested part of the compiler, so possibly both may happen.
>
> But arbitrary arithmetic expressions aren't marked as potentially trapping
> / having side-effects with -ftrapv, so cases such as
>
> int f(int a, int b) { return 0 * (a + b); }
>
> get the potentially trapping arithmetic folded away. If -ftrapv is to
> have properly defined semantics, those must include trapping if (a + b)
> overflows in the above code.
Sure, the only clean way to do this is to introduce new tree codes for
trapping arithmetic. Then the usual mechanisms of omit_one_operand
and friends like tree_could_trap_p can work. VRP can for example then
optimize trapping codes to non-trapping codes.
Richard.
Re: birthpoints in rtl.
Diego Novillo wrote: On 2/29/08 7:04 PM, Steven Bosscher wrote: I am not sure what would happen if GCC would start using FUD chains. Is it like in SSA that every register is assigned only once? But this would only affect the UD chains built by the DF code. Yes, that's what I meant by "no subscripts" (see also my other message re. birthpoints). Instead of subscripting variables you have multiple defs for each variable. End each def is obviously assigned only once, and each use in the IL stream except for phis has only one reaching def. You do not necessarily need to think of subscripts, though they are a clean notation for singleton UD chains. Paolo
Re: birthpoints in rtl.
On 3/1/08 8:50 AM, Paolo Bonzini wrote: Yes, that's what I meant by "no subscripts" (see also my other message re. birthpoints). Instead of subscripting variables you have multiple defs for each variable. End each def is obviously assigned only once, and each use in the IL stream except for phis has only one reaching def. Ah, sure, the subscripts in this case become a notational convenience. The DF objects are all linked in the web. Diego.
Re: [PATCH][4.3] Deprecate -ftrapv
Seems a pity, this feature is really needed for Ada, which requires efficient overflow checking for signed arithmetic, and it seems useful for C, where signed overflow is undefined, and it would be nice to enable trapping. Right now, Ada uses really horrible double length arithmetic to do trapping. It's not the only way to do it though, and it's best to reimplement -ftrapv in terms of GIMPLE. I'm for deprecating -ftrapv and reimplementing it. I could mentor a GSOC project for reimplementation of -ftrapv. Paolo
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Kenner wrote: Clearly. My point was that Ada doesn't need a *broken* -ftrapv. So if there's no hope of fixing it, we might as well deprecate it. Sure, but right now we have the start of a constructive discussion of how to fix it, so the best thing would be to contribute positively to that and see where it gets us :-) No one needs a broken anything, but we have to be careful about deprecating things just because they are broken! We have to be really sure that there's no hope of fixing it. In this case, the feature would be very useful in debugging C (especially given GCC's aggressive use of the undefinedness of arithmetic overflow in C, it would definitely be nice to be able to test at -O0 -ftrapv and have this find overflows).
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Robert Dewar wrote:
> Joseph S. Myers wrote:
>
> > But arbitrary arithmetic expressions aren't marked as potentially trapping /
> > having side-effects with -ftrapv, so cases such as
> >
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to have
> > properly defined semantics, those must include trapping if (a + b) overflows
> > in the above code.
>
> Interestingly enough, Ada semantics allow the overflow in this case. The
> rule in Ada is that if an arithmetic operation overflows, it must either
> raise an exception or yield the correct value. Now if you say:
>
>A := B + C;
>
> Then even if you allow an overflowed value for B+C it will be caught
> by the normal required range check on the assignment to A, so this rule
> is really only relevant for intermediate results. A canonical example
> where this rule is likely to be useful is
>
>A := B * C / D;
>
> where it is fine to do a double length multiply followed by a division
> that brings the result back in range, even if B*C is out of range.
IMHO this semantics asks for the frontend to implement the overflow
check. Does the above mean that Ada does intermediate arithmetics
in wider types? I don't see how you could catch the B + C case
otherwise (assuming the range check for the assignment to A covers
all of As range of valid values).
Richard.
Re: [PATCH][4.3] Deprecate -ftrapv
Paolo Bonzini wrote: Seems a pity, this feature is really needed for Ada, which requires efficient overflow checking for signed arithmetic, and it seems useful for C, where signed overflow is undefined, and it would be nice to enable trapping. Right now, Ada uses really horrible double length arithmetic to do trapping. It's not the only way to do it though, and it's best to reimplement -ftrapv in terms of GIMPLE. Right ... from Ada's point of view, it is of course only of limited value to have an implementation of -ftrapv that is equally horrible :-) I'm for deprecating -ftrapv and reimplementing it. I could mentor a GSOC project for reimplementation of -ftrapv. Perhaps if the current implementation is too broken, that might be the most constructive approach ... Paolo
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, Mar 1, 2008 at 2:57 PM, Robert Dewar <[EMAIL PROTECTED]> wrote: > Paolo Bonzini wrote: > >> Seems a pity, this feature is really needed for Ada, which requires > >> efficient overflow checking for signed arithmetic, and it seems > >> useful for C, where signed overflow is undefined, and it would be > >> nice to enable trapping. > >> > >> Right now, Ada uses really horrible double length arithmetic to > >> do trapping. > > > > It's not the only way to do it though, and it's best to reimplement > > -ftrapv in terms of GIMPLE. > > Right ... from Ada's point of view, it is of course only of limited > value to have an implementation of -ftrapv that is equally horrible :-) > > > > > I'm for deprecating -ftrapv and reimplementing it. I could mentor a > > GSOC project for reimplementation of -ftrapv. > > Perhaps if the current implementation is too broken, that might be > the most constructive approach ... I agree. Richard.
Re: birthpoints in rtl.
On 2/29/08 10:01 PM, Kenneth Zadeck wrote: it is more productive to spend the cycles getting rid of the libcalls rather than figuring out the edge cases. as steven implied, we have been on the verge of getting rid of them for years and just have just not fixed the last reason. The amount of time that we spent in 4.3 fixing the last two libcall bugs could have been much better spent just ditching them. I think both problems are orthogonal. One way of modeling libcalls would be stringing all the insns in the libcall sequence with a single DF object that's defined and used by all the insns in the sequence. Sure, getting rid of libcalls will make things easier, but setting up FUD chains on DF is needed for sparseness. In fact, what you describe as birthpoints are almost exactly FUD chains. Implementing them over the DF structures should not really be complicated at all: - DF already has DEF and USE objects, these are similar to the memory operands in GIMPLE. - DF already links USE and DEF objects. It just does it in a simplistic way, creating dense UD chains. All you have to do is factor them out at dominance frontiers. The birthpoint idea is exactly the same as a PHI node. A factoring device that lets you remove superfluous UD links. subcall writes are not total kills and we are careful to model them correctly when we see them individually. The question that i have is when you see a join where one arm modifies the the first byte and the other arm modifies the 4th byte. there is no store to the second and third bytes and no way in rtl to exactly model it as a single move. Two options: - Conservatively treat partial references as full references. So, two different subreg references with the same parent are considered references to the parent. This is how we model references to arrays in gimple. You will also need to model DEF-DEF links to avoid DCEing partial stores. - Create subreg objects in the DF data structure, similar to the SFTs in gimple. Associate an object to each subreg. References to the subregs are references to these SFTs and references to the parent register create one reference per SFT in its children list. I would go for option #2 as it models subregs separately. As opposed to gimple, the list of SFTs per register will not be long. Diego.
Re: birthpoints in rtl.
On 3/1/08 5:13 AM, Jan Hubicka wrote: while I am with Diego that would preffer PHI nodes on side especially in FUD chain where rest of your SSA is on side too. But if we go with the extra instruction scheme, I think you are much better to use RTL USE instruction. The moves are generated by target machinery and can do funny things, like clobbering flags or whatever. USEs are transparent this way. One step at a time, though. Changing the current dense UD chains in DF should be fairly easy. However, going to a rewriting SSA form in RTL is going to be more involved. We may even need to do the same split we do in GIMPLE and have both a rewriting form and a FUD-chain form. Diego.
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Guenther wrote: IMHO this semantics asks for the frontend to implement the overflow check. Does the above mean that Ada does intermediate arithmetics in wider types? I don't see how you could catch the B + C case otherwise (assuming the range check for the assignment to A covers all of As range of valid values). So here's exactly what happens now in Ada 1. If -gnato is not set (no overflow checking) In this case, the situation is exactly the same as C, and the front end ignores the possibility of overflow. The official Ada semantics are that if you suppress overflow checks, and an overflow occurs (intermediate or otherwise), the executino is erroneous (undefined in C-speak). So Ada with checks off is in all respects identical to C semantics. No problem. 2. If -gnato is set (overflow checking on) In this case, the front end does generate all overflow checks (there is an example of this earlier in the thread from me, which shows the original Ada source, the pseudo-Ada expanded source from the front end, and the final assembly. In this mode, we don't bother trying to allow cases like (B*C)/D, if the B*C overflows it will raise an exception. The approach is to do double length arithmetic and range check the result, unless we are at 64-bits, in which case we call library routines that do the arithmetic overflow checking. Note that in Ada, you can often avoid one or both ends of the range check, e.g. type R is integer range 1 .. 10; RV : R; R := R + 1; no need for double length arithmetic here, you just check that the result is not greater than 10. Now of course what we would hope for is a back end -ftrapv mode that at least in some cases on some targets is more efficient, e.g. in -gnatOs mode at least on the ia32, we would generate INTO instructions, and on the MIPS trapping adds. Richard.
Re: [PATCH][4.3] Deprecate -ftrapv
> int f(int a, int b) { return 0 * (a + b); }
>
> get the potentially trapping arithmetic folded away. If -ftrapv is to
> have properly defined semantics, those must include trapping if (a + b)
> overflows in the above code.
Why? Is there any language that requires such semantics?
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Richard Kenner wrote:
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to
> > have properly defined semantics, those must include trapping if (a + b)
> > overflows in the above code.
>
> Why? Is there any language that requires such semantics?
Not exactly. -ftrapv semantics are defined _very_ sparsely.
"This option generates traps for signed overflow on addition,
subtraction and multiplication operations."
it doesn't say if it preserves traps on dead code, so Josephs
interpretation is one possible valid one.
Richard.
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semantics?
Not C, since trapping overflow is just one facet of "undefined behavior"
and we can define that facet as we wish! :-)
Paolo
Re: birthpoints in rtl.
On Sat, Mar 1, 2008 at 3:01 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 2/29/08 10:01 PM, Kenneth Zadeck wrote: > > > it is more productive to spend the cycles getting rid of the libcalls > > rather than figuring out the edge cases. as steven implied, we have > > been on the verge of getting rid of them for years and just have just > > not fixed the last reason. The amount of time that we spent in 4.3 > > fixing the last two libcall bugs could have been much better spent just > > ditching them. > > I think both problems are orthogonal. One way of modeling libcalls > would be stringing all the insns in the libcall sequence with a single > DF object that's defined and used by all the insns in the sequence. And there's another special-case treatment for libcalls. On top of REG_LIBCALL/REG_RETVAL/REG_LIBCALL_ID. This is bug prone. For GCC 4.3 alone, I've fixed half a dozen libcall blocks related bugs, and others have fixed at least as many. Not to mention all the extra work they caused for the people working on the df branch. They were a major headache. You're right technically: The problems are orthogonal in the sense that it *can* be done. But I, for one, would not even start working on RTL-FUD before libcall blocks are dead and gone. Just because I wouldn't want to handle it as a special case that Gr. Steven
Re: [PATCH][4.3] Deprecate -ftrapv
> No one needs a broken anything, Not necessarily and perhaps not in this case. Let's suppose there was an implementation of -ftrapv that did trap, but only about 80% of the time. Such an implementation would nevertheless be useful in C since there overflow is not a required feature of the language, but merely useful, and you could well argue that it's better to catch 80% of the overflows than 0%. But for Ada, it's a language requirement that we catch *all* overflows, so an implementation that was 80% correct there isn't useful at all since an alternate one is required.
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semantics?
For C, the above fragment of code is undefined if a+b overflows. Since
the purpose of -ftrapv for C, it is desirable that it catch this case
as well, since gcc might otherwise do peculiar things, or on some other
compiler you might get other peculiar things or a trap etc.
Obviously the C language does not require this, since it does not
require -ftrapv in the first place, that's just a handy addition
that we make to gcc, and we get to decide what's most useful.
For Ada, as I discussed in my last note, max performance says
you can ignore the check here, but generally for max performance
you turn off checks anyway. It is certainly allowed to optimize
this to zero ..
in fact there are two rules that let you optimize the above to
zero in Ada.
1. The rule about correct results for intermediate computations
being OK even if they are out of range.
2. The rule about not doing operations whose only purpose is
to see if they raise a predfined exception.
Certainly it is acceptable to do the check in the Ada case,
and if you are concerned about writing maximally portable
Ada code, desirable.
Re: [PATCH][4.3] Deprecate -ftrapv
> IMHO this semantics asks for the frontend to implement the overflow > check. Does the above mean that Ada does intermediate arithmetics > in wider types? No, it means that it must *either* do the arithmetic in wider types *or* use arithmetic in the narrower types that checks for overflow.
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Guenther wrote:
On Sat, 1 Mar 2008, Richard Kenner wrote:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semantics?
Not exactly. -ftrapv semantics are defined _very_ sparsely.
"This option generates traps for signed overflow on addition,
subtraction and multiplication operations."
it doesn't say if it preserves traps on dead code, so Josephs
interpretation is one possible valid one.
And anyway, no point in doing energetic exergesis on vague language
defining an option that has never worked anyway :-)
Part of "fixing" -ftrapv should be to carefully document exactly
what it does/is-intended-to-do (hopefully those are the same :-))
Richard.
Re: birthpoints in rtl.
And there's another special-case treatment for libcalls. On top of REG_LIBCALL/REG_RETVAL/REG_LIBCALL_ID. This is bug prone. For GCC 4.3 alone, I've fixed half a dozen libcall blocks related bugs, and others have fixed at least as many. Not to mention all the extra work they caused for the people working on the df branch. They were a major headache. You're right technically: The problems are orthogonal in the sense that it *can* be done. But I, for one, would not even start working on RTL-FUD before libcall blocks are dead and gone. Just because I wouldn't want to handle it as a special case that BTW if the plan for -ftrapv being discussed in another thread takes shape, that's one less reason for libcall notes. Paolo
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Kenner wrote: No one needs a broken anything, Not necessarily and perhaps not in this case. Let's suppose there was an implementation of -ftrapv that did trap, but only about 80% of the time. Such an implementation would nevertheless be useful in C since there overflow is not a required feature of the language, but merely useful, and you could well argue that it's better to catch 80% of the overflows than 0%. But for Ada, it's a language requirement that we catch *all* overflows, so an implementation that was 80% correct there isn't useful at all since an alternate one is required. Might still be useful as the default behavior if it was significantly more efficient than the complete mechanism, and if in practice the intent was to catch the other 20% over time.
Re: [PATCH][4.3] Deprecate -ftrapv
Well presumably one would want to use target dependent stuff for detecting overflow where it exists (sticky overflow bits on power, O flag on PC, trapping add on MIPS etc). On the whole I think you'd want to benefit from tree-ssa optimizing overflow checks where possible (including optimizing them away with VRP), if you hope for a -ftrapv that could be turned on by default for Ada with performance impact as small as possible. That would suggest back ends matching overflow-check patterns and converting them into such instructions. Yes, fully fully agreed. Paolo
Re: [PATCH][4.3] Deprecate -ftrapv
On Fri, 29 Feb 2008, Robert Dewar wrote: Well presumably one would want to use target dependent stuff for detecting overflow where it exists (sticky overflow bits on power, O flag on PC, trapping add on MIPS etc). In fact, when I wrote the original -ftrapv code, it was for the sole purpose of using the trapping add on mips. On Sat, 1 Mar 2008, Joseph S. Myers wrote: The only targets defining the v insn patterns at present appear to be alpha and pa. Considering the trouble that you get when you try to generate branches in a non-branch expander, we should probably have alternate named patterns to be used in ports to processors that have no conditional trap facility, or where a conditional trap is more expensive than a well predictable conditional branch. We want arithmetic-and-branch-on-overflow patterns for these. One peculiarity of these patterns would be that they would be required to expand into more than one instruction, since the write of the result must not be in the same instruction as the branch due to reload limitations. Thus the overflow condition in CC0 / other flags register / predicate register has to be actually exposed in rtl to show the dependency between arithmetic and branch. We should document this quirk in the description of these named patterns. When the machine independent expander machinery wants to expand a trapping arithmetic operation that has no matching named pattern defined by the port, and there is no conditional trap defined, it can than use the arithmetic-and-branch-on-overflow pattern to branch to an abort call if an overflow occurs. To allow branch inversion to work, we don't need to do anything special if the condition is expressed as a comparison against 0 of a 'integer' flag regsiter or a predicate bit. However, if the condition is in CC0 or a CCmode flags register, we want a way to express the overflow and non-overflow conditions so that reverse_condition or REVERSE_CONDITION can do its work. I see two possibilities here. For simplicity I will describe them here in terms of CC0, although many target ports would actually use a scheduler-exposed flags register with an appropriate CCmode mode. - We could have (overflow CC0 0) and (nooverflow CC0 0), where overflow and nooverflow are two new comparison codes, and the trailing 0 is a dummy argument for the sake of consistency with comparison operators. - We could have (ge CC0 overflow) and (lt CC0 overflow), where overflow is a new one-of-a-kind RTX object.
Re: [PATCH][4.3] Deprecate -ftrapv
I missed once point noticed by Joseph also, that the libgcc implementation uses signed types in the implementation of the trapping arithmetics. Where we of course optimize away the overflow check, so the libgcc routines will never trap. (if it does work in some cases then this would be a missed optimization, so sooner or later it is going to break more) In theory, if -ftrapv worked properly and at the compiler level (no libcalls), the implementation of __addvsi3 could be just return a + b; compiled with -ftrapv itself... Paolo
Re: [PATCH][4.3] Deprecate -ftrapv
Joern Rennecke wrote: Considering the trouble that you get when you try to generate branches in a non-branch expander, we should probably have alternate named patterns to be used in ports to processors that have no conditional trap facility, or where a conditional trap is more expensive than a well predictable conditional branch. Note that even if this is the case (conditional trap more expensive), it may be appropriate in -Os mode. A one-byte INTO instruction after every add takes less space than conditional jump to trapping code. Of course it is always interesting that less code = less i-cache pressure, and so you get something back for that in practice, YMMV.
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 2008-03-01 at 09:05 -0500, Robert Dewar wrote: > Note that in Ada, you can often avoid one or both ends of > the range check, e.g. > > type R is integer range 1 .. 10; > > RV : R; > > R := R + 1; > > no need for double length arithmetic here, you just check that the > result is not greater than 10. Isn't that a job for VRP? I remember long discussions about VRP and Ada (I don't remenber the conclusion though), if something is done to replace trapv it has to taken that into account. Laurent
new regression on 4.3.0 branch
Not a primary target, but still... Results for 4.3.0 20080301 (prerelease) [gcc-4_3-branch revision 132798] (GCC) testsuite on m32c-unknown-elf --- Start of forwarded message --- gcc result changes... Multilib: m32c-sim/-mcpu=m32c PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 -fomit-frame-pointer PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 -fomit-frame-pointer -funroll-loops PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 -g g++ result changes... LAST_UPDATED: Sat Mar 1 07:02:21 UTC 2008 (revision 132798) Target is m32c-unknown-elf Host is i686-pc-linux-gnu --- End of forwarded message ---
Re: new regression on 4.3.0 branch
On Sat, Mar 1, 2008 at 4:48 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > > Not a primary target, but still... > > Results for 4.3.0 20080301 (prerelease) [gcc-4_3-branch revision 132798] > (GCC) testsuite on m32c-unknown-elf > > --- Start of forwarded message --- > gcc result changes... > > Multilib: m32c-sim/-mcpu=m32c > PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 > -fomit-frame-pointer > PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 > -fomit-frame-pointer -funroll-loops > PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 > -fomit-frame-pointer -funroll-all-loops -finline-functions > PASS-FAIL: gcc.c-torture/execute/980707-1.c execution, -O3 -g > > g++ result changes... > > LAST_UPDATED: Sat Mar 1 07:02:21 UTC 2008 (revision 132798) > > Target is m32c-unknown-elf > Host is i686-pc-linux-gnu Can you pin-point the patch that caused this and investigate what is going wrong? Thanks, Richard.
Re: new regression on 4.3.0 branch
> Can you pin-point the patch that caused this and investigate what is > going wrong? Sure. It was some time yesterday at least (that script runs every night), but I'll try to narrow it down further.
Re: Excess registers pushed - regs_ever_live not right way?
I'm am still struggling with a good solution that avoids unneeded saves of parameter registers. To solve problem all I need to know are the registers actually used for parameters. Since the caller assumes all of these are clobbered by callee - they should never need to be saved. DF_REG_DEF_COUNT is showing 1 artificial def for all POTENTIAL parameter registers - not just the ones that are really used (since it uses target FUNCTION_ARG_REGNO_P to get parameter registers) So the DF artificial defs are useless in trying to find real parameter registers. That seem to require going over all DF chains to work out which registers are externally defined. DF does not solve problem for me. There has got to be an easier way of finding parameter registers used by function. Ideas? Seongbae Park (박성배, 朴成培) wrote: > You can use DF_REG_DEF_COUNT() - if this is indeed a parameter register, > there should be only one def (artificial def) or no def at all. > Or if you want to see all defs for the reg, > follow DF_REG_DEF_CHAIN(). > > Seongbae > > On Wed, Feb 27, 2008 at 6:03 PM, Andrew Hutchinson > <[EMAIL PROTECTED]> wrote: > >> Register contains parameter that is passed to function. This register >> is not part of call used set. >> >> If this type of register were modified by function, then it would be >> saved by function. >> >> If this register is not modified by function, it should not be saved. >> This is true even if function is not a leaf function (as same register >> would be preserved by deeper calls) >> >> >> Andy >> >> >> >> >> >> Seongbae Park (박성배, 朴成培) wrote: >> > On Wed, Feb 27, 2008 at 5:16 PM, Andrew Hutchinson >> > <[EMAIL PROTECTED]> wrote: >> > >> >> Register saves by prolog (pushes) are typically made with reference to >> >> "df_regs_ever_live_p()" or "regs_ever_live. "|| >> >> >> >> If my understanding is correct, these calls reflect register USEs and >> >> not register DEFs. So if register is used in a function, but not >> >> otherwise changed, it will get pushed unnecessarily on stack by prolog. >> >> >> > >> > This implies that the register is either a global register >> > or a parameter register, in either case it won't be saved/restored >> > as callee save. >> > What kind of a register is it and how com there's only use of it in a >> function >> > but it's not a global ? >> > >> > Seongbae >> > >> > >> >> > > > >
Bootstrap failure building libobjc fixed
Hello all, apologies for causing a bootstrap failure when building libobjc due to my patch for PR 35063 (r132800). As of r132802, I believe this issue is now fixed. Big thanks to Jerry DeLisle for helping out with the fix. -- Janne Blomqvist
Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP
hello sorry after 2 more success with gcc build this night ,i have not succeeded to reproduce the error "Ada.Calendar is not a predefined library unit" the difficult with mingw, there are no dependance packages, only overwrite binaries manualy and flex,bison and deps libs are not natively present for gcc build. now i'm restart from scrach, delete all my mingw env, write each action i do ... cheers julien On Fri, 29 Feb 2008 19:33:27 +0100 (CET), "Ralf Wildenhues" <[EMAIL PROTECTED]> said: > * dju wrote on Fri, Feb 29, 2008 at 03:19:45AM CET: > > platform : microsoft windowsXP(32) sp2 intel core duo > > > > i managed to build gcc-4.2.3 using MinGW-5.1.3 candidate with gcc 3.4.5 > > and binutils-2.17.50 in MSYS-1.0.10 > > [...] > > > > > > only one change in gcc-4.2.3 source : > > > in /work/src/gcc-4.2.3/libada/Makefile.in line 30 > > > [EMAIL PROTECTED]@ > > > by > > > LN_S=cp > > > > Why was that change necessary? Can you post the error that you got > > without it? > > > > Thanks, > > Ralf --- dju - ~-=. (__) ..m00...m00...m000.. (__) . (__) .=-~ - ~-=.. (@@) .. (OO) ... (@@) ..=-~ - ~-=... \/ \/ ..Cows need love too !!.. \/ ...=-~
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Richard Guenther wrote:
> > But arbitrary arithmetic expressions aren't marked as potentially trapping
> > / having side-effects with -ftrapv, so cases such as
> >
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to
> > have properly defined semantics, those must include trapping if (a + b)
> > overflows in the above code.
>
> Sure, the only clean way to do this is to introduce new tree codes for
> trapping arithmetic. Then the usual mechanisms of omit_one_operand
> and friends like tree_could_trap_p can work. VRP can for example then
> optimize trapping codes to non-trapping codes.
Yes, new tree codes (or flags on existing ones) to distinguish trapping /
wrapping / undefined arithmetic are a clean approach. Then -ftrapv and
-fwrapv would be used only when front ends build trees, and not
subsequently to affect the semantics of given GIMPLE trees. It might be
useful for optimizers to understand two expressions being equivalent in
one direction only (if you have an overflow-undefined version of an
expression, and an overflow-wrapping or overflow-trapping version, you can
just evaluate the latter version and use the result for the
overflow-undefined version, but not vice versa).
Depending on the target (whether it has instruction patterns for these
operations), and on other flags such as -Os, and on the particular types
involved, the trapping codes might then get converted to wrapping codes
plus inline checks at some point through tree-ssa (especially if one
argument is a constant), or might make it all the way to expand. If given
bit-field types, Ada types with special ranges, etc. (types not having the
full range of their mode, or checked arithmetic on char or short where we
don't provide libgcc functions because such arithmetic won't arise in C
because of promotions), inline checks would definitely be needed since
there wouldn't be suitable libgcc functions. (The inline checks for
special cases could simply be: do the checked arithmetic in the full width
of the mode where there is a libgcc function, then add inline range checks
on the result for the exact range desired.)
So far, the LTO work has concentrated on proving the concept by allowing
real programs such as GCC and SPEC (but in a single language and built
with a single set of options) to be built and linked using the LTO
infrastructure. (In the earlier days there was also all the work on
reducing memory usage; unfortunately most of the miscellaneous tree
trimming changes from that are still languishing on the oldlto branch
without having been merged to trunk, despite many having been preapproved
to go on trunk after 4.3 branched.) To complete LTO it will be necessary
to change all implicit GIMPLE semantics (in global variables or langhooks)
into explicit semantics directly encoded in the GIMPLE - including
flag_trapv and flag_wrapv among many others, but I don't know when that
part of the LTO work might happen.
--
Joseph S. Myers
[EMAIL PROTECTED]
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Richard Kenner wrote:
> > int f(int a, int b) { return 0 * (a + b); }
> >
> > get the potentially trapping arithmetic folded away. If -ftrapv is to
> > have properly defined semantics, those must include trapping if (a + b)
> > overflows in the above code.
>
> Why? Is there any language that requires such semantics?
They are the natural interpretation of -ftrapv that's simplest to describe
in terms of the abstract machine of the C standard: any signed integer
arithmetic overflow in the abstract machine (and maybe integer division by
0, signed or unsigned) should be guaranteed to yield a trap at runtime.
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02026.html
http://gcc.gnu.org/ml/gcc/2007-09/msg00399.html
describe my understanding of these natural semantics.
--
Joseph S. Myers
[EMAIL PROTECTED]
Re: [PATCH][4.3] Deprecate -ftrapv
* Robert Dewar: > So here's exactly what happens now in Ada > > 1. If -gnato is not set (no overflow checking) > > In this case, the situation is exactly the same as C, and the front end > ignores the possibility of overflow. It's C in -fwrapv mode, isn't it? (Otherwise, you can't really get the other constraint checks to work, including bounds checking for array access.) > The official Ada semantics are that if you suppress overflow checks, > and an overflow occurs (intermediate or otherwise), the executino is > erroneous (undefined in C-speak). So Ada with checks off is in all > respects identical to C semantics. No problem. Uh-oh, this is really, really surprising.
Re: [PATCH][4.3] Deprecate -ftrapv
* Richard Kenner:
>> int f(int a, int b) { return 0 * (a + b); }
>>
>> get the potentially trapping arithmetic folded away. If -ftrapv is to
>> have properly defined semantics, those must include trapping if (a + b)
>> overflows in the above code.
>
> Why? Is there any language that requires such semantics?
Standard ML. I don't think there is a GCC front end (and it's not
likely that one will be feasible, at least until GCC supports a fitting
garbage collector).
Re: [PATCH][4.3] Deprecate -ftrapv
* Florian Weimer:
> * Richard Kenner:
>
>>> int f(int a, int b) { return 0 * (a + b); }
>>>
>>> get the potentially trapping arithmetic folded away. If -ftrapv is to
>>> have properly defined semantics, those must include trapping if (a + b)
>>> overflows in the above code.
>>
>> Why? Is there any language that requires such semantics?
>
> Standard ML. I don't think there is a GCC front end (and it's not
> likely that one will be feasible, at least until GCC supports a fitting
> garbage collector).
Oh, and a less obscure example is C# (Section 14.5.13 in ECMA-334, 4th
edition, June 2006).
Re: [PATCH][4.3] Deprecate -ftrapv
Florian Weimer wrote: * Robert Dewar: So here's exactly what happens now in Ada 1. If -gnato is not set (no overflow checking) In this case, the situation is exactly the same as C, and the front end ignores the possibility of overflow. It's C in -fwrapv mode, isn't it? (Otherwise, you can't really get the other constraint checks to work, including bounds checking for array access.) No, it is exactly C, if an arithmetic operation causes overflow and you do not have -gnato set, and overflow occurs, the program execution is erroneous. I reread the last para above more than once but cannot guess what you are getting. The official Ada semantics are that if you suppress overflow checks, and an overflow occurs (intermediate or otherwise), the executino is erroneous (undefined in C-speak). So Ada with checks off is in all respects identical to C semantics. No problem. Uh-oh, this is really, really surprising. Why is it surprising, if you suppress overflow checks you are saying that overflow does not occur, just as you say this for *any* C program. I don't understand the surprise or the concern here, can you elucidate? If you think your program might have integer overflow, and you want to check for this, you must use -gnato.
Re: [PATCH][4.3] Deprecate -ftrapv
Florian Weimer wrote:
* Richard Kenner:
int f(int a, int b) { return 0 * (a + b); }
get the potentially trapping arithmetic folded away. If -ftrapv is to
have properly defined semantics, those must include trapping if (a + b)
overflows in the above code.
Why? Is there any language that requires such semantics?
Standard ML. I don't think there is a GCC front end (and it's not
likely that one will be feasible, at least until GCC supports a fitting
garbage collector).
Why is it a GCC issue to support a GC for ML, I don't get it ...
Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin
Mark, While I don't see any particular differences in how gcc 4.3 branch links its shared libraries with or without r131198 applied, I do notice that it causes the xgcc created to be linked against the system libgcc. Without r131198, only the xgcc in stage1-gcc is linked to the system libgcc. With r131198, all copies of xgcc created in the build are linked to the system libgcc instead of that from the build. Do we have any other targets that link gcc (and xgcc) with the shared libgcc? I see that i386 and x86_64 linux creates a gcc (and xgcc) linked to the static libgcc. If any other targets use a shared libgcc for gcc (and xgcc) they may be broken as well. Jack On Fri, Feb 29, 2008 at 06:12:05PM -0800, Mark Mitchell wrote: > Jack Howarth wrote: >> Mark, >>One other question. Does the bug fixed by the offending patch... >> >> http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01010.html >> >> ...merit breaking even a secondary target? Wouldn't it be better >> to regress that patch out for gcc 4.3.0 (to be reintroduced in >> gcc 4.3.1 when the problems that it causes for darwin are solved)? > > I think it's important, since, IIUC, it improves our ability to test on all > platforms. But, I certainly encourage you to figure out why it breaks > Darwin and work out how to fix it! > > -- > Mark Mitchell > CodeSourcery > [EMAIL PROTECTED] > (650) 331-3385 x713
Re: [PATCH][4.3] Deprecate -ftrapv
* Robert Dewar: > Florian Weimer wrote: >> * Robert Dewar: >> >>> So here's exactly what happens now in Ada >>> >>> 1. If -gnato is not set (no overflow checking) >>> >>> In this case, the situation is exactly the same as C, and the front end >>> ignores the possibility of overflow. >> >> It's C in -fwrapv mode, isn't it? (Otherwise, you can't really get the >> other constraint checks to work, including bounds checking for array >> access.) > > No, it is exactly C, if an arithmetic operation causes overflow > and you do not have -gnato set, and overflow occurs, the program > execution is erroneous. I reread the last para above more than once > but cannot guess what you are getting. Are we talking about the Ada semantics or GNAT without -gnato? In the latter case, the documentation disagrees with you: The reason that we distinguish overflow checking from other kinds of range constraint checking is that a failure of an overflow check can generate an incorrect value, but cannot cause erroneous behavior. This is unlike the situation with a constraint check on an array subscript, where failure to perform the check can result in random memory description, or the range check on a case statement, where failure to perform the check can cause a wild jump. And to avoid erroneous execution on integer overflow, I think you have to specify the equivalent -fwrapv (otherwise, the middle end might do nasty things to your range checks). > Why is it surprising, if you suppress overflow checks you are saying > that overflow does not occur, just as you say this for *any* C > program. > > I don't understand the surprise or the concern here, can you > elucidate? The documentation says something else, that's why it's surprising. 8-)
Re: [PATCH][4.3] Deprecate -ftrapv
* Robert Dewar: >> Standard ML. I don't think there is a GCC front end (and it's not >> likely that one will be feasible, at least until GCC supports a fitting >> garbage collector). > > Why is it a GCC issue to support a GC for ML, I don't get it ... ML programs are mostly functional and allocate lots of small objects with very short lifespans. Without GC support in GCC, you're basically stuck with some sort of conservative collector. And that is unlikely to result in acceptable throughput.
Re: [PATCH][4.3] Deprecate -ftrapv
Florian Weimer wrote: Are we talking about the Ada semantics or GNAT without -gnato? In the latter case, the documentation disagrees with you: The reason that we distinguish overflow checking from other kinds of range constraint checking is that a failure of an overflow check can generate an incorrect value, but cannot cause erroneous behavior. This is unlike the situation with a constraint check on an array subscript, where failure to perform the check can result in random memory description, or the range check on a case statement, where failure to perform the check can cause a wild jump. And to avoid erroneous execution on integer overflow, I think you have to specify the equivalent -fwrapv (otherwise, the middle end might do nasty things to your range checks). The documentation needs minor adjustment, I will remove the word erroneous, and rephrase it as: The reason that we distinguish overflow checking from other kinds of constraint checking is that a failure of an overflow check, unlike for example the failure of a range check, can result in an incorrect value, but cannot cause random memory destruction (like an out of range subscript), or a wild jump (from an out of range case value). Overflow checking is also quite expensive in time and space, since in general it requires the use of double length arithmetic.
Re: [PATCH][4.3] Deprecate -ftrapv
Florian Weimer wrote: * Robert Dewar: Standard ML. I don't think there is a GCC front end (and it's not likely that one will be feasible, at least until GCC supports a fitting garbage collector). Why is it a GCC issue to support a GC for ML, I don't get it ... ML programs are mostly functional and allocate lots of small objects with very short lifespans. Without GC support in GCC, you're basically stuck with some sort of conservative collector. And that is unlikely to result in acceptable throughput. Not clear what "in GCC" means here, seems to me you could perfectly well handle this with a combination of front end stuff and run time routines.
Re: [PATCH][4.3] Deprecate -ftrapv
Robert Dewar wrote: The reason that we distinguish overflow checking from other kinds of constraint checking is that a failure of an overflow check, unlike for example the failure of a range check, can result in an incorrect value, but cannot cause random memory destruction (like an out of range subscript), or a wild jump (from an out of range case value). Overflow checking is also quite expensive in time and space, since in general it requires the use of double length arithmetic. Just to be clear, although theoretically in Ada semantics, the program execution is erroneous if an overflow check fails and -gnato is off, but in practice with GNAT, the range of possible effects does not include memory destruction or wild jumps. Similarly with GCC and C, the failure of an overflow check is theoretically undefined and unlimited (just like erroneous in Ada), but in practice the back end will not turn an overflow into unexpected memory destruction or a wild jump, at least not often :-)
Re: Excess registers pushed - regs_ever_live not right way?
2008/3/1 Andrew Hutchinson <[EMAIL PROTECTED]>: > I'm am still struggling with a good solution that avoids unneeded saves > of parameter registers. > > To solve problem all I need to know are the registers actually used for > parameters. Since the caller assumes all of these are clobbered by > callee - they should never need to be saved. I'm totally confused what is the problem here. I thought you were seeing extra callee-save register save/restore in prologue, but now it sounds like you're seeing extra caller-save register save/restore. Which one are you trying to solve, and what kind of target is this ? > DF_REG_DEF_COUNT is showing 1 artificial def for all POTENTIAL parameter > registers - not just the ones that are really used (since it uses target > FUNCTION_ARG_REGNO_P to get parameter registers) You said you wanted to know if there's a def of a register within a function. For an incoming parameter, there will be one artificial def, and if there's no other def, it means there's no real def of the register within the function. > So the DF artificial defs are useless in trying to find real parameter > registers. I don't understand what you mean by this. What do you mean by "real parameter register" ? > That seem to require going over all DF chains to work out which > registers are externally defined. DF does not solve problem for me. What do you mean by "externally defined" ? DF may not solve the problem for you, but now I'm completely lost on what your problem is. > There has got to be an easier way of finding parameter registers used by > function. If you want to find all the uses (use as in reading a register but not writing to it), you should look at USE chain, not DEF chain, naturally. Seongbae
Re: [PATCH][4.3] Deprecate -ftrapv
C: integer overflow undefined, checking desirable at least for debugging purposes. I think latest Fortran is same as C, can someone confirm? Yes, it is. Overflow undefined and no checking required; I think very few Fortran users actually use (or would use) checking on signed overflow. FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: Excess registers pushed - regs_ever_live not right way?
Sorry terminology is fighting language! by parameter - I mean argument registers - also a stray "use" may have crept in. Original problem : prolog is saving "live" registers that are not "call used" following normal gcc methods. But in AVR target this will include some argument registers - as not all argument registers are "call used". Function Argument registers do not need to be saved (since callee assumes they are always clobbered). To solve problem all I need to know is what registers really do contain function arguments. Then I can omit these from prolog saves and fix bug. DF does not tell me what registers contain function arguments. It marks all possible arguments registers with artificial def (which are known anyway). Unfortunately it is not as simple as counting defs as I had hoped. So I would then have to go through all chains for "possible" arguments to see if that external def is actually used inside function. This can not be shortcut by looking for just any use - or multiple defs as real argument registers can be re-use inside function. Is this conclusion correct? Andy Seongbae Park (박성배, 朴成培) wrote: 2008/3/1 Andrew Hutchinson <[EMAIL PROTECTED]>: I'm am still struggling with a good solution that avoids unneeded saves of parameter registers. To solve problem all I need to know are the registers actually used for parameters. Since the caller assumes all of these are clobbered by callee - they should never need to be saved. I'm totally confused what is the problem here. I thought you were seeing extra callee-save register save/restore in prologue, but now it sounds like you're seeing extra caller-save register save/restore. Which one are you trying to solve, and what kind of target is this ? DF_REG_DEF_COUNT is showing 1 artificial def for all POTENTIAL parameter registers - not just the ones that are really used (since it uses target FUNCTION_ARG_REGNO_P to get parameter registers) You said you wanted to know if there's a def of a register within a function. For an incoming parameter, there will be one artificial def, and if there's no other def, it means there's no real def of the register within the function. So the DF artificial defs are useless in trying to find real parameter registers. I don't understand what you mean by this. What do you mean by "real parameter register" ? That seem to require going over all DF chains to work out which registers are externally defined. DF does not solve problem for me. What do you mean by "externally defined" ? DF may not solve the problem for you, but now I'm completely lost on what your problem is. There has got to be an easier way of finding parameter registers used by function. If you want to find all the uses (use as in reading a register but not writing to it), you should look at USE chain, not DEF chain, naturally. Seongbae
Re: [PATCH][4.3] Deprecate -ftrapv
FX Coudert wrote: C: integer overflow undefined, checking desirable at least for debugging purposes. I think latest Fortran is same as C, can someone confirm? Yes, it is. Overflow undefined and no checking required; I think very few Fortran users actually use (or would use) checking on signed overflow. But assuming the gcc is playing C-style games, it is probably a useful thing to be able to verify that your code is free of such possibilities. FX
Possible GCC 4.3 driver regression caused by your patch
Hi Carlos and Mark, Your "Relocated compiler should not look in $prefix" patch here: http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html appears to have caused a regression in my GCC 4.3 testing. In summary, there is a small window *during the GCC build itself* where GCC does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is called to build the target libraries, the startfiles in $prefix/lib are not used. Instead, the startfiles from the host's /usr/lib are used which breaks my build. Note that the problem seems to rectify itself once the just-built GCC is installed into $prefix. Here's the scenario: - Native build - i686-pc-linux-gnu - --prefix=/temptools - Glibc already installed in /temptools/lib Compare the following -v output snippets to demonstrate the problem: GCC 4.2.3 $ /temptools/src/gcc-build/./gcc/xgcc -B/temptools/src/gcc-build/./gcc/ dummy.c -v /mnt/sysroot/temptools/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /temptools/lib/ld-linux.so.2 /mnt/sysroot/temptools/bin/../lib/gcc/i686-pc-linux-gnu/4.2.3/../../../crt1.o GCC 4.3.0-RC1 $ /temptools/src/gcc-build/./gcc/xgcc -B/temptools/src/gcc-build/./gcc/ dummy.c -v /temptools/src/gcc-build/./gcc/collect2 --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /temptools/lib/ld-linux.so.2 /usr/lib/crt1.o NOTE - I can try to work around the problem by defining STANDARD_STARTFILE_PREFIX_1 and define STANDARD_STARTFILE_PREFIX_2 to "" in the target headers but then the build fails when linking libgcc_s.so.1. /temptools/i686-pc-linux-gnu/bin/ld: crti.o: No such file: No such file or directory I realize my scenario is slightly non-standard, but nevertheless, I'd be grateful if you could pass comment on whether this is a regression or not. I haven't "relocated" anything. All I've done is try to build a native GCC with --prefix=/temptools which used to work fine. Thanks for any help. Thanks Greg
