This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)*To*: matz at suse dot de*Cc*: ebotcazou at adacore dot com, gcc-patches at gcc dot gnu dot org, iant at google dot com, mark at codesourcery dot com, richard dot guenther at gmail dot com*Date*: Thu, 11 Oct 2007 13:01:49 EDT*Subject*: Re: [PATCH] Fix optimization regression in constant folder*References*: <200709171539.26653.ebotcazou@adacore.com> <200709301801.39718.ebotcazou@adacore.com> <m3r6kf3gyx.fsf@localhost.localdomain> <200710010127.59677.ebotcazou@adacore.com> <m3abr33dbp.fsf@localhost.localdomain> <10710010056.AA15609@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710010325340.23011@wotan.suse.de> <10710010257.AA21585@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710010454060.23011@wotan.suse.de> <10710010344.AA22633@vlsi1.ultra.nyu.edu> <470D0C50.4080506@codesourcery.com> <Pine.LNX.4.64.0710111658530.23011@wotan.suse.de> <10710111536.AA24058@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710111756080.23011@wotan.suse.de> <10710111621.AA25372@vlsi1.ultra.nyu.edu> <Pine.LNX.4.64.0710111840360.23011@wotan.suse.de>

> Yes I understand that. But what we have to do in the middle-end from C++ > constructs like Mark has shown has to be done in a type which does not > have the ignore_overflow "semantic" (because the justification for that > semantic, namely negative values have small magnitude simply doesn't > hold). In fact the most natural choice for a type to calculate that > expression would have been unsigned because that allows all rearrangements > of the operands. But when the natural type for doing arithmetics on such > operands is type X it simply doesn't make sense to store those operands as > having type Y, as conversions would be required all the time we actually > look at the operands. But I thought that we agreed yesterday that, unless there are some surprises coming from givs in loop optimization, we should treat sizetypes as wrapping on overflow, whether signed or unsigned. So I'm not sure what you mean above. Certainly the point is to do the entire sizing computation in ONE type and not convert back and forth: that's the whole point of sizetype!

**Follow-Ups**:**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Guenther

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**References**:**Re: [PATCH] Fix optimization regression in constant folder***From:*Ian Lance Taylor

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Mark Mitchell

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

**Re: [PATCH] Fix optimization regression in constant folder***From:*Richard Kenner

**Re: [PATCH] Fix optimization regression in constant folder***From:*Michael Matz

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |