[Bug c/33674] New: Nonexistent i386 register name `%SIL' used
GCC tries to use a register `%SIL' in my test on an i386 machine. However, the
lowest 8 bits of ESI can be directly accessed only in x86-64, but not i386. I
also observe in other tests the use of another two bad register names `%DIL'
and `%BPL'.
The following code can reproduce the bug:
static inline char contain (const char *ptr, int len, char c)
{
charr;
int od,oc;
asm volatile (
"cld\n\t"
"repnz scasb\n\t"
"sete %0"
:"=r"(r),"=D"(od),"=c"(oc)
:"c"(len),"a"(c),"D"(ptr)
);
return r;
}
__attribute__((regparm(3)))
int test(int a, int b, int c, int d, const char *buf, int len, int ch)
{
d += a * b;
if (contain (buf, len, ch))
a++;
return a+b+c+d;
}
The command line and the error message:
$ gcc -save-temps -O1 -c test.c -Wall -Wextra
test.s: Assembler messages:
test.s:21: Error: bad register name `%sil'
I checked the assembly output and found that GCC had allocated `%SIL' for `r'
in function `contain'.
The following is my GCC version info:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-6)
--
Summary: Nonexistent i386 register name `%SIL' used
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richardpku at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33674
[Bug target/43215] New: x86-64: Nonstandard instruction "movd %xmm0, %rax"
#include
uint64_t extract_double (double x)
{
union {
double dbl;
uint64_t u;
} t;
t.dbl = x;
return t.u;
}
Compile this function with "x86_64-pc-linux-gnu-gcc -O2 -march=core2 -S a.c",
and we get the following assembly codes:
extract_double:
.LFB0:
.cfi_startproc
movd%xmm0, %rax
ret
The instruction "movd %xmm0, %rax" is nonstandard. Movd should be replaced by
movq.
(GNU assembler silently accepts it as if it were "movq %xmm0, %rax", so it
probably has caused no practical problems.)
--
Summary: x86-64: Nonstandard instruction "movd %xmm0, %rax"
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richardpku at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43215
[Bug inline-asm/68084] New: Inverted conditions generated for x86 inline assembly "flag output constraints"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68084
Bug ID: 68084
Summary: Inverted conditions generated for x86 inline assembly
"flag output constraints"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: richardpku at gmail dot com
Target Milestone: ---
I have been trying out the new "flag output constraints" feature in inline
assembly ("=@ccCC"), and have found GCC sometimes incorrectly generates
inverted conditions in assembler code.
The minimal test case is as follows:
_Bool dec_ref(unsigned *p)
{
_Bool r;
asm ("cmp %2, %1" : "=@ccae"(r) : "m"(*p), "ri"(2));
if (r)
return __atomic_sub_fetch(p, 1, __ATOMIC_RELEASE) == 0;
return 1;
}
GCC (6.0.0 20151024) generates the following assembler code:
dec_ref:
cmp $2, (%rdi)
movl$1, %eax
jc .L7
rep ret
.p2align 4,,10
.p2align 3
.L7:
lock subl $1, (%rdi)
sete%al
ret
where "jc" is incorrect. It should be "jnc".
Interestingly, GCC generates the expected code if "=@ccae" is written as
"=@ccnb" (ae and nb are synonymous).
[Bug c++/68246] New: Incorrect evaluation of C++1z fold expressions (... || expr) in concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68246 Bug ID: 68246 Summary: Incorrect evaluation of C++1z fold expressions (... || expr) in concepts Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richardpku at gmail dot com Target Milestone: --- template concept bool A_concept = (... || (x < 0)); template constexpr bool A_constexpr = (... || (x < 0)); static_assert(A_concept<-1, 1>); // This assertion fails, while it should not static_assert(A_constexpr<-1, 1>); // OK. Both static assertions should not fail. It appears "&&" doesn't has this problem: template concept bool B_concept = (... && (x < 0)); template constexpr bool B_constexpr = (... && (x < 0)); static_assert(B_concept<-1, -1>); // OK static_assert(B_constexpr<-1, -1>); // OK
[Bug lto/44184] New: "asm goto" does not work with LTO
Consider this file:
#include
int x = 1;
int main ()
{
asm goto ("decl %0; jnz %l[a]" :: "m"(x) : "memory" : a);
printf ("Hello world\n");
a:
return 0;
}
It compiles and links correctly without LTO.
But with LTO, "gcc-4.5.0 -flto a.c", there is an error:
In file included from :0:0:
a.c: In function 'main':
a.c:7:2: error: invalid 'asm': operand number out of range
lto-wrapper: /usr/bin/gcc-4.5.0 returned 1 exit status
collect2: lto-wrapper returned 1 exit status
--
Summary: "asm goto" does not work with LTO
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richardpku at gmail dot com
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=44184
[Bug libstdc++/99181] New: char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181
Bug ID: 99181
Summary: char_traits (and thus string_view) compares
strings differently in constexpr and non-constexpr
contexts
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: richardpku at gmail dot com
Target Milestone: ---
Minimal program to produce bug (run it on a platform where char is a signed
type, such as i386/x86-64):
/tmp % cat a.cpp
#include
#include
using namespace std;
int main() {
// constexpr
constexpr bool i = ("\xff"sv > "aaa"sv);
cout << i << ",";
// not constexpr
auto a = "\xff"sv, b = "aaa"sv;
cout << (a > b) << endl;
return 0;
}
/tmp % g++ -std=gnu++2a a.cpp && ./a.out
0,1
The expected result is "1,1".
In a non-constexpr context, std::char_traits::compare invokes
__builtin_memcmp, which is required by C standard to interpret characters as
unsigned char.
In a constexpr context, however, std::char_traits::compare invokes
__gnu_cxx::char_traits::compare, which in turn calls
__gnu_cxx::char_traits::lt to compare chars.
__gnu_cxx::char_traits::lt (unlike std::char_traits::lt) is not
specialized to compare chars as unsigned char.
[Bug c++/100588] New: Destroying delete shouldn't be called if constructor throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100588
Bug ID: 100588
Summary: Destroying delete shouldn't be called if constructor
throws
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richardpku at gmail dot com
Target Milestone: ---
Consider this program:
#include
#include
class A {
public:
A() { throw 42; }
~A() { puts("A::~A"); }
void operator delete(void* p) {
puts("regular delete invoked");
::operator delete(p);
}
void operator delete(A* p, std::destroying_delete_t) {
puts("destroying delete invoked");
p->~A();
::operator delete(p);
}
};
int main() {
try {
new A;
} catch (int) {
}
}
Output compiled with GCC:
destroying delete invoked
A::~A
Output compiled with Clang:
regular delete invoked
I believe clang has the correct behavior.
A destroying delete function is expected to invoke the destructor explicitly.
As a result, the current GCC implementation would indirectly invoke the
destructor on an instance that wasn't successfully constructed, which obviously
isn't the intended behavior.
It is even worse if class A has a base class, in which case the destructor of
the base class is called twice if an exception is thrown in A's constructor.
[Bug libstdc++/100889] New: Wrong param type for std::atomic_ref<_Tp*>::wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889
Bug ID: 100889
Summary: Wrong param type for std::atomic_ref<_Tp*>::wait
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: richardpku at gmail dot com
Target Milestone: ---
/tmp % cat a.cpp
#include
void* p;
void foo() { std::atomic_ref(p).store(nullptr); }
/tmp % g++-11.1.0 -c -std=gnu++20 a.cpp
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/atomic:41,
from a.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h: In
instantiation of 'struct std::__atomic_ref':
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/atomic:1618:12:
required from 'struct std::atomic_ref'
a.cpp:3:31: required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h:1873:7:
error: invalid parameter type 'void'
1873 | wait(_Tp __old, memory_order __m = memory_order_seq_cst) const
noexcept
| ^~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h:1873:7:
error: in declaration 'void std::__atomic_ref<_Tp*, false, false>::wait(_Tp,
std::memory_order) const'
Apparently, the first param of std::atomic<_Tp*>::wait should be _Tp* instead
of _Tp.
It appears this bug has existed since GCC 11, when __cpp_lib_atomic_wait was
implemented.
[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889 --- Comment #1 from Richard Li --- Created attachment 50917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50917&action=edit Proposed patch This patch fixes the problem.
