On Wed, Feb 1, 2012 at 11:40 AM, Jakub Jelinek ja...@redhat.com wrote:
Well, the C++11/C11 model doesn't allow to use the underlying type
for accesses, consider e.g.
struct S { long s1; unsigned int s2 : 5; unsigned int s3 : 19; unsigned char
s4; unsigned int s5; };
struct T { long s1 :
On Wed, Feb 1, 2012 at 12:01 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
- However, while using the *smallest* possible access may generate
correct code, it often generates really *crappy* code. Which is
exactly the bug that I reported in
http://gcc.gnu.org/bugzilla
On Wed, Feb 1, 2012 at 12:16 PM, Jakub Jelinek ja...@redhat.com wrote:
So the kernel really doesn't care what you do to things *within* the
bitfield.
But what is *within* the bitfield? Do you consider s4 or t2 fields
(non-bitfield fields that just the ABI wants to pack together with
the
On Wed, Feb 1, 2012 at 12:41 PM, Torvald Riegel trie...@redhat.com wrote:
You do rely on the compiler to do common transformations I suppose:
hoist loads out of loops, CSE, etc. How do you expect the compiler to
know whether they are allowed for a particular piece of code or not?
We have
On Wed, Feb 1, 2012 at 12:53 PM, Torvald Riegel trie...@redhat.com wrote:
For volatile, I agree.
However, the original btrfs example was *without* a volatile, and that's
why I raised the memory model point. This triggered an error in a
concurrent execution, so that's memory model land, at
On Wed, Feb 1, 2012 at 1:24 PM, Torvald Riegel trie...@redhat.com wrote:
It's not the only thing we do. We have cases where it's not that you
can't hoist things outside of loops, it's that you have to read things
exactly *once*, and then use that particular value (ie the compiler
can't be
On Wed, Feb 1, 2012 at 1:25 PM, Boehm, Hans hans.bo...@hp.com wrote:
Here are some more interesting ones that illustrate the issues (all
declarations are non-local, unless stated otherwise):
struct { char a; int b:9; int c:7; char d} x;
Is x.b = 1 allowed to overwrite x.a? C11 says no,
On Wed, Feb 1, 2012 at 2:45 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
My (perhaps forlorn and naive) hope is that C++11 memory_order_relaxed
will eventually allow ACCESS_ONCE() to be upgraded so that (for example)
access-once increments can generate a single increment-memory
On Mon, Nov 15, 2010 at 3:16 AM, Jakub Jelinek ja...@redhat.com wrote:
I don't see any problems on the assembly level. i8k_smm is
not inlined in this case and checks all 3 conditions.
If it really is related to gcc not understanding that *regs has
changed due to the memory being an automatic
On Mon, Nov 15, 2010 at 9:40 AM, Jim Bos jim...@xs4all.nl wrote:
Hmm, that doesn't work.
[ Not sure if you read to whole thread but initial workaround was to
change the asm(..) to asm volatile(..) which did work. ]
Since I have a different gcc than yours (and I'm not going to compile
my
On Mon, Nov 15, 2010 at 10:30 AM, Jim Bos jim...@xs4all.nl wrote:
Attached version with plain 2.6.36 source and version with the committed
patch, i.e with the '+m (*regs)'
Looks 100% identical in i8k_smm() itself, and I'm not seeing anything
bad. The asm has certainly not been optimized away
On Mon, Nov 15, 2010 at 10:45 AM, Jeff Law l...@redhat.com wrote:
A memory clobber should clobber anything in memory, including autos in
memory; if it doesn't, then that seems like a major problem. I'd like to
see the rationale behind not clobbering autos in memory.
Yes. It turns out that
On Mon, Nov 15, 2010 at 11:12 AM, Jakub Jelinek ja...@redhat.com wrote:
Ah, the problem is that memory_identifier_string is only initialized in
ipa-reference.c's initialization, so it can be (and is in this case) NULL in
ipa-pure-const.c.
Ok. And I guess you can verify that all versions of
On Sun, Nov 14, 2010 at 4:52 PM, James Cloos cl...@jhcloos.com wrote:
Gcc 4.5.1 running on an amd64 box cross-compiling for a P3 i8k fails
to compile the module since commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48
with:
CC drivers/char/i8k.o
drivers/char/i8k.c: In function ‘i8k_smm’:
On Thu, 19 Nov 2009, Thomas Gleixner wrote:
standard function start:
push %ebp
mov%esp, %ebp
call mcount
modified function start on a handful of functions only seen with gcc
4.4.x on x86 32 bit:
push %edi
lea
On Thu, 19 Nov 2009, Richard Guenther wrote:
Note that I only can reproduce the issue with
-mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2.
Since you can reproduce it with -mincoming-stack-boundary=2, I woul
suggest just fixing mcount handling that way regardless of
On Thu, 19 Nov 2009, Andrew Haley wrote:
I've got all that off-list. I found the cause, and replied in another
email. It's not a bug.
Oh Gods, are we back to gcc people saying sure, we do stupid things, but
it's allowed, so we don't consider it a bug because it doesn't matter that
real
On Thu, 19 Nov 2009, Linus Torvalds wrote:
Oh Gods, are we back to gcc people saying sure, we do stupid things, but
it's allowed, so we don't consider it a bug because it doesn't matter that
real people care about real life, we only care about some paper, and real
life doesn't matter
On Thu, 19 Nov 2009, Linus Torvalds wrote:
I bet other people than just the kernel use the mcount hook for subtler
things than just doing profiles. And even if they don't, the quoted code
generation is just crazy _crap_.
For the kernel, if the only case is that timer_stat.c thing
On Thu, 19 Nov 2009, H. Peter Anvin wrote:
Calling the profiler immediately at the entry point is clearly the more
sane option. It means the ABI is well-defined, stable, and independent
of what the actual function contents are. It means that ABI isn't the
normal C ABI (the __fentry__
On Thu, 19 Nov 2009, Frederic Weisbecker wrote:
That way the lr would have the current function, and the parent would
still be at 8(%sp)
Yeah right, we need at least such very tiny prologue for
archs that store return addresses in a reg.
Well, it will be architecture-dependent.
For
On Fri, 20 Nov 2009, Thomas Gleixner wrote:
While testing various kernel configs we found out that the problem
comes and goes. Finally I started to compare the gcc command line
options and after some fiddling it turned out that the following
minimal deltas change the code generator
On Wed, 12 Dec 2007, Nicolas Pitre wrote:
So... my conclusion is that the glibc allocator has fragmentation issues
with this work load, given the notable difference with the Google
allocator, which itself might not be completely immune to fragmentation
issues of its own.
Yes.
Note
On Wed, 12 Dec 2007, David Miller wrote:
I personally don't think it's unreasonable for GIT to have it's
own customized allocator at least for certain object types.
Well, we actually already *do* have a customized allocator, but currently
only for the actual core object descriptor that
On Tue, 11 Dec 2007, Jon Smirl wrote:
So why does our threaded code take 20 CPU minutes longer (12%) to run
than the same code with a single thread?
Threaded code *always* takes more CPU time. The only thing you can hope
for is a wall-clock reduction. You're seeing probably a combination
On Tue, 11 Dec 2007, Jon Smirl wrote:
So if you want to use more threads, that _forces_ you to have a bigger
memory footprint, simply because you have more live objects that you
work on. Normally, that isn't much of a problem, since most source files
are small, but if you have a few
On Thu, 6 Dec 2007, Harvey Harrison wrote:
I've updated the public mirror repo with the very-packed version.
Side note: it might be interesting to compare timings for
history-intensive stuff with and without this kind of very-packed
situation.
The very density of a smaller pack-file might
On Fri, 7 Dec 2007, David Miller wrote:
Also I could end up being performance limited by SHA, it's not very
well tuned on Sparc. It's been on my TODO list to code up the crypto
unit support for Niagara-2 in the kernel, then work with Herbert Xu on
the userland interfaces to take advantage
On Thu, 6 Dec 2007, Harvey Harrison wrote:
7:41:25elapsed 86%CPU
Heh. And this is why you want to do it exactly *once*, and then just
export the end result for others ;)
-r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26
pack-1d46ca030c3d6d6b95ad316deb922be06b167a3d.pack
But
On Thu, 6 Dec 2007, Jeff King wrote:
What is really disappointing is that we saved only about 20% of the
time. I didn't sit around watching the stages, but my guess is that we
spent a long time in the single threaded writing objects stage with a
thrashing delta cache.
I don't think you
On Thu, 6 Dec 2007, Daniel Berlin wrote:
I worked on Monotone and other systems that use object stores. for a
little while :) In particular, I believe GIT's original object store was
based on Monotone, IIRC.
Yes and no.
Monotone does what git does for the blobs. But there is a big
On Thu, 6 Dec 2007, NightStrike wrote:
No disrespect is meant by this reply. I am just curious (and I am
probably misunderstanding something).. Why remove all of the
documentation entirely? Wouldn't it be better to just document it
more thoroughly?
Well, part of it is that I don't
On Thu, 6 Dec 2007, Jon Loeliger wrote:
On Thu, 2007-12-06 at 00:09, Linus Torvalds wrote:
Git also does delta-chains, but it does them a lot more loosely. There
is no fixed entity. Delta's are generated against any random other version
that git deems to be a good delta candidate
On Thu, 6 Dec 2007, Jon Smirl wrote:
time git blame -C gcc/regclass.c /dev/null
[EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c /dev/null
real1m21.967s
user1m21.329s
Well, I was also hoping for a compared to not-so-aggressive packing
number on the
On Wed, 5 Dec 2007, Harvey Harrison wrote:
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
Yes, --aggressive is generally a bad idea. I think we should remove it or
at least fix it. It doesn't do what the name implies, because it
On Thu, 6 Dec 2007, Daniel Berlin wrote:
Actually, it turns out that git-gc --aggressive does this dumb thing
to pack files sometimes regardless of whether you converted from an
SVN repo or not.
Absolutely. git --aggressive is mostly dumb. It's really only useful for
the case of I know I
101 - 136 of 136 matches
Mail list logo
