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://
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
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:
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
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
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
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
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
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
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
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/
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
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
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/
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
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 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
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
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
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/
20 matches
Mail list logo
