On 26/09/2011 02:37, Miles Bader wrote:
David Brown writes:
So what advantages would there be in declaring a volatile buffer like
this to be "const"? At best, you are helping the compiler check that
you don't accidentally write to it in your own code.
That's actually pretty handy tho...
O
David Brown writes:
> So what advantages would there be in declaring a volatile buffer like
> this to be "const"? At best, you are helping the compiler check that
> you don't accidentally write to it in your own code.
That's actually pretty handy tho...
-Miles
--
Everywhere is walking distanc
On 25/09/11 17:15, Dave Korn wrote:
On 25/09/2011 13:56, David Brown wrote:
There is a big difference between defining an object as "const", and
merely declaring it as const or accessing it as const. When you access
it as const, you are saying "/I/ won't change the object with this
access". W
On 25/09/11 16:16, Andreas Schwab wrote:
David Brown writes:
There is a big difference between defining an object as "const", and
merely declaring it as const or accessing it as const. When you access it
as const, you are saying "/I/ won't change the object with this access".
When you declare
On 25/09/2011 13:56, David Brown wrote:
> There is a big difference between defining an object as "const", and
> merely declaring it as const or accessing it as const. When you access
> it as const, you are saying "/I/ won't change the object with this
> access". When you declare an object as co
David Brown writes:
> There is a big difference between defining an object as "const", and
> merely declaring it as const or accessing it as const. When you access it
> as const, you are saying "/I/ won't change the object with this access".
> When you declare an object as const (such as an exte
On 24/09/2011 18:25, John Regehr wrote:
it. And while I think the compiler should be allowed to generate the
optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully
understand the idea of generating the older, slower, but definitely
correct code of 4.5.
My understanding is that the
it. And while I think the compiler should be allowed to generate the
optimised code of 4.6 (i.e., the change is not a bug IMHO), I fully
understand the idea of generating the older, slower, but definitely correct
code of 4.5.
My understanding is that the standard mandates the old behavior, so
On 24/09/2011 17:09, John Regehr wrote:
What can't make sense is a /static/ "volatile const" which is
/defined/ locally, rather than just declared.
The code in question sounds well-defined (but probably poor style) to me.
It is never OK to access a qualified object through an unqualified
point
What can't make sense is a /static/ "volatile const" which is /defined/
locally, rather than just declared.
The code in question sounds well-defined (but probably poor style) to me.
It is never OK to access a qualified object through an unqualified
pointer, but my understanding is that accessi
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
My hopes were high but unfortunately it is not fixed yet.
git head 36181f98 still generates the same unexpected code.
Cheers
On 23/09/11 12:33, Paulo J. Matos wrote:
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make
sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of t
On 22/09/11 22:15, Richard Guenther wrote:
Btw, I think this is an old bug that has been resolved. Did you make sure to
test a recent 4.6 branch snapshot or svn head?
Should have tested git head. Compiling git head now to check the current
status of this issue.
--
PMatos
On Wed, Sep 21, 2011 at 4:57 PM, Paulo J. Matos wrote:
> On 21/09/11 15:21, David Brown wrote:
>>
>> And since this
>> situation would not occur in real code (at least, not code that is
>> expected to do something useful other than test the compiler's code
>> generation), there is no harm in makin
On 21/09/2011 20:50, Georg-Johann Lay wrote:
David Brown schrieb:
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brown writes:
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - t
On 21/09/2011 16:57, Paulo J. Matos wrote:
On 21/09/11 15:21, David Brown wrote:
And since this
situation would not occur in real code (at least, not code that is
expected to do something useful other than test the compiler's code
generation), there is no harm in making sub-optimal object code.
David Brown schrieb:
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brown writes:
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compi
On 21/09/11 15:21, David Brown wrote:
And since this
situation would not occur in real code (at least, not code that is
expected to do something useful other than test the compiler's code
generation), there is no harm in making sub-optimal object code.
Actually the reason why I noticed this is
On 21/09/2011 15:57, Ian Lance Taylor wrote:
David Brown writes:
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compile-time constant.
But s
David Brown writes:
> On 21/09/2011 10:21, Paulo J. Matos wrote:
>> On 21/09/11 08:03, David Brown wrote:
>>> Asking to read it by a volatile read does not
>>> change the nature of "foo" - the compiler can still implement it as a
>>> compile-time constant.
>>
>> But since I am accessing the data
On 21/09/2011 10:21, Paulo J. Matos wrote:
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compile-time constant.
But since I am accessing the data through the pointer and the pointer
qual
On 21/09/11 08:03, David Brown wrote:
Asking to read it by a volatile read does not
change the nature of "foo" - the compiler can still implement it as a
compile-time constant.
But since I am accessing the data through the pointer and the pointer
qualifies the data as volatile, shouldn't the c
On 20/09/11 17:35, Ian Lance Taylor wrote:
I agree that this looks like a bug. Please file a bug report marked as
a regression.
Ian
Thanks. Reported as 50472 even though I am just reading Davids post and
he is convincing me that this might not be a bug after all, however, it
is still behav
On 20/09/2011 18:35, Ian Lance Taylor wrote:
"Paulo J. Matos" writes:
The following code:
static const unsigned int foo = 1;
unsigned int test( void )
{
const volatile unsigned int *bar =&foo;
return ( *bar );
}
in GCC45 works as expected:
$test:
ld AL,#foo ;; AL is return register
"Paulo J. Matos" writes:
> The following code:
> static const unsigned int foo = 1;
> unsigned int test( void )
> {
> const volatile unsigned int *bar = &foo;
> return ( *bar );
> }
>
> in GCC45 works as expected:
> $test:
> ld AL,#foo ;; AL is return register
> bra 0,X ;; end functi
25 matches
Mail list logo
