test 100%
of a core was doing interrupt processing.
Anyway, thanks again for all your responses.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Richard Guenther wrote:
On Nov 27, 2007 2:23 PM, Howard Chu <[EMAIL PROTECTED]> wrote:
A bit of a minor mystery. Not a problem, just a curiosity. If someone knew off
the top of their head a reason for it, that'd be cool, but otherwise no sweat.
I'd try -Os, you might
e, 27 Nov 2007 05:17:04 -0800
From: Howard Chu <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Howard Chu wrote:
Howard Chu wrote:
Howard Chu wrote:
For reference, the pe
Dave Korn wrote:
On 23 November 2007 23:32, Howard Chu wrote:
And it looks
like current bash on cygwin doesn't handle case/esac constructs correctly,
so e.g.
the configure script for BerkeleyDB 4.6.21 fails there.
Could you possibly send a testcase to the cygwin mailing list? We ha
bearable. (Normally I would use MSYS but
the last one I tried just crashes immediately on Win64.) And it looks like
current bash on cygwin doesn't handle case/esac constructs correctly, so e.g.
the configure script for BerkeleyDB 4.6.21 fails there.
Gotta hand it to Microsoft, they've
Dave Korn wrote:
On 12 November 2006 04:16, Howard Chu wrote:
Dave Korn wrote:
f = (struct foo *)(void *)buf;
That's good, but why is it safe?
Passing through void* means gcc has to assume it could alias anything,
IIUIC, as a result of the sta
ever used to access that memory, aliasing
doesn't matter
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Mike Stump wrote:
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
Ian Lance Taylor wrote:
Howard Chu <[EMAIL PROTECTED]> writes:
Daniel Berlin wrote:
We ask the TBAA analyzer "can a store to a short * touch i.
In this case, it says "no", because it's not legal.
If you know the code is not legal, why don't yo
ust need to fix one file in a
very large program.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
lly, once I'd excised that abominable imake crap and replaced
it with pure GNU make. (One hour builds down to about 5 minutes, as I
recall.)
Of course, if your program has fewer than 80 source files you may not
get 100% utilization out of the machine, but at that point are you
really going
Andrew Pinski wrote:
On Fri, 2006-11-10 at 23:05 -0800, Howard Chu wrote:
Daniel Berlin wrote:
We ask the TBAA analyzer "can a store to a short * touch i.
In this case, it says "no", because it's not legal.
If you know the code is not legal, why don't
t;
s[0] = buf[0];
s[1] = buf[1];
printf("%x %x %x %x\n", buf[0], buf[1], buf[2], buf[3] );
puts(text);
/* system(text); */
}
The above code compiles without warning with -O2 / -O3
-Wstrict-aliasing, but the result is quite different from compiling
access the same memory - it knows it's
the same pointer, and therefore must be accessing the same memory. I can
understand strange results occurring when there's ambiguity, but there
is no ambiguity here.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Direct
Andreas Schwab wrote:
Howard Chu <[EMAIL PROTECTED]> writes:
I understand that logic, in the general case. In this specific example,
none of those conditions apply. foo is an uninitialized local
variable. Therefore the compiler cannot know that it has a valid copy of
it in any regist
Joe Buck wrote:
On Fri, Nov 10, 2006 at 04:18:25PM -0800, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Hm, actually it still prints the correct result for me. What platform
are you using where it actually makes a
Richard Guenther wrote:
On 11/10/06, Howard Chu <[EMAIL PROTECTED]> wrote:
I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
returning values through a void ** argument. As far as I can tell, this
doesn't actually cause any problems, but gcc 4.1 with -Wstrict-al
Mike Stump wrote:
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
Richard Guenther wrote:
On 11/10/06, Howard Chu <[EMAIL PROTECTED]> wrote:
The program prints the expected result with both strict-aliasing and
no-strict-aliasing on my x86_64 box. As such, when/why would I need to
worry about this warning?
If you compile with -O3 -combine *.c -o al
g *.c -o alias
The program prints the expected result with both strict-aliasing and
no-strict-aliasing on my x86_64 box. As such, when/why would I need to
worry about this warning?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://
20 matches
Mail list logo
