Quoting Steven Bosscher <[EMAIL PROTECTED]>:
> On 12/13/06, Joern Rennecke <[EMAIL PROTECTED]> wrote:
> > In http://gcc.gnu.org/ml/gcc/2006-12/msg00328.html, you wrote:
> > However, because the SH has delayed branches, there is always a guaranteed
> way
> > to find a register - one can be saved, a
> static __inline__ void atomic_add(atomic_t *v, int i)
> {
> __asm__ __volatile__("addl %1,%0" : "+m" (*v) : "d" (i));
> }
>
> Then the compiler complains with:
>
> /asm/atomic.h:33: warning: read-write constraint does not allow a register
>
> So is the warning wrong?
Yes, the warning is wr
Quoting Jason Merrill <[EMAIL PROTECTED]>:
> Well, I assumed the same thing when I started poking at that code, but then
> someone pointed out that it didn't actually work that way, and as I recall
> the code does in fact assume a register. I certainly would not object to
> making '+' work proper
>> cvs would never do such nonsense.
>Absolutely! It would just print all the directory names in the middle of the
>diffs. I call that nonsense as well.
But the directory names go to stderr. When you redirect stdout to a file,
a diff without the directory names is written to that file, while yo
Quoting "Paulo J. Matos" :
That's seriously annoying. The idea was to ditch cc0 and explicitly
represent CC in a register to perform optimizations like splitting add
and addc for a double word addition. If by hiding my register flags
means going back to cc0, then it seems that the only way to go
Quoting Hans-Peter Nilsson :
On Fri, 23 Sep 2011, Joern Rennecke wrote:
Quoting "Paulo J. Matos" :
> My addition instruction sets all the flags. So I have:
This is annoying, but can be handled. Been there, done that.
dse.c needs a small patch, which I intend to submit sometime in the future
Quoting Stefan Dösinger :
I talked to Alexandre again, and his main concern wasn't so much the global
flag, but that the existance of the push %ebp; mov %esp, %ebp was still up
to the feelings of the compiler and the moon phase.
So what he wants is something like a msvc_prolog attribute that ma
Quoting Stefan Dösinger :
If the frame pointer is not needed:
mov.s %edi, %edi
push %ebp
mov.s %esp, %ebp
pop %ebp
; Continue normally here. I think that case can't be improved too much,
since the msvc_prolog stuff modifies the base pointer.
If ebp needs to be saved because it contains a use
Quoting Stefan Dösinger :
Here's some code attached that actually works, but is far from perfect.
The 'msvc_prologue' attribute is limited to 32 bit. None of the applications
that try to place hooks are ported to Win64 yet, so it is impossible to tell
what they'll need. Besides, maybe I am luck
Quoting Ian Lance Taylor :
Joern Rennecke writes:
Quoting Manuel López-Ibáñez :
2009/1/29 Joern Rennecke :
The runtime library license says that you can link libgcc with
proprietary code, whether that proprietary code was compiled with gcc
or whether it was compiled with some non-gcc pro
Quoting Paulo Matos :
Hello,
I am trying to model a predicate register mode that acts like a
vector. We have a few predicate registers that have 8 bits in size
but they are set accordingly to the mode of operation (not
necessarily a comparison). Word size is 64.
Yes need some surgery
Quoting "Lu, John" :
However, if I modify the function so that one of the factors is reused,
long f1(long a, long b, long c) {
res0=((long long) a)*((long long) b);
res1=((long long) c)*((long long) b);
}
combine will not fuse the reused sign-extension result to generate th
Quoting BELBACHIR Selim :
Any ideas on how to get around this problem?
You can look at the name of library functions.
Quoting "H.J. Lu" :
What is the expect run-time behavior when a + b has
overflow/underflow?
The expectation is wrap-around. Note that loop strenght reduction can
cause assumed wrap-around semantics in RTL for strictly conforming C input
where no such wrap-around is in evidence.
Quoting "H.J. Lu" :
What is the run-time result when overflow happens?
Assuming you use a 32 bit unsigned base address, and the space beyond 4G
is unmapped, you'll get a SEGV.
Somehow this got stuck in the spam filter.
- Forwarded message from [EMAIL PROTECTED] -
Date: Sat, 01 Mar 2008 09:21:21 -0500
From: Joern Rennecke <[EMAIL PROTECTED]>
Reply-To: Joern Rennecke <[EMAIL PROTECTED]>
Subject: Re: [PATCH][4.3] Deprecate -ftrapv
To: gcc@gcc.gnu.or
16 matches
Mail list logo
