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_s
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 dec
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 so
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 ex
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-n
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 functi
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:
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
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
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(
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 lan
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 f
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;
>
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
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 attribut
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
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
|
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. How
>
> 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-
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
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
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, wher
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
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
> "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 refe
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. }
>
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 /o
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" i
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
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 spelli
> 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 -isy
>
> 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"
> |
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 p
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
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, Andre
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/
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 me
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
> | 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 Fortr
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
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 op
> | 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 sh
>
> 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
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?
|
|
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 undefi
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 deve
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.
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/
* 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 vers
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 relation
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
51 matches
Mail list logo
