++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
Target Milestone: ---
Created attachment 52913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52913&action=edit
zip file containing test case.
The attached pre-processed source generat
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
Target Milestone: ---
Found while experimenting with modules for Boost.Math, consider a module which
exports an
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
Target Milestone: ---
Reduced test case:
module.cpp:
module;
#include
export module test_support;
export template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91705
--- Comment #1 from John Maddock ---
Forgot to add: this effects operators ++ and -- in both prefix and postfix
versions. The standard selected (14,17,2a) makes no difference.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
Target Milestone: ---
The following short program was accepted by gcc-8, but results in an error with
gcc-9.1:
template
constexpr T test_increment(T t)
{
return ++t;
}
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689
--- Comment #1 from John Maddock ---
I think I've found the problem - make the nu parameter negative and you get the
correct answers.
These functions appear to use the same definition for ellint_3 as GSL uses
(same code?), but TR1 uses a differe
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
Target Milestone: ---
The std::tr1 functions comp_ellint_3 and ellint_3 appear to return garbage
values whenever the nu parameter is non zero.
For example:
comp_ellint_3(0.75, 0
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
std::numeric_limits::max() returns
0x7fff which is definitely not 2^128-1. Looks like
a cut and paste error from numeric_limits<__int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #26 from John Maddock ---
(In reply to jos...@codesourcery.com from comment #25)
> On Thu, 20 Nov 2014, john at johnmaddock dot co.uk wrote:
>
> > While we're opening cans of worms intmax_t should clearly be __i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
John Maddock changed:
What|Removed |Added
CC||john at johnmaddock dot co.uk
Severity: blocker
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
This effects gcc-4.8.1 and 4.8.2 (at least), on both mingw32 and mingw64, the
following program segfaults:
#include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540
Bug #: 56540
Summary: No __SIZEOF__XXX__ macro for __float128
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #7 from John Maddock 2011-04-25
17:21:15 UTC ---
Sorry to be dumb, but doesn't the result of the C code violate section G.5.2 in
C99 - which is to say that no matter what the value of the imaginary part of an
expression, it never chan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Summary: std::complex constructor buggy in the face of NaN's
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
Assig
14 matches
Mail list logo
