Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
Created attachment 55619
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55619=edit
Reproducing testcase
Attached is a reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93990
Jack Lloyd changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
Bug 67317 has regressed, starting in GCC 6
Same test case as 67317:
#include
#include
unsigned long long testcarry(unsigned
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
Aarch64 8.2-A has an optional extension for SM4. This is a Chinese
cryptographic algorithm analogous to AES. GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #15 from Jack Lloyd ---
Thanks for the fast fix and backporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69210
--- Comment #1 from Jack Lloyd ---
This still occurs with GCC 9.1.0
iority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
The POWER9 ISA includes a hardware random number generator "DARN" which is
similar to x86 RDRAND/RDSEED. Using the GCC intrinsics and *an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82328
Jack Lloyd changed:
What|Removed |Added
CC||lloyd at randombit dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498
--- Comment #17 from Jack Lloyd ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498
--- Comment #5 from Jack Lloyd ---
Jakub thank you very much for your comments, this was helpful for me in getting
consistent rol/ror generation.
Speaking as a user it's frustrating that Clang and GCC don't just have a
builtin for rotations
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
GCC doesn't seem to realize that x86 masks the high bits in the rol/ror
instructions. GCC 7.2.0 on x86-64 compiles this function, which is attempting
to do a 32-bit rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
Jack Lloyd changed:
What|Removed |Added
CC||lloyd at randombit dot net
--- Comment #6
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lloyd at randombit dot net
Target Milestone: ---
In GCC 5.3 -Wsuggest-final-{types,methods} seems a little trigger happy. For
example this code:
$ cat final.cpp
// in a header...
class A
{
public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53301
Bug #: 53301
Summary: Spurious -Wzero-as-null-pointer-constant with
reference arguments
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173
Bug #: 52173
Summary: internal compiler error: verify_ssa failed possibly
caused by itm
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173
--- Comment #1 from Jack Lloyd lloyd at randombit dot net 2012-02-08 15:52:19
UTC ---
Created attachment 26615
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26615
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173
Jack Lloyd lloyd at randombit dot net changed:
What|Removed |Added
Attachment #26615|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51457
Bug #: 51457
Summary: Add warning about impossible boolean comparisons
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766
Bug #: 50766
Summary: Binutils 2.22.51 rejects bmi2 pext operation with
memory operands
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet
--- Comment #1 from lloyd at randombit dot net 2010-05-06 22:53 ---
Created an attachment (id=20591)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20591action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44018
--- Comment #8 from lloyd at randombit dot net 2010-01-21 15:38 ---
Jon (and Paolo) - thanks for doing the work!
Is there an easy workaround I can apply locally for this? I tried replacing all
instances of `typename _Fn::result_type` with `typename
result_of_Fn(_Args...)::type
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64
--- Comment #2 from lloyd at randombit dot net 2010-01-21 05:01 ---
Still ICEs with r156097:
g++-4.5-r156097 -std=c++0x decl.cpp
In file included from
/usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/future:40:0,
from
--- Comment #4 from lloyd at randombit dot net 2010-01-21 05:02 ---
I could not replicate this problem after upgrading mpfr, closing as invalid
--
lloyd at randombit dot net changed:
What|Removed |Added
--- Comment #1 from lloyd at randombit dot net 2010-01-21 05:04 ---
Still ICEs with r156097
$ g++-4.5-r156097 -std=c++0x decl.cpp
decl2.cpp: In function 'int main()':
decl2.cpp:11:9: error: no matching function for call to
'main()::lambda()::__lambda0()'
decl2.cpp:9:11: note
-pthread causes
immediate crash
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit
: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
--- Comment #1 from lloyd at randombit dot net 2009-11-27 21:39 ---
Created an attachment (id=19165)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19165action=view)
Test case
Here is the full output compiling this on my machine:
$ g++-4.5-20091112 -Wall -W -std=c++0x movable.cpp
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host
--- Comment #1 from lloyd at randombit dot net 2009-11-25 18:49 ---
Created an attachment (id=19151)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19151action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42177
at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42082
--- Comment #1 from lloyd at randombit dot net 2009-11-17 19:48 ---
Created an attachment (id=19030)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19030action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42082
at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42083
by -
Wunused and -Wunused-parameter
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet
--- Comment #3 from lloyd at randombit dot net 2008-07-09 15:39 ---
Seemingly fixed in 4.3.0 or 4.3.1, closing this pr. Tested attached testcase
with
$ g++ -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org
--- Comment #2 from lloyd at randombit dot net 2008-03-03 16:57 ---
Oh, and both versions were built with mpfr 2.2.1, which configure told me was
buggy but acceptable (if I remember the wording correctly) - is this my
problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35426
--- Comment #1 from lloyd at randombit dot net 2008-03-03 16:55 ---
Created an attachment (id=15255)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15255action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35426
: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host
--- Comment #2 from lloyd at randombit dot net 2007-11-16 00:50 ---
Is there be any way to modify the code such that GCC would have an easier time
seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's
__assert_fail is marked with noreturn I thought it might help
--- Comment #5 from lloyd at randombit dot net 2007-11-16 02:00 ---
Argh, you are correct. The original code has
unsigned int n = an_input / 160;
so this could never occur there, but GCC's inability to tell that this
assignment means that n cannot be UINT_MAX (in that code
--- Comment #3 from lloyd at randombit dot net 2007-11-16 01:49 ---
Here's another example, which I think may represent a different case (and which
I found much more surprising than the first):
$ cat no_loop_opt2.c
void g(unsigned int n)
{
unsigned int k;
for(k = 0; k = n
--- Comment #1 from lloyd at randombit dot net 2007-10-17 16:06 ---
Created an attachment (id=14363)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14363action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33800
: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http
--- Comment #2 from lloyd at randombit dot net 2007-10-17 16:48 ---
Backtrace (command line args for cc1plus chosen by stracing g++)
$ gdb /home/jack/opt/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus
Using host libthread_db library /lib64/libthread_db.so.1.
(gdb) run
incorrect for C++0x
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build
--- Comment #17 from lloyd at randombit dot net 2007-08-27 13:14 ---
This should probably be reexamined with regards to C++0x, since it includes
'long long' and my reading of the working group draft is that a constant too
large to fit into a long should be considered a long long
--- Comment #2 from lloyd at randombit dot net 2007-06-30 22:11 ---
The behavior still exists in the 4.3 20070622 snapshot. It does not occur using
-march=core2 (the actual CPU in question). The bad value results when using
-ftree-vectorize and -march or -mtune =nocona. -O, -O2, or -O3
: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
--- Comment #3 from lloyd at randombit dot net 2007-06-27 19:06 ---
I haven't seen such code written in the first place ever.
Neither had I, until I found out it is endemic in a large project at work.
I'd just as soon write a script to find these cases, but figuring out what
--- Comment #5 from lloyd at randombit dot net 2007-06-27 19:33 ---
I filed the bug because it seems like this would be at least marginally useful,
and this way people can find it / read the discussion / whatever. Even if the
end result is WONTFIX, that at least lets anyone
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC
--- Comment #1 from lloyd at randombit dot net 2007-05-17 07:36 ---
Created an attachment (id=13567)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13567action=view)
A short testcase for bug 31966
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
--- Comment #4 from lloyd at randombit dot net 2007-05-10 17:51 ---
Manuel,
For your example code, GCC _is_ aware that the function always returns, since
the code it generates for it (with optimization) is:
f:
movl%edi, %eax
ret
So obviously it knows, at the level
org
ReportedBy: lloyd at randombit dot net
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
--- Comment #2 from lloyd at randombit dot net 2007-05-09 22:16 ---
So are you saying that it is the case that the f() function below might return
without a value? Since that is what the warning suggests.
(My interpretation re the optimizer may be completely off, I don't know GCC
--- Comment #1 from lloyd at randombit dot net 2007-03-07 14:47 ---
This is also true for C++ unless -pedantic is specified (which is confusing
since I thought -pedantic-errors was the default for C++, but apparently this
changed at some point). Using '-Wall -Wextra -ansi -std=c++98
at randombit dot net
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
--- Comment #2 from lloyd at randombit dot net 2006-01-17 19:32 ---
Ah, I misread it, but the bug should stay open IMO - the invalidity of the code
reduces it to GCC doesn't reject invalid code, which is obviously a low
priority, but still a bug, no?
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from lloyd at randombit dot net 2006-01-17 21:39 ---
Thank you for the reference Gaby. I'm now not quite sure what purpose a pure
virtual destructor has, or why it should be legal, but neither the apparent
language oddity nor my confusion about same is a GCC problem, so
62 matches
Mail list logo
