[Bug target/110792] New: GCC 13 x86_32 miscompilation of Whirlpool hash function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110792 Bug ID: 110792 Summary: GCC 13 x86_32 miscompilation of Whirlpool hash function Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal 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 reproducing testcase for an apparent miscompilation bug in GCC 13 when compiling for 32-bit x86. Upstream issue: https://github.com/randombit/botan/issues/3637 This code is the core loop of the Whirlpool hash function. In the attachment if `CAUSE_CODEGEN_BUG` is defined then a particular function is defined in an anonymous namespace. When that happens, GCC apparently generates invalid code $ g++ -O2 -std=c++20 -m32 whirl.cpp -o whirl $ ./whirl 19FA61D75522A466 9B44E39C1D2E1726 C530232130D407F8 9AFEE0964997F7A7 3E83BE698B288FEB CF88E3E03C4F0757 EA8964E59B63D937 08B138CC42A66EB3 # above is the correct Whirlpool hash for the empty message $ g++ -DCAUSE_CODEGEN_BUG -O2 -std=c++20 -m32 whirl.cpp -o whirl $ ./whirl zsh: segmentation fault ./whirl If compiled with Ubsan/Asan, the code is ok: $ g++ -DCAUSE_CODEGEN_BUG -fsanitize=address -fsanitize=undefined -O2 -std=c++20 -m32 whirl.cpp -o whirl $ ./whirl 19FA61D75522A466 9B44E39C1D2E1726 C530232130D407F8 9AFEE0964997F7A7 3E83BE698B288FEB CF88E3E03C4F0757 EA8964E59B63D937 08B138CC42A66EB3 My GCC is $ g++ -v Using built-in specs. COLLECT_GCC=/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.1 20230429 (GCC) This is the compiler from Arch Linux which is AFAIK stock GCC. The original report related to the GCC 13 included in Alpine Edge.
[Bug target/93990] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93990 Jack Lloyd changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jack Lloyd --- Good enough for me, closing, thanks.
[Bug target/93990] New: [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93990
Bug ID: 93990
Summary: [x86] Silly code generation for
_addcarry_u32/_addcarry_u64
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
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 long long a, unsigned long long
b, unsigned long long c, unsigned long long d)
{
unsigned long long result0, result1;
_addcarry_u64(_addcarry_u64(0, a, c, ), b, d,
);
return result0 ^ result1;
}
GCC 5.4.1 (only) produces the expected output
.cfi_startproc
addq%rdi, %rdx # a, tmp99
adcq%rsi, %rcx # b, tmp107
movq%rdx, %rax # tmp99, D.28638
xorq%rcx, %rax # tmp107, D.28638
ret
.cfi_endproc
GCC 6.4.1, 7.4.1, 8.3.0 and 9.2.0 all produce variations on this [GCC 9.2.0
output here]:
.cfi_startproc
subq$40, %rsp #,
.cfi_def_cfa_offset 48
# adx.cpp:5:{
movq%fs:40, %rax# MEM[( long unsigned int
*)40B], tmp107
movq%rax, 24(%rsp) # tmp107, D.33144
xorl%eax, %eax # tmp107
# /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/adxintrin.h:69: return
__builtin_ia32_addcarryx_u64 (__CF, __X, __Y, __P);
addq%rdx, %rdi # tmp105, tmp93
movq%rsi, %rax # tmp104, tmp104
setc%r8b#, _12
movq%rdi, 8(%rsp) # tmp93,
addb$-1, %r8b #, _12
adcq%rcx, %rax # tmp106, tmp104
movq%rax, 16(%rsp) # tmp97,
# adx.cpp:8:return result0 ^ result1;
xorq%rdi, %rax # tmp93,
# adx.cpp:9:}
movq24(%rsp), %rdx # D.33144, tmp109
xorq%fs:40, %rdx# MEM[( long unsigned int
*)40B], tmp109
jne .L5 #,
addq$40, %rsp #,
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
All were compiled with -O3. I checked 9.2.0 output with -O and -O2 as well,
with no significant change.
[Bug target/93370] New: Aarch64 accepts but ignores target("+sm4") unless ARMv8.2-A is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93370
Bug ID: 93370
Summary: Aarch64 accepts but ignores target("+sm4") unless
ARMv8.2-A is enabled
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: 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. GCC supports these via intrinsic.
The confusion came about because GCC accepts `__attribute__((target("+sm4")))`
but unless ARMv8.2-A is also enabled (eg via -march=armv8.2-a command line
flag) then it complains about a target specific option mismatch, which is the
usual error when trying to use an intrinsic for an extension that is not
enabled when compiling that function or file. In contrast if you pass something
GCC doesn't know about to target() then it errors with a clear message "pragma
or attribute 'target("+foo")' is not valid".
Example:
$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9.2.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /build/aarch64-linux-gnu-gcc/src/gcc-9.2.0/configure
--prefix=/usr --program-prefix=aarch64-linux-gnu-
--with-local-prefix=/usr/aarch64-linux-gnu
--with-sysroot=/usr/aarch64-linux-gnu
--with-build-sysroot=/usr/aarch64-linux-gnu
--with-native-system-header-dir=/include --libdir=/usr/lib
--libexecdir=/usr/lib --target=aarch64-linux-gnu --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --disable-nls --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 9.2.0 (GCC)
$ cat sm4.c
#include
#if WORKS
#define TARGET "arch=armv8.2-a+sm4"
#else
#define TARGET "+sm4"
#endif
void __attribute__((target(TARGET))) enc(uint32_t b[4])
{
uint32x4_t B = vld1q_u32(b);
vsm4eq_u32(B, B); // from SM4 extension
vst1q_u32(b, B);
}
$ aarch64-linux-gnu-gcc -DWORKS=1 -Wall -Wextra -c sm4.c -o sm4.o
$ aarch64-linux-gnu-gcc -DWORKS=0 -march=armv8.2-a -Wall -Wextra -c sm4.c -o
sm4.o
$ aarch64-linux-gnu-gcc -DWORKS=0 -Wall -Wextra -c sm4.c -o sm4.o
In file included from sm4.c:1:
/usr/lib/gcc/aarch64-linux-gnu/9.2.0/include/arm_neon.h: In function 'void
enc(uint32_t*)':
/usr/lib/gcc/aarch64-linux-gnu/9.2.0/include/arm_neon.h:33125:1: error:
inlining failed in call to always_inline 'uint32x4_t vsm4eq_u32(uint32x4_t,
uint32x4_t)': target specific option mismatch
33125 | vsm4eq_u32 (uint32x4_t __a, uint32x4_t __b)
| ^~
sm4.c:12:14: note: called from here
12 |vsm4eq_u32(B, B);
|~~^~
In file included from sm4.c:1:
/usr/lib/gcc/aarch64-linux-gnu/9.2.0/include/arm_neon.h:33125:1: error:
inlining failed in call to always_inline 'uint32x4_t vsm4eq_u32(uint32x4_t,
uint32x4_t)': target specific option mismatch
33125 | vsm4eq_u32 (uint32x4_t __a, uint32x4_t __b)
| ^~
sm4.c:12:14: note: called from here
12 |vsm4eq_u32(B, B);
|~~^~
This is not a huge bug but it would be nice if GCC gave a more obvious error to
hint at the problem, since it accepts +sm4 but does not actually respect it
unless ARMv8.2-A is separately enabled. I imagine this situation holds true for
some of the other Aarch64 extensions but have not checked this.
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #15 from Jack Lloyd --- Thanks for the fast fix and backporting
[Bug c++/69210] False positives from -Wsuggest-final-types/methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69210 --- Comment #1 from Jack Lloyd --- This still occurs with GCC 9.1.0
[Bug target/91481] New: POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
Bug ID: 91481
Summary: POWER9 "DARN" RNG intrinsic produces repeated output
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: 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 *any optimization
level* then `__builtin_darn()` and `__builtin_darn_raw()` produce repeated
output:
$ cat darn.c
#include
#include
int main()
{
uint64_t darn[32];
for(size_t i = 0; i != 32; ++i)
darn[i] = __builtin_darn(); // or __builtin_darn_raw()
for(size_t i = 0; i != 32; ++i)
printf("%016lX\n", darn[i]);
}
$ $HOME/opt/bin/powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/home/lloyd/opt/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/lloyd/opt/libexec/gcc/powerpc64le-unknown-linux-gnu/9.2.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc-9.2.0/configure --prefix=/home/lloyd/opt
--enable-languages=c,c++
Thread model: posix
gcc version 9.2.0 (GCC)
$ $HOME/opt/bin/powerpc64le-unknown-linux-gnu-gcc -mcpu=power9 -O -m64 darn.c
-o darn
$ ./darn
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
...
The binary produces a unique value each time it is executed, but the same value
repeats. If no optimization is used, then different values are produced. Since
these instructions are supposed to be used to seed cryptographic random number
generators, this is quite bad. I don't know PPC asm but my read of the
generated code when optimizations are enabled is that `darn` is invoked just
once and then the value is placed repeatedly into the array - maybe GCC has not
been taught that this instruction is volatile and produces a different output
each time it is used?
Originally observed with "gcc version 8.3.1 20190304 (Advance-Toolchain-at12.0)
[revision 269374] (GCC)" on gcc135, same behavior with stock GCC 9.2.0.
I don't think there is an issue with the hardware; if using inline asm instead
of the intrinsics, everything seems to work as expected.
[Bug target/82328] x86 rdrand: flags not used directly when branching on success/failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82328 Jack Lloyd changed: What|Removed |Added CC||lloyd at randombit dot net --- Comment #1 from Jack Lloyd --- This is still an issue in GCC 9.1.0
[Bug target/82498] Missed optimization for x86 rotate instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498 --- Comment #17 from Jack Lloyd --- Thank you!
[Bug target/82498] Missed optimization for x86 rotate instruction
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 like MSVC does, instead you have to guess what expressions the optimizer(s) know about. That said there are a lot of strange ways to right a rotate and probably GCC doesn't need to know all of them.
[Bug target/82498] New: Missed optimization for x86 rotate instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82498
Bug ID: 82498
Summary: Missed optimization for x86 rotate instruction
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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 without invoking undefined behavior
#include
uint32_t rotate_left(uint32_t input, uint8_t rot)
{
if(rot == 0)
return input;
rot %= 8 * sizeof(uint32_t);
return static_cast((input << rot) | (input >>
(8*sizeof(uint32_t)-rot)));;
}
Into
movl%esi, %ecx # rot, rot
movl%edi, %eax # input, tmp97
andl$31, %ecx #, rot
roll%cl, %eax # rot, tmp97
testb %sil, %sil # rot
cmove %edi, %eax # tmp97,, input,
The `andl` is unnecessary as the machine will mask the rotation amount for us.
In addition the testb/cmov pair can be omitted. Overall this resulted in a ~15%
slowdown in some code using many variable rotations (CAST-128 cipher being used
in an OpenPGP library).
Some related (but not quite the same, and supposedly fixed) issues: 57157 59100
[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010 Jack Lloyd changed: What|Removed |Added CC||lloyd at randombit dot net --- Comment #6 from Jack Lloyd --- Still occurs with GCC 7.2.0
[Bug c++/69210] New: False positives from -Wsuggest-final-types/methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69210
Bug ID: 69210
Summary: False positives from -Wsuggest-final-types/methods
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
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:
virtual ~A() {}
virtual int f(int x) { return 2*x; }
virtual int g(int x) = 0;
};
// later in a source file...
int foo(A& a, int x)
{
return a.f(a.g(x));
}
$ g++ -O3 -std=c++11 -c -Wall -Wextra -Wsuggest-final-types
-Wsuggest-final-methods final.cpp
final.cpp:3:7: warning: Declaring type 'class A' final would enable
devirtualization of 1 call [-Wsuggest-final-types]
class A
^
final.cpp:7:19: warning: Declaring method 'virtual int A::f(int)' final would
enable devirtualization of 1 call [-Wsuggest-final-methods]
virtual int f(int x) { return 2*x; }
$ g++ -v
Using built-in specs.
COLLECT_GCC=/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.3.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)
But I think it doesn't make sense to warn that a type should be final, when the
type is directly introducing the new virtual call that could be devirtualized:
if it made sense for A or A::f to be final it would be more reasonable to
remove the virtual keyword entirely. In fact here A can't even be instantiated
due to the pure virtual g(), and thus must be overridden, but gcc seems to miss
that.
This comes up whenever a base type A defines a virtual function with a default
and GCC sees A& being used, without any subclasses of A being visible at the
call.
I have no idea how complicated this would be to fix or if there is any interest
in doing so. I'd be willing to try my hand at a patch, if there is any chance
it would be accepted (if so, any pointers on how/where to proceed would be
great as I'm not that familiar with the gcc sources).
[Bug c++/53301] New: Spurious -Wzero-as-null-pointer-constant with reference arguments
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
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ll...@randombit.net
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
The following causes a warning under -Wzero-as-null-pointer-constant:
class x { public: x(int v) {} };
void foo(const x = 0);
wnull.cpp:4:22: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
void foo(const x = 0);
The warning is avoided if the argument is passed as a non-reference type or if
the default argument is `x(0)`. Likely the reference type is being treated
identically to a pointer type even though in this case the value is used to
initialize the underlying type, not the reference.
$ g++-4.8.0-r187195 -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.8.0-r187195/bin/g++-4.8.0-r187195
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.0-r187195/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --prefix=/usr/local/gcc-4.8.0-r187195
--enable-languages=c,c++ --program-suffix=-4.8.0-r187195
Thread model: posix
gcc version 4.8.0 20120505 (experimental) (GCC)
[Bug middle-end/52173] New: internal compiler error: verify_ssa failed possibly caused by itm
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 Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ll...@randombit.net Testcase, attached, fails to compile under -O3. Fine under -O2. The error does not occur if I comment out the __transaction_relaxed $ g++-4.7.0 -O3 -std=c++11 -fgnu-tm concur.cpp -o concur -litm concur.cpp: In function 'void many_sets()': concur.cpp:19:6: error: definition in block 8 does not dominate use in block 98 for SSA_NAME: D.40799_64 in statement: D.43917_72 = (size_type) D.40799_64; concur.cpp:19:6: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Version info: $ g++-4.7.0 -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++-4.7.0 COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.0-r183974/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-svn/configure --prefix=/usr/local/gcc-4.7.0-r183974 --enable-languages=c,c++,go --program-suffix=-4.7.0-r183974 Thread model: posix gcc version 4.7.0 20120207 (experimental) (GCC)
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
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
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
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 is obsolete|| --- Comment #2 from Jack Lloyd lloyd at randombit dot net 2012-02-08 15:54:25 UTC --- Created attachment 26616 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26616 Testcase Elide the thread stuff from the testcase, doesn't affect the error
[Bug c++/51457] New: Add warning about impossible boolean comparisons
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
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ll...@randombit.net
Neither GCC 4.6.0 (release) and 4.7 svn (r181390) warn about the impossible
comparison in
bool f(bool b)
{
return (b == 'a');
}
The optimizer figures out it is always false and will optimize it to
xorl%eax, %eax
ret
From the description in the manual I would have expected -Wtype-limits to
detect this case.
[Bug target/50766] New: Binutils 2.22.51 rejects bmi2 pext operation with memory operands
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
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ll...@randombit.net
This program
#include stdio.h
#include x86intrin.h
int main()
{
unsigned int x = 0x23593464;
unsigned int y = 0xF9494302;
unsigned int z = _pext_u32(x, y);
printf(%08X %08X %08X\n, x, y, z);
}
when compiled with gcc 4.7 without optimizations, produces a call to pext that
looks like this:
pext%eax, -16(%rbp), %eax
which binutils 2.22.51.20111017 rejects with
Error: operand size mismatch for `pext'
With -O2, gcc places all operands in registers, and as will accept it.
Version:
$ g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++-4.7.0
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.0-r179617/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --program-suffix=-4.7.0-r179617
--prefix=/usr/local/gcc-4.7.0-r179617 --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20111006 (experimental) (GCC) ) and using
$ as --version
GNU assembler (GNU Binutils) 2.22.51.20111017
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-unknown-linux-gnu'.
[Bug libstdc++/45133] New: [c++0x] std::future will crash with NULL deref if get() is called twice
The following quick snippet crashes with GCC 4.5.0, on the second call to
get():
#include future
int make_int() { return 52; }
int main()
{
std::futureint future_in = std::async(make_int);
printf(%d\n, future_in.get());
printf(%d\n, future_in.get());
}
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00401c3f in std::__future_base::_State::wait (this=0x0) at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:281
281 _M_run_deferred();
(gdb) backtrace
#0 0x00401c3f in std::__future_base::_State::wait (this=0x0) at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:281
#1 0x00402e9d in std::__basic_futureint::_M_get_result
(this=0x7fffd880)
at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:515
#2 0x00402560 in std::futureint::get (this=0x7fffd880) at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:594
#3 0x004017a2 in main () at promise.cpp:10
Obviously this is not a valid operation, since get() moves the result and then
zaps itself (and valid() returns false after get() is called). However from a
usability standpoint this doesn't seem ideal. It looks like adding a check in
__basic_future::_M_get_result that ensures that _M_state is not NULL would be
sufficient to catch this case.
I would assume the result of doing a get() when !valid() is undefined, so
throwing an exception when someone does this would be conforming, and a lot
more obvious and friendly. If for some reason this couldn't work, even just an
assertion fail would be more informative than a NULL pointer deref.
--
Summary: [c++0x] std::future will crash with NULL deref if get()
is called twice
Product: gcc
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-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133
[Bug inline-asm/44018] New: Using cpuid.h, can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
I have some code (will be attached) that fails to compile with GCC 4.5.0 if you use the exact right (wrong) flags: $ g++-4.5.0 -fPIC -m32 -O2 -c cpuid.cpp -o cpuid.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/cpuid.h: In function 'unsigned int get_x86_cache_line_size()': /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/cpuid.h:179:52: error: can't find a register in class 'CLOBBERED_REGS' while reloading 'asm' /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/cpuid.h:179:52: error: 'asm' operand has impossible constraints /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/cpuid.h:179:52: error: 'asm' operand has impossible constraints /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/cpuid.h:179:52: error: 'asm' operand has impossible constraints If not using -fPIC, or if using -O instead of -O2, it compiles. This code compiles with the same flags (and any other permutation I've thought to try) with GCC 4.3.1 and 4.4.3. As far as I know the code is valid. I've pruned it down as much as I could. $ g++-4.5.0 -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0/g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /tmp/portage/sys-devel/gcc-4.5.0/work/gcc-4.5.0/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.0/python --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.0 p1.0' Thread model: posix gcc version 4.5.0 (Gentoo 4.5.0 p1.0) This is the Gentoo build of GCC 4.5.0, but I've checked the packaging; there are no noticeable patches being applied to the 4.5.0 sources, so I think this is a problem in vanilla 4.5.0. -- Summary: Using cpuid.h, can't find a register in class 'CLOBBERED_REGS' while reloading 'asm' Product: gcc Version: 4.5.0 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: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44018
[Bug inline-asm/44018] Using cpuid.h, can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
--- 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
[Bug libstdc++/42819] [C++0x] std::async fails to compile with simple tests, including N3000 example
--- 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` in future just to see if I can get things going
for me locally, but then get this error on the N3000 example:
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.2:38:0,
from n3000.cpp:1:
/usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:
In instantiation of 'std::result_ofstd::launch(work(int)::lambda())':
/usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/future.2:1328:41:
instantiated from 'std::futuretypename std::result_of_Functor(_ArgTypes
...)::type std::async(_Fn, _Args ...) [with _Fn = work(int)::lambda(),
_Args = {}, typename std::result_of_Functor(_ArgTypes ...)::type = int]'
n3000.cpp:17:57: instantiated from here
/usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:183:9:
error: 'std::declval [with _Tp = std::launch, typename
std::add_rvalue_reference_Tp::type = std::launch]()' cannot be used as a
function
I'm not sure if I have messed this up (my C++0x-fu is still very weak), or if
functional's result_of needs further changes to support this case - it looks to
be using decltype now (a recent change I think; thanks again!) so I had guessed
this would 'just work', but I had never even heard of declval and looking at
type_traits can't quite grok what it's doing or why this isn't happy. Simple
test cases I've tried using result_of on global functions and lambdas seem to
work so I'm having a hard time narrowing it down. Thus this comment. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug libstdc++/42819] New: [C++0x] std::async fails to compile with simple tests, including N3000 example
Here is the example for std::async included in the N3000 draft (section
30.6.9):
#include future
int work1(int value);
int work2(int value);
int work(int value)
{
auto handle = std::async([=] { return work2(value); });
int tmp = work1(value);
return tmp + handle.get();
}
With svn r156097, it fails to compile:
$ g++-4.5-r156097 -std=c++0x -c n3000.cpp
n3000.cpp: In function 'int work(int)':
n3000.cpp:8:57: error: no matching function for call to
'async(work(int)::lambda())'
n3000.cpp:8:57: error: unable to deduce 'auto' from 'expression error'
It also fails with `auto handle = std::async(work2, value);`
$ g++-4.5-r156097 -v
Using built-in specs.
COLLECT_GCC=g++-4.5-r156097
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-r156097/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --enable-languages=c,c++
--prefix=/usr/local/gcc-4.5-r156097 --program-suffix=-4.5-r156097
Thread model: posix
gcc version 4.5.0 20100120 (experimental) (GCC)
--
Summary: [C++0x] std::async fails to compile with simple tests,
including N3000 example
Product: gcc
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-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
[Bug c++/42082] [C++0x] ICE on probably invalid with canonical types differ for identical types
--- 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 decl.cpp:1:
/usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/mutex:
In function 'void std::call_once(std::once_flag, _Callable, _Args ...) [with
_Callable = std::_Mem_fnvoid
(std::__future_base::_State::*)(std::functionstd::unique_ptrstd::__future_base::_Result_base,
std::__future_base::_Result_base::_Deleter(), bool), _Args =
{std::__future_base::_State* const,
std::reference_wrapperstd::functionstd::unique_ptrstd::__future_base::_Result_base,
std::__future_base::_Result_base::_Deleter() ,
std::reference_wrapperbool}, std::once_flag = std::once_flag]':
/usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/future:310:23:
instantiated from here
/usr/local/gcc-4.5-r156097/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/mutex:727:7:
internal compiler error: canonical types differ for identical types int() and
int()
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42082
[Bug middle-end/35426] GCC 4.3.0 ICE on valid code in init2.c
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35426
[Bug c++/42083] [C++0x] ICE on invalid with tree check: expected aggr_init_expr, have error_mark in build_value_init
--- 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: candidates are: main()::lambda()::lambda(const main()::lambda()) decl2.cpp:9:11: note: main()::lambda()::lambda(main()::lambda()) decl2.cpp:11:9: internal compiler error: tree check: expected aggr_init_expr, have error_mark in build_value_init, at cp/init.c:319 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ g++-4.5-r156097 -v Using built-in specs. COLLECT_GCC=g++-4.5-r156097 COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-r156097/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-svn/configure --enable-languages=c,c++ --prefix=/usr/local/gcc-4.5-r156097 --program-suffix=-4.5-r156097 Thread model: posix gcc version 4.5.0 20100120 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42083
[Bug c++/42198] New: [C++0x] Using std::thread without -pthread causes immediate crash
It looks like any use of std::thread compiled in a program without -pthread (or
probably some specific macro set by -pthread, but hard to say as -pthread isn't
really documented to begin with) will crash on the spot. For instance, this
code:
#include thread
void f() {}
int main()
{
std::thread t(f);
t.join();
}
will die unless -pthread is set:
$ g++-4.5-20091112 -std=c++0x -ggdb -O0 fail.cpp -o fail
$ gdb ./fail
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-pc-linux-gnu...
(gdb) run
Starting program: /home/lloyd/fail
Program received signal SIGSEGV, Segmentation fault.
0x7faf94deb459 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) backtrace
#0 0x7faf94deb459 in ?? () from /lib64/ld-linux-x86-64.so.2
#1 0x7faf94df14b5 in ?? () from /lib64/ld-linux-x86-64.so.2
#2 0x7faf94b87a27 in std::thread::_M_start_thread (this=0x7fff9cff8850,
__b=
{std::__shared_ptrstd::thread::_Impl_base,
(__gnu_cxx::_Lock_policy)2u = {_M_ptr = 0x1669030, _M_refcount = {_M_pi =
0x1669010}}, No data fields})
at ../../../../gcc-4.5-20091112/libstdc++-v3/src/thread.cc:88
#3 0x00400eed in threadvoid (*)() (this=0x7fff9cff8850, __f=0x400ca4
f())
at
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/typeinfo:121
#4 0x00400cc4 in main ()
(gdb)
Some thoughts:
Perhaps -pthread should be implied by -std=c++0x/-std=gnu++0x? (Except at least
nominally one could use std::thread with DCE or Solaris threads, so is -pthread
right anyway?)
At least an assert() failure or (preferably) a compile-time error would be
nice; I can't imagine a much worst compiler diagnostic than having the program
silently crash with a segmentation fault.
--
Summary: [C++0x] Using std::thread without -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 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=42198
[Bug c++/42201] New: [C++0x] std::vectorstd::unique_futureT::push_back fails
For reasons I do not fully understand, std::vectorstd::unique_futureT's push_back fails because it attempts to use the (deleted) copy constructor and (copying) assignment operator. The std::vector implementation seems to support move-only objects in C++0x mode, and I don't really see why that is not working here. $ g++-4.5-20091112 -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++-4.5-20091112 COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-20091112/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.5-20091112/configure --prefix=/usr/local/gcc-4.5-20091112 --program-suffix=-4.5-20091112 --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20091112 (experimental) (GCC) -- Summary: [C++0x] std::vectorstd::unique_futureT::push_back fails 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 triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42201
[Bug c++/42201] [C++0x] std::vectorstd::unique_futureT::push_back fails
--- 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 -o move
In file included from
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/vector:69:0,
from movable.cpp:1:
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/future:
In member function 'void std::vector_Tp,
_Alloc::_M_insert_aux(std::vector_Tp, _Alloc::iterator, _Args ...) [with
_Args = {std::unique_futureint}, _Tp = std::unique_futureint, _Alloc =
std::allocatorstd::unique_futureint , std::vector_Tp, _Alloc::iterator =
__gnu_cxx::__normal_iteratorstd::unique_futureint*,
std::vectorstd::unique_futureint , typename std::vector_Tp,
_Alloc::_Base::_Tp_alloc_type::pointer = std::unique_futureint*]':
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/vector.tcc:100:4:
instantiated from 'void std::vector_Tp, _Alloc::emplace_back(_Args ...)
[with _Args = {std::unique_futureint}, _Tp = std::unique_futureint, _Alloc
= std::allocatorstd::unique_futureint ]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_vector.h:747:9:
instantiated from 'void std::vector_Tp, _Alloc::push_back(value_type)
[with _Tp = std::unique_futureint, _Alloc =
std::allocatorstd::unique_futureint , value_type =
std::unique_futureint]'
movable.cpp:12:50: instantiated from here
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/future:440:22:
error: deleted function 'std::unique_future_Res
std::unique_future_Res::operator=(const std::unique_future_Res) [with _Res
= int]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/vector.tcc:314:4:
error: used here
In file included from
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/vector:61:0,
from movable.cpp:1:
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/future:
In static member function 'static _BI2 std::__copy_move_backwardtrue, false,
std::random_access_iterator_tag::__copy_move_b(_BI1, _BI1, _BI2) [with _BI1 =
std::unique_futureint*, _BI2 = std::unique_futureint*]':
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_algobase.h:596:18:
instantiated from '_BI2 std::__copy_move_backward_a(_BI1, _BI1, _BI2) [with
bool _IsMove = true, _BI1 = std::unique_futureint*, _BI2 =
std::unique_futureint*]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_algobase.h:606:45:
instantiated from '_BI2 std::__copy_move_backward_a2(_BI1, _BI1, _BI2) [with
bool _IsMove = true, _BI1 = std::unique_futureint*, _BI2 =
std::unique_futureint*]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_algobase.h:677:56:
instantiated from '_BI2 std::move_backward(_BI1, _BI1, _BI2) [with _BI1 =
std::unique_futureint*, _BI2 = std::unique_futureint*]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/vector.tcc:308:4:
instantiated from 'void std::vector_Tp,
_Alloc::_M_insert_aux(std::vector_Tp, _Alloc::iterator, _Args ...) [with
_Args = {std::unique_futureint}, _Tp = std::unique_futureint, _Alloc =
std::allocatorstd::unique_futureint , std::vector_Tp, _Alloc::iterator =
__gnu_cxx::__normal_iteratorstd::unique_futureint*,
std::vectorstd::unique_futureint , typename std::vector_Tp,
_Alloc::_Base::_Tp_alloc_type::pointer = std::unique_futureint*]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/vector.tcc:100:4:
instantiated from 'void std::vector_Tp, _Alloc::emplace_back(_Args ...)
[with _Args = {std::unique_futureint}, _Tp = std::unique_futureint, _Alloc
= std::allocatorstd::unique_futureint ]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_vector.h:747:9:
instantiated from 'void std::vector_Tp, _Alloc::push_back(value_type)
[with _Tp = std::unique_futureint, _Alloc =
std::allocatorstd::unique_futureint , value_type =
std::unique_futureint]'
movable.cpp:12:50: instantiated from here
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/future:440:22:
error: deleted function 'std::unique_future_Res
std::unique_future_Res::operator=(const std::unique_future_Res) [with _Res
= int]'
/usr/local/gcc-4.5-20091112/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_algobase.h:561:6:
error: used here
[Bug c++/42177] New: [C++0x] ICE in function_and_variable_visibility, at ipa.c:296
Attached code fails with: $ g++-4.5-20091112 -std=c++0x ipa.cpp -o ipa ipa.cpp:23:4: internal compiler error: in function_and_variable_visibility, at ipa.c:296 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Version info: $ g++-4.5-20091112 -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++-4.5-20091112 COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-20091112/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.5-20091112/configure --prefix=/usr/local/gcc-4.5-20091112 --program-suffix=-4.5-20091112 --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20091112 (experimental) (GCC) As far as I can tell the code is valid. -- Summary: [C++0x] ICE in function_and_variable_visibility, at ipa.c:296 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 triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42177
[Bug c++/42177] [C++0x] ICE in function_and_variable_visibility, at ipa.c:296
--- 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
[Bug c++/42082] New: [C++0x] ICE on probably invalid with canonical types differ for identical types
The attached code causes an ICE with gcc 4.5 20091112. I'm somewhat certain but not positive that it is not valid code. $ g++-4.5-20091112 -std=c++0x decl.cpp -o decl decl.cpp: In function 'std::unique_future_Res async(F) [with T = int, F = main()::lambda()]': decl.cpp:16:30: instantiated from here decl.cpp:7:46: internal compiler error: canonical types differ for identical types int() and int() Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [C++0x] ICE on probably invalid with canonical types differ for identical types 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 triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42082
[Bug c++/42082] [C++0x] ICE on probably invalid with canonical types differ for identical types
--- 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
[Bug c++/42083] New: [C++0x] ICE on invalid with tree check: expected aggr_init_expr, have error_mark in build_value_init
This code (in includes needed) ICEs with GCC 4.5 20091112
templatetypename F
decltype(F()) run(F f)
{
return f();
}
int main()
{
auto l = []() { return 5; };
run(l);
}
Compiler output:
$ g++-4.5-20091112 -std=c++0x decl.cpp -o decl
decl.cpp: In function 'int main()':
decl.cpp:14:9: error: no matching function for call to
'main()::lambda()::__lambda0()'
decl.cpp:12:11: note: candidates are: main()::lambda()::lambda(const
main()::lambda())
decl.cpp:12:11: note:
main()::lambda()::lambda(main()::lambda())
decl.cpp:14:9: internal compiler error: tree check: expected aggr_init_expr,
have error_mark in build_value_init, at cp/init.c:319
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [C++0x] ICE on invalid with tree check: expected
aggr_init_expr, have error_mark in build_value_init
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 triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42083
[Bug c++/42066] New: C++0x lambda captures are not understood as used by -Wunused and -Wunused-parameter
GCC 4.5's -Wunused and -Wunused-parameter warnings don't understand that i and
n being used in the function below:
#include functional
std::functionint () foo(int i)
{
int n = 5;
return [=]() { return i+n; };
}
$ g++-4.5-20091112 -std=c++0x -Wall -Wextra -c lambda.cpp
lambda.cpp: In function 'std::functionint() foo(int)':
lambda.cpp:5:8: warning: unused variable 'n'
lambda.cpp: At global scope:
lambda.cpp:3:23: warning: unused parameter 'i'
Using optimizations doesn't seem to have an effect on this either way.
Workaround: Adding i and n explicitly to the capture list causes GCC to
understand that they are being used in this function.
$ g++-4.5-20091112 -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++-4.5-20091112
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-20091112/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20091112/configure
--prefix=/usr/local/gcc-4.5-20091112 --program-suffix=-4.5-20091112
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20091112 (experimental) (GCC)
--
Summary: C++0x lambda captures are not understood as used 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: 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=42066
[Bug middle-end/33800] ICE-on-valid (segfault) on x86_64
--- 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/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-cld --disable-libgcj --enable-languages=c,c++,objc,obj-c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1' Thread model: posix gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1) All cases that had failed with the 20070907 snapshot worked fine. -- lloyd at randombit dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33800
[Bug c/35426] New: GCC 4.3.0 ICE on valid code in init2.c
A simple C source fails with an ICE with 4.3.0 (the 20070907 and 20080228 snapshots) with optimizations (-O1/-O2/-Os -- I haven't narrowed it down to which exact optimization though). This machine is x86-64 but the same assertion occurs targeting both x86-64 (-m64) and x86 (-m32). Fedora Core 5 machine, system binutils 2.6.91.0.6. Same file compiles and executes with optimizations with GCC 4.1.1 $ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3-20080228/configure --prefix=/home/jack/opt --with-mpfr=/home/jack/opt Thread model: posix gcc version 4.3.0 20080228 (prerelease) (GCC) $ gcc -O2 speed.c -lm -o speed init2.c:38: assertion failed: ((32 - 0)+0) == (((32 - 0)+0)/8) * 8 sizeof(mp_limb_t) == (((32 - 0)+0)/8) speed.c: In function main: speed.c:16: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. distcc[28444] ERROR: compile speed.c on localhost failed The file in question is simple enough that I'm definitely thinking this may be a build issue - it looks like any code calling libm functions fails with this problem? It doesn't appear to be anything in FC5's math.h; removing the include of math.h and explicitly declaring pow() had no effect. -- Summary: GCC 4.3.0 ICE on valid code in init2.c 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 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=35426
[Bug c/35426] GCC 4.3.0 ICE on valid code in init2.c
--- 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
[Bug c/35426] GCC 4.3.0 ICE on valid code in init2.c
--- 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
[Bug c/34114] New: Missed optimization: cannot determine loop termination
As far as I can see the loop in the function f() always terminates without the
loop counter overflowing, but GCC cannot tell that it does.
$ g++-4.3-20070907 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907
--enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt
Thread model: posix
gcc version 4.3.0 20070907 (experimental) (GCC)
$ cat no_loop_opt.c
void f(unsigned int in)
{
unsigned int rnd_to_2 = (in - (in % 2));
unsigned int i;
for(i = 0; i != rnd_to_2; i += 2)
;
}
$ gcc-4.3-20070907 -O2 -Wall -Wextra -Wunsafe-loop-optimizations -c
no_loop_opt.c
no_loop_opt.c: In function f:
no_loop_opt.c:7: warning: cannot optimize loop, the loop counter may overflow
--
Summary: Missed optimization: cannot determine loop termination
Product: 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 triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- 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), but that didn't
seem to have an effect.
Short background that might be relevant: the code this is derived from is doing
partial loop unrolling (8 iterations in the actual code) with a block of inline
asm inserted, and then another loop following that handles any slop. Would
rewriting the loop as
while(in = 2)
{
in -= 2;
i += 2;
}
be likely to help? I see that it does with one particular version (4.1.2), but
I have no intuition if that is because the optimizer understands such loops
better or if it is just random luck.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- 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) is clearly much like the original example. And then I simplified it enough that the loop actually could be infinite... Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination
--- 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; ++k)
;
}
(motoko ~)$ g++-4.1.2 -O2 -Wunsafe-loop-optimizations -c no_loop_opt2.c
no_loop_opt2.c: In function 'void g(unsigned int)':
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
no_loop_opt2.c:5: warning: cannot optimize possibly infinite loops
(same output with 4.2.0)
However if = is changed to , no problem.
Version info:
$ g++-4.1.2 -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-libunwind-exceptions
--enable-multilib --enable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2)
$ g++-4.2.0 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2.0/configure --enable-languages=c,c++,objc,obj-c++
--program-suffix=-4.2.0
Thread model: posix
gcc version 4.2.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug c++/33800] ICE-on-valid (segfault) on x86-64
--- 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
[Bug c++/33800] New: ICE-on-valid (segfault) on x86-64
$ g++-4.3-20070907 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907 --enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt Thread model: posix gcc version 4.3.0 20070907 (experimental) (GCC) $ g++-4.3-20070907 -fpic -O1 -c seed.i -o seed.o src/seed.cpp: In member function virtual void Botan::SEED::enc(const Botan::byte*, Botan::byte*) const: src/seed.cpp:52: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Results with other flags: -fpic: OK -fPIC: OK -O1: FAIL -O2: OK -O1 -fpic: FAIL -O1 -fPIC: FAIL -O2 -fpic: FAIL -O2 -fPIC: FAIL -- Summary: ICE-on-valid (segfault) on x86-64 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 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=33800
[Bug c++/33800] ICE-on-valid (segfault) on x86-64
--- 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 -fpreprocessed seed.i -quiet -dumpbase seed.i -mtune=generic
-auxbase-strip seed.o -O1 -fpic -o /tmp/whatever.o
Starting program:
/home/jack/opt/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus
-fpreprocessed seed.i -quiet -dumpbase seed.i -mtune=generic -auxbase-strip
seed.o -O1 -fpic -o /tmp/whatever.o
Program received signal SIGSEGV, Segmentation fault.
0x007a94f5 in reload_as_needed (live_known=1) at
../../gcc-4.3-20070907/gcc/reload1.c:4161
4161 if (p != insn INSN_P (p)
(gdb) backtrace
#0 0x007a94f5 in reload_as_needed (live_known=1) at
../../gcc-4.3-20070907/gcc/reload1.c:4161
#1 0x007acb61 in reload (first=0x2b0f45955680, global=1) at
../../gcc-4.3-20070907/gcc/reload1.c:1146
#2 0x00b39c96 in rest_of_handle_global_alloc () at
../../gcc-4.3-20070907/gcc/global.c:683
#3 0x00761961 in execute_one_pass (pass=0x1001b60) at
../../gcc-4.3-20070907/gcc/passes.c:1115
#4 0x00761b40 in execute_pass_list (pass=0x1001b60) at
../../gcc-4.3-20070907/gcc/passes.c:1168
#5 0x00761b55 in execute_pass_list (pass=0xffd5a0) at
../../gcc-4.3-20070907/gcc/passes.c:1169
#6 0x0083de10 in tree_rest_of_compilation (fndecl=0x2b0f457c8400) at
../../gcc-4.3-20070907/gcc/tree-optimize.c:404
#7 0x009acb80 in cgraph_expand_function (node=0x2b0f45810700) at
../../gcc-4.3-20070907/gcc/cgraphunit.c:1077
#8 0x009aee20 in cgraph_optimize () at
../../gcc-4.3-20070907/gcc/cgraphunit.c:1146
#9 0x004aafed in cp_write_global_declarations () at
../../gcc-4.3-20070907/gcc/cp/decl2.c:3302
#10 0x007e48b7 in toplev_main (argc=Variable argc is not available.
) at ../../gcc-4.3-20070907/gcc/toplev.c:1058
#11 0x003a3d61c784 in __libc_start_main () from /lib64/libc.so.6
#12 0x00403d79 in _start ()
#13 0x7fb66e48 in ?? ()
#14 0x in ?? ()
(gdb) print p
$1 = 0x0
(gdb) print insn
$2 = 0x2b0f459890f0
(gdb) print *insn
$3 = {code = INSN, mode = VOIDmode, jump = 0, call = 0, unchanging = 0, volatil
= 0, in_struct = 0, used = 0, frame_related = 0, return_val = 0, u = {fld =
{{rt_int = 15, rt_uint = 15, rt_str = 0xafafafaf000f Address
0xafafafaf000f out of bounds,
rt_rtx = 0xafafafaf000f, rt_rtvec = 0xafafafaf000f, rt_type =
HImode, rt_addr_diff_vec_flags = {min_align = 15, base_after_vec = 0,
min_after_vec = 0, max_after_vec = 0, min_after_base = 0, max_after_base = 0,
offset_unsigned = 0, scale = 0},
rt_cselib = 0xafafafaf000f, rt_bit = 0xafafafaf000f, rt_tree =
0xafafafaf000f, rt_bb = 0xafafafaf000f, rt_mem = 0xafafafaf000f,
rt_reg = 0xafafafaf000f, rt_constant = 0xafafafaf000f}}, hwint =
{-5787213829993660401},
block_sym = {fld = {{rt_int = 15, rt_uint = 15, rt_str = 0xafafafaf000f
Address 0xafafafaf000f out of bounds, rt_rtx = 0xafafafaf000f,
rt_rtvec = 0xafafafaf000f, rt_type = HImode, rt_addr_diff_vec_flags =
{min_align = 15,
base_after_vec = 0, min_after_vec = 0, max_after_vec = 0,
min_after_base = 0, max_after_base = 0, offset_unsigned = 0, scale = 0},
rt_cselib = 0xafafafaf000f, rt_bit = 0xafafafaf000f, rt_tree =
0xafafafaf000f, rt_bb = 0xafafafaf000f,
rt_mem = 0xafafafaf000f, rt_reg = 0xafafafaf000f, rt_constant
= 0xafafafaf000f}, {rt_int = 1167626240, rt_uint = 1167626240, rt_str =
0x2b0f45989000 \005, rt_rtx = 0x2b0f45989000, rt_rtvec = 0x2b0f45989000,
rt_type = 1167626240,
rt_addr_diff_vec_flags = {min_align = 0, base_after_vec = 0,
min_after_vec = 0, max_after_vec = 0, min_after_base = 0, max_after_base = 1,
offset_unsigned = 0, scale = 152}, rt_cselib = 0x2b0f45989000, rt_bit =
0x2b0f45989000, rt_tree = 0x2b0f45989000,
rt_bb = 0x2b0f45989000, rt_mem = 0x2b0f45989000, rt_reg =
0x2b0f45989000, rt_constant = 0x2b0f45989000}, {rt_int = 1157078704, rt_uint =
1157078704, rt_str = 0x2b0f44f79eb0 \005, rt_rtx = 0x2b0f44f79eb0, rt_rtvec =
0x2b0f44f79eb0,
rt_type = 1157078704, rt_addr_diff_vec_flags = {min_align = 176,
base_after_vec = 0, min_after_vec = 1, max_after_vec = 1, min_after_base = 1,
max_after_base = 1, offset_unsigned = 0, scale = 247}, rt_cselib =
0x2b0f44f79eb0, rt_bit = 0x2b0f44f79eb0,
rt_tree = 0x2b0f44f79eb0, rt_bb = 0x2b0f44f79eb0, rt_mem =
0x2b0f44f79eb0, rt_reg = 0x2b0f44f79eb0, rt_constant = 0x2b0f44f79eb0}}, block
= 0x2b0f45948900, offset = -5787213829993660410}, rv = {cl = 3, decimal = 1,
sign = 1, signalling = 0,
canonical = 0, uexp = 0, sig = {47344592130048, 47344581582512,
47344591866112}}, fv = {data = {low = 12659530243715891215, high =
47344592130048}, mode = 1157078704}}}
--
lloyd
[Bug c++/33736] New: error: integer constant is too large for �long� type incorrect for C++0x
Integer constants that don't fit into a long cause a pedwarn in GCC as of the 20070907 snapshot (this has been the behavior for a while). However this is incorrect for C++0x which does (at least in the WG draft) allows for something to be placed in a long long or unsigned long long if it doesn't fit into anything smaller (section 2.13.1.2 + table 5). However GCC pedwarns even with -std=c++0x or -std=gnu++0x (On x86-64 or other 64-bit machines this behavior can be observed while compiling with -m32). $ g++-4.3-20070907 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907 --enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt Thread model: posix gcc version 4.3.0 20070907 (experimental) (GCC) -- Summary: error: integer constant is too large for long type 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 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=33736
[Bug c++/13358] long long and C++ do not mix well
--- 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 or unsigned long long just as in C99. I think that would mean this warning should be disabled (in C++0x mode) on all platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
[Bug tree-optimization/31966] Miscompiles valid code with -ftree-vectorize and -march=nocona
--- 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 is also required; a binary compiled with -Os produces the correct value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug c++/32525] New: Request for new warning: useless dynamic_casts
It might be useful for GCC to warn about dynamic_casts which are not necessary.
For instance a dynamic_castT*(T*), or a dynamic_cast from a derived class to
a base class (there might be some corner cases here with multiple
inheritance?). I do see that such dynamic_casts are no-op'ed away (even without
any optimization flags! (at least in my toy test program)), which is certainly
positive. However it would be nice if the programmer was notified about them,
since even if there is no run-time cost, there is a source-level increase in
complexity which can easily be avoided (and there may well be run-time costs
involved with other compilers).
A quick example of the sort of thing I have in mind:
class base
{
public:
virtual int f() = 0;
virtual ~base() {}
};
class derived : public base
{
public:
int f() { return 1; }
};
#include stdio.h
int main()
{
derived* obj = new derived();
base* baseptr = dynamic_castbase*(obj); // warn: to a base class
derived* sametype = dynamic_castderived*(obj); // warn: same type
derived* from_base = dynamic_castderived*(baseptr); // ok
printf(%d %d %d %d\n,
obj-f(), baseptr-f(), sametype-f(), from_base-f());
}
(Compiling this on x86-64 shows GCC 4.1.0 is no-op'ing the first two
dynamic_casts, with or without optimization).
--
Summary: Request for new warning: useless dynamic_casts
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: 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
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- 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 the type of the casted-from pointer/reference is can be somewhat nontrivial. Warnings are for cases where either code may not do what you expect, or where a certain way of coding has a significant cost that can be avoided. I think that's a good definition. My impression is that dynamic_cast is fairly expensive, and while it is great that GCC noops out this case I suspect not all compilers will do the same; at this point I'm not even sure that GCC does it consistently. So I'd figure it a reasonable case for a warning as per your second condition. I doubt anyone will ever implement this. I've gotten used to that. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug c++/32525] Request for new warning: useless dynamic_casts
--- 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 in the future who searches the bug database know what the situation is. I'm sorry if I made it sound like I was expecting this to be implemented immediately or anything like that. That is not the case at all; even serious problems like code miscompilations can go a good while without being analyzed or fixed due to time and resource constraints, and something like this naturally falls much (much) deeper into the queue of things to work on. Thus my comment about being used to it, I know there is are many more interesting/important things to work on in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32525
[Bug tree-optimization/31966] New: Miscompiles valid code with -ftree-vectorize and -march=nocona
$ gcc-4.2.0 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2.0/configure --enable-languages=c,c++,objc,obj-c++ --program-suffix=-4.2.0 Thread model: posix gcc version 4.2.0 $ gcc-4.2.0 divop.c -o divop $ ./divop 3CBA83 $ gcc-4.2.0 -ftree-vectorize -O2 divop.c -o divop $ ./divop 3CBA83 $ gcc-4.2.0 -ftree-vectorize -O2 -march=opteron divop.c -o divop $ ./divop 3CBA83 $ gcc-4.2.0 -ftree-vectorize -O2 -march=nocona divop.c -o divop $ ./divop 2B672F This also affects GCC 4.1.1, I have not checked 4.1.2 or the 4.3 snapshots. In addition to -march=nocona it requires -O1/-O2/-O3 (-Os does not trigger it under 4.2.0, though it _does_ in 4.1.1). -- Summary: Miscompiles valid code with -ftree-vectorize and - march=nocona Product: gcc Version: 4.2.0 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 target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31966
[Bug tree-optimization/31966] Miscompiles valid code with -ftree-vectorize and -march=nocona
--- 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
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- 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 of the code generator, it's just a question
of propagating that information back to the frontend.
Speaking of the same warnings with-or-without optimizations - should I then
file a bug about:
int f(int x)
{
int y;
if(x)
return y;
return 0;
}
No warning about y being used uninitialized unless I compile with
optimizations...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug c/31878] New: Spurious warnings generated due to not optimizing first
$ cat return.c
#include assert.h
int f(int x) {
if(x)
return x;
assert(x);
}
$ gcc -O2 -c -Wall -W return.c
return.c: In function int f(int):
return.c:9: warning: control reaches end of non-void function
The call to assert expands to (glibc 2.4):
(static_castvoid ((x) ? 0 : (__assert_fail (x, return.c, 8,
__PRETTY_FUNCTION__), 0)));
So unless I'm missing something f() is equivalent to:
if(x)
return x;
else
__assert_fail(/* etc */);
However when explicitly written in this way, we don't get a warning:
$ cat return2.c
#include assert.h
int f(int x)
{
if(x)
return x;
else
__assert_fail (x, __FILE__, __LINE__, __PRETTY_FUNCTION__);
}
$ gcc -O2 -Wall -c return2.c
$
Looking at the produced assembly on an x86-64 system, GCC is only performing
the comparison once (when optimizing), so it should see that there is no
codepath that doesn't either return or call a noreturn function. However I'm
guessing warnings are generated prior to the optimizer running and thus don't
see this?
Marked as Severity: trivial because one can always insert a dummy return after
the assert. Which is good because AFAICT fixing this would require rewriting
GCC. :)
--
Summary: Spurious warnings generated due to not optimizing first
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot 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
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- 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 internals, but I have a hard time believing that GCC warning about something that cannot possibly happen is not a bug) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug c/28368] -std=c89 doesn't warn about gcc's ?: extension
--- 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' gives no warning. I'm not sure if it's really a bug, since the GCC docs make it pretty clear that -ansi et. al. are basically useless in terms of getting it to warn you about using extensions, but it is certainly unexpected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug c++/25826] New: pure virtual destructors accepted by GCC, but cause link failure
The following code:
class A
{
public:
virtual ~A() = 0;
};
class B : public A
{
public:
~B() {}
};
int main()
{
B b;
}
compiles with GCC 4.0.2 (clean with -ansi -Wall -Wextra) but does not link due
to an undefined reference to ~A(). Herb Sutter claims this code is valid, for
whatever that might be worth (http://www.gotw.ca/gotw/031.htm), but in either
case this seems to be a bug; either it should be rejected with a diagnostic as
invalid code, or it should link (and ideally do something sensible).
--
Summary: pure virtual destructors accepted by GCC, but cause
link failure
Product: gcc
Version: 4.0.2
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: 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
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- 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/show_bug.cgi?id=25826
[Bug c++/25826] pure virtual destructors accepted by GCC, but cause link failure
--- 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... Andrew, Gaby, sorry to distract you with the invalid bug report. I'll check the standard first next time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25826
