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*: Michael Matz <matz at suse dot de>*To*: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>*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 18:51:46 +0200 (CEST)*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>

Hi, On Thu, 11 Oct 2007, Richard Kenner wrote: > > As shown we can't calculate with sizetypes in C anyway, > > We're not calculating them *in C*, but in the middle-end, as an > *implementation* of C-language features, such as indexing. 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. Ciao, Michael.

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

**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

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

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