On Fri, Jul 13, 2012 at 10:34 AM, Mike Stump <mikest...@comcast.net> wrote: > On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote: >> On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump <mikest...@comcast.net> wrote: >>> This patch adds __int256 to the front-ends. > >>> We have another patch underway to do N-bit constant ints, where N is >>> defined by the port. This patch is in the process of being reviewed now, >>> and Kenny should be able to submit it shortly. >> >> How do you handle the fact that we cannot represent all constants of __int256 >> or larger with an INTEGER_CST? I think this introduces latent wrong-code >> bugs almost everywhere in the compiler. > > As I said, in Kenny's next patch, we add support for all constants of any > size the port needs. I don't know if you've ever tried to use the compiler > with OImode, but, what I can say is the bugs are not terribly latent at times > and they are not hidden very well at all, today. The goal of course, is to > improve that and make it work better. These issues that I know about > existed, prior to my patch, and we are in the process of fixing them. Some > have been fixed, others remain to be fixed. The issues I'm thinking about > exist with or without my patch to the frontend to support __int256. Merely > adding __int256 doesn't make any of the issues I'm aware of appear, and the > issues I'm aware of don't appear with sizes less than 256. > > I have put the patch through the C test suite, and it doesn't show any > failures. > > Do you have any examples of bugs that are _introduced_ by my patch? I'd be > happy to fix any that arise.
No. Just you expose the users to those bugs by exposing __int256 ;) Docs should have a pretty big fat warning on it. Richard.
