From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1743 invoked by alias); 21 Feb 2010 18:50:36 -0000 Received: (qmail 1579 invoked by alias); 21 Feb 2010 18:50:22 -0000 Date: Sun, 21 Feb 2010 18:50:00 -0000 Message-ID: <20100221185022.1578.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "gdr at integrable-solutions dot net" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-02/txt/msg02175.txt.bz2 ------- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50 ------- Subject: Re: numeric_limits::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com wrote: > ------- Comment #38 from veksler at il dot ibm dot com  2010-02-21 18:20 ------- > (In reply to comment #37) > >> is_modulo is intended to describe the implementation's choice, not necessarily >> the CPU behaviour (which the implementation may choose to mask or not.) >> >> The issue here is that GCC does not always deliver the CPU behaviour, so it >> is more a problem with GCC than with the standard. >> >> Users who want to make incompatible assumptions about types in the same program >> deserve what they get. >> > > This is not that simple. libstdc++.so is out of user's control, > libkde.so (or whatever its name is) is out of user's control. Agreed. > > So if -fwrapv affects the definition of is_modulo then: > so the issue then is that you get two people who make incompatible assumptions about the same type for the same program. If that is case, I'm not sure what libstdc++ would have to do. After all, the resulting program is out of the control of libstdc++. > If libstdc++.so is compiled without -fwrapv, then the user can't > use -fwrapv without a potential ODR violation. agreed. > What if libkde.so, > which is supplied by a third party, was compiled with -fwrapv, while > libsdc++.so was compiled by some sysadmin, accessible through NFS. agreed. > They must be compiled with exactly the same flags, both out of user's control, > otherwise they'll cause an ODR violation. > > Having is_modulo lie looks not as bad as it initially seemed. At least I have > the option to ignore is_modulo altogether without going to the land of > undefined behavior. my conclusion would be that is_modulo is not the right interface to test whether a component in the program was compiled with -fwrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200