Note also that in glibc, _Float128 support in printf code can only be
used in limited circumstances: either on powerpc64le, as one of the
multiple supported long double formats there, or through the sharing of
the printf code with the implementation of strfromf128.
In particular, there are no
(Not that suseconds_t *needs* to be 64-bit to store values from 0 to
99, but there's nothing wrong with it being 64-bit either, it just
needs to agree with the type of tv_usec.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Shouldn't we fix how suseconds_t is defined in glibc in the 64-bit time
case? It's not as if any interfaces in glibc use suseconds_t other than
as part of struct timeval (though we should still warn in NEWS about
potential compatibility issues for any interfaces using suseconds_t in
third-party
*** Bug 14412 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/192134
Title:
slow math sin function for some values on amd64
To manage notifications
Really the issue for sin/cos/sincos is the same, so retitling the bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/192134
Title:
slow math sin function for some values on amd64
To manage
Confirmed with current sources. Suspending until a faster correctly
rounding implementation (such as that proposed in
http://gcc.gnu.org/ml/gcc/2012-02/msg00298.html ) is available as this
is probably not amenable to a simple local fix.
--
You received this bug notification because you are a
I do not believe there is a glibc bug here.
* The bug report quotes a manpage for the readdir system call as saying
that d_off refers to the current dirent rather than the next dirent.
That is correct, but irrelevant. The readdir system call is a backwards
compatibility one using a very old
Dan,
Please read my comments in more detail. Because offsets in directories
are opaque cookies (if you look at the autofs sources in the kernel,
you'll see that they are hash values for autofs, for example), and
because the __lseek64 call's offset ends up being passed to the
filesystem's llseek
Author: jsm28
Date: Wed Oct 12 11:56:03 2011
New Revision: 179845
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179845
Log:
PR c/50565
* convert.c (convert_to_integer): Do not narrow operands of
pointer subtraction.
testsuite:
* gcc.c-torture/compile/pr50565
Fixed for 4.5.4, 4.6.2, 4.7.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/771087
Title:
mmpong version 0.9.1-1 failed to build on amd64 with GCC-4.6/oneiric
To manage notifications about this bug
Author: jsm28
Date: Wed Oct 12 11:57:36 2011
New Revision: 179846
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179846
Log:
PR c/50565
* convert.c (convert_to_integer): Do not narrow operands of
pointer subtraction.
testsuite:
* gcc.c-torture/compile/pr50565
Author: jsm28
Date: Wed Oct 12 11:58:47 2011
New Revision: 179847
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179847
Log:
PR c/50565
* convert.c (convert_to_integer): Do not narrow operands of
pointer subtraction.
testsuite:
* gcc.c-torture/compile/pr50565
Patch (to convert.c) submitted: http://gcc.gnu.org/ml/gcc-
patches/2011-10/msg00894.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/771087
Title:
mmpong version 0.9.1-1 failed to build on amd64
13 matches
Mail list logo
