[Bug c++/49289] eh_frame section created although using -fno-exceptions and fno-rtti

2011-06-05 Thread codemasterhs at yahoo dot de
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´

[Bug c++/49289] eh_frame section created although using -fno-exceptions and fno-rtti

2011-06-05 Thread codemasterhs at yahoo dot de
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] New: eh_frame section created although using -fno-exceptions and fno-rtti

2011-06-05 Thread codemasterhs at yahoo dot de
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

[Bug c/42126] gcc optimizes line away/optimizes to an endless loop

2009-11-21 Thread codemasterhs at yahoo dot de
--- 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 volatil

[Bug c/42126] gcc optimizes line away/optimizes to an endless loop

2009-11-20 Thread codemasterhs at yahoo dot de
--- 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 volati

[Bug c/42126] gcc optimizes line away/optimizes to an endless loop

2009-11-20 Thread codemasterhs at yahoo dot de
--- 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] New: gcc optimizes line away/optimizes to an endless loop

2009-11-20 Thread codemasterhs at yahoo dot de
word!? -- 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 Rep

[Bug c/39620] wrong assumption of clobbered registers of inline assembly

2009-04-03 Thread codemasterhs at yahoo dot de
--- 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

[Bug c/39620] New: wrong assumption of clobbered registers of inline assembly

2009-04-03 Thread codemasterhs at yahoo dot de
: 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 inline-asm/36514] New: inline assembly generates wrong code

2008-06-12 Thread codemasterhs at yahoo dot de
quot;(*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