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
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
>
> --- Commen
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
: 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 "optimize
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
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 conve
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 n
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
++
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, gc
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 d
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
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 attach
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
13 matches
Mail list logo
