> In that case it specifies that any evaluation of "*foo" in an rvalue
> context specifies a read (with a few exceptions for G++ where the C++
> language generally confuses things). Specifically it mentions the
> statement "*src;" and discusses the statement as providing "a void
> context". In o
My apologies for the late response, I've had a lot on my schedule
over the last week.
On Dec 02, 2006, at 23:29:28, David Schwartz wrote:
It comes down to just what those guarantees GCC provides actually
are.
This is the first correct statement in your email. In any case
the documented G
> > It comes down to just what those guarantees GCC provides actually are.
> This is the first correct statement in your email. In any case the
> documented GCC guarantees have always been much stronger than you
> have been trying to persuade us they should be. I would argue that
> the C standa
On Dec 01, 2006, at 09:03:26, David Schwartz wrote:
"David Schwartz" <[EMAIL PROTECTED]> writes:
The problem is that '*(volatile unsigned int *)' results in a
'volatile unsigned int'.
No, it doesn't. Values don't have qualifiers, only objects have.
Qualifiers on rvalues are meaningless.
>> Next you stick a my_other_func declaration in a header and use
>> my_other_func instead of my_func() in the main function. Now the
>> result is that the compiler has no damn clue what my_other_func()
>> contains so it can't optimize it out of the loop with either
>> version. You cannot treat
> "David Schwartz" <[EMAIL PROTECTED]> writes:
>
> > The problem is that '*(volatile unsigned int *)' results in a 'volatile
> > unsigned int'.
>
> No, it doesn't. Values don't have qualifiers, only objects have.
> Qualifiers on rvalues are meaningless.
Yeah. That's the problem here. The 'volati
> No, it can't. If you leave the prototype alone and the function when
> called in sequence returns the same list of values, then by
> definition the internals can have no effect on the code which uses
> that function. As further proof, if you wrapped my "my_func()" with
> this in some C file:
>
"David Schwartz" <[EMAIL PROTECTED]> writes:
> The problem is that '*(volatile unsigned int *)' results in a 'volatile
> unsigned int'.
No, it doesn't. Values don't have qualifiers, only objects have.
Qualifiers on rvalues are meaningless.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECT
On Dec 01, 2006, at 06:24:54, David Schwartz wrote:
Imagine we change the code to read from some auto-increment hardware
at a specific MMIO address instead of a global:
static int my_func(int a)
{
return a + *(volatile int *)(0xABCD1234);
}
But you're telling me that the change in the
> Imagine we change the code to read from some auto-increment hardware
> at a specific MMIO address instead of a global:
> > static int my_func(int a)
> > {
> > return a + *(volatile int *)(0xABCD1234);
> > }
> But you're telling me that the change in the header file (where the
> new function
On Fri, Dec 01, 2006 at 08:28:16AM +0100, Willy Tarreau wrote:
> Oh, I'm perfectly aware of this. That's in part why I started the hotfix
> branch in the past :-) But sometimes, fixes consist in merging all the
> patches from the maintenance branch (eg: from 4.1.0 to 4.1.1), and if
> this is the ca
On Fri, Dec 01, 2006 at 05:32:42PM +1100, Keith Owens wrote:
> Willy Tarreau (on Fri, 1 Dec 2006 06:26:53 +0100) wrote:
> >On Fri, Dec 01, 2006 at 04:14:04PM +1100, Keith Owens wrote:
> >> SuSE's SLES10 ships with gcc 4.1.0. There is nothing to stop a
> >> distributor from backporting the bug fix
Willy Tarreau (on Fri, 1 Dec 2006 06:26:53 +0100) wrote:
>On Fri, Dec 01, 2006 at 04:14:04PM +1100, Keith Owens wrote:
>> SuSE's SLES10 ships with gcc 4.1.0. There is nothing to stop a
>> distributor from backporting the bug fix from gcc 4.1.1 to 4.1.0, but
>> this patch would not allow the fixed
On Nov 29, 2006, at 20:04:28, David Schwartz wrote:
Ask yourself this question: Can an assignment to a non-volatile
variable be optimized out? Then ask yourself this question: Does
casting away volatile make it not volatile any more?
Hmm, let's put this in a C file:
int my_global = 0;
An
On Fri, Dec 01, 2006 at 04:14:04PM +1100, Keith Owens wrote:
> Andrew Morton (on Thu, 30 Nov 2006 21:05:51 -0800) wrote:
> >On Wed, 29 Nov 2006 21:14:10 +0100
> >Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >
> >> Then why not simply check for gcc 4.1.0 in compiler.h and refuse to build
> >> with 4.1
Andrew Morton (on Thu, 30 Nov 2006 21:05:51 -0800) wrote:
>On Wed, 29 Nov 2006 21:14:10 +0100
>Willy Tarreau <[EMAIL PROTECTED]> wrote:
>
>> Then why not simply check for gcc 4.1.0 in compiler.h and refuse to build
>> with 4.1.0 if it's known to produce bad code ?
>
>Think so. I'll queue this and
On Wed, 29 Nov 2006 21:14:10 +0100
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Then why not simply check for gcc 4.1.0 in compiler.h and refuse to build
> with 4.1.0 if it's known to produce bad code ?
Think so. I'll queue this and see how many howls it causes.
--- a/init/main.c~gcc-4-1-0-is-bus
Ask yourself this question: Can an assignment to a non-volatile variable be
optimized out? Then ask yourself this question: Does casting away volatile
make it not volatile any more?
> The volatile'ness does not simply disappear the moment you
> assign the result to some local variable which is no
On Wed, Nov 29, 2006 at 04:08:00AM -0500, Jakub Jelinek wrote:
> On Wed, Nov 29, 2006 at 02:56:20PM +1100, Keith Owens wrote:
> > Nicholas Miell (on Tue, 28 Nov 2006 19:08:25 -0800) wrote:
> > >On Wed, 2006-11-29 at 13:22 +1100, Keith Owens wrote:
> > >> Compiling 2.6.19-rc6 with gcc version 4.1.0
On Wed, Nov 29, 2006 at 02:56:20PM +1100, Keith Owens wrote:
> Nicholas Miell (on Tue, 28 Nov 2006 19:08:25 -0800) wrote:
> >On Wed, 2006-11-29 at 13:22 +1100, Keith Owens wrote:
> >> Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux),
> >> wait_hpet_tick is optimized away to a never ending l
On Wed, 2006-11-29 at 15:30 +1100, Keith Owens wrote:
> David Miller (on Tue, 28 Nov 2006 20:04:53 -0800 (PST)) wrote:
> >From: Keith Owens
> >Date: Wed, 29 Nov 2006 14:56:20 +1100
> >
> >> Secondly, I believe that this is a separate problem from bug 22278.
> >> hpet_readl() is correctly using vol
David Miller (on Tue, 28 Nov 2006 20:04:53 -0800 (PST)) wrote:
>From: Keith Owens
>Date: Wed, 29 Nov 2006 14:56:20 +1100
>
>> Secondly, I believe that this is a separate problem from bug 22278.
>> hpet_readl() is correctly using volatile internally, but its result is
>> being assigned to a pair of
From: Keith Owens
Date: Wed, 29 Nov 2006 14:56:20 +1100
> Secondly, I believe that this is a separate problem from bug 22278.
> hpet_readl() is correctly using volatile internally, but its result is
> being assigned to a pair of normal integers (not declared as volatile).
> In the context of wait
Nicholas Miell (on Tue, 28 Nov 2006 19:08:25 -0800) wrote:
>On Wed, 2006-11-29 at 13:22 +1100, Keith Owens wrote:
>> Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux),
>> wait_hpet_tick is optimized away to a never ending loop and the kernel
>> hangs on boot in timer setup.
>>
>> 001a :
On Wed, 2006-11-29 at 13:22 +1100, Keith Owens wrote:
> Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux),
> wait_hpet_tick is optimized away to a never ending loop and the kernel
> hangs on boot in timer setup.
>
> 001a :
> 1a: 55 push %ebp
> 1b: 89 e5
25 matches
Mail list logo
