Note that at -O3 there is a difference still:
clang (3.6.0):
addl%esi, %edi
movl%edi, %eax
retq
gcc (4.9.2)
leal(%rdi,%rsi), %eax
ret
Can't tell which is best, if any.
OG.
On Tue, May 12, 2015 at 4:06 AM, wrote:
>
>
>
>
>> On May 11, 2015
On Mon, Apr 26, 2010 at 02:00:30PM -0400, Richard Kenner wrote:
> Olivier Galibert wrote:
> > You can't force some entity to release source code they have
> > copyright to, that's not part of the legal remedies that are
> > available to a judge.
>
> What makes
On Mon, Apr 26, 2010 at 07:03:25PM +0200, Steven Bosscher wrote:
> There is so much negativism about a mere nuisance in this thread. It's
> a shame, but I guess it's just more proof that negative discussions
> about GCC are more popular than positive ones.
Seriously, depending on the country it's
On Mon, Apr 26, 2010 at 09:53:51AM -0700, Chris Lattner wrote:
> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
> able to enforce copyright is pretty useless IMO. While you can
> force someone to release their code, the GPL doesn't force them to
> assign the copyright to the
On Sun, Apr 25, 2010 at 12:36:46PM -0400, Richard Kenner wrote:
> I said "A" large part. There is certainly a perception that the
> copyright assignment is an issue too. But, as was discussed here, there
> IDENTICAL liability with and without the assignment. So this is illusory.
Oh please. Ask
On Sat, Jan 23, 2010 at 09:21:47AM -0500, Joern Rennecke wrote:
> [This started on gcc-patches]
> Quoting Richard Guenther :
[...]
> > bool all_critical_edge_p = true;
> > all_critical_edge_p &= e->flags & EDGE_CRITICAL;
[...]
> I think a better long-term plan would be to add an option to insert
On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote:
> If the kernel allows state to leak from one process to another,
> for example from a process running as root to a process running as an
> ordinary user, it's a bug, with possible security implications.
I don't think that it is relevant in
On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> >>It's a kernel bug, and it needs to be fixed.
> >
> >I'm not convinced. It's been that
On Wed, Mar 05, 2008 at 03:21:43PM -0800, David Daney wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> >>FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
> >>and happens seldomly if
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere else. And in gcc for blindl
On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
> and happens seldomly if at all. And only on unfixed kernels. A program
> needs to do std explicitely, which most don't do _and_ get hit by a signal
> whil
On Thu, Mar 06, 2008 at 12:13:04AM +0200, Adrian Bunk wrote:
> Compiling older kernels with new gcc versions has never been supported.
You read the thread too fast. It's not at all about compiling the
kernel.
OG.
On Thu, Mar 06, 2008 at 12:07:39AM +0100, Michael Matz wrote:
> For security problems I prefer fixes over work-arounds. The fix lies in
> the kernel, the work-around in gcc.
Incorrect. The bugs are in the ABI documentation and in gcc, and the
fixes should be done there. Doing it in the kernel
On Mon, Dec 03, 2007 at 04:16:17PM +0300, [EMAIL PROTECTED] wrote:
> Have you got a chance to take a look at the materials?
> If yes, what do you think on it?
Nope, sorry, too busy with other things.
OG.
On Fri, Nov 23, 2007 at 11:49:03AM +0300, [EMAIL PROTECTED] wrote:
[Changing the _vptr or C equivalent dynamically]
> I would like the community would have considered the idea. I am ready to
> answer all the questions you might have.
Changing the virtual function pointer dynamically using a seria
On Sat, Nov 03, 2007 at 03:38:51AM +1100, skaller wrote:
> My argument is basically: there is no need for any such
> feature in a well written program. Each thread already has
> its own local stack. Global variables should not be used
> in the first place (except for signals etc where
> there is no
On Sat, Nov 03, 2007 at 03:31:14AM +1100, skaller wrote:
> On Fri, 2007-11-02 at 07:39 -0700, Ian Lance Taylor wrote:
> > I think you need to look at the TLS access code before deciding that
> > it has bad performance.
>
> You already said it costs a register? That's a REALLY high cost
> to pay t
On Wed, Oct 03, 2007 at 12:24:27PM +0200, Manfred Schwarb wrote:
> I'm in a loss where to search for the real cause. Has anybody a hint
> how to proceed further?
Sounds like weird-but-somewhat-determinist behaviour you can get when
you do out-of-bounds access on the stack or this kind of problems.
On Thu, Mar 01, 2007 at 04:51:24PM -0800, Andrew Pinski wrote:
> If someone wants a patch committed they will ping it
> a couple of times and if they lost interest because they now decide it
> is not a good thing or they no longer care about it, it will just fall
> down the way side.
If it's a new
On Fri, Dec 01, 2006 at 07:57:51PM -0800, Andrew Pinski wrote:
> On Fri, 2006-12-01 at 17:21 +, Al Viro wrote:
> > The thing is, absolute majority of callbacks really want a pointer to
> > some object. There is a handful of cases where we really want a genuine
> > number - not a pointer cast t
On Sun, Nov 12, 2006 at 02:46:58PM -0800, Michael Eager wrote:
> It would seem that the place to require the personality
> routine would be in the routine which causes the stack
> unwinding, not in every C++ object file, whether needed
> or not.
Doesn't that otherwise very valid point of view brea
On Thu, Apr 20, 2006 at 04:52:14PM +0100, Dave Korn wrote:
> Yet it would seem to me at first glance that, since dividing unsigned by an
> exact power-of-2 can be optimised to a right shift, and since we can deduce
> that (1 << bpp) is always going to be a power-of-2
Isn't that true only if bpp
On Thu, Apr 20, 2006 at 08:38:00AM -0700, H. J. Lu wrote:
> On Thu, Apr 20, 2006 at 05:18:08PM +0200, Olivier Galibert wrote:
> > I need to be able to do unaligned memory accesses to memory in
> > big-endian or little-endian mode. For portability, I'd like to do it
> > i
I need to be able to do unaligned memory accesses to memory in
big-endian or little-endian mode. For portability, I'd like to do it
in pure C, but I'd like the compiler to generate optimal sequences for
the operations. Most CPUs that I know of even have special
instructions designed to speed up p
On Sun, Jul 17, 2005 at 11:56:46AM -0700, Geoffrey Keating wrote:
> "D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
> > An object that has volatile-qualified type may be modified in ways
> > unknown to the implementation or have other unknown side
> > effects. Therefore any expression referring to
On Wed, Jul 13, 2005 at 01:28:14AM +0200, Falk Hueffner wrote:
> You're missing my point; size_t was just an example, whoever does this
> will know what the correct type is for their system. All I'm saying
> is that we shouldn't go to the trouble to document and kick along some
> language extensio
On Wed, Jun 29, 2005 at 02:12:40PM +0100, Dave Korn wrote:
> In fact, doesn't this suggest that in _most_ circumstances, *saturation*
> would be the best behaviour?
No, you'd be killing most emulators and a lot of virtual machine
implementations.
char x = (char)((unsigned char)y + (unsigned c
On Tue, Jun 28, 2005 at 02:44:40PM -0700, Joe Buck wrote:
> I challenge you, Robert, to find us a C compiler that generates trapping
> instructions for integer adds by default. I do not believe that such a
> compiler exists.
Perusing the manpage of SGI's cc and CC on IRIX, there isn't even an
opt
On Tue, Jun 28, 2005 at 02:52:10PM -0400, Robert Dewar wrote:
> Olivier Galibert wrote:
> >On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
> >
> >> It certainly wasn't meant to be. It was meant to be a dispassionate
> >>description of the state o
On Tue, Jun 28, 2005 at 07:36:00PM +0100, Dave Korn wrote:
> Original Message
> >From: Olivier Galibert
> >Sent: 28 June 2005 19:02
>
> > On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
> >> It certainly wasn't meant to be. It was meant
On Tue, Jun 28, 2005 at 10:50:39AM -0700, Joe Buck wrote:
> On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
> > On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
> > > This is childish and insulting.
> >
> > Calling a large part of the p
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
> It certainly wasn't meant to be. It was meant to be a dispassionate
> description of the state of facts. Software that violates the C standard
> just *is* "buggy" or "incorrect", and your personal pride has absolutely
> nothing to do
On Tue, Jun 28, 2005 at 12:59:10PM -0400, Morten Welinder wrote:
> > In particular, a very large number of C and C++ programs are written
> > with the assumptions:
>
> >- signed and unsigned types are modulo, except in loop induction
> > variables where it's bad taste
>
> Well, as demonstrated by
On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
> Olivier Galibert writes:
> > On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
> > > Original Message----
> > > >From: Olivier Galibert
> > > >Sent: 28 June 2005 15:25
&g
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
> Original Message
> >From: Olivier Galibert
> >Sent: 28 June 2005 15:25
>
> > In particular, a very large number of C and C++ programs are written
> > with the assumptions:
>
> This i
On Tue, Jun 28, 2005 at 10:30:39PM +0800, Jonathan Wilson wrote:
> >- sizeof(int) == 4, sizeof(long long) == 8
> I swear 16 bit compilers have sizeof(int) = 2 with sizeof(long) = 4
Yes, and some computers have 9-bit bytes too. Tried running linux,
gnome, kde, gimp, cdrecord, mame, qemu... on them
On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
> But the whole idea of hardware semantics is bogus, since you are
> assuming some connection between C and the hardware which does not
> exist. C is not an assembly language.
A non-negligible part of the use of C and even C++ is as a h
On Fri, May 27, 2005 at 12:26:13AM +0200, Gabriel Dos Reis wrote:
> If it was and angle! Not everything that is an argument to sin or cos
> is an angle. They are just functions! Suppose you're evaluating an
> approximation of a Fourrier series expansion.
If you're evaluating it at the floating
On Wed, Mar 09, 2005 at 07:04:39AM +0100, Gabriel Dos Reis wrote:
> That is a rather weak argument. What is the type of the argument if
> it were possible?
float obviously. You follow the standard promotion/type resolution
rules you already handle for operators like +. Done correctly,
min/max a
39 matches
Mail list logo
