Kaveh R. Ghazi [EMAIL PROTECTED] writes:
[...]
| I'd like to do for tree and rtx what I did for const char *,
| namely constify those tree/rtx functions that aren't supposed to
| modify their arguments. This would require introducing the
| const_tree and const_rtx typedefs
On 14 July 2006 18:22, Kaveh R. Ghazi wrote:
Now imagine if I change the type of __t to const_tree like so:
typedef const union tree_node *const_tree;
#define TREE_CHECK(T, CODE) __extension__ \
({ const_tree const __t = (T); \
if (TREE_CODE (__t) != (CODE)) \
tree_check_failed
Kaveh R. Ghazi [EMAIL PROTECTED] writes:
#define TREE_CHECK(T, CODE) __extension__ \
({ const_tree const __t = (T); \
How about
typeof(T) const __t = (T);
?
Ian
How about
typeof(T) const __t = (T);
?
Ian
Oops, I didn't realize that using typeof preserves const-ness and
doesn't evaluate side-effects in T. After some quick testing it
turns out typeof is exactly what I needed. I'm regtesting some
patches now.
Thanks!
On 6/29/06, Kaveh R. Ghazi [EMAIL PROTECTED] wrote:
Notice that the value of the parameter b is never changed in the
function body. Consequently, if the current optimizers cannot figure
that simple cases out (where b is not annotated const), then the
optimizers in deficient in that
On 29 June 2006 14:44, Richard Guenther wrote:
But with C language constructs you cannot assume that an object
passed to a function via a const pointer is not modified. So, there
is no real const regarding to objects pointed to. Consider
void foo(const int *i)
{
int *k = (int *)i;
On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation,
you deserve everything you get.
No it is not, in fact it is legal C and there is no aliasing
violation as you
are still accessing the memory as an int.
--
On 29 June 2006 14:55, Andrew Pinski wrote:
On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation, you deserve everything you get.
No it is not, in fact it is legal C and there is no aliasing
violation as you
are
Dave Korn [EMAIL PROTECTED] writes:
But it's really legal to cast away const?
All that matters is the effective type of the accessed object, see 6.5#7.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key
On 6/29/06, Dave Korn [EMAIL PROTECTED] wrote:
On 29 June 2006 14:55, Andrew Pinski wrote:
On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation, you deserve everything you get.
No it is not, in fact it is legal C and
On 29 June 2006 15:12, Andreas Schwab wrote:
Dave Korn [EMAIL PROTECTED] writes:
But it's really legal to cast away const?
All that matters is the effective type of the accessed object, see 6.5#7.
Andreas.
Ah yes, now I remember... we had a long thread on this sometime last year,
On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation, you deserve everything you get.
No it is not, in fact it is legal C and there is no aliasing violation
as you are still accessing the memory as an int.
--
On 29 June 2006 16:15, Kaveh R. Ghazi wrote:
On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation, you deserve everything you get.
No it is not, in fact it is legal C and there is no aliasing violation
as you
On Jun 29, 2006, at 6:51 AM, Dave Korn wrote:
That's cheating! You casted away const, it's a blatant aliasing
violation,
you deserve everything you get. The compiler is specifically
*allowed* to
assume you don't pull stunts like this *in order to* make const-
optimisation
possible and
Dave Korn [EMAIL PROTECTED] writes:
| On 29 June 2006 14:44, Richard Guenther wrote:
|
| But with C language constructs you cannot assume that an object
| passed to a function via a const pointer is not modified. So, there
| is no real const regarding to objects pointed to. Consider
|
|
int G;
void foo(const int *P1) {
G = *P1 + 1;
}
int bar() {
int tmp = G;
foo(G);
return G-tmp;
}
bar returns 1, not 0, and there is no pointer casting happening.
Well, G is known to escape anyway here. Even worse is this:
-- f1.c --
extern int G;
void foo(const int *P1) {
Andreas Schwab writes:
Dave Korn [EMAIL PROTECTED] writes:
But it's really legal to cast away const?
All that matters is the effective type of the accessed object, see 6.5#7.
It's not clear to me that it's legal to convert (const int*) to
(int*). 6.3.2.3, Pointers, says
2 For any
Andrew Pinski [EMAIL PROTECTED] writes:
| On Jun 27, 2006, at 7:58 AM, Gabriel Dos Reis wrote:
|
| We we do have numbers that support that claim for real programs, then
| we have a bug in the optimizers :-)
|
| Huh?
Yes.
| Stupid example where a const argument can change:
| tree a;
| int
Notice that the value of the parameter b is never changed in the
function body. Consequently, if the current optimizers cannot figure
that simple cases out (where b is not annotated const), then the
optimizers in deficient in that respect. That is the point.
-- Gaby
I agree that the
On Jun 28, 2006, at 7:14 PM, Kaveh R. Ghazi wrote:
Notice that the value of the parameter b is never changed in the
function body. Consequently, if the current optimizers cannot figure
that simple cases out (where b is not annotated const), then the
optimizers in deficient in that respect.
Kaveh R. Ghazi [EMAIL PROTECTED] writes:
[...]
| I'd like to do for tree and rtx what I did for const char *, namely
| constify those tree/rtx functions that aren't supposed to modify their
| arguments. This would require introducing the const_tree and
| const_rtx typedefs Tristan suggested.
Dear all,
from comments in the #gcc irc channel, I understood that it is not
advisable for gcc patches to use the const qualifier in function
prototypes. I would like to understand why. Apart from its main
purpose, I believed that the use of 'const' helps the compiler to
optimise the code. Of
On 27/06/06, Andrew Haley [EMAIL PROTECTED] wrote:
Well, const functions are nonstandard, and gcc itself is written in
Standard C so they can't be used. But As for const args, I can't see
any good reason not to use them, and there are 400 uses in gcc.
I meant const arguments, sorry for the
Manuel López-Ibáñez [EMAIL PROTECTED] writes:
| Dear all,
|
| from comments in the #gcc irc channel, I understood that it is not
| advisable for gcc patches to use the const qualifier in function
| prototypes. I would like to understand why. Apart from its main
| purpose, I believed that the use
On Jun 27, 2006, at 6:29 AM, Manuel López-Ibáñez wrote:
On 27/06/06, Andrew Haley [EMAIL PROTECTED] wrote:
Well, const functions are nonstandard, and gcc itself is written in
Standard C so they can't be used. But As for const args, I can't see
any good reason not to use them, and there are
On Jun 27, 2006, at 7:58 AM, Gabriel Dos Reis wrote:
We we do have numbers that support that claim for real programs, then
we have a bug in the optimizers :-)
Huh?
Stupid example where a const argument can change:
tree a;
int f(const tree b)
{
TREE_CODE(a) = TREE_CODE (b) + 1;
return
On Tue, 2006-06-27 at 13:51 +0100, Manuel López-Ibáñez wrote:
from comments in the #gcc irc channel, I understood that it is not
advisable for gcc patches to use the const qualifier in function
prototypes. I would like to understand why. Apart from its main
purpose, I believed that the use of
Andrew Pinski wrote:
Stupid example where a const argument can change:
tree a;
int f(const tree b)
{
TREE_CODE(a) = TREE_CODE (b) + 1;
return TREE_CODE (b);
}
You're not changing the constant argument b, just what b might point
to. I don't think there are any optimizing opportunities for
Manuel López-Ibáñez wrote:
Dear all,
from comments in the #gcc irc channel, I understood that it is not
advisable for gcc patches to use the const qualifier in function
prototypes. I would like to understand why. Apart from its main
purpose, I believed that the use of 'const' helps the
On 27/06/06, Daniel Berlin [EMAIL PROTECTED] wrote:
Manuel López-Ibáñez wrote:
Apart from its main
purpose, I believed that the use of 'const' helps the compiler to
optimise the code.
It generally doesn't, unless you apply const to the underlying type, and
not just the pointer.
IE you say
On 27/06/06, Andrew Haley [EMAIL PROTECTED] wrote:
OK, now you're getting the idea, you need to think about the
difference between
const union tree_node *
union tree_node *const
const union tree_node *const
My fault then, I was erroneously assuming that if tree is equal to
union
Manuel López-Ibáñez wrote:
On 27/06/06, Daniel Berlin [EMAIL PROTECTED] wrote:
Manuel López-Ibáñez wrote:
Apart from its main
purpose, I believed that the use of 'const' helps the compiler to
optimise the code.
It generally doesn't, unless you apply const to the underlying type, and
not
32 matches
Mail list logo
