[Bug c/39620] New: wrong assumption of clobbered registers of inline assembly
I have the following code:
static inline void zeromem4b(uint32t *dst, uint32t count) {
asm volatile("xor %%eax,%%eax\n\trep stosl"
:
:"c"(count),"D"(dst)
:"%eax", "cc", "memory");
}
If I call it and after it want to, e.g. print out the value of *dst it gives me
the value which it has after running the function. That means that gcc thinks
that "%edi" hasn´t changed, but it did and I can not put it into the clobbered
list, because this gives me an error.
I compile with "-O2 -Wall -fno-builtin -march=i586".
--
Summary: wrong assumption of clobbered registers of inline
assembly
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: codemasterhs at yahoo dot de
GCC host triplet: cygwin
GCC target triplet: i586 elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39620
[Bug c/39620] wrong assumption of clobbered registers of inline assembly
--- Comment #2 from codemasterhs at yahoo dot de 2009-04-03 08:30 ---
Subject: Re: wrong assumption of clobbered registers of inline
assembly
The code is for my loader/os and so I can´t and do not want to use the
builtin functions.
Your 1st example works, but I find it a bit strange that I have to write
such code only to tell gcc, that 2 registers are clobbered! Your 2nd
example doesn´t work, because of the plus, this gives me an error.
I think the better way would be either gcc assumes that edi and ecx are
clobbered (which isn´t so) or I can specify that in the clobbered list
(which is not possible)!
jakub at gcc dot gnu dot org wrote:
> --- Comment #1 from jakub at gcc dot gnu dot org 2009-04-03 08:11 ---
> User error, if you don't tell gcc that %edi is clobbered, obviously it can
> assume it hasn't.
> As rep stosl modifies both %ecx and %edi, you can write e.g.:
> int tmp1, tmp2;
> asm volatile("xor %%eax,%%eax\n\trep stosl" : "=c" (tmp1), "=D" (tmp2) : "0"
> (count), "1" (dst) : "%eax", "cc", "memory");
> or:
> asm volatile("xor %%eax,%%eax\n\trep stosl" : "+c" (count), "+D" (dst) : :
> "%eax", "cc", "memory");
> if you don't mind that the count and dst variables will change.
> Also note that __builtin_memset (dst, '\0', count); will in most cases
> result in more optimal code for your CPU, hardcoding these in assembly is
> usually a bad idea.
>
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39620
[Bug c/42126] New: gcc optimizes line away/optimizes to an endless loop
The problem with the endless loop is in the function "smpAllocMsg". There gcc
makes out of the while loop ("freeList == 0") an endless loop.
The problem with the line which is optimized away is in the
smpSendMsgBroadcast, its the line "serviceMsg= msg". This problem can be
avoided if I call another function (I tested printf) before the while loop
(msg->refCount > 0).
These 2 problems only occur if I use the "-O2" switch with "-O1" it works.
What I do not understand is, why is gcc doing that, although I´m using the
volatile keyword!?
--
Summary: gcc optimizes line away/optimizes to an endless loop
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: codemasterhs at yahoo dot de
GCC host triplet: cygwin
GCC target triplet: i586-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #1 from codemasterhs at yahoo dot de 2009-11-20 22:28 --- Created an attachment (id=19070) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19070&action=view) the out from gcc with -v -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #3 from codemasterhs at yahoo dot de 2009-11-20 22:50 --- (In reply to comment #2) > Neither freeList nor serviceMsg are volatile. Thus freeList can never change > and serviceMsg = msg is a dead assignment. > But they are, or is my syntax wrong? static volatile struct smpMsg_t *serviceMsg; static volatile struct smpMsg_t *freeList; -- codemasterhs at yahoo dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #5 from codemasterhs at yahoo dot de 2009-11-21 09:02 --- (In reply to comment #4) > The pointer is not declared volatile. > > static struct smpMsg_t * volatile freeList; > > would be a volatile pointer. > Ok, this worked. So where has to be the volatile keyword, so that everything works? I mean I thought "volatile TYPE (like int, char and so on) foo" is right, isn´t it? Or does this only not work for pointers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug c++/49289] New: eh_frame section created although using -fno-exceptions and fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49289
Summary: eh_frame section created although using
-fno-exceptions and fno-rtti
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: codemaste...@yahoo.de
This is the code:
class Foo {
public:
void foo();
};
void test() {
Foo bar;
bar.foo();
}
This is the commandline to compile:
-O2 -fno-exceptions -fno-rtti -c
Output from "gcc -v":
Using built-in specs.
COLLECT_GCC=C:\MinGW\msys\1.0\local\cross\bin\i586-elf-gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/msys/1.0/local/cross/bin/../libexec/gcc/i586-elf/4.
6.0/lto-wrapper.exe
Target: i586-elf
Configured with: ../gcc-4.6.0/configure --with-gmp=/usr/local --target=i586-elf
--prefix=/usr/local/cross --disable-nls --enable-languages=c,c++
--without-heade
rs
Thread model: single
gcc version 4.6.0 (GCC)
[Bug c++/49289] eh_frame section created although using -fno-exceptions and fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49289 --- Comment #2 from Tobias Schlegl 2011-06-05 13:49:07 UTC --- > on x86_64 you want -fno-asynchronous-unwind-info. Eh-frame is mandated by the > PS-ABI. Yeah, but I´m compiling for i586, so x86_32!
[Bug c++/49289] eh_frame section created although using -fno-exceptions and fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49289 --- Comment #4 from Tobias Schlegl 2011-06-05 15:54:32 UTC --- > Oh it is done so that people can unwind as the frame pointer is omitted. Try > with -fno-omit-frame-pointer or -fno-asynchronous-unwind-info . -fno-asynchronous-unwind-info doesn´t exist (in my gcc), but -fnoasynchronous-unwind-table and with it the eh_frame section is gone. -fno-omit-frame-pointer exists, but with it the eh_frame section is also created.
[Bug inline-asm/36514] New: inline assembly generates wrong code
The inline assembly I use in one function generates code which the assembler
does not understand (it generates a non existant cpu register).
This is the commandline output:
Using built-in specs.
Target: i586-elf
Configured with: ../gcc-4.3.1/configure --target=i586-elf --prefix=/usr/cross
--
disable-nls --enable-languages=c,c++ --without-headers --with-newlib
Thread model: single
gcc version 4.3.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=pentium'
/usr/cross/libexec/gcc/i586-elf/4.3.1/cc1.exe -E -quiet -v gzip.c
-mtune=pentiu
m -O2 -fpch-preprocess -o gzip.i
ignoring nonexistent directory
"/usr/cross/lib/gcc/i586-elf/4.3.1/../../../../i5
86-elf/sys-include"
ignoring nonexistent directory
"/usr/cross/lib/gcc/i586-elf/4.3.1/../../../../i5
86-elf/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/cross/lib/gcc/i586-elf/4.3.1/include
/usr/cross/lib/gcc/i586-elf/4.3.1/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=pentium'
/usr/cross/libexec/gcc/i586-elf/4.3.1/cc1.exe -fpreprocessed gzip.i -quiet
-dum
pbase gzip.c -mtune=pentium -auxbase gzip -O2 -version -o gzip.s
GNU C (GCC) version 4.3.1 (i586-elf)
compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd
0.
125), GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 51cdd6038f6ef46be90f22b7598c4d3c
In file included from gzip.c:4:
printf.h:9: warning: conflicting types for built-in function 'printf'
printf.h:11: warning: conflicting types for built-in function 'putchar'
COMPILER_PATH=/usr/cross/libexec/gcc/i586-elf/4.3.1/:/usr/cross/libexec/gcc/i586
-elf/4.3.1/:/usr/cross/libexec/gcc/i586-elf/:/usr/cross/lib/gcc/i586-elf/4.3.1/:
/usr/cross/lib/gcc/i586-elf/:/usr/cross/lib/gcc/i586-elf/4.3.1/../../../../i586-
elf/bin/
LIBRARY_PATH=/usr/cross/lib/gcc/i586-elf/4.3.1/:/usr/cross/lib/gcc/i586-elf/4.3.
1/../../../../i586-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=pentium'
=
This is the .i file:
# 1 "gzip.c"
# 1 ""
# 1 ""
# 1 "gzip.c"
# 1 "gzip.h" 1
# 1 "typedef.h" 1
typedef unsigned char uint8t;
typedef unsigned short uint16t;
typedef unsigned int uint32t;
typedef unsigned long long int uint64t;
# 5 "gzip.h" 2
# 22 "gzip.h"
#pragma pack(1)
struct gzip_hdr_t {
uint8t id1;
uint8t id2;
uint8t cm;
uint8t flg;
uint32t mtime;
uint8t xfl;
uint8t os;
};
#pragma pack()
uint32t gzipIsGZip(uint8t *file);
uint32t gzipUnzip(uint8t *file, void *dest);
uint8t getNextBit(uint8t *ptr, uint32t *posByte, uint8t *posBit);
# 2 "gzip.c" 2
# 1 "printf.h" 1
# 9 "printf.h"
void printf(char *format, ...);
void printfTrace(char *format, ...);
void putchar(char c);
void putcharTrace(char c);
void itoa(char *str, int num, uint32t base, uint32t flags);
void strreverse(char *begin, char *end);
uint32t getxy();
void setxy(uint32t x, uint32t y);
void scroll_down();
# 4 "gzip.c" 2
uint32t gzipIsGZip(uint8t *file) {
struct gzip_hdr_t *gzip= (struct gzip_hdr_t *)file;
if(gzip->id1 != 0x1f)
return 0;
if(gzip->id2 != 0x8b)
return 0;
if(gzip->cm != 8)
return 0;
return 1;
}
uint32t gzipUnzip(uint8t *file, void *dest) {
struct gzip_hdr_t *gzip= (struct gzip_hdr_t *)file;
uint8t *ptr, final, type, posBit;
uint16t crc16, len, *help;
uint32t posByte;
if(!gzipIsGZip(file))
return 0;
ptr= file + sizeof(struct gzip_hdr_t);
if(gzip->flg & 0x4) {
ptr+= (uint16t)*ptr;
}
if(gzip->flg & 0x8) {
while(*ptr != '\0') {
ptr++;
}
}
if(gzip->flg & 0x10) {
while(*ptr != '\0') {
ptr++;
}
}
if(gzip->flg & 0x2) {
crc16= *ptr;
ptr++;
}
posByte= 0;
posBit= 0;
do {
final= getNextBit(ptr,&posByte,&posBit);
type= (getNextBit(ptr,&posByte,&posBit) << 1) |
getNextBit(ptr,&posByte,&posBit);
if(type == 0x3)
return 0;
if(type == 0x0) {
if(posBit != 0) {
posBit= 0;
posByte++;
}
help= (uint16t *)((uint32t)ptr + posByte);
len= *help;
} else {
if(type == 0x2) {
}
}
}while(!final);
return 1;
}
uint8t getNextBit(uint8t *ptr, uint32t *posByte, uint8t *posBit) {
uint8t *help= ptr + *posByte, res;
asm volatile("testb %2,%1\n\t"
"setne %0"
:"=r"(res)
:"r"(*help),"r"((uint8t)(1 << *posBit)));
if(*posBit == 7) {
*posBit= 0;
(*posByte)++;
} else {
(*posBit)++;
}
return res;
}
--
Summary: inline assembly generates wrong code
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: codemasterhs at yahoo dot de
GCC host triplet: cygwin
GCC target triplet: i586-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36514
