[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
inline
int field(T const&)
{
return 0;
}
template
struct Foo
{
int field;
};
template
inline
void useFoo()
{
Foo 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()
{
useFoo();
return 0;
}
[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=31187&action=edit
a simple code illustrating the bug
The attached file shows that by turning a specialization of
template
struct Foo {};
like this one (which works just fine)
template
struct Foo{};
into
template
struct Foo() >::type >{};
we can get ambigouities, even when typename always_true() >::type
always resolves to void.
For more details, look at the attachement
[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 ---
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< Foo >() is false
in order to discard the specialization with the enable_if. In
other words, the X in check is not completely arbitrary,
it my be related to Foo.
I find it odd that in the code below gcc uses the information
that check< Foo >() is false and in the first version it
neglects the equivalent information that check< Foo >()
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
constexpr bool check() { return false; }
template struct Bar {};
template
struct Bar() >::type> {};
template
struct Bar< Foo > {};
void instance()
{
Bar< Foo, 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 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
> Bar
> for any X where check() is true, and the second 'func' takes Bar for
> any
> X that matches Foo. 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] ambiguous call to function template overloads not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #9 from Walter Mascarenhas ---
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< Foo >()
in order to decide whether or not the code is ambiguous:
If we provide an specialization
template <> constexpr bool check >() {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< Foo >() 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 struct Bar() > >{};
would be essentially equivalent to
template struct Bar{};
and this looks less specialized than
template <> struct Bar< Foo, 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 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< Foo >() is false
> > in order to discard the specialization with the enable_if. In
> > other words, the X in check is not completely arbitrary,
> > it my be related to Foo.
>
> GCC can't instantiate check with a dependent type Ty, because that's
> not a
> meaningful thing to do. And it's not allowed to use Foo, 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 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&action=edit a simple code showing the bug Libquadmath converts the INFINITY long double to a NAN __float128
[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 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=32171&action=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 Bar >':
// /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
// template using Buggy = typename X::template S;
// :-1: error: [main.o] Error 1^
//
struct A {};
template
struct Foo
{
using Type = int;
// if the next line is replaced by template then all is fine
template
using S = A;
};
template
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.
template using Buggy = typename X::template S;
};
void foobar()
{
Bar< Foo > bf;
}
[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_limits::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 ---
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 ---
> 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
> #include
> #include
>
> 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++/116891] New: invalid optimization of -fma(-x, y, -z) when -03 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891
Bug ID: 116891
Summary: invalid optimization of -fma(-x,y,-z) when -03 and
-frounding-math are used
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: walter.mascarenhas at gmail dot com
Target Milestone: ---
GCC generates invalid code for this statement
x = - fma( -y, z, -w )
with -frounding-math. It "optimizes" it to
x = fma( y, z, w )
but this is incorrect when the rounding mode is downwards or upwards.
In more detail, for the function
double bad_fma( double y, double z, double w) {
return std::fma( -y, z, -w );
}
with flags -O3 -mfma -frounding-math
I get this in godbolt, with gcc 14.2:
bad_fma:
vfmadd132sd xmm0, xmm2, xmm1
ret
That is, gcc incorrectly "optimizes" the code.
[Bug middle-end/116891] invalid optimization of -fma(-x,y,-z) when -03 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891
--- Comment #2 from Walter Mascarenhas ---
Hi,
You will find two files attached to this message:
1) the cpp file contains the C++ code, with comments describing
the exact options used and the g++ version. The bug is
described in detail in a comment in this file.
2) the .s file was obtained with g++'s -S flag.
In a quick look at it you will notice that it contains only
vfmadd132sd instructions and no changes of signs,
that is, g++ is "optimizing"
- ( fma( -a, x, - y) )
to fma( a, x, y ), and this is not supposed to happen
when -frounding-math is used.
walter.
On Sun, Sep 29, 2024 at 11:10 PM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891
>
> Andrew Pinski changed:
>
>What|Removed |Added
>
>
> Status|UNCONFIRMED |WAITING
> Component|c++ |middle-end
>Last reconfirmed||2024-09-30
> Ever confirmed|0 |1
>
> --- Comment #1 from Andrew Pinski ---
> I tried:
> ```
> #include
>
> double bad_fma( double y, double z, double w) {
>return std::fma( -y, z, -w );
> }
> ```
>
> and it produces with `-O3 -frounding-math -mfma`:
> ```
> _Z7bad_fmaddd:
> .cfi_startproc
> vfnmsub132sd%xmm1, %xmm2, %xmm0 # tmp104, tmp105,
> ret
> ```
>
> https://godbolt.org/z/fzs1cso3P
>
>
> Can you provide the preprocessed source you are using and/or even the full
> testcase including what headers you are using and what exact options you
> used?
>
> --
> You are receiving this mail because:
> You reported the bug.
[Bug middle-end/116891] [12/13/14/15 Regression] invalid optimization of -fma(-x,x,-z) when -03 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891 --- Comment #8 from Walter Mascarenhas --- sorry, I did not pay enough attention. On Tue, Oct 1, 2024 at 5:18 AM pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891 > > --- Comment #7 from Andrew Pinski --- > (In reply to Walter Mascarenhas from comment #6) > > Hi Andrew, > > > >The proper optimization in this case would be to use the instruction > > vfnmsub132pd followed by a change of sign. It could be something like > > > That is exactly what I Said just using internals of gcc. > > Note bugzilla is usually a mix of both user facing information and > internals of > what needs to be done inside gcc. > > -- > You are receiving this mail because: > You reported the bug.
[Bug middle-end/116891] [12/13/14/15 Regression] invalid optimization of -fma(-x,x,-z) when -03 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891
--- Comment #6 from Walter Mascarenhas ---
Hi Andrew,
The proper optimization in this case would be to use the instruction
vfnmsub132pd followed by a change of sign. It could be something like
fma_ru:
vfnmsub132pd xmm0, xmm2, xmm1
vmovddup xmm1, QWORD PTR .LC1[rip]
vxorpd xmm0, xmm0, xmm1
ret
.LC1:
.long 0
.long -2147483648
On Mon, Sep 30, 2024 at 3:30 PM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891
>
> Andrew Pinski changed:
>
>What|Removed |Added
>
>
> Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
>|invalid optimization of |invalid optimization of
>|-fma(-x,y,-z) when -03 and |-fma(-x,x,-z) when -03 and
>|-frounding-math are used|-frounding-math are used
>
> --- Comment #5 from Andrew Pinski ---
> Simplified testcase:
> ```
> double f(double ae, double ax)
> {
> return -__builtin_fma( -ax, ax, -ae );
> }
> ```
>
> That is pushing the outer negate into FMA is not valid due to
> addition/multiply
> being in infinite precision.
>
> --
> You are receiving this mail because:
> You reported the bug.
