can DECL_RESULT be 0?
In tree.def:329 it is written that DECL_RESULT holds a RESULT_DECL node for the value of a function, or it is 0 for a function that returns no value. (C functions returning void have zero here.) but C functions returning void have void_type_node in DECL_RESULT. Also note that allocate_struct_function calls aggregate_value_p on the DECL_RESULT and aggregate_value_p assumes that its argument is not null. Should DECL_RESULT be allowed to be null or should the comment be fixed? If DECL_RESULT can be null, should aggregate_value_p return false if its argument is null? Thanks, Rafael pgpxrfhDLZjkA.pgp Description: PGP signature
Re: Null pointer check elimination
On Saturday 12 November 2005 01:53, Ian Lance Taylor wrote: > Note that it is also possible to simply store the attribute on > DECL_ATTRIBUTES and look it up using lookup_attribute. > This is my strong preference. The original RFE (PR 20318) called for attributes to be used in C/C++ function declarations. It would be pointless to have to lookup this attributes in two different ways inside tree-vrp.c.
Re: Null pointer check elimination
On Fri, 2005-11-11 at 22:53 -0800, Ian Lance Taylor wrote: > David Daney <[EMAIL PROTECTED]> writes: > > > > Eventually we should manually mark certain function DECLs as > > > not-returning-null instead of my kludgy test for this one case. I don't > > > know if/when I can get to that. Perhaps somebody else can take it from > > > here. > > > > Looks like all the bits in struct tree_common are used up. > > > > Q: Would it make sense to add a flag to struct tree_decl_common to > > indicate !zero, set it using an attribute, (and automatically in the > > java front-end for the cases above), and then test for it in > > tree-vrp.c similar to below? > > This should be done using an attribute, yes. If this is going to be > tested frequently enough, it would make sense to add a bit to struct > tree_function_decl (I don't see any reason to put it in struct > tree_decl-common) (there is currently room for one more bit in > tree_function_decl on a machine which requires 16-bit alignment, or 17 > more bits on a machine which requires 32-bit alignment). Note you could also put things in decl_non_common, but i'd probably beat you up :) > Note that it > is also possible to simply store the attribute on DECL_ATTRIBUTES and > look it up using lookup_attribute. IMHO, this is the way to go. The number of times we look at attributes on function_decls (IE through call_expr_flags, etc) is so small i've never understood why we use so many bits to represent thing we are getting from attributes. Most functions have no attributes, so it's a very simple check for lookup_attribute to perform. Even when they have *1* attribute, it's still simple. > > Ian
Re: Null pointer check elimination
A "function-never-returns-null" attribute doesn't seem like
the right mechanism. Instead, there should be a "never-null"
attribute on pointer types. A "function-never-returns-null" is
just a function whose return-type has the "never-null" attribute.
A type attribute is much more useful. For example it allows:
String x = shared ? "x" : new String("x");
// The type of x [in a single-assignment-world] is non-null.
[If we already have such a mechanism, I apologize.]
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
On Saturday 12 November 2005 12:05, Per Bothner wrote:
> A "function-never-returns-null" attribute doesn't seem like
> the right mechanism. Instead, there should be a "never-null"
> attribute on pointer types. A "function-never-returns-null" is
> just a function whose return-type has the "never-null" attribute.
>
I disagree. We would have to prove that every possible instance of this
type is non-NULL.
> A type attribute is much more useful. For example it allows:
> String x = shared ? "x" : new String("x");
> // The type of x [in a single-assignment-world] is non-null.
>
No. We don't put our types in SSA form. Another variable of type String
could very well be NULL.
Re: Null pointer check elimination
Diego Novillo writes: > On Saturday 12 November 2005 12:05, Per Bothner wrote: > > A "function-never-returns-null" attribute doesn't seem like > > the right mechanism. Instead, there should be a "never-null" > > attribute on pointer types. A "function-never-returns-null" is > > just a function whose return-type has the "never-null" attribute. > > > I disagree. We would have to prove that every possible instance of this > type is non-NULL. Couldn't we attach an assertion to the tree? That way we could just use the inference logic we already have. Andrew.
Re: Null pointer check elimination
Note that this correspond to the "not null" feature added to Ada 2006
in various places, including pointer type definitions:
type Ptr is not null access Integer;
You can also have a regular pointer type and subtype it
with not null, but I guess the Ada front-end introduces
a generated subtype:
type P is access Integer;
function F return not null P;
The trunk Ada front-end supports this when the -gnat05
flag is used.
Laurent
On Sat, 2005-11-12 at 09:05 -0800, Per Bothner wrote:
> A "function-never-returns-null" attribute doesn't seem like
> the right mechanism. Instead, there should be a "never-null"
> attribute on pointer types. A "function-never-returns-null" is
> just a function whose return-type has the "never-null" attribute.
>
> A type attribute is much more useful. For example it allows:
> String x = shared ? "x" : new String("x");
> // The type of x [in a single-assignment-world] is non-null.
>
> [If we already have such a mechanism, I apologize.]
Re: Null pointer check elimination
On Saturday 12 November 2005 12:19, Andrew Haley wrote:
> Couldn't we attach an assertion to the tree? That way we could just
> use the inference logic we already have.
>
We already do that. In Per's test case,
String x = shared ? "x" : new String("x");
we get into VRP with an SSA form along these lines:
if (shared_1)
x_4 = "x"
else
{
x_5 = new String("x");
x_6 = ASSERT_EXPR
}
x_7 = PHI
VRP already knows that "x" is non-NULL. The new function attribute will
cause VRP to insert the ASSERT_EXPR for x_5. VRP will detetermine that
x_7 is non-NULL.
Re: Null pointer check elimination
Diego Novillo wrote: On Saturday 12 November 2005 12:05, Per Bothner wrote: A "function-never-returns-null" attribute doesn't seem like the right mechanism. Instead, there should be a "never-null" attribute on pointer types. A "function-never-returns-null" is just a function whose return-type has the "never-null" attribute. I disagree. We would have to prove that every possible instance of this type is non-NULL. I think you're missing the point. The proposal is for a "type variant" - not that different from say "constant". "non-null java.lang.String" is a different POINTER_TYPE object than "[possibly-null] java.lang.String". If you dereference an expression whose type is "non-null java.lang.String" then you know you don't need an null pointer check. If you derefernce an expression of type "[possibly-null] java.lang.String" then you do need the null pointer check. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Diego Novillo writes:
> On Saturday 12 November 2005 12:19, Andrew Haley wrote:
>
> > Couldn't we attach an assertion to the tree? That way we could just
> > use the inference logic we already have.
> >
> We already do that. In Per's test case,
>
> String x = shared ? "x" : new String("x");
>
> we get into VRP with an SSA form along these lines:
>
> if (shared_1)
>x_4 = "x"
> else
> {
> x_5 = new String("x");
> x_6 = ASSERT_EXPR
> }
> x_7 = PHI
>
> VRP already knows that "x" is non-NULL. The new function attribute will
> cause VRP to insert the ASSERT_EXPR for x_5. VRP will detetermine that
> x_7 is non-NULL.
OK, so what's to stop the front-end from generating the assertion at
gimplification time? Then we don't need any new attributes in the
middle-end.
Andrew.
Re: Null pointer check elimination
On Saturday 12 November 2005 12:24, Laurent GUERBY wrote: > Note that this correspond to the "not null" feature added to Ada 2006 > in various places, including pointer type definitions: > >type Ptr is not null access Integer; > Ah, this is different and it would be very helpful. If it's a language mandated thing, then VRP could just rely in this type attribute and default to 'non-zero' when it can't infer any other useful value.
Re: Null pointer check elimination
On Saturday 12 November 2005 12:27, Per Bothner wrote: > I think you're missing the point. The proposal is for a "type variant" > - not that different from say "constant". > Ah, yes, sorry about that. Yes, that would be useful as well. However, that is an orthogonal issue to having non-NULL function attributes. We can use both. If the front end guarantees that all instances of a type are non-NULL, as in the Ada case just posted, then VRP can and should make use of that.
Re: Null pointer check elimination
On Sat, 2005-11-12 at 12:30 -0500, Diego Novillo wrote: > On Saturday 12 November 2005 12:24, Laurent GUERBY wrote: > > Note that this correspond to the "not null" feature added to Ada 2006 > > in various places, including pointer type definitions: > > > >type Ptr is not null access Integer; > > > Ah, this is different and it would be very helpful. If it's a language > mandated thing, then VRP could just rely in this type attribute and > default to 'non-zero' when it can't infer any other useful value. Yes it's language mandated (well when the ISO Ada 2006 revision is out next year :), my guess is that the Ada front-end remove some of it's own checks based on this but that this information is not passed outside the front-end, may be Richard Kenner or Robert Dewar can comment on this. Laurent
gcc-4.1-20051112 is now available
Snapshot gcc-4.1-20051112 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051112/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 106827 You'll find: gcc-4.1-20051112.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051112.tar.bz2 C front end and core compiler gcc-ada-4.1-20051112.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051112.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051112.tar.bz2 C++ front end and runtime gcc-java-4.1-20051112.tar.bz2 Java front end and runtime gcc-objc-4.1-20051112.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051112.tar.bz2The GCC testsuite Diffs from 4.1-20051105 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Null pointer check elimination
On Saturday 12 November 2005 12:29, Andrew Haley wrote:
> Diego Novillo writes:
>
> > if (shared_1)
> >x_4 = "x"
> > else
> > {
> > x_5 = new String("x");
> > x_6 = ASSERT_EXPR
> > }
> > x_7 = PHI
> >
> > VRP already knows that "x" is non-NULL. The new function attribute
> > will cause VRP to insert the ASSERT_EXPR for x_5. VRP will
> > detetermine that x_7 is non-NULL.
>
> OK, so what's to stop the front-end from generating the assertion at
> gimplification time? Then we don't need any new attributes in the
> middle-end.
>
The FE is not emitting SSA code. In 'x = new String("x")', it will know
that 'x' is non-NULL at that point, but it cannot prove that 'x' will
remain non-NULL everywhere. When you are in SSA form, x_6 is non-NULL and
everywhere you see x_6 you are guaranteed to be dealing with a non-NULL
value.
The helpful hint we need from the FE inside VRP is for it to mark the
actual call as returning non-NULL.
Re: Null pointer check elimination
Per Bothner <[EMAIL PROTECTED]> writes: | A "function-never-returns-null" attribute doesn't seem like | the right mechanism. Instead, there should be a "never-null" | attribute on pointer types. A "function-never-returns-null" is | just a function whose return-type has the "never-null" attribute. We already have such mechanism: a reference type -- which morally is implemented as a pointer type. -- Gaby
Re: Null pointer check elimination
Diego Novillo <[EMAIL PROTECTED]> writes: | On Saturday 12 November 2005 12:05, Per Bothner wrote: | > A "function-never-returns-null" attribute doesn't seem like | > the right mechanism. Instead, there should be a "never-null" | > attribute on pointer types. A "function-never-returns-null" is | > just a function whose return-type has the "never-null" attribute. | > | I disagree. We would have to prove that every possible instance of this | type is non-NULL. No, you don't have to. Just in the same way you don't have to prove that a function with "function-never-returns-null" attributes never returns null. -- Gaby
Re: Null pointer check elimination
Diego Novillo <[EMAIL PROTECTED]> writes: | On Saturday 12 November 2005 12:27, Per Bothner wrote: | | > I think you're missing the point. The proposal is for a "type variant" | > - not that different from say "constant". | > | Ah, yes, sorry about that. Yes, that would be useful as well. However, | that is an orthogonal issue to having non-NULL function attributes. We | can use both. I'm not convinced. I believe Per's suggestion is far superior, and more general and does cover pretty well the issue at hand. Plus, a pointer-type-without-null is another spelling for reference type. -- Gaby
Re: Null pointer check elimination
> > Per Bothner <[EMAIL PROTECTED]> writes: > > | A "function-never-returns-null" attribute doesn't seem like > | the right mechanism. Instead, there should be a "never-null" > | attribute on pointer types. A "function-never-returns-null" is > | just a function whose return-type has the "never-null" attribute. > > We already have such mechanism: a reference type -- which morally is > implemented as a pointer type. That was mentioned a way ago as being wrong. A reference type can be NULL. -- Pinski
Re: Null pointer check elimination
On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote: > Per Bothner <[EMAIL PROTECTED]> writes: > | A "function-never-returns-null" attribute doesn't seem like > | the right mechanism. Instead, there should be a "never-null" > | attribute on pointer types. A "function-never-returns-null" is > | just a function whose return-type has the "never-null" attribute. > > We already have such mechanism: a reference type No. We've had this discussion before, and the conclusion what that reference types can be NULL. http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html Paul
Re: Null pointer check elimination
Per Bothner wrote: A "function-never-returns-null" attribute doesn't seem like the right mechanism. Instead, there should be a "never-null" attribute on pointer types. A "function-never-returns-null" is just a function whose return-type has the "never-null" attribute. Gabriel Does Reis wrote: We already have such mechanism: a reference type -- which morally is implemented as a pointer type. Andrew Pinski wrote: That was mentioned a way ago as being wrong. A reference type can be NULL. There are other differences, at least in C++: If you assign to a pointer, you change the pointer, while if you assign to a reference you modify the referenced object. I.e. if a variable has reference type, then the reference itself is constant. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
On Saturday 12 November 2005 13:36, Gabriel Dos Reis wrote:
> I'm not convinced. I believe Per's suggestion is far superior, and
> more general and does cover pretty well the issue at hand. Plus,
> a pointer-type-without-null is another spelling for reference type.
>
I'm thinking of C here, where we don't have that luxury. The original RFE
was in 20318 where they have some C functions that are guaranteed to
return non-NULL (I'm quoting from memory here):
int *this_never_returns_NULL (void) __attribute__ ((never_returns_null));
We would not want to pin the never-null attribute to 'int *':
foo()
{
int *p = this_never_returns_NULL ();
< ... use p without modifying it ... > <-- p is never NULL here.
p = other_fn ();
< ... use p without modifying it ... > <-- p may be NULL here.
}
In languages where you could make the type itself have that guarantee, then
great, let's use the type attributes. In type-challenged languages, we
use whatever we can get our hands on.
Re: Null pointer check elimination
Diego Novillo wrote:
> int *this_never_returns_NULL (void) __attribute__
((never_returns_null));
>
> We would not want to pin the never-null attribute to 'int *':
Well, of course. That's why we're talking about a type *variant*.
To emphasise: this is a type variant *in the gcc internals* - i.e.
using a distinct POINTER_TYPE node. To what extent this is reflected
at the source level is up to front-ends.
Thus:
int *this_never_returns_NULL(void) __attribute__((never_returns_null));
could be viewed as syntactic sugar for:
(int __attribute__((never_null)) *) this_never_returns_NULL(void);
[Note I'm unsure about __attribute__ and declaration syntax, so it
is possible this wouldn't work. But that's a syntax issue, so it ignore
it in the following.]
>
> foo()
> {
>int *p = this_never_returns_NULL ();
>< ... use p without modifying it ... > <-- p is never NULL here.
>p = other_fn ();
>< ... use p without modifying it ... ><-- p may be NULL here.
> }
We could allow, if desired:
foo()
{
int __attribute__((never_null)) *p = this_never_returns_NULL ();
< ... use p without modifying it ... > <-- p is never NULL here.
p = other_fn (); /* error - caught by the compiler */
}
Consider:
foo()
{
int *p;
if (test)
{
p = this_never_returns_NULL ();
< ... use p without modifying it ... > <-- p never NULL here.
}
else
{
p = other_fn ();
< ... use p without modifying it ... > <-- p may be NULL here.
}
... more uses of p ...;
}
The internal SSA form might be something like:
foo()
{
if (test)
{
int __attribute__((never_null)) *p_1 = this_never_returns_NULL();
< ... use p without modifying it ... > <-- p_1 never NULL here.
}
else
{
int *p_2 = other_fn ();
< ... use p without modifying it ... > <-- p_2 may be NULL here.
}
int *p_3 = PHI(p_1, p_2);
... more uses of p ...;
}
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: cross newlib builds on svn head
On Thu, 2005-11-03 at 17:43 +0100, Paolo Bonzini wrote: > Joel Sherrill <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I have been trying to build sparc-rtems4.7 on the head using newlib's > > head for a few days now. I have finally narrowed the behavior down. > > > > If I configure for sparc I am configuring for sparc-rtems4.7 with c and > > c++, it builds fine. The build process uses xgcc for newlib as one > > would expect. If I add ada to the --enable-languages then newlib fails > > to build because it picks a non-existent compile (sparc-rtems4.7-cc) to > > build with. > > Can you try the attached patch? > > Paolo Hi Paolo, any chance to get this patch in SVN? Thanks in advance, Laurent
Re: Null pointer check elimination
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A type attribute is much more useful. For example it allows:
Per> String x = shared ? "x" : new String("x");
Per> // The type of x [in a single-assignment-world] is non-null.
I think we will need extra code to recognize that String references
via the constant pool will never be null.
Since we make direct references to the constant pool (i.e., we don't
emit a function call), a purely function-call-based approach to
handling non-nullity won't be sufficient.
Tom
Re: Null pointer check elimination
On Saturday 12 November 2005 14:35, Per Bothner wrote:
> The internal SSA form might be something like:
>
> foo()
> {
> if (test)
> {
> int __attribute__((never_null)) *p_1 =
> this_never_returns_NULL(); < ... use p without modifying it ... > <--
> p_1 never NULL here. }
> else
> {
>int *p_2 = other_fn ();
>< ... use p without modifying it ... > <-- p_2 may be NULL here.
> }
>int *p_3 = PHI(p_1, p_2);
> ... more uses of p ...;
> }
>
Well, I am not an FE person, so I don't much care how you convey the
information into the optimizers.
From a user's perspective I see the obvious drawback that you've just
forced me to edit a potentially large number of source files just to add
the __attribute__((never_null)). The other approach just needs a single
__attribute__ in the function declaration.
Another problem I would have as a user is if you suddenly make 'int *' and
'int * __attribute__((non_null))' different/incompatible types. If I have
a function that takes 'int *' as argument, I don't want to start adding
tons of type casts to get around compiler warnings/errors.
From an optimizer perspective, I fail to see how would your approach give
me better information inside VRP. But since your approach seems to give
me the same information, I don't much care how the FE implements this. If
you decide to have type attributes, I'll use it. If you mark the
function, I'll use it with the same effect.
cross builds to avr fail
Building a --target=avr compiler currently fails because /usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc -B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/ -B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem /opt/cross/avr/include -isystem /opt/cross/avr/sys-include -O2 -O2 -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -U_FORTIFY_SOURCE -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -DL_ashrdi3 -c ../../gcc/libgcc2.c -o libgcc/./_ashrdi3.o ../../gcc/libgcc2.c: In function '__muldi3': ../../gcc/libgcc2.c:511: error: total size of local objects too large which does not make any sense. The above is for a x86_64 host, but I see this errors everywhere. Any idea? Thanks, Richard.
Re: Null pointer check elimination
Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > Per Bothner <[EMAIL PROTECTED]> writes: | > | > | A "function-never-returns-null" attribute doesn't seem like | > | the right mechanism. Instead, there should be a "never-null" | > | attribute on pointer types. A "function-never-returns-null" is | > | just a function whose return-type has the "never-null" attribute. | > | > We already have such mechanism: a reference type -- which morally is | > implemented as a pointer type. | | That was mentioned a way ago as being wrong. A reference type can be NULL. You have to explain me why a reference can be null. -- Gaby
Re: Null pointer check elimination
Paul Brook <[EMAIL PROTECTED]> writes: | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote: | > Per Bothner <[EMAIL PROTECTED]> writes: | > | A "function-never-returns-null" attribute doesn't seem like | > | the right mechanism. Instead, there should be a "never-null" | > | attribute on pointer types. A "function-never-returns-null" is | > | just a function whose return-type has the "never-null" attribute. | > | > We already have such mechanism: a reference type | | No. We've had this discussion before, and the conclusion what that reference | types can be NULL. | | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html That simply means GCC got it wrong. -- Gaby
Re: Null pointer check elimination
Diego Novillo <[EMAIL PROTECTED]> writes: | On Saturday 12 November 2005 13:36, Gabriel Dos Reis wrote: | | > I'm not convinced. I believe Per's suggestion is far superior, and | > more general and does cover pretty well the issue at hand. Plus, | > a pointer-type-without-null is another spelling for reference type. | > | I'm thinking of C here, where we don't have that luxury. I know you're thinking of C. But we're talking about implementatin here. We have the luxury to -- and we must -- introduce types that are not expressible at the pure C source level. -- Gaby
Re: cross builds to avr fail
> Building a --target=avr compiler currently fails because > > /usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc > -B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/ > -B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem > /opt/cross/avr/include -isystem /opt/cross/avr/sys-include -O2 -O2 -O2 > -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -U_FORTIFY_SOURCE > -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF > -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED > -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include > -I../../gcc/../libcpp/include -DL_ashrdi3 -c ../../gcc/libgcc2.c -o > libgcc/./_ashrdi3.o ../../gcc/libgcc2.c: In function '__muldi3': > ../../gcc/libgcc2.c:511: error: total size of local objects too large > > which does not make any sense. The above is for a x86_64 host, but I > see this errors everywhere. I guess the sanity check I've added doesn't apply to micro-controllers. Try the attached patch. -- Eric Botcazou Index: function.c === --- function.c (revision 106821) +++ function.c (working copy) @@ -479,7 +479,8 @@ assign_stack_local_1 (enum machine_mode function->x_stack_slot_list = gen_rtx_EXPR_LIST (VOIDmode, x, function->x_stack_slot_list); - /* Try to detect frame size overflows. */ + /* Try to detect frame size overflows on native platforms. */ +#if BITS_PER_WORD >= 32 if ((FRAME_GROWS_DOWNWARD ? (unsigned HOST_WIDE_INT) -function->x_frame_offset : (unsigned HOST_WIDE_INT) function->x_frame_offset) @@ -491,6 +492,7 @@ assign_stack_local_1 (enum machine_mode /* Avoid duplicate error messages as much as possible. */ function->x_frame_offset = 0; } +#endif return x; }
Re: Null pointer check elimination
>
> Paul Brook <[EMAIL PROTECTED]> writes:
>
> | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote:
> | > Per Bothner <[EMAIL PROTECTED]> writes:
> | > | A "function-never-returns-null" attribute doesn't seem like
> | > | the right mechanism. Instead, there should be a "never-null"
> | > | attribute on pointer types. A "function-never-returns-null" is
> | > | just a function whose return-type has the "never-null" attribute.
> | >
> | > We already have such mechanism: a reference type
> |
> | No. We've had this discussion before, and the conclusion what that
> reference
> | types can be NULL.
> |
> | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html
>
> That simply means GCC got it wrong.
Was there an example of:
int f(int &);
int g(void)
{
int *a = 0;
return f(*a);
}
Yes this would be undefined code but so what.
-- Pinski
Re: Null pointer check elimination
Diego Novillo wrote: From a user's perspective I see the obvious drawback that you've just forced me to edit a potentially large number of source files just to add the __attribute__((never_null)). I'm clearly not explaining myself ... Of course I'm not proposing that. My point was that my proposal *allows* explicit setting of the __attribute__((never_null)). But more likely it's the *compiler* (optimizer) that sets the attribute. The other approach just needs a single __attribute__ in the function declaration. You missed this > int *this_never_returns_NULL(void) __attribute__((never_returns_null)); > could be viewed as syntactic sugar for: > (int __attribute__((never_null)) *) this_never_returns_NULL(void); I.e. just a single attribute in the function declaration. The phrase "syntactic sugar" means that people can write the former, and it's equivalent to the latter. Another problem I would have as a user is if you suddenly make 'int *' and 'int * __attribute__((non_null))' different/incompatible types. If I have a function that takes 'int *' as argument, I don't want to start adding tons of type casts to get around compiler warnings/errors. Bad example. The 'int *' type is more general than 'int*__attribute__((non_null))', so assigning an expression that has type 'int*__attribute__((non_null))' to a variable or parameter that has type 'int*' is always safe, and shouldn't warn. As to the other way round, that is a user interface issue, orthognal to the semantic issue. But if a variable is explicitly declared 'int * __attribute__((non_null))' and you pass it an 'int *' expression then a warning is probably in order, since you're doing something dangerous. One more point: If someone writes: int *x = this_never_returns_NULL(); Then the type of x is 'int *' and that of this_never_returns_NULL() is 'int __attribute__((never_null)) *'. This is fine and safe. However, ideally the compiler should realize that x actually has the more specific type 'int __attribute__((never_null)) *', and should use that information to generate better code. It seems this should be straightforward using SSA, as I sketched in my previous message. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Tom Tromey wrote:
"Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A type attribute is much more useful. For example it allows:
Per> String x = shared ? "x" : new String("x");
Per> // The type of x [in a single-assignment-world] is non-null.
I think we will need extra code to recognize that String references
via the constant pool will never be null.
Since we make direct references to the constant pool (i.e., we don't
emit a function call), a purely function-call-based approach to
handling non-nullity won't be sufficient.
Right - the "type-variant" approach handles that smoothly.
I.e. in Java a string literal would have type
"never-null pointer to java.lang.String".
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Andrew Pinski <[EMAIL PROTECTED]> writes:
| Was there an example of:
|
|
| int f(int &);
|
| int g(void)
| {
| int *a = 0;
| return f(*a);
| }
|
|
| Yes this would be undefined code but so what.
So it is NOT a compeling example that a reference can be null. You
have to try harder, Andrew.
-- Gaby
Re: cross builds to avr fail
On Sat, 12 Nov 2005, Eric Botcazou wrote: > > Building a --target=avr compiler currently fails because > > > > /usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc > > -B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/ > > -B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem > > /opt/cross/avr/include -isystem /opt/cross/avr/sys-include -O2 -O2 -O2 > > -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -U_FORTIFY_SOURCE > > -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes > > -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF > > -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED > > -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include > > -I../../gcc/../libcpp/include -DL_ashrdi3 -c ../../gcc/libgcc2.c -o > > libgcc/./_ashrdi3.o ../../gcc/libgcc2.c: In function '__muldi3': > > ../../gcc/libgcc2.c:511: error: total size of local objects too large > > > > which does not make any sense. The above is for a x86_64 host, but I > > see this errors everywhere. > > I guess the sanity check I've added doesn't apply to micro-controllers. Try > the attached patch. That works! Thanks, Richard.
Re: Null pointer check elimination
On Saturday 12 November 2005 20:57, Gabriel Dos Reis wrote: > Paul Brook <[EMAIL PROTECTED]> writes: > | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote: > | > Per Bothner <[EMAIL PROTECTED]> writes: > | > | A "function-never-returns-null" attribute doesn't seem like > | > | the right mechanism. Instead, there should be a "never-null" > | > | attribute on pointer types. A "function-never-returns-null" is > | > | just a function whose return-type has the "never-null" attribute. > | > > | > We already have such mechanism: a reference type > | > | No. We've had this discussion before, and the conclusion what that > | reference types can be NULL. > | > | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html > > That simply means GCC got it wrong. If by "GCC got it wrong" you mean several key GCC developers disagree with your opinion of what the semantics of REFERENCE_TYPE are/should be, then yes. Paul
Re: Null pointer check elimination
Paul Brook <[EMAIL PROTECTED]> writes: | On Saturday 12 November 2005 20:57, Gabriel Dos Reis wrote: | > Paul Brook <[EMAIL PROTECTED]> writes: | > | On Saturday 12 November 2005 18:32, Gabriel Dos Reis wrote: | > | > Per Bothner <[EMAIL PROTECTED]> writes: | > | > | A "function-never-returns-null" attribute doesn't seem like | > | > | the right mechanism. Instead, there should be a "never-null" | > | > | attribute on pointer types. A "function-never-returns-null" is | > | > | just a function whose return-type has the "never-null" attribute. | > | > | > | > We already have such mechanism: a reference type | > | | > | No. We've had this discussion before, and the conclusion what that | > | reference types can be NULL. | > | | > | http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01463.html | > | > That simply means GCC got it wrong. | | If by "GCC got it wrong" you mean several key GCC developers disagree with | your opinion Do you need to get it personal? | of what the semantics of REFERENCE_TYPE are/should be, then yes. See, it is not a semantics I made up. Even people arguing for null reference recognize it is undefined behaviour. -- Gaby
Re: Null pointer check elimination
> | of what the semantics of REFERENCE_TYPE are/should be, then yes. > > See, it is not a semantics I made up. Even people arguing for null > reference recognize it is undefined behaviour. With C++ yes but not with Fortran where there are optional arguments. So What you are saying is that Fortran should not use reference types. Well in fortran, all agruments are passed via a reference so that is just wrong. Using pointers there would be just wrong, as that is not the semantics for the variable. -- Pinski
Re: Null pointer check elimination
On Saturday 12 November 2005 16:11, Per Bothner wrote: > I'm clearly not explaining myself ... > Well, it doesn't help that I'm not really good at language stuff, so don't worry and thanks for putting up with the silly questions. > However, ideally the compiler should realize that x actually has > the more specific type 'int __attribute__((never_null)) *', and > should use that information to generate better code. It seems > this should be straightforward using SSA, as I sketched in my > previous message. > Aha, yes, that's fine then. I'll defer the decision of type vs function attribute to you folks. However you end up marking it, that will only mean a couple line change in VRP.
Re: Null pointer check elimination
Andrew Pinski <[EMAIL PROTECTED]> writes: | > | of what the semantics of REFERENCE_TYPE are/should be, then yes. | > | > See, it is not a semantics I made up. Even people arguing for null | > reference recognize it is undefined behaviour. | | With C++ yes but not with Fortran where there are optional arguments. Then what is the difference between a pointer type and a reference type? | So What you are saying is that Fortran should not use reference types. No. What I'm saying is that the use of "reference" to model optional arguments needs more work in terms of explanation and justification. | Well in fortran, all agruments are passed via a reference so that is just | wrong. Using pointers there would be just wrong, as that is not the | semantics for the variable. So, what is the semantics? What is the real difference? -- Gaby
Re: Null pointer check elimination
> | Well in fortran, all agruments are passed via a reference so that is just > | wrong. Using pointers there would be just wrong, as that is not the > | semantics for the variable. > > So, what is the semantics? What is the real difference? Did you actually read the thread I referenced? The short answer is debug info. Paul
Re: Null pointer check elimination
> > Andrew Pinski <[EMAIL PROTECTED]> writes: > > | > | of what the semantics of REFERENCE_TYPE are/should be, then yes. > | > > | > See, it is not a semantics I made up. Even people arguing for null > | > reference recognize it is undefined behaviour. > | > | With C++ yes but not with Fortran where there are optional arguments. > > Then what is the difference between a pointer type and a reference type? To the middle-end nothing, to the debugging info there is something. > | Well in fortran, all agruments are passed via a reference so that is just > | wrong. Using pointers there would be just wrong, as that is not the > | semantics for the variable. > > So, what is the semantics? What is the real difference? The semantics for reference type to the middle-end is no different from a pointer type, it is only when printing out what the debug info should include. Let me ask you this, how would represent agruments for Fortran then as pointers but then we get much worse debug info as we get currently? GCC is not a C++ play ground. -- Pinski
Re: Null pointer check elimination
Paul Brook <[EMAIL PROTECTED]> writes: | > | Well in fortran, all agruments are passed via a reference so that is just | > | wrong. Using pointers there would be just wrong, as that is not the | > | semantics for the variable. | > | > So, what is the semantics? What is the real difference? | | Did you actually read the thread I referenced? Yes, I did. Why are you willing to assume I did not? | The short answer is debug info. You see, I asked for semantics at the language level, you answer "side implementation detail". Yet, you're willing to jump to the conclusion that I did not read the thread. -- Gaby
Re: Null pointer check elimination
Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > | > | of what the semantics of REFERENCE_TYPE are/should be, then yes. | > | > | > | > See, it is not a semantics I made up. Even people arguing for null | > | > reference recognize it is undefined behaviour. | > | | > | With C++ yes but not with Fortran where there are optional arguments. | > | > Then what is the difference between a pointer type and a reference type? | | To the middle-end nothing, That is why GCC got it wrong. [...] | GCC is not a C++ play ground. ? -- Gaby
Adding the D programming language
Hi! I read some documentation about D programming language and began to test few .d files/modules. I think the D language is promising, and even if it has a garbage collector, it seems to be a good alternative in front of Java and .Net languages since it implements everything that quite every developpers cry out in C++. Is it plan to add the D language in the ones that are supported by GCC by default? Regards, Creak
Re: Adding the D programming language
On Nov 12, 2005, at 5:06 PM, Romain Failliot wrote: Is it plan to add the D language in the ones that are supported by GCC by default? No plans I'm aware of, but, asking the D folks would be more productive than asking us.
Re: cross builds to avr fail
Eric Botcazou <[EMAIL PROTECTED]> writes: > > Building a --target=avr compiler currently fails because > > > > /usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/xgcc > > -B/usr/src/packages/BUILD/gcc-4.1.0-20051110/obj-x86_64-suse-linux/./gcc/ > > -B/opt/cross/avr/bin/ -B/opt/cross/avr/lib/ -isystem > > /opt/cross/avr/include -isystem /opt/cross/avr/sys-include -O2 -O2 -O2 > > -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -U_FORTIFY_SOURCE > > -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes > > -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF > > -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED > > -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include > > -I../../gcc/../libcpp/include -DL_ashrdi3 -c ../../gcc/libgcc2.c -o > > libgcc/./_ashrdi3.o ../../gcc/libgcc2.c: In function '__muldi3': > > ../../gcc/libgcc2.c:511: error: total size of local objects too large > > > > which does not make any sense. The above is for a x86_64 host, but I > > see this errors everywhere. > > I guess the sanity check I've added doesn't apply to micro-controllers. Try > the attached patch. I didn't realize that we had a target with BITS_PER_UNIT == 8 && UNITS_PER_WORD == 1. I see that for the AVR POINTER_SIZE is 16, which suggests that this code should use POINTER_SIZE or GET_MODE_BITSIZE (Pmode) rather than BITS_PER_WORD. But restricting it to BITS_PER_WORD >= 32 should also be fine. Ian
Re: Adding the D programming language
* Romain Failliot: > Is it plan to add the D language in the ones that are supported by GCC > by default? There is a GCC front end, but it has zero chance of being integrated into FSF GCC at this stage. The run-time library license contains this little gem: * (ii) Any derived versions of this software (howsoever modified) * remain the sole property of Synesis Software.
How Can I Get See A Memory Map For An Executable
i want to check in my C++ program, what variable is allocated in where. is there such a tool? another relative question is, where the 'new' operator get memory from? the global heap? does it same with what 'malloc' get from? thanks. -- steven woody (id: narke) Celine: Well, who says relationships have to last forever? - Before Sunrise (1995)
Runtime Memory Usage Graph
how can i get see the runtime memory useage graph for my c++ program? this will include stack memory and dynamic memory (heap). thanks. - narke
