cuted.
-- Till
Andrew Haley wrote:
H.J. Lu wrote:
On Mon, Jun 22, 2009 at 11:14 AM, Till
Straumann wrote:
Andrew Haley wrote:
Till Straumann wrote:
gcc-4.3.2 seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to acc
Andrew Haley wrote:
Till Straumann wrote:
gcc-4.3.2 seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to access multiple
such objects in a 'parallel' fashion.
E.g., instead of reading two consecutive
'volatile short's
gcc-4.3.2 seems to produce bad code when
accessing an array of small 'volatile'
objects -- it may try to access multiple
such objects in a 'parallel' fashion.
E.g., instead of reading two consecutive
'volatile short's sequentially it reads
a single 32-bit longword. This may crash
e.g., when access
Hi.
What is the proper way to tell gcc that a
inline assembly statement either modifies
a particular area of memory or needs it
to be updated/in-sync because the assembly
reads from it.
E.g., assume I have a
struct blah {
int sum;
...
};
which is accessed by my assembly code.
int my_chksu
Andreas Schwab wrote:
Till Straumann <[EMAIL PROTECTED]> writes:
asm volatile ("lwz %0, 16(%1)":"=r"(val):"b"(base),"m"(*reg_p));
asm volatile ("lwz%U1%X1 %0, %1":"=r"(val):"m"(*reg_p));
Hmm - t
Andreas Schwab wrote:
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
On Mon, Mar 31, 2008 at 03:06:24PM +0200, Andreas Schwab wrote:
The side effect is carried out by using %U0, which expands to u for a
PRE_{INC,DEC,MODIFY} operand. There is no way to encode that in the
insn operand it
Andreas Schwab wrote:
Till Straumann <[EMAIL PROTECTED]> writes:
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); }
while (0)
Looking closer, your asm statement has a bug. The "m&qu
Daniel Jacobowitz wrote:
On Wed, Mar 26, 2008 at 09:25:05AM -0700, Till Straumann wrote:
Is my inline assembly wrong or is this a gcc bug ?
Your inline assembly seems wrong.
I'm not yet convinced about that...
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm vol
As of gcc-4.3.0 one of my drivers stopped working.
I distilled the code down to a few lines (see below).
The output of
gcc-4.3.0 -S -O2 -c tst.c
and
gcc-4.2.3 -S -O2 -c tst.c
is attached. The code generated by gcc-4.2.3 is as expected.
However, gcc-4.3.0 does not produce a correct resul
The issue of gcc implicitely generating floating point
instructions (i.e., without 'double' or 'float' types
being used in the source code) has come up a few times
in the past (e.g., 2002/10: GCC floating point usage)
Miraculously, I found that gcc-4.0.2 (unlike 3.2 or 3.4)
no longer generates a
10 matches
Mail list logo
