[Bug libquadmath/78415] New: sqrtq does not round correctly when round mode is upward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78415
Bug ID: 78415
Summary: sqrtq does not round correctly when round mode is
upward
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: walter.mascarenhas at gmail dot com
Target Milestone: ---
//
// The code below shows that sqrtq does not round
// correctly when the rounding mode is upwards.
//
#include
#include
#include
#include
int main()
{
__float128 x = 1.0;
x += 2.0 * FLT128_EPSILON;
std::fesetround(FE_UPWARD);
__float128 su = sqrtq(x);
// the sqrt is rounded to 1 + 2 epsilon, whereas the least __float128
// above the mathematical sqrt(1 + 2 epsilon) is 1 + epsilon:
// The Taylor series for sqrt around 1 yields
// sqrt(1 + 2 epsilon) ~ 1 + epsilon - epsilon^2/2 < 1 + epsilon.
assert(su == x);
}
[Bug libquadmath/78414] New: libquamath converts (long double) INFINITY to NAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78414 Bug ID: 78414 Summary: libquamath converts (long double) INFINITY to NAN Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: walter.mascarenhas at gmail dot com Target Milestone: --- Created attachment 40078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40078=edit a simple code showing the bug Libquadmath converts the INFINITY long double to a NAN __float128
[Bug c++/64497] New: std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497 Bug ID: 64497 Summary: std::scalbln does not round correctly for long doubles Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: walter.mascarenhas at gmail dot com The overload std::scalbln(long double, long) may not round the result correctly when the exponent is very small. For instance, with round mode = near, std::scalbln(1.1L, -16446) returns 0, whereas std::scalbn(1.1L, -16446) and std::ldexp(1.1L, -16446) return std::numeric_limitslong double::denorm_min(), which I believe is the correct result.
[Bug c++/64497] std::scalbln does not round correctly for long doubles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497
--- Comment #2 from Walter Mascarenhas walter.mascarenhas at gmail dot com ---
What if there is a difference in the expected behavior
for this function in C and C++11? Is it not up to g++
for implementing what is mandated in C++11? (This
is not a rhetorical question, I really do not know the answer.)
In http://man7.org/linux/man-pages/man3/scalbn.3.html it
is written that scalbln should return 0 in case of underflow:
If the result underflows, a range error occurs, and the functions
return zero, with a sign the same as *x*.
On the other hand,
http://en.cppreference.com/w/cpp/numeric/math/scalbn states that
If a range error due to underflow occurs, the correct result (after
rounding) is returned.
I looked at the standard (N3797.pdf) but did not find anything
specific about std::scalbln.
If there is indeed a discrepancy in the definitions of scalbln in C
and C++11 then there
may be no bug in libm, and my vendor will not change it.
I do not have a copy of the ISO 60599 standard, and I do not know whether
the content of the pages http://man7.org/linux/man-pages/man3/scalbn.3.html and
http://en.cppreference.com/w/cpp/numeric/math/scalbn are compatible with
any standards. Therefore I am in no position to argue,
but maybe you could think a bit longer about this..
On Mon, Jan 5, 2015 at 10:29 AM, redi at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64497
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
GCC just calls the scalnlnl() function in libm, so it's not a GCC bug, and
is
not specific to C++ either. I suggest you report it to your libc vendor.
Complete testcase in C:
#include stdio.h
#include math.h
#include assert.h
int main()
{
long double di = scalbnl(1.1L, -16446);
assert( di != 0.0L );
long double dl = scalblnl(1.1L, -16446L);
assert( dl != 0.0L );
}
--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.
[Bug c++/60273] New: gcc gets confused when one class uses variadic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60273
Bug ID: 60273
Summary: gcc gets confused when one class uses variadic
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: walter.mascarenhas at gmail dot com
Created attachment 32171
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32171action=edit
gcc asked me to submit this file
//
// When compiling this file in Ubuntu 13.04, gcc 4.8.1 crashes with the
// following message. Clang 3.0 compiles the file with no problems.
//
// /home/walter/code/klein/tests/platform/gcc_bug/main.cc:-1: In instantiation
of 'struct BarFooint ':
// /home/walter/code/klein/tests/platform/gcc_bug/main.cc:25: required from
here
// /home/walter/code/klein/tests/platform/gcc_bug/main.cc:20: internal compiler
error: Segmentation fault
// templateint... Ns using Buggy = typename X::template SNs...;
// :-1: error: [main.o] Error 1^
//
struct A {};
template class X
struct Foo
{
using Type = int;
// if the next line is replaced by template int... N then all is fine
template int N1, int N2
using S = A;
};
template class X
struct Bar
{
// if the next line is commented then all is fine.
using Type = typename X::Type;
// if the next line is commented then all is fine.
templateint... Ns using Buggy = typename X::template SNs...;
};
void foobar()
{
Bar Fooint bf;
}
[Bug c++/59056] ambiguous call to function template overloads not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #9 from Walter Mascarenhas walter.mascarenhas at gmail dot com ---
1) I just wrote that Richard's paragraph, IN ITSELF,
does not explain why things are as they are. I did not
write that there aren't other reasons to justify the
standard's decisions.
2) As I wrote, GCC does depend on the value of check Fooint ()
in order to decide whether or not the code is ambiguous:
If we provide an specialization
template constexpr bool checkFooint () {return false;}
then the ambiguity goes away. Of course, this specialization
changes the code and brings in other issues. I just want
to point out, naively, that the value of
check Fooint () is relevant for GCC.
3) In my naive user point of view, I believed that Richard's
observation that the only available definition of check
always return true would imply that
template class X struct BarX, Enable_if checkX() {};
would be essentially equivalent to
template class X struct BarX, void{};
and this looks less specialized than
template struct Bar Fooint, void {},
This was my naive view. If the standard says
otherwise then there is no point in arguing
about it.
walter.
On Thu, Nov 14, 2013 at 1:04 AM, richard-gccbugzilla at metafoo dot co.uk
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #8 from Richard Smith richard-gccbugzilla at metafoo dot
co.uk ---
(In reply to Walter Mascarenhas from comment #7)
In itself, Richard's paragraph Morally, the function should
ambiguous...
implies that the code below is ambiguous. However, it
compiles just fine with gcc 4.8.1, because gcc also takes into
account the information that check Fooint () is false
in order to discard the specialization with the enable_if. In
other words, the X in checkX is not completely arbitrary,
it my be related to FooT.
GCC can't instantiate checkTy with a dependent type Ty, because that's
not a
meaningful thing to do. And it's not allowed to use Fooint, because
partial
ordering of templates does not depend on the actual deduced arguments for
the
template specialization (it orders the templates themselves, not their
specializations). Also, the only available definition of check always
returns
true. So I really don't see how that could be the case.
--
You are receiving this mail because:
You reported the bug.
[Bug c++/59056] ambiguous call to function template overloads not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #7 from Walter Mascarenhas walter.mascarenhas at gmail dot com ---
In itself, Richard's paragraph Morally, the function should ambiguous...
implies that the code below is ambiguous. However, it
compiles just fine with gcc 4.8.1, because gcc also takes into
account the information that check Fooint () is false
in order to discard the specialization with the enable_if. In
other words, the X in checkX is not completely arbitrary,
it my be related to FooT.
I find it odd that in the code below gcc uses the information
that check Fooint () is false and in the first version it
neglects the equivalent information that check Fooint ()
is true. Of course, the standard has the last word on these
things, but not everything in it is morally obvious or
completely logical.
Here is the modified code (I only changed the value
returned by check from true to false):
template class X
constexpr bool check() { return false; }
template class X, class Enable = void struct Bar {};
template class X
struct BarX, typename std::enable_if checkX() ::type {};
template class T
struct Bar FooT {};
void instance()
{
Bar Fooint, void av;
}
On Wed, Nov 13, 2013 at 7:00 PM, richard-gccbugzilla at metafoo dot co.uk
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #5 from Richard Smith richard-gccbugzilla at metafoo dot
co.uk ---
(In reply to Jonathan Wakely from comment #2)
I thought if the partial specializations were ambiguous then these
function
overloads should be too.
Yes, this inconsistency is very surprising. GCC, EDG, and Clang all behave
the
same way, and yet I can find no justification for this behavior in the
standard.
Morally, the function call should be ambiguous. The first 'func' takes
BarX
for any X where checkX() is true, and the second 'func' takes BarX for
any
X that matches FooT. Neither of those constraints implies the other, so
the
call should be ambiguous.
In Clang's case, the problem is that we fail to enforce
[temp.deduct.type](14.8.2.5)/1 when partially ordering function templates
-- we
don't check that deduction actually succeeded in finding types that make
'A'
match the 'deduced A' -- but we do check that when partially ordering class
templates, and we don't spot the problem earlier because the
enable_if... is
a non-deduced context. I expect EDG and GCC have a similar bug.
--
You are receiving this mail because:
You reported the bug.
[Bug c++/59056] New: enable_if turns a non-ambiguous template into an ambiguous one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
Bug ID: 59056
Summary: enable_if turns a non-ambiguous template into an
ambiguous one
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: walter.mascarenhas at gmail dot com
Created attachment 31187
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31187action=edit
a simple code illustrating the bug
The attached file shows that by turning a specialization of
template class A, class Enable = void
struct Foo {};
like this one (which works just fine)
template class A
struct FooA, void{};
into
template class A
struct FooA, std::enable_if typename always_trueA() ::type {};
we can get ambigouities, even when typename always_trueA() ::type
always resolves to void.
For more details, look at the attachement
[Bug c++/56516] New: problem parsing templates: object.field 10 interpreted as ill formed template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56516
Bug #: 56516
Summary: problem parsing templates: object.field 10
interpreted as ill formed template
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: walter.mascaren...@gmail.com
// The following code illustrates what I consider to be a bug in
// g++ 4.7.2 with options -std=c++11 -g -Wall, with Qt 5.0.1 in Ubuntu 12.04
LTS
template typename T
inline
int field(T const)
{
return 0;
}
template typename T
struct Foo
{
int field;
};
template typename N
inline
void useFoo()
{
FooN foo;
// the next line causes the error parse error in template argument list
// g++ seems to be considering foo.field 10 as some ill formed
// invocation of the template function field
for( ; foo.field 10; )
{
}
}
int main()
{
useFooint();
return 0;
}
