Re: g++-3.4 bug
On Mon, 20 Feb 2012, Torbjorn Granlund wrote: Marc Glisse writes: Yes, my main concern is whether I should let people notice that the testsuite is failing so they try a more recent compiler, or work around it by disabling the use of __builtin_constant_p for 3.4.* (and anything older?). If just the test suite is miscompiled, libgmp.* and libgmpxx.* seem fine. and the compiler is actually still used, then we might as well make a (trivial) workaround in the test suite. I am not sure what you mean. Note that as is, a g++34 user who multiplies a mpz_class by 4u (what the testsuite does) in his code is likely to hit the bug. I am not really happy with hiding the testsuite failure, I'd rather either let the testsuite noisily fail, or (trivially) work around the bug in gmpxx.h so the user's code is safe too. (now that I think about it, there is a testsuite failure on solaris (likely with g++-3.4.3) visible at http://hydra.nixos.org/build/2112917 when creating a mpz_class from an mpz_t, 3.4 is really an unlucky number) which last I checked didn't work with the master repos ;-) (it doesn't understand the instruction jb,pt in mpn/x86_64/mod_34lsub1.asm (and neither does oracle)) I suppose we could as well remove it. Now done. Thanks. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: g++-3.4 bug
Marc Glisse writes: Yes, my main concern is whether I should let people notice that the testsuite is failing so they try a more recent compiler, or work around it by disabling the use of __builtin_constant_p for 3.4.* (and anything older?). If just the test suite is miscompiled, and the compiler is actually still used, then we might as well make a (trivial) workaround in the test suite. Note that we resisted the temptation to work around the GCC 4.3.2 bug that made mpn/generic/rootrem.c become miscompiled. In this case, we had a compiler which was very much used, but no reasonable workaround was found. which last I checked didn't work with the master repos ;-) (it doesn't understand the instruction jb,pt in mpn/x86_64/mod_34lsub1.asm (and neither does oracle)) I suppose we could as well remove it. Now done. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: g++-3.4 bug
On Mon, 20 Feb 2012, Richard Guenther wrote: Ah, ok - I thought you might have one. I'm not really interested in GCC 3.4.x bugs either - after all this version has been out of maintainance for six years... Yes, my main concern is whether I should let people notice that the testsuite is failing so they try a more recent compiler, or work around it by disabling the use of __builtin_constant_p for 3.4.* (and anything older?). ... has have 4.2.x and 4.3.x. But it seems freebsd is stuck with 4.2.2, the last release with GPLv2. I suppose for freebsd testing should focus on LLVM. which last I checked didn't work with the master repos ;-) (it doesn't understand the instruction jb,pt in mpn/x86_64/mod_34lsub1.asm (and neither does oracle)) Note that people who accept gplv2 but not gplv3 are fairly likely to be unhappy with gmp anyway... -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: g++-3.4 bug
Richard Guenther writes: ... has have 4.2.x and 4.3.x. But it seems freebsd is stuck with 4.2.2, the last release with GPLv2. I suppose for freebsd testing should focus on LLVM. I think differently. I am developing GMP on FreeBSD systems, and use gcc there. I don't waste any time on LLVM. It is a pity they make this play about GPLv3, but I don't think they'll get out of their block for many years. In the meantime, one may always install things from /usr/ports/lang/gcc*. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: g++-3.4 bug
On Mon, 20 Feb 2012, Marc Glisse wrote:
> On Mon, 20 Feb 2012, Richard Guenther wrote:
>
> > On Thu, 16 Feb 2012, Marc Glisse wrote:
> >
> > > Hello,
> > >
> > > some tests currently fail on gmpxx with g++-3.4 (on shell). This is due to
> > > a
> > > bug in g++-3.4, which for l=2 says the following is true:
> > > __builtin_constant_p(l) && (l == 0)
> > > it is interesting to insert a printf statement that prints both l and l==0
> > > and
> > > have it print 2 and true :-/
> >
> > Not for me.
> >
> > int main () { int l = 2; if (__builtin_constant_p (l) && (l == 0)) return
> > 1; return 0; }
>
> Did you try getting a snapshot of the gmp repos and running the c++ testsuite?
> Yes, your simple example passes, but you know better than I do how much the
> context matters for optimizations. And since the bug doesn't seem reproducible
> with more recent versions of gcc, there is little motivation to reduce the
> failing tests.
Ah, ok - I thought you might have one. I'm not really interested in
GCC 3.4.x bugs either - after all this version has been out of
maintainance for six years...
> The failing compiler was 3.4.6, from ports on freebsd 8.1, with -O2 -m64.
> 4.2.5 seems good.
... has have 4.2.x and 4.3.x. But it seems freebsd is stuck with 4.2.2,
the last release with GPLv2. I suppose for freebsd testing should focus
on LLVM.
Richard.
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: g++-3.4 bug
On Mon, 20 Feb 2012, Richard Guenther wrote:
On Thu, 16 Feb 2012, Marc Glisse wrote:
Hello,
some tests currently fail on gmpxx with g++-3.4 (on shell). This is due to a
bug in g++-3.4, which for l=2 says the following is true:
__builtin_constant_p(l) && (l == 0)
it is interesting to insert a printf statement that prints both l and l==0 and
have it print 2 and true :-/
Not for me.
int main () { int l = 2; if (__builtin_constant_p (l) && (l == 0)) return
1; return 0; }
Did you try getting a snapshot of the gmp repos and running the c++
testsuite? Yes, your simple example passes, but you know better than I do
how much the context matters for optimizations. And since the bug doesn't
seem reproducible with more recent versions of gcc, there is little
motivation to reduce the failing tests.
The failing compiler was 3.4.6, from ports on freebsd 8.1, with -O2 -m64.
4.2.5 seems good.
In gmpxx.h, you can do this change:
struct __gmp_binary_lshift // LINE 425
{
static void eval(mpz_ptr z, mpz_srcptr w, mp_bitcnt_t l)
{
if (__GMPXX_CONSTANT(l) && (l == 0))
{
std::cerr << l << '\n'; // NEW LINE
if (z != w) mpz_set(z, w);
}
(and replace with at the beginning)
and wonder why it prints "2"...
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: g++-3.4 bug
On Thu, 16 Feb 2012, Marc Glisse wrote:
> Hello,
>
> some tests currently fail on gmpxx with g++-3.4 (on shell). This is due to a
> bug in g++-3.4, which for l=2 says the following is true:
> __builtin_constant_p(l) && (l == 0)
> it is interesting to insert a printf statement that prints both l and l==0 and
> have it print 2 and true :-/
Not for me.
int main () { int l = 2; if (__builtin_constant_p (l) && (l == 0)) return
1; return 0; }
Richard.
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
g++-3.4 bug
Hello, some tests currently fail on gmpxx with g++-3.4 (on shell). This is due to a bug in g++-3.4, which for l=2 says the following is true: __builtin_constant_p(l) && (l == 0) it is interesting to insert a printf statement that prints both l and l==0 and have it print 2 and true :-/ More recent versions like g++42 seem fine. There are various simple workarounds that make g++34 happy (although in principle they shouldn't change anything), but that seems a bit dangerous (who knows where the bug might be lurking?). My current plan is to replace the test for the existence of __builtin_constant_p from __GNUC__ >= 2 to __GMP_GNUC_PREREQ(4, 2) (or possibly 4.0 or 4.1 if I can get access to either to check if the bug is present). This would only affect the use of __builtin_constant_p in gmpxx.h (not anywhere else, in particular not gmp.h), which is new in gmp-5.1. Does that sound ok? -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
