https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111897
--- Comment #3 from Agner Fog ---
I have asked the authors of the linked document. They say that the example in
the document is wrong. The latest version still has the error in the example:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111897
--- Comment #2 from Agner Fog ---
Thank you Jonathan.
The problem is that the C++ standard is becoming so complicated that nobody can
master it, not even the persons who wrote the example in the proposal.
`_Float16 A{1.0};` gives a warning, wh
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: agner at agner dot org
Target Milestone: ---
Initializing a _Float16 gives false warning. Example:
_Float16 A = 1.0;
This gives the "warning: converting to ‘_Float16’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920
Agner Fog changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920
--- Comment #3 from Agner Fog ---
It seems to work with gcc 9.4.0.
Thank you
++
Assignee: unassigned at gcc dot gnu.org
Reporter: agner at agner dot org
Target Milestone: ---
Created attachment 54526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54526&action=edit
code to reproduce error
The attached file test.cpp gives wrong code when optimized with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89597
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89485
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83250
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41084
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253
--- Comment #13 from Agner Fog ---
Thank you. I agree that integer overflow should be well-defined when using
intrinsics.
Is it possible to do the same optimization with boolean vector intrinsics, such
as _mm_and_epi32 and _mm_or_ps to enable op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351
--- Comment #2 from Agner Fog ---
AVX512 allows all _memory_ source operands to broadcast from a scalar on almost
all vector instructions for 128-, 256- and 512-bit vectors with 32- or 64-bit
elements. See section 4.6.1 in "Intel® Architecture In
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: agner at agner dot org
The AVX512 instruction set allows instructions with broadcast, but there are no
corresponding intrinsic functions. The programmer has to write a broadcast
intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253
--- Comment #11 from Agner Fog ---
Thanks for the links Marc.
You are right, the discussion in the gcc-patches mailing list ignores integer
vectors. You need a solution that also allows optimizations on integer
intrinsic functions (perhaps cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253
--- Comment #9 from Agner Fog ---
Many programmers are using a vector class library rather than writing intrinsic
functions directly. Such libraries have overloaded operators which are inlined
to produce intrinsic functions. Therefore, we cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56253
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #8 from
Assignee: unassigned at gcc dot gnu.org
Reporter: agner at agner dot org
A few compare functions are missing in avx512intrin.h, e.g.
_mm512_cmpgt_epu32_mask and _mm512_cmpgt_epu64_mask
All intrinsic functions for typecasting are also missing. Please add these
functions, as
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: agner at agner dot org
Created attachment 33159
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33159&action=edit
test code to replicate bug
Definitions _MM_MANTISSA_NO
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: agner at agner dot org
Created attachment 33117
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33117&action=edit
c++ file producing error
The attached file bug1.cpp ge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071
Bug #: 53071
Summary: Wrong instruction replacement when compiling for xop
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932
--- Comment #10 from Agner Fog 2012-04-13 16:50:33 UTC
---
_mm256_permutevar8x32_epi32 has the operands in wrong order. They need
to be swapped. Did you fix this too?
On 12-04-2012 20:37, uros at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932
Bug #: 52932
Summary: AVX2 intrinsic _mm256_permutevar8x32_ps has wrong
parameter type
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #15 from Agner Fog 2011-07-27 14:27:33 UTC
---
How do you define "clever things"? Checking that a variable is within the
allowed range is certainly a standard thing that every SW teacher tells you to
do. I think it is reasonable to ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #13 from Agner Fog 2011-07-26 19:31:48 UTC
---
My example does indeed give a warning when compiled with -Wstrict-overflow=2.
Unfortunately, -Wall implies only -Wstrict-overflow=1 so I got no warning in
the first place. I think the war
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #12 from Agner Fog 2011-07-25 14:21:52 UTC
---
No the behavior is not predictable when it sometimes warns about ignoring
overflow, and sometimes not. Please add a warning when it optimizes away an
overflow check after the abs function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #10 from Agner Fog 2011-07-25 07:43:58 UTC
---
I still think that a compiler should be predictable and consistent. It is
inconsistent that a+5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #8 from Agner Fog 2011-07-24 08:16:39 UTC
---
Thanks for your comments.
Why is the behavior different for signed and unsigned?
The expression (a + 5 < a) is reduced to always false when a is signed, but not
when a is unsigned.
-Wal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
Summary: Explicit check for integer negative after abs
optimized away
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
--- Comment #16 from Agner Fog 2011-07-08 08:52:32 UTC
---
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > What is the status of this issue?
> >
> > It is implemented on ifunc branch.
> >
> > > Is optio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
--- Comment #15 from Agner Fog 2011-05-30 13:13:06 UTC
---
(In reply to comment #14)
> (In reply to comment #13)
> > What is the status of this issue?
>
> It is implemented on ifunc branch.
>
> > Is option 3 implemented?
>
> Yes, on ifunc bran
--- Comment #13 from agner at agner dot org 2010-02-21 16:21 ---
What is the status of this issue?
Is option 3 implemented?
Which versions of Linux and binutils support IFUNC?
Any plans for BSD and Mac?
--
agner at agner dot org changed:
What|Removed
Version: 4.2.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agner at agner dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37880
--- Comment #26 from agner at agner dot org 2006-09-23 08:23 ---
Thank you for fixing this, but you need to tell the world which solution you
have chosen. Please see the discussion at the dublicate bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537 for arguments for and against
each
--- Comment #11 from agner at agner dot org 2006-08-23 08:04 ---
This problem wouldn't have happened if the ABI had been better maintained.
Somebody decides to change the calling convention without properly documenting
the change, and somebody else makes another change th
--- Comment #8 from agner at agner dot org 2006-08-03 20:20 ---
hjl wrote:
>Apparently, it was done on purpose
Yes, the -Os non-alignment was obviously done on purpose. The problem is that
other modules that may be called from the -Os module rely on the stack being
aligned by 16.
--- Comment #6 from agner at agner dot org 2006-06-08 06:27 ---
Comment #5 From hjl confirms my point: The error can occur in an optimized part
of the program that uses XMM registers when some other, noncritical, part of
the program is compiled with -Os
We need a comment from the ABI
--- Comment #4 from agner at agner dot org 2006-05-11 07:11 ---
Thanks for confirming this bug. If Gcc relies on the stack being aligned then
it has to be an official ABI requirement.
It makes perfectly sense to compile the whole program, or some of it, with -Os
and also use XMM. -Os
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agner at agner dot org
GCC host triplet: x64
GCC target triplet: ia32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
42 matches
Mail list logo
