> On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote:
> > while speaking about uninitialized variables gcc developers probably
want
> > to look at their own sources first:
> > gcc/testsuite/gcc.dg/vect/vect-27.c
>
> If any code in the testsuite is broken, it should be changed.
should be f
On Nov 11, 2006, at 7:56 PM, Howard Chu wrote:
You probably can't, in the case of a shared library, but you
probably could for a static library.
I think I agree, though, a JIT can peer past a shared boundary as
well. A non-JIT can as well, but it has to have some mechanism to
unpeer acros
Howard Chu <[EMAIL PROTECTED]> writes:
> As I recall, we chose int[] for alignment reasons, figuring we'd have no
> guarantees on the alignment of a char[].
Neither you have on int[].
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürn
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 standard allowing
On Nov 11, 2006, at 10:45 PM, Howard Chu wrote:
Andrew Pinski wrote:
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
Your code will be safe on all counts if you change buf from int[] to
char[]. The language standard grants a special exemption to char*
pointers. Without that exem
Andrew Pinski wrote:
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
Your code will be safe on all counts if you change buf from int[] to
char[]. The language standard grants a special exemption to char*
pointers. Without that exemption, it would be impossible to write
malloc in
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
>
> Your code will be safe on all counts if you change buf from int[] to
> char[]. The language standard grants a special exemption to char*
> pointers. Without that exemption, it would be impossible to write
> malloc in C.
Actually it
Howard Chu <[EMAIL PROTECTED]> writes:
> Here's a different example, which produces the weaker warning
> warning: type-punning to incomplete type might break strict-aliasing rules
>
> struct foo;
>
> int blah(int fd) {
> int buf[BIG_ENOUGH];
> void *v = buf;
> struct foo
On 12 November 2006 04:16, Howard Chu wrote:
> Dave Korn wrote:
>> On 12 November 2006 03:35, Howard Chu wrote:
>>
>>
>>> If we go through the temporary variable v, there's no warning. If we
>>> don't use the temporary variable, we get the "might break" message.
>>>
>>
>> Try
>>
>>
>>>
On 12 November 2006 03:35, Howard Chu wrote:
> Here's a different example, which produces the weaker warning
> warning: type-punning to incomplete type might break strict-aliasing rules
>
> struct foo;
>
> int blah(int fd) {
> int buf[BIG_ENOUGH];
> void *v = buf;
> str
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
in a
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 you abort the compilation
with an er
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 you abort the compilation
> with an error code?
It's not act
Howard Chu wrote:
> extern void getit( void **arg );
>
> main() {
>union {
>int *foo;
>void *bar;
>} u;
>
>getit( &u.bar );
>printf("foo: %x\n", *u.foo);
> }
Rask Ingemann Lambertsen wrote:
> As far as I know, memcpy() is the answer
Howard Chu <[EMAIL PROTECTED]> writes:
> That's good to know, thanks. But frankly that's braindead to require
> someone to add all these new union declarations all over their code,
There is no need for any union trick in your example. Just use a
temporary with the correct type, and you have stri
On Fri, Nov 10, 2006 at 02:32:10PM -0800, Howard Chu wrote:
>
> With the previous example, if alias1.c was instead:
>
>
> #include
>
> extern void getit( void **arg );
>
> main() {
>union {
>int *foo;
>void *bar;
>} u;
>
>getit( &u.
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 you abort the compilation
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 you abort the compilation
> with an error code?
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 you abort the compilation
with an error code? The current silent behavior provides a mechanism for
creating source-
On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote:
> while speaking about uninitialized variables gcc developers probably want
> to look at their own sources first:
> gcc/testsuite/gcc.dg/vect/vect-27.c
If any code in the testsuite is broken, it should be changed. And this
is not really
On Fri, 10 Nov 2006, Daniel Berlin wrote:
> > > It will load the value from memory, true, but who says that the store to
> > > memory will happen before that? The compiler is allowed to reorder the
> > > statements since it "knows" that foo and *arg cannot alias.
> > >
> >
> > If the compiler is
Hm. If you're going to reorder these things, then I would expect either
an error or a warning at that point, because you really do know that a
reference to an uninitialized variable is happening.
We do warn when we see an uninitialized value if -Wuninitialized is on.
We don't warn at every poin
Daniel Berlin wrote:
> It will load the value from memory, true, but who says that the
store to
> memory will happen before that? The compiler is allowed to reorder
the
> statements since it "knows" that foo and *arg cannot alias.
>
If the compiler is smart enough to know how to reorder the s
> It will load the value from memory, true, but who says that the store to
> memory will happen before that? The compiler is allowed to reorder the
> statements since it "knows" that foo and *arg cannot alias.
>
If the compiler is smart enough to know how to reorder the statements,
then it shoul
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 register. In fa
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 register. In fact what it should k
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 differen
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 difference?
Rather, he is sayi
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-aliasing
will compl
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
in a
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
in a library compiled
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 alias it w
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-aliasing
will complain. For example, take th
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-aliasing
will complain. For example, take these two separate source files:
alias1.c
#i
34 matches
Mail list logo
