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, pins...@gmail.com wrote:
On
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 FSF.
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 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 you say that?
The law, *duh*
Why couldn't
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. Asking
On Sat, Jan 23, 2010 at 09:21:47AM -0500, Joern Rennecke wrote:
[This started on gcc-patches]
Quoting Richard Guenther richard.guent...@gmail.com:
[...]
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
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
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 way for 15 years, it's that way in
the BSD kernels
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 at all. And only on unfixed kernels. A program
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 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 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 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
while
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
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 to
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 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 to
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 break
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
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
in pure C, but I'd like
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 is
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 extension,
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
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
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 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 is a bad line of reasoning in general. There is a vast
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
In particular, a very large number of C and C
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 with
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 programs out there, including a non
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 to be a dispassionate
description of the state
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 of facts. Software that violates the C standard
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
35 matches
Mail list logo
