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*: Richard Biener <richard dot guenther at gmail dot com>*To*: Lawrence Crowl <crowl at google dot com>*Cc*: Ian Lance Taylor <iant at google dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, Mike Stump <mikestump at comcast dot net>, Kenneth Zadeck <zadeck at naturalbridge dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>*Date*: Wed, 10 Apr 2013 09:38:27 +0200*Subject*: Re: Comments on the suggestion to use infinite precision math for wide int.*References*: <506C72C7 dot 7090207 at naturalbridge dot com> <CAFiYyc2buJtu8RMKnLnvvb-A2=aYwopO+RBLPO6iJ3gKnq-hvg at mail dot gmail dot com> <87pq3y3kyk dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <CAFiYyc3NjOxpQ-Y9GDrQOET+dc3LXWuiuM=DxqmyASE8urRoWw at mail dot gmail dot com> <50912D85 dot 1070002 at naturalbridge dot com> <CAFiYyc2Q2UQPmkhExi2c8f-BSGLv+Rq1rOy4NdPQmTqSRE1A0A at mail dot gmail dot com> <5091331C dot 3030504 at naturalbridge dot com> <CAFiYyc1L6zuehE75dEfd_fB1-81F1fDHpL3kS=tbk6qAK3Texg at mail dot gmail dot com> <512D686B dot 90000 at naturalbridge dot com> <CAFiYyc3fXewAW2dU6-RHLiTQ-ZiLgdWmfwdFF6k1VqxPsrvZbQ at mail dot gmail dot com> <515B16EB dot 5020303 at naturalbridge dot com> <CAFiYyc2qWwDcqzCMpMSiQ72w5ry=a3ZpxkFkiK7OvvBA0h4eGw at mail dot gmail dot com> <515C1AFB dot 3080105 at naturalbridge dot com> <CAFiYyc12qGj92j+5yCUEpghOZXqjjAgOzS_H6QJpKvd-dyfU0A at mail dot gmail dot com> <515C55D7 dot 7020003 at naturalbridge dot com> <CAFiYyc0sp1wbq1J+FXoJWcb9UcsOWiwjJ_KaQkbbgCnddxhVzA at mail dot gmail dot com> <5161AA07 dot 7090706 at naturalbridge dot com> <CAFiYyc1QArda2jm56=eT_ugqX39m4tW=gf7FCowuruq-xOdQGg at mail dot gmail dot com> <5162BB64 dot 3070007 at naturalbridge dot com> <CAGqM8fYKvS6uNW3smZBUQcWZHtqUzR5yD-dkh3Zvkn7mALKVbQ at mail dot gmail dot com> <CAFiYyc0Cj6=M1__GWs9KsFcTfMJGDV9E74gdrzZsus6N0nbX7g at mail dot gmail dot com> <CAGqM8fZ7NxiMnC6PTA8v6w_E6ZJ5HbjhJXzh-HAOJqaSx+7rnw at mail dot gmail dot com>

On Tue, Apr 9, 2013 at 5:36 PM, Lawrence Crowl <crowl@google.com> wrote: > > On Apr 9, 2013 2:02 AM, "Richard Biener" <richard.guenther@gmail.com> wrote: >> >> On Mon, Apr 8, 2013 at 10:39 PM, Lawrence Crowl <crowl@google.com> wrote: >> > On 4/8/13, Kenneth Zadeck <zadeck@naturalbridge.com> wrote: >> >> The other problem, which i invite you to use the full power of >> >> your c++ sorcery on, is the one where defining an operator so >> >> that wide-int + unsigned hwi is either rejected or properly >> >> zero extended. If you can do this, I will go along with >> >> your suggestion that the internal rep should be sign extended. >> >> Saying that constants are always sign extended seems ok, but there >> >> are a huge number of places where we convert unsigned hwis as >> >> the second operand and i do not want that to be a trap. I went >> >> thru a round of this, where i did not post the patch because i >> >> could not make this work. And the number of places where you >> >> want to use an hwi as the second operand dwarfs the number of >> >> places where you want to use a small integer constant. >> > >> > You can use overloading, as in the following, which actually ignores >> > handling the sign in the representation. >> > >> > class number { >> > unsigned int rep1; >> > int representation; >> > public: >> > number(int arg) : representation(arg) {} >> > number(unsigned int arg) : representation(arg) {} >> > friend number operator+(number, int); >> > friend number operator+(number, unsigned int); >> > friend number operator+(int, number); >> > friend number operator+(unsigned int, number); >> > }; >> > >> > number operator+(number n, int si) { >> > return n.representation + si; >> > } >> > >> > number operator+(number n, unsigned int ui) { >> > return n.representation + ui; >> > } >> > >> > number operator+(int si, number n) { >> > return n.representation + si; >> > } >> > >> > number operator+(unsigned int ui, number n) { >> > return n.representation + ui; >> > } >> >> That does not work for types larger than int/unsigned int as HOST_WIDE_INT >> usually is (it's long / unsigned long). When you pass an int or unsigned >> int >> to >> >> number operator+(unsigned long ui, number n); >> number operator+(long ui, number n) >> >> you get an ambiguity. You can "fix" that by relying on template argument >> deduction and specialization instead of on overloading and integer >> conversion >> rules. > > Ah, I hadn't quite gotten the point. This problem is being fixed in the > standard, but that won't help GCC anytime soon. > >> >> > If the argument type is of a template type parameter, then >> > you can test the template type via >> > >> > if (std::is_signed<T>::value) >> > .... // sign extend >> > else >> > .... // zero extend >> > >> > See http://www.cplusplus.com/reference/type_traits/is_signed/. >> >> Yes, if we want to use the standard library. For what integer types >> is std::is_signed required to be implemented in C++98 (long long?)? > > It is in C++03/TR1, which is our base requirement. Otherwise, we can test > ~(T)0<(T)0. Yeah, I think we want to test ~(T)0<(T)0 here. Relying on C++03/TR1 is too obscure if there is an easy workaround. Richard. >> Consider non-GCC host compilers. >> >> Richard. >> >> > If you want to handle non-builtin types that are asigne dor unsigned, >> > then you need to add a specialization for is_signed. >> > >> > -- >> > Lawrence Crowl

**Follow-Ups**:

**References**:**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Kenneth Zadeck

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Kenneth Zadeck

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Kenneth Zadeck

**Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1***From:*Richard Biener

**Comments on the suggestion to use infinite precision math for wide int.***From:*Kenneth Zadeck

**Re: Comments on the suggestion to use infinite precision math for wide int.***From:*Richard Biener

**Re: Comments on the suggestion to use infinite precision math for wide int.***From:*Kenneth Zadeck

**Re: Comments on the suggestion to use infinite precision math for wide int.***From:*Lawrence Crowl

**Re: Comments on the suggestion to use infinite precision math for wide int.***From:*Richard Biener

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

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