Re: GCC's statement expression extension

Re: GCC's statement expression extension

[Richard Kenner]

    Speaking for the users, I would argue that removal of statement
    expressions, even in C++ only, is a supremely bad idea.  I would
    hesitate to guess how many people use these features right now, but I
    would be willing to bet it more than the people reading this mailing
    list.  Misdesigned or not, it is an incredibly useful feature, and
    people use it.  Even if there are better ways of doing it, won't
    change all of the extant code out in the world.  

I *strongly* agree

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Michael>     Speaking for the users, I would argue that removal of
    Michael> statement expressions, even in C++ only, is a supremely
    Michael> bad idea.

    Richard> I *strongly* agree

Your opinions are valuable.  Although I think you may not fully
understand the C++ user base.  Those folks that I have come in contact
with eschew such extensions pretty strongly.  I suspect that very,
very few C++ programs contain statement expressions -- except via
macros in C libraries.

Just refusing to remove the extensions doesn't solve the problems,
sadly.  These things don't work in C++, and making them work is highly
nontrivial.  Programs using the standard library don't work, because
of these decisions, and surprising behavior often results without
programmer knowledge, because these things are in the standard
library, not user code.

I think that we cannot do anything until these things are removed from
glibc.  I think we cannot remove these things from glibc until we make
some improvements in the compiler to make other options equally
attractive to the library folks.  And I think we can't remove these
things from the compiler until we can reasonably expect people to use
the new libraries.

On the other hand, the arguments Michael makes apply to almost any
extension, and I do not agree, by any means, that we must preserve all
extensions for all time.  The same argument justifies preserving many
bugs; every time we issue an error that we did not before, we break
programs.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Michael Meissner]

On Thu, Jul 27, 2000 at 06:38:00PM -0700, Mark Mitchell wrote:
> On the other hand, the arguments Michael makes apply to almost any
> extension, and I do not agree, by any means, that we must preserve all
> extensions for all time.  The same argument justifies preserving many
> bugs; every time we issue an error that we did not before, we break
> programs.

That's why any extension should be considered carefully before being put in.
Speaking of the embedded world, I would say the following extensions are used
extensively:

	Statement expressions
	Long long (but hey, this is no longer an extension in C99)
	Variable attributes
	Inline
	Function attributes
	Extended asm
	Asm labels
	Explicit Reg Vars

I know there are people using Labels as Values to speed up state machines like
simulators.

I don't have a handle on the usage of the other extensions.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: GCC's statement expression extension

[Jim Wilson]

In article < 20000727221757.27796@cse.cygnus.com > you write:
>On Thu, Jul 27, 2000 at 06:38:00PM -0700, Mark Mitchell wrote:
>Speaking of the embedded world, I would say the following extensions are used
>extensively:
>	Statement expressions
>	...

This doesn't make any sense to me.  All of the extensions you listed have
obvious and important uses to embedded programmers, except for statement
expressions.  There is nothing intrinsic about them that makes them more
useful for embedded programs than other extensions.  I doubt that very
many of our customers would notice or care if they disappeared.

Is there any particular reason why you put them in this list?

Jim

Re: GCC's statement expression extension

[Michael Meissner]

On Thu, Jul 27, 2000 at 09:16:14PM -0700, Jim Wilson wrote:
> In article < 20000727221757.27796@cse.cygnus.com > you write:
> >On Thu, Jul 27, 2000 at 06:38:00PM -0700, Mark Mitchell wrote:
> >Speaking of the embedded world, I would say the following extensions are used
> >extensively:
> >	Statement expressions
> >	...
> 
> This doesn't make any sense to me.  All of the extensions you listed have
> obvious and important uses to embedded programmers, except for statement
> expressions.  There is nothing intrinsic about them that makes them more
> useful for embedded programs than other extensions.  I doubt that very
> many of our customers would notice or care if they disappeared.
> 
> Is there any particular reason why you put them in this list?

I think have seen PRs come in with big hairy macros that use statement
expressions, though not recently.  Of course the only way to find out is to
remove them from the compiler and see who complains.....

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: GCC's statement expression extension

[Nick Ing-Simmons]

Michael Meissner <meissner@cygnus.com> writes:
>
>I think have seen PRs come in with big hairy macros that use statement
>expressions, though not recently.  Of course the only way to find out is to
>remove them from the compiler and see who complains.....

perl uses statement expressions (in C though mainly) when compiled with GCC.

-- 
Nick Ing-Simmons

Re: GCC's statement expression extension

[Gabriel Dos Reis]

Nick Ing-Simmons <nik@tiuk.ti.com> writes:

| Michael Meissner <meissner@cygnus.com> writes:
| >
| >I think have seen PRs come in with big hairy macros that use statement
| >expressions, though not recently.  Of course the only way to find out is to
| >remove them from the compiler and see who complains.....
| 
| perl uses statement expressions (in C though mainly) when compiled with GCC.

IIRC, Perl-6.0 is written in C++ and I hope they aren't using
statement-expressions. 

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

Re: GCC's statement expression extension

[Nick Ing-Simmons]

Gabriel Dos Reis <gdr@codesourcery.com> writes:
>Nick Ing-Simmons <nik@tiuk.ti.com> writes:
>
>| Michael Meissner <meissner@cygnus.com> writes:
>| >
>| >I think have seen PRs come in with big hairy macros that use statement
>| >expressions, though not recently.  Of course the only way to find out is to
>| >remove them from the compiler and see who complains.....
>| 
>| perl uses statement expressions (in C though mainly) when compiled with GCC.
>
>IIRC, Perl-6.0 is written in C++ 

Perl6 is not written in anything right now it is just a concept.
Chip's "topaz" experiment was C++ but is still not clear that C++ will
be what is used. Best guess right now is meta-language which is massaged 
into ANSI C via perl script.

But perl5 (which does have statement expressions) will be around for a while.
They are fairly localized though so we could get rid of them if necessary.

>and I hope they aren't using
>statement-expressions. 

Agreed - we are going to cleanup the internals a lot to only do 
"measured" optimizations, not what whoever coded it thought would 
be quicker...

>
>-- Gaby
>CodeSourcery, LLC                             http://www.codesourcery.com
-- 
Nick Ing-Simmons

Re: GCC's statement expression extension

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| Just refusing to remove the extensions doesn't solve the problems,
| sadly.  These things don't work in C++, and making them work is highly
| nontrivial.  Programs using the standard library don't work, because
| of these decisions, and surprising behavior often results without
| programmer knowledge, because these things are in the standard
| library, not user code.

And far more importantly, efforts put in trying to make those
extensions work could be put, productively, in implementing standard
functionalities we're missing.  sigh.  

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

Re: GCC's statement expression extension

[Stan Shebs]

Mark Mitchell wrote:
> 
> [...]  I suspect that very,
> very few C++ programs contain statement expressions -- except via
> macros in C libraries.

Take a page out of RMS' playbook and start a survey.  There's a
a huge base of GNU users that Eric Raymond calls "dark matter"
because we never hear from them - but they certainly notice when
the compiler no longer compiles their code!  Since those programmers
don't typically have any contact with GCC developers, they just use
whatever constructs they happen to find in the documentation.

> Just refusing to remove the extensions doesn't solve the problems,
> sadly.  These things don't work in C++, and making them work is highly
> nontrivial.  Programs using the standard library don't work, because
> of these decisions, and surprising behavior often results without
> programmer knowledge, because these things are in the standard
> library, not user code.

Do they work some of the time?  If so, then since they're documented
without any caveats for C++, you're stuck with supporting them.

> I think that we cannot do anything until these things are removed from
> glibc.  I think we cannot remove these things from glibc until we make
> some improvements in the compiler to make other options equally
> attractive to the library folks.  And I think we can't remove these
> things from the compiler until we can reasonably expect people to use
> the new libraries.
> 
> On the other hand, the arguments Michael makes apply to almost any
> extension, and I do not agree, by any means, that we must preserve all
> extensions for all time.  The same argument justifies preserving many
> bugs; every time we issue an error that we did not before, we break
> programs.

If you deprecate statement expressions in C++ today, you might be able to
remove them 10 years from now.  Or to be more accurate, you could remove
them today, but it would ruin GCC's reputation.  The documentation is
basically a promise that GCC will make its best effort to conform to
the described behavior; if you break even a small one of the promises
because it's hard to deliver on, what assurance do users have that you
won't later blow off a critical feature if it becomes difficult to implement?

(Bugs don't count because our documented promise is to eliminate bugs,
not preserve them.)

Stan

Re: GCC's statement expression extension

[Gabriel Dos Reis]

Stan Shebs <shebs@apple.com> writes:

[...]

| If you deprecate statement expressions in C++ today, you might be able to
| remove them 10 years from now.  Or to be more accurate, you could remove
| them today, but it would ruin GCC's reputation.  The documentation is
| basically a promise that GCC will make its best effort to conform to
| the described behavior;

Was there a promise that statement expressions will work with C++?

-- Gaby

Re: GCC's statement expression extension

[Stan Shebs]

Gabriel Dos Reis wrote:
> 
> Stan Shebs <shebs@apple.com> writes:
> 
> [...]
> 
> | If you deprecate statement expressions in C++ today, you might be able to
> | remove them 10 years from now.  Or to be more accurate, you could remove
> | them today, but it would ruin GCC's reputation.  The documentation is
> | basically a promise that GCC will make its best effort to conform to
> | the described behavior;
> 
> Was there a promise that statement expressions will work with C++?

Actually, there's a loophole; the head of the "Extensions to the C Language
Family" chapter says "Most of the [extensions in this chapter] are also
available in C++."  Some extensions are explicitly characterized as
deprecated for C++, such as generalized lvalues, but statement expressions
have no such caution.  So there's no explicit promise involved here.

Stan

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

    Stan> Do they work some of the time?  If so, then since they're
    Stan> documented without any caveats for C++, you're stuck with
    Stan> supporting them.

We are? I don't see that.  There are already other C extensions that
don't work in C++.  C++ is (still) a changing language.  If we can
deliver better conformance at the price of a rarely used extension, I
bet our user-base will thank us.

We remove "signatures" in a recent release of G++, and I've heard not
one complaint.  I think that was a good decision.  We didn't wait ten
years.

    Stan> If you deprecate statement expressions in C++ today, you
    Stan> might be able to remove them 10 years from now.  Or to be
    Stan> more accurate, you could remove them today, but it would
    Stan> ruin GCC's reputation.

Not necessarily.  If we need to do this to improve conformance, we'll
win with one set of people.  We may lose with another.  This is (as I
said before) something we need to evaluate case-by-case: what are the
penalties, what are the benefits, how many people will be affected,
how do they feel about it.

The C++ user community is very different from the C user community.
C++ users are used to more change in their compilers, from version to
version, and more intent on reaching standards-conformance than C
users.

Look, I'll go back to my secret scheming, and not air it here.  In
order to get where I want to go, I've first got to get this stuff out
of libc, and to do that I've got to be able to claim you don't *need*
this stuff in libc, and that means I've got to somehow get the inliner
to work better.  Coincidentally, we're doing function-at-a-time in C,
and that will help make inlining easier...

This whole discussion was probably premature.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Stan Shebs]

Mark Mitchell wrote:
> 
> >>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:
> 
>     Stan> Do they work some of the time?  If so, then since they're
>     Stan> documented without any caveats for C++, you're stuck with
>     Stan> supporting them.
> 
> We are? I don't see that.

OK, even if the First Interstate Bank of Elbonia has a million lines
of C++ that include 20,000 distinct statement expressions that work
fine now, strictly speaking you don't have to keep G++ working for them.
Those guys will continue using an old compiler, and will tell everybody
who will listen about how they got hosed by the FSF, including their
friends at other companies who are thinking about whether to use GNU.
If you don't mind that, no problem to drop.

> There are already other C extensions that
> don't work in C++.  C++ is (still) a changing language.  If we can
> deliver better conformance at the price of a rarely used extension, I
> bet our user-base will thank us.

*If* it's rarely-used!  In the absence of a survey or widely-broadcast
announcement, you can't really know.  Apple quietly dropped Objective-C++
from OS X prereleases because we didn't think anybody used it, and
found out otherwise when we started getting messages "why can't we
compile our ObjC++ code any more?".

> We remove "signatures" in a recent release of G++, and I've heard not
> one complaint.  I think that was a good decision.  We didn't wait ten
> years.

If I understand right, there's not been an official FSF release
since they were removed - at least my 2.95 manual still describes
them.  A lot of users (such as Apple) prefer to adopt only the
official releases rather than snapshots, so they won't even know
that anything has happened to signatures until the next release comes
out.

> The C++ user community is very different from the C user community.
> C++ users are used to more change in their compilers, from version to
> version, and more intent on reaching standards-conformance than C
> users.

The way I hear it is that they just want *something* stable for a change,
and standards-conformance is just a way to get there.  For instance,
Apple's C++ developers actually care more about Metrowerks compat than
standards conformance (fortunately, Metrowerks also has the aim of being
standard).  Also, since they can only use Apple's modified version of
GCC, their complaints and problems come to us in the tools group, not to
bug-gcc.  So you probably haven't heard much of what they have to say.

> This whole discussion was probably premature.

Actually, I found it very useful!  Now I know to go look for uses
of statement expressions in Apple's existing C++ code (I suspect
there are few if any, but I've been surprised before), and to warn
our developers against depending on statement expressions in C++.

I get the sense that you wish this wasn't a discussion topic, but
that's wrong thinking; if you're contemplating changing the language
accepted by the compiler, particularly by removing constructs, you
want to let as many people as possible know about it.  Get a note up
on Slashdot for instance.  Users will accept a lot of change, as long
as they know that it's coming.

Stan

Re: GCC's statement expression extension

[llewelly]

Stan Shebs <shebs@apple.com> writes:

> Mark Mitchell wrote:
> >
[snip]
> > There are already other C extensions that
> > don't work in C++.  C++ is (still) a changing language.  If we can
> > deliver better conformance at the price of a rarely used extension, I
> > bet our user-base will thank us.

As a C++ programmer and user of gcc, I mostly agree with that; if
  glibc's use of statement experesions can be resolved, I will be
  content to see them go the way of nested functions and signatures. I
  would be happy to see computed gotos removed from C++ (can they at
  least be disallowed in blocks that contain calls to non-trivial
  constructors or destructors?) as well.

However, as soon as I said that, I immediately thought of a g++
  extension I do *not* want removed: allowing templates with default
  arguments to be used as template template parameters when the formal
  template template parameter has fewer arguments than the actual
  parameter, and the excess arguments of the actual all have defaults.

This is not even a documented extension (at least, I cannot find it in
  gcc/extend.texi).

And then I thought of another one: The extra containers and algorithms
  that libstdc++-v3 inherits from the sgi stl (<hash_map>, etc). Not
  exactly a g++ issue, but still an example of an extension I do not
  want removed.

If it came down to chosing between less ICEs on legal code, and one of
  these extensions, I would probably choose in favor of the former,
  but I would like to see a request for comment posted in a more
  widely read forum before hand.

> 
> *If* it's rarely-used!  In the absence of a survey or widely-broadcast
> announcement, you can't really know.  Apple quietly dropped Objective-C++
> from OS X prereleases because we didn't think anybody used it, and
> found out otherwise when we started getting messages "why can't we
> compile our ObjC++ code any more?".

Yuck. Sounds like a maintenance nightmare to me.

[snip]
> 
> If I understand right, there's not been an official FSF release
> since they were removed - at least my 2.95 manual still describes
> them.  A lot of users (such as Apple) prefer to adopt only the
> official releases rather than snapshots, so they won't even know
> that anything has happened to signatures until the next release comes
> out.

Sort of. gcc 2.95.x will reject signatures unless -fhandle-signatures
  is passed on the command line, and even with the flag it will give a
  warning. One would hope that users of signatures seeing the warning
  would either complain or fix their code.

[snip]
> 
> I get the sense that you wish this wasn't a discussion topic, but
> that's wrong thinking; if you're contemplating changing the language
> accepted by the compiler, particularly by removing constructs, you
> want to let as many people as possible know about it.  Get a note up
> on Slashdot for instance.  Users will accept a lot of change, as long
> as they know that it's coming.

Yes, please, before you remove any extensions - or add any new
  extensions - make announcements in widely read forums, and ask for
  user input.

Anyway, I had thought: how hard would it be to grab source tarballs of
  a few large C++ projects (like KDE), and scan them for uses of
  extensions (statement expressions, for example) that are under
  consideration for removal?

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "llewelly" == llewelly  <llewelly@dbritsch.dsl.xmission.com> writes:

    llewelly> However, as soon as I said that, I immediately thought
    llewelly> of a g++ extension I do *not* want removed: allowing
    llewelly> templates with default arguments to be used as template
    llewelly> template parameters when the formal template template
    llewelly> parameter has fewer arguments than the actual parameter,
    llewelly> and the excess arguments of the actual all have
    llewelly> defaults.

Interesting.  I looked at that code recently, and couldn't decide if
the standard intended that, or not.  It doesn't actually say.  I sent
mail to a couple of people about what they thought the standard
intended, but nobody replied.

The problem is that there are no safe extensions in this area.  If g++
accepts this code, and shouldn't, then I bet I can come up with an
overloading example where g++ gives an ambiguous overloading message
on valid code, where a conforming compiler wouldn't.  Basically, you
can't allow any additional template instantiations without breaking
conforming code.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

    Stan> I get the sense that you wish this wasn't a discussion
    Stan> topic, but that's wrong thinking; if you're contemplating

No, not at all.  All I'm thinking is that I started a firestorm with a
casual comment, and that I didn't really mean to.  Basically, I feel
like some people are saying categorically that we can't remove
extensions, even ones that don't work, aren't widely used, etc., and I
don't buy that.  I think we need to take things case by case.

In particular, if a ton of people use something then of course we have
to be considerate of that.  If, however, only a few people use
something and it causes real pain either to us or to other users, then
we might decide to nix some extension.

As for statement expressions in C++, I think you should caution your
users not to use them.  Not because they might go awa, but because
they don't have documented semantics in C++ (for example, when does a
temporary created in the statement expression go away?), because there
are known bugs in the C++ implementation of statement expressions that
are hard to fix, because using them is unportable, and because there
are better ways to provide equivalent functionality in C++.

The reason I'd like to drop this discussion is that I don't think it's
productive *at this time*.  We're not going to drop
statement-expressions in C++ until we know that that will work
technically -- and that requires *at least* looking at the glibc
headers and kernel headers.  Then, we have to decide whether we can do
it from the point of view of the number of users, how they use the
extension, etc. -- all the things you suggest.

Note that I suggested that we could perhaps deprecate this extension
in the next release.  (We can only do that if we solve the technical
problems, because we don't want people seeing lots of bugs warnings.)
That's a nice solution because it allows us to back off of removing
the feature if we get lots of complaints about the deprecation.
Simultaneously, it puts follks on notice that they're using some funky
features that they should think twice about using.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Per Bothner]

Mark Mitchell <mark@codesourcery.com> writes:

> statement expressions ... don't have documented semantics in C++
> (for example, when does a temporary created in the statement
> expression go away?),

Intuitively, it seems to me there is only one rational answer:
when you exit the (block of) the statmenet expression.

This answer appears obvious if you have Scheme experience, since in
Scheme all statements are expressions (though they sometimes return an
unspecified value), and blocks (let-expressions) are syntatic sugar of
a call to a lambda-expression.  Think of a statement expression as
short-hand for an inline function that got inlined.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

    Per> Mark Mitchell <mark@codesourcery.com> writes:

    >> statement expressions ... don't have documented semantics in
    >> C++ (for example, when does a temporary created in the
    >> statement expression go away?),

    Per> Intuitively, it seems to me there is only one rational
    Per> answer: when you exit the (block of) the statmenet
    Per> expression.

That seems like the obvious right answer.  It just doesn't work very
well for:

  X x;
  X f();

  x = ({ f(); });

Oops.  The return value of f() got destroyed before we got a chance to
copy it.  (There are more complex examples with similar problems,
including binding things to references, which cause lifetime
extensions in C++.)

I *am* a pretty experienced Scheme programmer.  (And ML, and other
functional languages.)  The problem is that the basic programming
model in C++ is different, and programmers think about things
differently.  Scheme is tremendously useful as a foundational
programming language analysis tool; every course I've taken or taught
on programming language theory features Scheme, and many use it as a
foundation onto which other programming languages are mapped.  But,
it's not always enough to simply say "if this were Scheme, what would
it mean?".

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Alexandre Oliva]

On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

>   X x;
>   X f();
>   x = ({ f(); });

> Oops.  The return value of f() got destroyed before we got a chance to
> copy it.

I see.  We'd have to have copied it to some temporary that would hold
the result of the statement expression before calling its destructor.
But we'd have to special-case this copy to only be done for the last
statement of a statement-expression.  Too bad.

Maybe the way to go is to require statement expressions to contain
explicit `return' statements, at least in C++.  This would at least
make it easier to support them in C++.  Is `return' currently usable
within statement expressions?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> Maybe the way to go is to require statement expressions
    Alexandre> to contain explicit `return' statements, at least in
    Alexandre> C++.  This would at least make it easier to support
    Alexandre> them in C++.  Is `return' currently usable within
    Alexandre> statement expressions?

Yes, but that means `return from this function', not `return from the
statement expression'.  (Which is why Per's analogy to inlining isn't
quite perfect, even in C.  If you're compiling Scheme to C, you want
to generate a `goto' in the statement expression (to a label later in
the statement expression) where in Scheme you had a `return'.)

So, making `return' in a statement expression mean `exit the statement
expression' would be the worst kind of change: it would change the
meaning of valid programs.

I think that Per's analogy of Scheme->C with OO Functional->C++ is not
that good.  The Scheme->C translation is much more tractable than the
C++ translation.  Many functional OO languages do not map well onto
C++.  (For example, if they allow method replacement, vtables are not
what you want.)  In C, inline functions get (well, the compiler should
do better) you 95% of the value of statement expressions.  The typeof
extension gets you a little extra power.  In C++, you can use inline
functions and templates to get all of that power.

I think the only compellilng arguments for keeping statement
expressions in C++ are:

  o They appear in headers that we need to compile in C++.
  
  o Some users may rely on them.

Those are important arguments, but I don't think there's a compelling
reason in the language itself.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Alexandre Oliva]

On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

Alexandre> Is `return' currently usable within
Alexandre> statement expressions?

> Yes, but that means `return from this function'

Damn!  I was hoping it would be either invalid or not supposed to
work :-(

> So, making `return' in a statement expression mean `exit the statement
> expression' would be the worst kind of change: it would change the
> meaning of valid programs.

Yup.

> I think the only compellilng arguments for keeping statement
> expressions in C++ are:

>   o They appear in headers that we need to compile in C++.
  
>   o Some users may rely on them.

> Those are important arguments, but I don't think there's a compelling
> reason in the language itself.

Yep.

How about, for a start, mandating that the result of a statement
expression be a POD object?  This would get us rid of the problem of
handling destructors and would be codifying existing practice, since,
if my understanding is correct, non-PODs get their destructors run
before the result is made available.  At the very least, we could
issue a warning for this case.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> How about, for a start, mandating that the result of a
    Alexandre> statement expression be a POD object?  This would get

Not a bad idea.

    Alexandre> us rid of the problem of handling destructors and would
    Alexandre> be codifying existing practice, since, if my
    Alexandre> understanding is correct, non-PODs get their
    Alexandre> destructors run before the result is made available.
    Alexandre> At the very least, we could issue a warning for this
    Alexandre> case.

There are other problems too:

  #define foo(X) ({ /* some code */ f(X); /* some more code */ })

Now, suppose that X is an expression that creates temporaries, and
that `foo' is a standard library function.  (I've seen this with the
glibc headers by the way.  Some of them do something like:

  #define foo(x) ({ int i = x; ... }) 

which has this form.)

Then, temporaries involved in the X expression are destroyed at the
end of the statement-expression, which is earlier than the language
says they should be.  We break conformant programs in this way.

That's another reason why this construct has such difficult semantics
in C++.  There's really no right answer -- the other answer is to wait
until the end of the enclosing full expression.  But then if you try
to do Per's inlining trick, you find your destructors are run too
late.

The bottom line is that statement-expressions just don't make sense in
C++.  The Scheme analogy (statements are just expressions that happen
to have no value) just doesn't really work because of the impact of
temporaries, destructors, etc.  The Scheme analogy does work much
better in C, and (to reiterate), I don't think statement-expressions
are nearly so problematic in C.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Alexandre Oliva]

On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

> There's really no right answer -- the other answer is to wait
> until the end of the enclosing full expression.

It appears to me that this would solve all of the problems you've
listed so far, and it seems reasonably sound to me.  Is there any
technical reason why we can't do it?  Or that makes it too difficult
to implement in the current C++ framework?

On one hand, I see this solution would be necessary to arrange for
non-POD types to work as arguments to macros.  On the other hand, I
find it troubling that the semantics might be slightly different from
that of an inline function.  But then, if I think of the latter
semantics (of having objects destructed at the end of the
statement-expression, instead of at the end of the full enclosing
statement) in the context of nested statement exceptions, which is not
totally unheard of with so many standard functions implemented as
macros, my head hurts.  It sounds far saner to me, according to the
C++ semantics, to have all temporaries created in it, even if in
nested statement expressions, destructed at the end of the full
statement in which they appear.  It's a pity that this would differ
from the semantics of an inlined function, but then, this has always
been a point in which a macro differs from an inlined function in C++.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

    Alexandre> On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com>
    Alexandre> wrote:

    >> There's really no right answer -- the other answer is to wait
    >> until the end of the enclosing full expression.

    Alexandre> It appears to me that this would solve all of the
    Alexandre> problems you've listed so far, and it seems reasonably
    Alexandre> sound to me.  Is there any technical reason why we
    Alexandre> can't do it?

We can implement anything.  :-)

But think how surprising it would be to users to have to explain that
statements in a statement-expression have different semantics from
statements that aren't in a statement-expression.  Essentially, you
then break the invariant that:

  {
    ...
  }

means the same thing as:

 ({
   ...
  });

which is extremely odd.  If you don't clean up temporaries, are you
still going to clean up named objects:

  ({ A a; })

When does `a' get destroyed?  Are you willing to destroy `a' first and
the temporaries that were created before it later, in opposition to
the usual last-in first-out order?  If not, named objects will not be
destroyed at the end of scopes internal to the statement-expression.
Very odd, indeed.

That's what I'm getting at here.  You can define the semantics any
weird way you want, and given N problems you can probably come up with
a semantics that solves all N of them.  What I don't think possible,
unfortunately, is come up with semantics that are consistent, in the
spirit of C++, and easy for users to understand, and will solve the
N+1st problem.

The issue here is that this is not an extension that would pass muster
with the committe -- even the same committee that OK'd many of the
oddities that many programming language theorists don't like, such as
multiple inheritance, virtual base classes, or user-defined
conversion.

I just don't believe this extension makes sense in C++.  It adds no
additional power, it provides no additional cleanliness, affords no
portability.  On the other hand, it has dubious semantics, at best,
and is difficult to implement (especially when you consider using
these things in default arguments.

I think we should be looking at the core issues: how many libraries
make use of this feature, can we ask the library maintainers to phase
out this feature over time, and how many users are using this
extension directly in their own code. 

If the answers to those questions are distinctly unfavorable, then we
may have little choice.  We will have to make up some least bogus
semantics, and go forward.  However, my instinct is that the answers
will be favorable, and we can proceed by first changing the libraries
and then phasing out the extension.  I think that's a process that
will take at least a year.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Per Bothner]

Mark Mitchell <mark@codesourcery.com> writes:

> I think that Per's analogy of Scheme->C with OO Functional->C++ is not
> that good.  The Scheme->C translation is much more tractable than the
> C++ translation.  Many functional OO languages do not map well onto
> C++.  (For example, if they allow method replacement, vtables are not
> what you want.)

No, but there is a good chance you might want to use the C++ abstraction
facilities such non-virtual methods and templates.

-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: GCC's statement expression extension

[Linus Torvalds]

In article < orvgxolqo1.fsf@guarana.lsd.ic.unicamp.br > you write:
>
>Maybe the way to go is to require statement expressions to contain
>explicit `return' statements, at least in C++.  This would at least
>make it easier to support them in C++.  Is `return' currently usable
>within statement expressions?

I think this would be a _wonderful_ rule.

Yes, it would break current practice and require changes.  But it would
make a ton of sense, and I always thought that the "use the last value"
rule was a bit ugly (yes, I realize that is how K&R C compilers actually
_used_ to work even for normal functins, and that "return" wasn't
actually required back in the Elder Days.  Even so, requiring a "return"
statement at the end of functions was a GoodThing(tm), and would be a
good thing for statement expressions too). 

If adding an explicit "return", and really making statement expressions
look more like "anonymous inline functions" would be all it took to make
them more palatable to C++, then I think this is definitely worth doing.
Much better than just getting rid of them. An dit would make them
cleaner in C too.

(And by making it warn about missing returns, it would be really easy to
fix up existing code even for people who weren't aware of the change)

		Linus

Re: GCC's statement expression extension

[Per Bothner]

Mark Mitchell <mark@codesourcery.com> writes:

> That seems like the obvious right answer.  It just doesn't work very
> well for:
> 
>   X x;
>   X f();
> 
>   x = ({ f(); });

What I meant to say was that this should be handled the same as:

X x;
X f();
inline X __tmp1() { return f(); }
x = __tmp1();
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: GCC's statement expression extension

[Marc Espie]

In article < 3981F647.2FBFFD19@apple.com > you write:
>Also, since they can only use Apple's modified version of
>GCC, their complaints and problems come to us in the tools group, not to
>bug-gcc.  So you probably haven't heard much of what they have to say.

Ouch.
This is a very bad way to do things. This means the Apple tools group hoard
some knowledge that may come very handy at times. 

There are fairly good reasons to do things that way (like, not burdening
the main gcc development process with specific, Apple-related issues).

When I handle gcc for OpenBSD, I do things that way, at least partially.
But I try very hard NOT to handle platform-independent issues at the 
OpenBSD level... when there are bugs I can fix, I send patches. When
there are bugs I can't fix, I ask here... and I send people to complain
here if they run into problems that seem representative of our user base
to me (or I try to give a reasonable image of what's going for us).

One major problem gcc had in the past is lack of feedback, lack of direction:
compiler growing and growing, with no real idea about what the userbase wanted.
Apart from the FSF mandate, there are issues... specifically, gcc will be
a failure if nobody uses it because of a (perceived or real) lack of 
robustness, or speed problems.

If you have specific instances of lots of users using some extensions over
in the Apple's tool group, please step forward and give them to us...

Reporting GCC issues (was Re: GCC's statement expression extension)

[Stan Shebs]

Marc Espie wrote:
> 
> In article < 3981F647.2FBFFD19@apple.com > you write:
> >Also, since they can only use Apple's modified version of
> >GCC, their complaints and problems come to us in the tools group, not to
> >bug-gcc.  So you probably haven't heard much of what they have to say.
> 
> Ouch.
> This is a very bad way to do things. This means the Apple tools group hoard
> some knowledge that may come very handy at times.

Quite true.  One of the reasons I'm at Apple is to change that, although
there is considerable inertia to overcome!  Open process was always
fairly easy at Cygnus, generally they only hired engineers who bought
into the idea to begin with.  Here you need to have concrete demonstrations
of actual benefits from the more open development process.

> There are fairly good reasons to do things that way (like, not burdening
> the main gcc development process with specific, Apple-related issues).

In practice, perhaps 90% of our user problems are related to Apple's
own changes - perhaps not surprising, since those changes have received
much less exercise and review than mainline GCC code.  (In some cases,
there is no one left at Apple who remembers the reasons for a change,
but you can't just take it out either, because the compiler dies.  Sigh.)

> One major problem gcc had in the past is lack of feedback, lack of direction:
> compiler growing and growing, with no real idea about what the userbase wanted.
> Apart from the FSF mandate, there are issues... specifically, gcc will be
> a failure if nobody uses it because of a (perceived or real) lack of
> robustness, or speed problems.

Amen!

> If you have specific instances of lots of users using some extensions over
> in the Apple's tool group, please step forward and give them to us...

I've brought up some internal issues here already, such as the embedded C++
question and overall compiler performance.  I've also encouraged other tools
engineers to forward their issues as well, although the response has been
disappointing so far - the first two got no substantive responses about the
GCC changes they proposed.  This was somewhat embarassing, since I had
sold the idea of posting proposals to the list as being an expected part
of GCC development, but the lack of response just confirmed the prevailing
internal skepticism about the value of working more closely with other GCC
developers.  (I remain optimistic though.)

Stan

Re: GCC's statement expression extension

[Mark Kettenis]

   From: Jamie Lokier <egcs@tantalophile.demon.co.uk> 
   Date: Fri, 4 Aug 2000 13:35:25 +0200 

   [Mark: the toupper example is not correct]

Indeed, please read on.

   Here is an example using Glibc's <bits/string2.h> implementation of
   strcmp.  (Work through the mass of __builtin_constant_p to the
   __strcmp_cg call).

     printf ("%s", (!strcmp ("yes", (a+b).c_str())) ? "equal" : "not equal");

Note that glibc leaves out a lot of its optimizations that use
statement expressions for C++.  Among these are tolower and toupper
(which are inlines for C++), and all of the string optimizations in
bits/string.h and bits/string2.h.

The only macro's that use statement expressions in <string.h> that are
used for C++ are strdupa and strndupa.  And these look to me as things
that would be impossible to implement using inlines.

Mark, please make sure that what you're saying about glibc in the
documentation is accurate.  Feel free to keep the comment if you can
find a *real* example where the semantics are problematic.  Otherwise,
replace the reference to the GNU C Library with a concrete example of
a statement expression that has problems.

Mark

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:

    Mark>    From: Jamie Lokier <egcs@tantalophile.demon.co.uk> Date:
    Mark> Fri, 4 Aug 2000 13:35:25 +0200

    Mark>    [Mark: the toupper example is not correct]

Oh, I see -- you're saying we use inlines instead.

    Mark> Mark, please make sure that what you're saying about glibc
    Mark> in the documentation is accurate.  Feel free to keep the
    Mark> comment if you can find a *real* example where the semantics
    Mark> are problematic.  Otherwise, replace the reference to the
    Mark> GNU C Library with a concrete example of a statement
    Mark> expression that has problems.

Fair enough.  

I originally discovered this problem in real code using glibc.  It may
well be that some of the problems have been fixed since then.

I will vaguify the documentation appropriately.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[John Marshall]

> RCS file: /cvs/gcc/egcs/gcc/extend.texi,v
[...]
> + string a, b;
> + printf("%s", toupper((a+b).c_str()[0]));
            ^^
            %c

    John

Re: GCC's statement expression extension

[Mark Mitchell]

Thanks; fixed.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Mike Stump]

> Date: Thu, 3 Aug 2000 19:55:01 +0200
> From: Jamie Lokier <egcs@tantalophile.demon.co.uk>
> To: Mike Stump <mrs@windriver.com>

>   printf("%s", toupper((a+b).c_str()[0]));

Nope, not a problem.  You need one that takes and returns the same
char *, ah, answered my own question:

printf("%s", strcat((a+b).c_str(), ""));

But even in this case, strcat I bet isn't a macro, and even it it
were, I bet it would not abuse SEs, and even if it did, catting in ""
wouldn't make any sense.

Re: GCC's statement expression extension

[Jamie Lokier]

[Mark: the toupper example is not correct]

Mike Stump wrote:
> >   printf("%s", toupper((a+b).c_str()[0]));
> 
> Nope, not a problem.  You need one that takes and returns the same
> char *...

You are right, but the macro doesn't have to return the same char * for
there to be a problem.

If the macro had the form ({ char * s = (arg); do_something_with(s); })
then it would break because arg, being (a+b).c_str(), would be destroyed
after s was assigned and before evaluating do_something_with(s).

Here is an example using Glibc's <bits/string2.h> implementation of
strcmp.  (Work through the mass of __builtin_constant_p to the
__strcmp_cg call).

  printf ("%s", (!strcmp ("yes", (a+b).c_str())) ? "equal" : "not equal");

enjoy,
-- Jamie

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Jamie" == Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:

    Jamie> [Mark: the toupper example is not correct]

Why not?

I have:

  # define __tobody(c, f, a) 
    (__extension__							      
     ({ int __res;							      
	...						      
	__res = a[(int) (c)];						      
	__res; }))

If `c' is `(a + b).c_str()[0]' then a temporary will be created for `a
+ b' when `c' is used as an array index.  That temporary will be
destroyed at the end of the statement:

  __res = a[(int) (c)];

inside the statement expression, which is earlier than the end of the
enclosing full expression.

I'm happy to change the documentation, but I'm confused as to why you
think your original example doesn't illustrate the problem.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Jamie Lokier]

Mark Mitchell wrote:
> Why not?

>   # define __tobody(c, f, a) 
>     (__extension__							      
>      ({ int __res;							      
> 	...						      
> 	__res = a[(int) (c)];						      
> 	__res; }))
> 

> If `c' is `(a + b).c_str()[0]' then a temporary will be created for `a
> + b' when `c' is used as an array index.  That temporary will be
> destroyed [...] inside the statement expression, which is earlier than
> the end of the enclosing full expression.

In this case, the observed behaviour is the same though isn't it?

If the string's destructor changes the current locale it might be
observable (I'm not sure if locales affect toupper), but if you put
that in the documentation it's going to look obscure.

-- Jamie

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Jamie" == Jamie Lokier <egcs@tantalophile.demon.co.uk> writes:

    Jamie> In this case, the observed behaviour is the same though
    Jamie> isn't it?

But, if you said something like:

  printf ("%c", (toupper..)), (a1 + b1);

you'd get the destruction order in the wrong order. 

In any case, I've removed the specific example, and vaguified the
text.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Mike Stump]

> To: mrs@windriver.com
> Cc: per@bothner.com, gcc@gcc.gnu.org
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Tue, 01 Aug 2000 21:52:07 -0700

> Since this does not work correctly in C++, can we agree that this
> usage should be removed from glibc when compiling C++?

Yes.

> Also, can we add a note to the documentation section on
> statement-expressions in C++ giving this example, and explaining how
> it can surprise C++ users, so that people who go read about this
> extension in C will at least be aware that there are issues with
> this extension in C++?

Sure.

printf("%s", bad_c_marco((a+b).c_str()));

would be the canonical example, but I don't know of a libc function to
put here that uses SEs.

Re: GCC's statement expression extension

[Jamie Lokier]

Mike Stump wrote:
> printf("%s", bad_c_marco((a+b).c_str()));
> 
> would be the canonical example, but I don't know of a libc function to
> put here that uses SEs.

  printf("%s", toupper((a+b).c_str()[0]));

-- Jamie

Re: GCC's statement expression extension

[Mark Mitchell]

Jamie --

  Thanks for your example.

  I've checked in the attached patch, using your example.  I've tried
to explain things so that both library designers and C++ users can
understand the issues.  Updates and clarifications are certainly
welcome.

  Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

2000-08-03  Mark Mitchell  <mark@codesourcery.com>

	* extend.texi: Add commentary on statement-expressions and their
	interactions with C++.

Index: extend.texi
===================================================================
RCS file: /cvs/gcc/egcs/gcc/extend.texi,v
retrieving revision 1.58
diff -c -p -r1.58 extend.texi
*** extend.texi	2000/07/28 13:24:20	1.58
--- extend.texi	2000/08/03 23:06:26
*************** If you don't know the type of the operan
*** 184,189 ****
--- 184,232 ----
  must use @code{typeof} (@pxref{Typeof}) or type naming (@pxref{Naming
  Types}).
  
+ Statement expressions are not supported fully in G++, and their fate
+ there is unclear.  (It is possible that they will become fully supported
+ at some point, or that they will be deprecated, or that the bugs that
+ are present will continue to exist indefinitely.)  Presently, statement
+ expressions do not work well as default arguments. 
+ 
+ In addition, there are semantic issues with statement-expressions in
+ C++.  If you try to use statement-expressions instead of inline
+ functions in C++, you may be surprised at the way object destruction is
+ handled.  For example:
+ 
+ @example
+ #define foo(a)  (@{int b = (a); b + 3; @})
+ @end example
+ 
+ @noindent
+ does not work the same way as:
+ 
+ @example
+ inline int foo(a) @{ int b = a; return b + 3; @}
+ @end example
+ 
+ @noindent
+ In particular, if the expression passed into @code{foo} involves the
+ creation of temporaries, the destructors for those temporaries will be
+ run earlier in the case of the macro than in the case of the function.
+ 
+ These considerations mean that it is probably a bad idea to use
+ statement-expressions of this form in header files that are designed to
+ work with C++.  Note that the GNU C Library does contain header files
+ using statement-expressions, and that these definitions make the library
+ technically non-conforming.  For example, when optimization is turned
+ on,
+ 
+ @example
+ string a, b;
+ printf("%s", toupper((a+b).c_str()[0]));
+ @end example
+ 
+ @noindent
+ will result in the destructor for the temporary created for @code{a+b}
+ being run earlier than it should be.
+ 
  @node Local Labels
  @section Locally Declared Labels
  @cindex local labels

Re: GCC's statement expression extension

[Kamil Iskra]

On Thu, 3 Aug 2000, Mark Mitchell wrote:

> RCS file: /cvs/gcc/egcs/gcc/extend.texi,v
> retrieving revision 1.58
> diff -c -p -r1.58 extend.texi
> *** extend.texi	2000/07/28 13:24:20	1.58
> --- extend.texi	2000/08/03 23:06:26
[snip]
> + @example
> + #define foo(a)  (@{int b = (a); b + 3; @})
> + @end example
> + 
> + @noindent
> + does not work the same way as:
> + 
> + @example
> + inline int foo(a) @{ int b = a; return b + 3; @}
> + @end example

I think there are two issues regarding the inline function.

First, "a" in the parameter list is typeless. It should be "int",
shouldn't it?

Second, this inline function looks very artificial. Why have an extra
local variable "b", if you can just "return a + 3"? I have little
experience with C++, but no sane C programmer would write it like this,
and I'm sure you agree. This makes me wonder: is this necessary for your
example, or not? Common sense suggests "not". I guess you did it like this
to make it look more similar to the statement expression, but that's just
my guess, and, at least for me, this extra obfuscation makes the whole
issue even more fuzzy than it already is.

I think you should either adjust the example, or add more explanation.
Examples should be cristal clear. This one is not, and thus it fails to
make the point.

Regards,

-- 
/ Kamil Iskra  kamil@wins.uva.nl                                          \
| Section Computational Science, Faculty FNWI, Universiteit van Amsterdam |
| tel. +31 20 525 75 35  fax. +31 20 525 74 90                            |
\ Kruislaan 403  room F.202  1098 SJ Amsterdam (NL)                       /

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Kamil" == Kamil Iskra <kamil@wins.uva.nl> writes:
 
  Kamil> I think you should either adjust the example, or add more
  Kamil> explanation.  Examples should be cristal clear. This one is
  Kamil> not, and thus it fails to make the point.

I'll fix the typo.  I don't find the example unclear -- but I wrote
it.

If you like, please write some additional explanatory text, and I will
be happy to incorporate it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Kamil Iskra]

On Fri, 4 Aug 2000, Mark Mitchell wrote:

> I'll fix the typo.  I don't find the example unclear -- but I wrote
> it.
> 
> If you like, please write some additional explanatory text, and I will
> be happy to incorporate it.

Having thought about it again, I came to a conclussion that there is
nothing more to explain about the example once you put "int" in front of
"a". Now it's clear that "b" in the inline function simply doesn't have
any significance.

Still, I think that "b" should simply be eliminated. A one-liner example
with nonrelevant code in it strikes me as odd. YMMV. It's a minor issue
anyway.

For refence, here's what I suggest:

--- extend.texi.orig	Sat Aug  5 19:13:21 2000
+++ extend.texi	Sat Aug  5 19:25:27 2000
@@ -203,7 +203,7 @@ handled.  For example:
 does not work the same way as:
 
 @example
-inline int foo(int a) @{ int b = a; return b + 3; @}
+inline int foo(int a) @{ return a + 3; @}
 @end example
 
 @noindent

-- 
/ Kamil Iskra  kamil@wins.uva.nl                                          \
| Section Computational Science, Faculty FNWI, Universiteit van Amsterdam |
| tel. +31 20 525 75 35  fax. +31 20 525 74 90                            |
\ Kruislaan 403  room F.202  1098 SJ Amsterdam (NL)                       /

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Kamil" == Kamil Iskra <kamil@wins.uva.nl> writes:

    Kamil> Still, I think that "b" should simply be eliminated. A
    Kamil> one-liner example with nonrelevant code in it strikes me as
    Kamil> odd. YMMV. It's a minor issue anyway.

Thanks for following up, and for providing the patch.

I prefer the current form since it makes it look like the macro above.

Let's agree to disagree.  I'll back out of the debate at this point --
if any of the other maintainers would prefer Kamil's documentation
change, please incorporate it.

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Mike Stump]

> To: per@bothner.com
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sat, 29 Jul 2000 10:42:58 -0700

> That seems like the obvious right answer.  It just doesn't work very
> well for:

>   X x;
>   X f();

>   x = ({ f(); });

It seems like it does to me.  There is a preexisting references extend
the life of temporaries rule already in the C++ standard that I think
covers one sensible way to treat this case.  With that, it make
perfect sense to me.  It is true, that we have to realize that rule
`fits' in this situation, I see that as obvious.

> Oops.  The return value of f() got destroyed before we got a chance to
> copy it.  (There are more complex examples with similar problems,
> including binding things to references, which cause lifetime
> extensions in C++.)

It seems like the same issue to me.

> To: Mark Mitchell <mark@codesourcery.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 29 Jul 2000 15:47:26 -0300

> I see.  We'd have to have copied it to some temporary that would
> hold the result of the statement expression before calling its
> destructor.

A copy ctor to another temporary is another way to think about this.
This also fits, though, at first blush I think less well than
extending the lifetime.  Though, there might be technical reasons that
cause one to want to mandate a copy, and then permit the compiler to
get it of it, if it can.

> To: Mark Mitchell <mark@codesourcery.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 29 Jul 2000 16:29:53 -0300

> How about, for a start, mandating that the result of a statement
> expression be a POD object?  This would get us rid of the problem of
> handling destructors

I don't see a problem handling destructors.  I think the inside temps
expire at their full expression within the statements, and the object
that escapes from the expression in the expression statement has its
lifetime extended.  Simple, easy, consistent, predictable and in the
spirit of the standard.

> To: aoliva@redhat.com
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sat, 29 Jul 2000 12:52:41 -0700

> There are other problems too:

>   #define foo(X) ({ /* some code */ f(X); /* some more code */ })

> Now, suppose that X is an expression that creates temporaries, and
> that `foo' is a standard library function.  (I've seen this with the
> glibc headers by the way.  Some of them do something like:

>   #define foo(x) ({ int i = x; ... }) 

> which has this form.)

> Then, temporaries involved in the X expression are destroyed at the
> end of the statement-expression, which is earlier than the language
> says they should be.  We break conformant programs in this way.

I find the argument where a person misuses #defines and doesn't meet
the requirements of the standard and breaks conformant code this way,
while implementing parts of the standard, to be not very convincing.
They can misuse a good number of features to break user code already.

> That's another reason why this construct has such difficult semantics
> in C++.

I don't see it this way.

> To: Mark Mitchell <mark@codesourcery.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 29 Jul 2000 18:07:12 -0300

> On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

> > There's really no right answer -- the other answer is to wait
> > until the end of the enclosing full expression.

> It appears to me that this would solve all of the problems you've
> listed so far, and it seems reasonably sound to me.

I don't think it is reasonable.  The words in the standard say that
certainly by the time the statement containing an expression ends, the
temps are gone.  You cannot violate this rule without a very good
reason.

> To: aoliva@redhat.com
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Sun, 30 Jul 2000 10:06:06 -0700

> You can define the semantics any weird way you want, and given N
> problems you can probably come up with a semantics that solves all N
> of them.  What I don't think possible, unfortunately, is come up
> with semantics that are consistent, in the spirit of C++, and easy
> for users to understand, and will solve the N+1st problem.

I disagree.  What problems remain?

> It adds no additional power, it provides no additional cleanliness,
> affords no portability.  On the other hand, it has dubious
> semantics, at best, and is difficult to implement (especially when
> you consider using these things in default arguments.

What are the issues you don't like with regard to default arguments?

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@windriver.com> writes:

    Mike> I find the argument where a person misuses #defines and
    Mike> doesn't meet the requirements of the standard and breaks
    Mike> conformant code this way, while implementing parts of the
    Mike> standard, to be not very convincing.  They can misuse a good
    Mike> number of features to break user code already.

I seem to be getting into an awful lot of heated philosophical
arguments lately.  How unpleasant.

The bottom line is that if statement-expressions do not appear in
glibc macros, out problems will be largely solved -- independent of
questions about the semantics of statement expressions, or the
correctness of the implementation.  They may or may not actually work
in C++ -- but they will work about as well as they ever did before,
and people who write conforming code will see conforming behavior.
Furthermore, I bet no one will complain about bugs in the
statement-expression code, since I think very few people use it in
C++.  So, I will be happy to have it live on, if that's what people
want.

The problems with glibc headers were what motivated my original
statement-expression investigation some months ago, so let's stay
focused on that.

It sounds like we are all agreed that under any proposed semantics
for statement-expressions, code like:

  #define foo(X) ({ int i = X; i + 1; })

should not appear in glibc headers (at least when compiling C++) since
it is not conforming in C++, since it will result in early destruction
of temporaries for C++ objects that occur during the creation of X.
(I think one of Alexandre's proposals would not have had this problem,
but I think the rest of us weren't too happy with those semantics,
which involved not destroying any temporaries created in the
statement-expression until much later.)

I believe that this use of statement-expressions is the primary
motivation for their use in glibc headers -- you want to avoid
evaluating something more than once, so you store it in a local
variable, declared in a statement-expression.  

Since this does not work correctly in C++, can we agree that this
usage should be removed from glibc when compiling C++?  Also, can we
add a note to the documentation section on statement-expressions in
C++ giving this example, and explaining how it can surprise C++ users,
so that people who go read about this extension in C will at least be
aware that there are issues with this extension in C++?

By the way, on my system, I tried to find uses of this stuff in the
standard headers, and this is what I came up with under /usr/include:

  bash$ find . -name '*.h' | xargs -n10 grep -l '({'
  ./glib.h
  ./bits/byteswap.h
  ./bits/mathinline.h
  ./bits/select.h
  ./bits/sigset.h
  ./bits/stdio.h
  ./bits/string2.h
  ./bits/waitstatus.h
  ./ctype.h
  ./libintl.h
  ./math.h
  ./obstack.h
  ./string.h
  ./sys/wait.h
  ./tgmath.h
  ./unistd.h
  ./applet-widget.h

Although are a few instances of the pseudo-template stuff that we
talked about in tgmath.h, most of these are simple optimizations.  If
nothing else, we can fall back to the out-of-line versions of things,
which will be at least correct.  In most cases, we could also use an
inline-version of things.  Since C++ uses tree-based inlining, and
since the tree-based inliner tries to just substitute constants into
inlined functions, it is even likely that builtin_constant_p will
work for C++ on inlined functions.  

Indeed:

  inline int f (const char *const s)
  {
    if (__builtin_constant_p (s))
      return 1;
    else 
      return 0;
  }

  int g ()
  {
    return f ("abc");
  }

compiles to:

  g__Fv:
  .LFB1:
	  pushl	%ebp
  .LCFI0:
	  movl	$1, %eax
	  movl	%esp, %ebp
  .LCFI1:
	  popl	%ebp
	  ret

in C++.  (In C, `g' will return 0, but since our function-at-a-time
work for C is nearly complete, that can be expected to change at some
point.)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Alexandre Oliva]

On Aug  1, 2000, Mike Stump <mrs@windriver.com> wrote:

>> From: Alexandre Oliva <aoliva@redhat.com>
>> Date: 29 Jul 2000 18:07:12 -0300

>> On Jul 29, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

>> > There's really no right answer -- the other answer is to wait
>> > until the end of the enclosing full expression.

>> It appears to me that this would solve all of the problems you've
>> listed so far, and it seems reasonably sound to me.

> I don't think it is reasonable.  The words in the standard say that
> certainly by the time the statement containing an expression ends, the
> temps are gone.

Yep.  But in the case of statement expressions, there isn't just one
statement containing the expression:

  ({ foo(); bar(); });

Why is it any ``more correct'' to destruct the temporary returned by
foo() in the statement `foo();' that it is to destruct it at the end
of the full enclosing statement?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC's statement expression extension

[Per Bothner]

Alexandre Oliva <aoliva@redhat.com> writes:

> Yep.  But in the case of statement expressions, there isn't just one
> statement containing the expression:
> 
>   ({ foo(); bar(); });
> 
> Why is it any ``more correct'' to destruct the temporary returned by
> foo() in the statement `foo();' that it is to destruct it at the end
> of the full enclosing statement?

You do the same as you would do in this case:

        inline T __tmp1() { foo(); return bar(); }
        ... __tmp1() ...

where T is the type of bar().  At least that is my proposal.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: GCC's statement expression extension

[Phil Edwards]

Linus Torvalds <torvalds@transmeta.com>:
[beyond-the-standards argument]
> Now, that does NOT mean that every extension should be considered a good
> one. I'm not arguing anything like that. But I do think that your
> standpoint that "it is an extension so it must be bad" is narrow-minded
> and ultimately stupid. Extensions must be judged on _other_ criteria.

I'm all for extensions for languages, as long as their default mode is off.
But the "extension == bad" criterion isn't the one being applied here.
One of the other criteria of which you speak is "does it even make sense
to do this, and can we do it in a rational manner?"

Statement expressions mostly fail that criterion for C++.  Certainly it can
be argued that it makes sense to add S.E. to C++ (I would argue against it,
but at least both sides have an arguement).  I don't think it can be done
in a way that works well; the rules for C++ are a bit more complicated
than those of C.

And as others have pointed out, adding S.E. to C gains you something.
Adding them to C++ gains you nothing, but costs you something.  At least,
adding them /in their present form/.


> But I do understand the problem: if you want to make statement expressions
> illegal in C++ (which I have no real opinion of - it's a language I don't
> care for), you're screwing up one of the original advantages of C++: the
> backwards compatibility with a language I _do_ care about, and one that I
> want to see live on rather than die the horrid death of being forever
> entomed in the cobwebs of standardization.

Not a valid argument, sorry.  C++ has as one of its goals backwards
compatibility with C.  It's not required to be sideways compatible with
things added to C (like, say, some of the stuff added to C99) after the fact.

If glibc wants to be useable under two languages, then it has to restrain
itself to the common denominator.


> Could somebody explain why C++ has so many problems with statement
> expressions? Maybe there is some solution to this - something that might
> involve a form of statement expression-like behaviour that works on both C
> and C++?

A bunch of the "technical reasons why not" have been hashed out on the
list since your message.  As far as a middle ground... hmm.  I like the
idea of improving on S.E. so that they're acceptable to both languages.
The semantics for S.E. under C++ are still just going to be ass-nasty
however they work.  Maybe some variation on the C99 inline functions.

And I suspect that the glibc headers would still have to be rewritten,
because some people like to write portable code, and use "-ansi -pedantic"
to help test for GCC-isms.  The glibc implementation, of course, could be
written purely in extensions and it wouldn't bother anybody.


Phil

Re: GCC's statement expression extension

[Richard Kenner]

From wilson@cygnus.com Fri Jul 28 00:24:22 2000
Received: from alpha2.ultra.nyu.edu by vlsi1.ultra.nyu.edu (4.1/1.34)
	id AA18487; Fri, 28 Jul 00 00:24:22 EDT
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5])
	by alpha2.ultra.nyu.edu (8.9.3/8.9.3) with ESMTP id AAA31914
	for <kenner@vlsi1.ultra.nyu.edu>; Fri, 28 Jul 2000 00:02:44 -0400 (EDT)
Received: from wilson.cygnus.com (wilson.cygnus.com [205.180.230.158])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA00201;
	Thu, 27 Jul 2000 21:11:14 -0700 (PDT)
From: Jim Wilson <wilson@cygnus.com>
Received: (wilson@localhost) by wilson.cygnus.com (8.9.3/8.6.4) id VAA21071; Thu, 27 Jul 2000 21:11:32 -0700
Date: Thu, 27 Jul 2000 21:11:32 -0700
Message-Id: < 200007280411.VAA21071@wilson.cygnus.com >
To: kenner@vlsi1.ultra.nyu.edu
Subject: Re: GCC's statement expression extension
Newsgroups: cygnus.egcs
In-Reply-To: < 10007280259.AA18359@vlsi1.ultra.nyu.edu >
Cc: gcc@gcc.gnu.org
Status: RO

In article < 10007280259.AA18359@vlsi1.ultra.nyu.edu > you write:
>    I suspect it is the obstacks use of ({ ... }) and ?: omitting the
>    middle argument in gcc 1.35.  
>
>Nope.  It's an error in bc-typecd.def.  Something about a float being
>promoted to double.

It is SPEC92 that contains gcc 1.35, and SPEC92 was obsoleted 5 years ago
when SPEC95 came out.  Anyone who cares about SPEC only cares about SPEC2000
now.  SPEC95 had gcc 2.5.3.  I haven't looked at SPEC2000 yet, but I would
be surprised if it didn't have at least gcc 2.7.2.

By the way, it is SPEC95 that has the bc-typecd.def problem, not SPEC92.
The erroneous code (and yes, it is invalid code) appears within a
#ifdef __GNUC__, so it is only gcc that could possibly fail to compile this
program.  And this isn't the only problem with this old code.  It isn't
64-bit clean either.  I had to fix several bugs to get it working on an
ia64-linux machine.  None of these problems justify changing how we
develop gcc.

Jim

Re: GCC's statement expression extension

[Kaveh R. Ghazi]

 > From: Mark Mitchell <mark@codesourcery.com>
 > 
 > >>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
 > 
 >     Kaveh> Mark,
 > 
 >     Kaveh> 	As I see it, you're only proposing removing stmt exprs
 >     Kaveh> from G++.  The blocking factor is glibc's use of them in
 >     Kaveh> headers to optimize things like the string functions.  I
 >     Kaveh> don't have access to my linux box at the
 > 
 > Oh, no!  Your access went away right in the middle of that sentence!

:-)  Sorry.

I was going to say...

I don't have access to my linux box at the moment, but IIRC don't the
glibc headers have a way, via a cpp macro or something, to turn off
use of the replacement string macros that use stmt exprs and back down
to function calls?  (__NO_STRING_INLINES?)

If so, we can just teach g++ to always pass -D__NO_STRING_INLINES to
cpp to make sure the appropriate magic happens to turn off these stmt
expr using macros and then you can safely take out stmt exprs from
G++.

I don't know if all stmt exprs were protected using wrappers macros
though.  E.g. I don't think strdupa() was macro wrapped.

	 Anyway, just a thought...

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

    Kaveh> I don't know if all stmt exprs were protected using
    Kaveh> wrappers macros though.  E.g. I don't think strdupa() was
    Kaveh> macro wrapped.

    Kaveh> 	 Anyway, just a thought...

Interesting idea/point.  That might well be the right thing to do.  I
suspect that getting glibc to wrap the stuff with macro conditionals
is something that those folks would want to do anyhow (for other
compilers), so that's probably a less thorny path.  Thanks for the
good suggestion!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Kaveh R. Ghazi]

 > From: Mark Mitchell <mark@codesourcery.com>
 > 
 > Folks --
 > 
 >   We've now degenerated (largely my fault!) into complete
 > abstraction.  Fun, but useless.
 > 
 >   We all agree that breaking compatibility (source or binary) is bad.
 > I hope we all agree that *sometimes* it is the best path -- if it
 > permits better optimizations, better stability, faster release cycles,
 > etc.  We have to take each of these things case by case; there's no
 > other way.

Mark,

	As I see it, you're only proposing removing stmt exprs from
G++.  The blocking factor is glibc's use of them in headers to
optimize things like the string functions.  I don't have access to my
linux box at the 

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

    Kaveh> Mark,

    Kaveh> 	As I see it, you're only proposing removing stmt exprs
    Kaveh> from G++.  The blocking factor is glibc's use of them in
    Kaveh> headers to optimize things like the string functions.  I
    Kaveh> don't have access to my linux box at the

Oh, no!  Your access went away right in the middle of that sentence!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

RE: GCC's statement expression extension

[Anjul Srivastava]

It does not have undefined behavior, and will always evaluate to: three plus
twice the old value of i.

But that's besides the point. Even if you consider: ++i + i++ the behavior
is undefined,

but it cannot format your hard disk and still remain conforming. It cannot
ever return 42, regardless of the value of i. (It can only return an odd
integer but this again is besides the point).

The C/C++ standards leave only the order of evaluation undefined. They say
that of the possible choices of order of evaluation, which one is selected
is undefined. But the fact that one of them is selected is mandated by the
standard. That's why 42 is out, and formatting the hard disk is out, as also
returning 43 when the value of i is 5 is not possible unless you violate the
standard.

-----Original Message-----
From: Linus Torvalds [ mailto:torvalds@transmeta.com ]

Think about a basic C (and C++) expression:

	++i + ++i

What does the C standard say about the above?

Right. It has undefined behavior. It can return 42. It can format your
harddisk. And the compiler is still strictly conforming, and yes, you get
the occasional "bug-report" about it, but everybody agrees that it _is_
undefined behaviour, and everybody even agrees on _why_ it is undefined
behaviour, and there is really no problem.

Re: GCC's statement expression extension

[Gabriel Dos Reis]

Anjul Srivastava <anjul.srivastava@sanchez.com> writes:

| It does not have undefined behavior, and will always evaluate to: three plus
| twice the old value of i.

This is getting a bit off-topic: you can't modify more than once an
objet without intervening sequence point and expect a defined
behavior.

But that has nothing to do with the unnecessary headache
statement-expressions are causing when it come to implement standard
functionalities and optimizations.  It is just a distraction brought
in in order to hide the main issue.  Let's not go that road.

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

Re: GCC's statement expression extension

[sidster]

* Anjul Srivastava (anjul.srivastava@sanchez.com) [20000728 12:13]:
> It does not have undefined behavior, and will always evaluate to: three plus
> twice the old value of i.
> 
> But that's besides the point. Even if you consider: ++i + i++ the behavior
> is undefined,
> 
> but it cannot format your hard disk and still remain conforming. It cannot
> ever return 42, regardless of the value of i. (It can only return an odd
> integer but this again is besides the point).


Of course it can:

   i = 20;

   n = ++i + i++;

   // assume evaluation is from right to left
   //
   n = (21+1) + 20;  // n = 42




Best regards,

patrick
--
We've heard that a million monkeys at a million keyboards could
produce the Complete Works of Shakespeare; now, thanks to the
Internet, we know this is not true.
   -Robert Wilensky

Re: GCC's statement expression extension

[Richard Kenner]

    I suspect it is the obstacks use of ({ ... }) and ?: omitting the
    middle argument in gcc 1.35.  

Nope.  It's an error in bc-typecd.def.  Something about a float being
promoted to double.

Re: GCC's statement expression extension

[Jim Wilson]

In article < 10007280259.AA18359@vlsi1.ultra.nyu.edu > you write:
>    I suspect it is the obstacks use of ({ ... }) and ?: omitting the
>    middle argument in gcc 1.35.  
>
>Nope.  It's an error in bc-typecd.def.  Something about a float being
>promoted to double.

It is SPEC92 that contains gcc 1.35, and SPEC92 was obsoleted 5 years ago
when SPEC95 came out.  Anyone who cares about SPEC only cares about SPEC2000
now.  SPEC95 had gcc 2.5.3.  I haven't looked at SPEC2000 yet, but I would
be surprised if it didn't have at least gcc 2.7.2.

By the way, it is SPEC95 that has the bc-typecd.def problem, not SPEC92.
The erroneous code (and yes, it is invalid code) appears within a
#ifdef __GNUC__, so it is only gcc that could possibly fail to compile this
program.  And this isn't the only problem with this old code.  It isn't
64-bit clean either.  I had to fix several bugs to get it working on an
ia64-linux machine.  None of these problems justify changing how we
develop gcc.

Jim

Re: GCC's statement expression extension

[Richard Kenner]

    If SPEC really contains invalid code, then we're between a rock and a
    hard place.  I don't think we should break the compiler just to
    compile a benchmark.  We could patch SPEC, and we can provide the
    patch to whomever we're allowed to, under the SPEC licenses.

Well the amusing part is that the piece of SPEC that won't compile is
GCC!  Indeed, both GCC 2.8.1 and the last pre-EGCS FSF codebase won't
compile with the latest GCC.

Re: GCC's statement expression extension

[Jeffrey A Law]

  In message < 10007280242.AA18275@vlsi1.ultra.nyu.edu >you write:
  >     If SPEC really contains invalid code, then we're between a rock and a
  >     hard place.  I don't think we should break the compiler just to
  >     compile a benchmark.  We could patch SPEC, and we can provide the
  >     patch to whomever we're allowed to, under the SPEC licenses.
  > 
  > Well the amusing part is that the piece of SPEC that won't compile is
  > GCC!  Indeed, both GCC 2.8.1 and the last pre-EGCS FSF codebase won't
  > compile with the latest GCC.
Inform spec if the code is invalid -- they issue patchrelease updates to
deal with this kind of thing.
jeff

Re: GCC's statement expression extension

[Michael Meissner]

On Thu, Jul 27, 2000 at 08:39:42PM -0600, Jeffrey A Law wrote:
> 
>   In message < 10007280242.AA18275@vlsi1.ultra.nyu.edu >you write:
>   >     If SPEC really contains invalid code, then we're between a rock and a
>   >     hard place.  I don't think we should break the compiler just to
>   >     compile a benchmark.  We could patch SPEC, and we can provide the
>   >     patch to whomever we're allowed to, under the SPEC licenses.
>   > 
>   > Well the amusing part is that the piece of SPEC that won't compile is
>   > GCC!  Indeed, both GCC 2.8.1 and the last pre-EGCS FSF codebase won't
>   > compile with the latest GCC.
> Inform spec if the code is invalid -- they issue patchrelease updates to
> deal with this kind of thing.

I suspect it is the obstacks use of ({ ... }) and ?: omitting the middle
argument in gcc 1.35.  You should be able to compile it by the hack of using
-D__GNUC__ so that the standard vanilla compiler invocations are used instead
of the GCC builtin, but you probably don't want to do this for measuring
performance, since it will make the resulting compiler slightly slower.

This BTW is a perfect example of my point that we really can't get rid of most
of the extensions.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:

    Michael> This BTW is a perfect example of my point that we really
    Michael> can't get rid of most of the extensions.

I disagree.  Compiling GCC 1.35 should not be a priority for current
versions of GCC.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Michael Meissner]

On Thu, Jul 27, 2000 at 08:16:04PM -0700, Mark Mitchell wrote:
> >>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:
> 
>     Michael> This BTW is a perfect example of my point that we really
>     Michael> can't get rid of most of the extensions.
> 
> I disagree.  Compiling GCC 1.35 should not be a priority for current
> versions of GCC.

Well it is for Red Hat.  We have contracts that mandate building and running
various releases of SPEC.  Whether or not approved modifications to the source
are acceptable, I dunno, since I haven't been working on those contracts.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: GCC's statement expression extension

[Jim Wilson]

In article < 20000727234956.65046@cse.cygnus.com > you write:
>> I disagree.  Compiling GCC 1.35 should not be a priority for current
>> versions of GCC.
>
>Well it is for Red Hat.  We have contracts that mandate building and running
>various releases of SPEC.  Whether or not approved modifications to the source
>are acceptable, I dunno, since I haven't been working on those contracts.

No, it isn't.  If the code in SPEC isn't valid ISO C, then we aren't
obligated to support it as is.

Jim

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:

    Michael> Well it is for Red Hat.  We have contracts that mandate
    Michael> building and running various releases of SPEC.

That's not a consideration that is relevant to what should go in FSF
GCC, though.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> Well the amusing part is that the piece of SPEC that
    Richard> won't compile is GCC!  Indeed, both GCC 2.8.1 and the
    Richard> last pre-EGCS FSF codebase won't compile with the latest
    Richard> GCC.

That is amusing!  I still don't think it implies we should change
current GCC, though -- unless it's buggy.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Richard Kenner]

    One of the saving graces here is that older versions of the compiler
    are always available.  

True, but that's why the SPEC example is so interesting.  The current
version of GCC cannot compile SPEC and I don't think it's acceptable
to say "well, we can get SPEC numbers on the older versions, so it
doesn't matter that we can't get it on the latest compiler".

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> True, but that's why the SPEC example is so interesting.
    Richard> The current version of GCC cannot compile SPEC and I
    Richard> don't think it's acceptable to say "well, we can get SPEC
    Richard> numbers on the older versions, so it doesn't matter that
    Richard> we can't get it on the latest compiler".

If SPEC really contains invalid code, then we're between a rock and a
hard place.  I don't think we should break the compiler just to
compile a benchmark.  We could patch SPEC, and we can provide the
patch to whomever we're allowed to, under the SPEC licenses.

I'm much more sympathetic to preserving brokenness in the compiler to
benefit a popular program that users need (like the Linux kernel) than
the SPEC, which is only used by the community to evaluate the
compiler.  (Frankly, it's probably more often used by vendors to
impress their customers than by any real users.)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Linus Torvalds]

In article < 20000727192618Z.mitchell@codesourcery.com >,
Mark Mitchell  <mark@codesourcery.com> wrote:
>
>I'm much more sympathetic to preserving brokenness in the compiler to
>benefit a popular program that users need (like the Linux kernel) than
>the SPEC, which is only used by the community to evaluate the
>compiler.

Note that the Linux kernel is not adevrse to change - I've disagreed
about some things in the past, but they have not been because the kernel
cannot change to accomodate a better compiler, but because I've
disagreed with the definition of "better" ;)

I do not actually think that the kernel is the "major" user of the
statement expression - I suspect there are many other users that may
even be completely unaware of this whole discussion.  But assuming the
kernel _was_ one of the major users, I would still encourage the gcc
maintainers to break existing functionality if it results in a better
compiler.

I may complain if I think things are DEproving (ie I'd really think that
removing the statement expression would be a bad thing), but please
don't "preserve brokenness in the compiler" due to the Linux kernel. 
I'd hate to feel that the Linux kernel was seen as an impediment for a
better compiler.  Really.  That would be the _last_ thing I'd want to
happen. 

If making syntactic or other changes to expression statements is
required for a better compiler, I'd be all for it.  Please don't
hesitate at all to add a requirement that "return" be used inside
statement expressions, for example.  At least not on account of Linux. 

We can easily change things like that - but having to rely on a less
powerful language would be painful. 

		Linus

Re: GCC's statement expression extension

[Richard Kenner]

    Your opinions are valuable.  Although I think you may not fully
    understand the C++ user base.  

I'm talking about *C* not C++. As you point out, I know nothing about the
latter user base.

    On the other hand, the arguments Michael makes apply to almost any
    extension, and I do not agree, by any means, that we must preserve all
    extensions for all time.  The same argument justifies preserving many
    bugs; every time we issue an error that we did not before, we break
    programs.

Sure, and that is indeed a problem.  For example, the latest sources cannot
compile the GCC that has part of SPEC due to a new error message.

With as large a user base as we have, we cannot afford to ignore these issues
and if we try to, we'll surely hear about it.

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> I'm talking about *C* not C++. As you point out, I know
    Richard> nothing about the latter user base.

OK.  And you'll note that I already said I was suggesting deprecating
this feature only in C++. :-)

    Richard> With as large a user base as we have, we cannot afford to
    Richard> ignore these issues and if we try to, we'll surely hear
    Richard> about it.

We cannot afford to ignore them.  But, we do occasionally have to move
forward as well.  Other compilers have even larger user bases -- and
they have certainly tightened things up even more.

One of the saving graces here is that older versions of the compiler
are always available.  It's not unreasonable to (occasionally) have
users make a choice between more features/better optimization and
100% source compatibility.  Of course, we shouldn't do this unless
there's a good reason.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Marc Espie]

In article < 20000727191552S.mitchell@codesourcery.com > you write:

>One of the saving graces here is that older versions of the compiler
>are always available.  It's not unreasonable to (occasionally) have
>users make a choice between more features/better optimization and
>100% source compatibility.  Of course, we shouldn't do this unless
>there's a good reason.

Err... ouch.
Remember, that's the way the linux kernel stayed stuck with 2.7.2 for years,
more or less.
These days, there are vendors who provide complete OS with an integrated
compiler.  Changing the compiler with a more recent one usually breaks 
things, not that many, but a few.  Most users are not savvy enough to do
the update.  Many users don't even know the issues involved.
Also, some people have to deal with clueless system administrators, or people
who don't care at all about C++. Those guys will stick with an older C 
compiler, because it compiles C the way K&R said it should be.
(and yes, in a world of 40Gb disks, you still meet quota and policies of
"don't install stuff on MY machine").

`User takes sysadmin hostage. Threatens to install gcc 3.0. News at eleven.'

Narrows down the `good reasons' quite a lot in my opinion...

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes:

    >> One of the saving graces here is that older versions of the
    >> compiler are always available.  It's not unreasonable to
    >> (occasionally) have users make a choice between more
    >> features/better optimization and 100% source compatibility.  Of
    >> course, we shouldn't do this unless there's a good reason.

    Marc> Narrows down the `good reasons' quite a lot in my opinion...

Folks --

  We've now degenerated (largely my fault!) into complete
abstraction.  Fun, but useless.

  We all agree that breaking compatibility (source or binary) is bad.
I hope we all agree that *sometimes* it is the best path -- if it
permits better optimizations, better stability, faster release cycles,
etc.  We have to take each of these things case by case; there's no
other way.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Kamil Iskra]

On Thu, 27 Jul 2000, Mark Mitchell wrote:

>     Richard> With as large a user base as we have, we cannot afford to
>     Richard> ignore these issues and if we try to, we'll surely hear
>     Richard> about it.
> We cannot afford to ignore them.  But, we do occasionally have to move
> forward as well.  Other compilers have even larger user bases -- and
> they have certainly tightened things up even more.

Sorry to butt in, but:

Out of curiosity: can you name a compiler with "even larger user base"
than GCC? I've been thinking hard, but failed to come up with anything.

-- 
/ Kamil Iskra  kamil@wins.uva.nl                                          \
| Section Computational Science, Faculty FNWI, Universiteit van Amsterdam |
| tel. +31 20 525 75 35  fax. +31 20 525 74 90                            |
\ Kruislaan 403  room F.202  1098 SJ Amsterdam (NL)                       /

Re: GCC's statement expression extension

[Mo McKinlay]

# Out of curiosity: can you name a compiler with "even larger user base"
# than GCC? I've been thinking hard, but failed to come up with anything.

I'd suspect Microsoft Visual C++ is one of them. Could well be wrong,
though ;>

-- 
Mo McKinlay             Chief Software Architect          inter/open Labs
-------------------------------------------------------------------------
GnuPG Key: pub  1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Kamil" == Kamil Iskra <kamil@wins.uva.nl> writes:

    Kamil> Out of curiosity: can you name a compiler with "even larger
    Kamil> user base" than GCC? I've been thinking hard, but failed to
    Kamil> come up with anything.

I don't think it's relevant -- but I think that MSVC++ probably has
more users than G++.  I was also referring to historical data; I
suspect that Sun's C++ compiler had more users than G++ at one point,
and yet they did make incompatible changes.  (I know this because I
was one of the users who had to change code at that point.)  

I have no hard data, and I'm happy to be told otherwise; these are
just my best guesses.  Let's not debate this on-list; just flame me
privately. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC's statement expression extension

[Joseph S. Myers]

GCC has the "statement expression" extension, where a compound statement
may be enclosed in parentheses and used as part of an expression, ({
... }).

It seems GCC does not restrict gotos in and out of statement expressions,
even where they don't particularly make sense.  For example, the
nonsensical program

	#include <stdio.h>
	int main(void){ printf ("%d\n", ({a:; 0; })); goto a; }

dumps core for me on i686-pc-linux-gnu (after printing 0 many times).

Is there any use for such jumps, or should this extension have a
constraint (in standards terminology) that a program shall not jump into a
statement expression from outside (with a mandatory error)?

Do jumps out of statement expressions work sensibly in GCC either (i.e.,
not crash, but with unspecified semantics relating to what of the
containing expression, except where subject to sequence point rules, has
been evaluated)?

Does GCC define the sequence point semantics of statement
expressions?  (For example, may evaluation of multiple statement
expressions within one containing expression be interleaved, cf the ruling
for DR#087 against the old C standard that function calls do not overlap?)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC's statement expression extension

[Jeffrey A Law]

  In message < Pine.SOL.4.21.0007220011570.29830-100000@orange.csi.cam.ac.uk >you
 write:
  > It seems GCC does not restrict gotos in and out of statement expressions,
  > even where they don't particularly make sense.  For example, the
  > nonsensical program
  > 
  > 	#include <stdio.h>
  > 	int main(void){ printf ("%d\n", ({a:; 0; })); goto a; }
  > 
  > dumps core for me on i686-pc-linux-gnu (after printing 0 many times).
Joys.  Note if we declare this valid behavior, then we should add this to the
"compile" part of the testsuite, else we should add it to the non-compile
part of the testsuite.

  > Is there any use for such jumps, or should this extension have a
  > constraint (in standards terminology) that a program shall not jump into a
  > statement expression from outside (with a mandatory error)?
I'm not really a language expert -- the way I tend to deal with this stuff
is ask myself _can_ the compiler deal with this situation in a sensible and
expected manner.  If it's simply impossible to deal with it in a sane manner,
then I recommend a constraint, else I recommend making the compiler generate
sane code.

  > Do jumps out of statement expressions work sensibly in GCC either (i.e.,
  > not crash, but with unspecified semantics relating to what of the
  > containing expression, except where subject to sequence point rules, has
  > been evaluated)?
Unknown.


  > Does GCC define the sequence point semantics of statement
  > expressions?  (For example, may evaluation of multiple statement
  > expressions within one containing expression be interleaved, cf the ruling
  > for DR#087 against the old C standard that function calls do not overlap?)
Unknown.


One of the long standing problems with GCC's extensions is they were not
well defined by the original authors -- lots of corner cases such as these
were never considered and thus there is nothing in the documentation about
the semantics of these cases.

I'm willing to go along with whatever makes the most sense from a language
design and implementation point of view.

jeff

Re: GCC's statement expression extension

[Mark Mitchell]

    In message < Pine.SOL.4.21.0007220011570.29830-100000@orange.csi.cam.ac.uk >you
   write:
    > It seems GCC does not restrict gotos in and out of statement expressions,
    > even where they don't particularly make sense.  For example, the
    > nonsensical program
    > 
    > 	#include <stdio.h>
    > 	int main(void){ printf ("%d\n", ({a:; 0; })); goto a; }
    > 
    > dumps core for me on i686-pc-linux-gnu (after printing 0 many times).

This should definitely be illegal.  In general, statement-expressions
are a poorly thought out extension, and do not have nice semantics.
This is hardly the first oddity of these beasts.  (For example, it's
very hard to implement statement expressions as default arguments in
C++, which means that certainly default argument expressions involving
standard library functions do not work in G++.  Another C++ example is
that object-lifetime with statement expressions is not well-defined,
and has no obviously correct choice.)

Note that there is a similar problem:

  a:
     f ("%d\n", ({goto a;})

Basically, a jump into or out of a call is going to leave the stack
messed up.

The best solution would be to treat all labels in a
statement-expression as local, and to forbid any goto that leaves the
scope of a statement epxression.

A secondary consideration is that we should consider deprecating the
statement-expression extension.  We should try to convince the glibc
people that statement-expressions are bad, since they are the heaviest
users of this hack.  The glibc people should remove all of that crud
in macros, and replace it with inline functions.  And we should make
the compiler optimize the inline fucntions appropriately so that they
cannot complain that performance is degraded.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> A secondary consideration is that we should consider deprecating the
> statement-expression extension.  We should try to convince the glibc
> people that statement-expressions are bad, since they are the heaviest
> users of this hack.  The glibc people should remove all of that crud
> in macros, and replace it with inline functions.  And we should make
> the compiler optimize the inline fucntions appropriately so that they
> cannot complain that performance is degraded.

The main reason glibc does this is because __builtin_constant_p
doesn't/didn't work inside inline functions.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Geoff" == Geoff Keating <geoffk@cygnus.com> writes:

    Geoff> The main reason glibc does this is because
    Geoff> __builtin_constant_p doesn't/didn't work inside inline
    Geoff> functions.

I understand.

I'm not convinced that we couldn't do this some other way, however.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Richard Henderson]

On Mon, Jul 24, 2000 at 03:48:16PM -0700, Geoff Keating wrote:
> The main reason glibc does this is because __builtin_constant_p
> doesn't/didn't work inside inline functions.

No, this has not been true for a while.


r~

Re: GCC's statement expression extension

[Richard Henderson]

On Sun, Jul 23, 2000 at 09:52:22AM -0700, Mark Mitchell wrote:
> We should try to convince the glibc people that statement-expressions
> are bad, since they are the heaviest users of this hack.

There are quite a few in the Linux kernel as well.

In addition, glibc uses this extension for things that simply cannot be
done with inline functions.  See <tgmath.h>.  Note that the types of
these expressions are dependant on the types of the arguments.  This is
otherwise impossible in C.  Also note that these functions are defined
by C99 -- I suppose the committee was thinking that these would be
compiler builtins or something.


r~

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    Richard> There are quite a few in the Linux kernel as well.

I'm sympathetic -- people used these things because a) we provided
them, and b) inline functions were not sufficiently optimized.

That's a blemish on GCC's history.  We should not punish our users
twice by ripping these things out from under them.

I think, though, that we should consider deprecating them (and issuing
warnings) in GCC 3.0, and removing them in the next major release.  

    Richard> In addition, glibc uses this extension for things that
    Richard> simply cannot be done with inline functions.  See
    Richard> <tgmath.h>.  Note that the types of these expressions are
    Richard> dependant on the types of the arguments.  This is
    Richard> otherwise impossible in C.  Also note that these
    Richard> functions are defined by C99 -- I suppose the committee
    Richard> was thinking that these would be compiler builtins or
    Richard> something.

Yes, probably.  

(Actually, I bet you can write those functions with only __typeof__
and not statement-expressions:

  # define __TGMATH_UNARY_REAL_ONLY(Val, Fct) \
      (sizeof (Val) == sizeof (double)
       ? ((__typeof__ (Val)) Fct (Val))
       : (sizeof (Val) == sizeof (float)
	  ? (__typeof__ (Val)) Fct##f (Val)
	  ...))

Does that do the trick?  The __typeof__ extension is far less
problematic than statement-expressions -- although even __typeof__ has
serious issues in C++, where the type of an expression can depend on
its context.)

There are certainly things that one can do with statement-expressions
that one cannot do without them.  However, I don't believe this
justifies keeping them indefinitely, given that their many
limitations.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Linus Torvalds]

In article < 20000726213803N.mitchell@codesourcery.com > you write:

In article < 20000726213803N.mitchell@codesourcery.com > you write:
>>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:
>
>    Richard> There are quite a few in the Linux kernel as well.
>
>I'm sympathetic -- people used these things because a) we provided
>them, and b) inline functions were not sufficiently optimized.

Some of the Linux cases could probably be replaced by inline functions.

However, there is one thing an inline function simply _cannot_ do. Not
now, not in the near future. And that's using "typeof". Which is a very
powerful thing indeed, often giving a nicer interface than any amount of
overloading could ever do, with simpler semantics.

So I think you're too harsh on statement expressions.  They are truly a
nice shorthand.  I don't see any badly defined semantics about them in
general: if the only issue with them is strange results from local
labels, then deprecating them sounds like much too harsh a treatment. 

What other problems do the statement expression have? It's certainly no
worse than function nesting, which has much nastier side effects (silly
games with the stack etc). 

And yes, you can get gcc to generate non-sensical code by using local
labels in an expression statement.  But hey, gcc generates non-sensical
code every time you give it nonsensical source - what's the big deal? If
the programmer writes nonsense, then why should the compiler care?

How about a new warning instead:

	strange.c:14: warning: programmer appears seriously deranged

and then let users decide themselves if they really want to use local
labels inside expression statements..

>(Actually, I bet you can write those functions with only __typeof__
>and not statement-expressions:
>
>  # define __TGMATH_UNARY_REAL_ONLY(Val, Fct) \
>      (sizeof (Val) == sizeof (double)
>       ? ((__typeof__ (Val)) Fct (Val))
>       : (sizeof (Val) == sizeof (float)
>	  ? (__typeof__ (Val)) Fct##f (Val)
>	  ...))

Think about cases where you need to use the same argument value multiple
times, so you need to assign it to a local variable in order to get
"function-like" behaviour.  Join that with the requirement to have
__typeof__, and you can neither use an inline function nor a normal
expression. 

So if you want to clean up the language, why not deprecate and
eventually get rid of nested functions instead - now _there_ is an
abomination from Pascal that should never have been created and that
I've never seen anybody actually use yet (although I wouldn't be in the
least surprised to hear of tons of uses: the perversity of programmers
should never be underestimated). 

		Linus

Re: GCC's statement expression extension

[Marc Espie]

In article < 200007270551.WAA02353@penguin.transmeta.com > you write:
>And yes, you can get gcc to generate non-sensical code by using local
>labels in an expression statement.  But hey, gcc generates non-sensical
>code every time you give it nonsensical source - what's the big deal? If
>the programmer writes nonsense, then why should the compiler care?

>How about a new warning instead:

>	strange.c:14: warning: programmer appears seriously deranged

>and then let users decide themselves if they really want to use local
>labels inside expression statements..

In the long run, I believe that this approach loses.

Extensions need to have properly defined semantics, and anything that does
not have fixed down semantics would need to be flagged as a bug, and downright
not compile at all (not possible in the real world, of course).

See, the issue is that those constructs only have an implementation-defined 
meaning that might change from one release to the next because, well,
because it's not documented, and it's hard to keep track of what other changes
to that big fat gcc program are going to do.

The only result is that the notion of a `bug in gcc' gets very fuzzy, and
then we get people not upgrading because the new version is `buggy' (when,
in fact, the implementation details changed, and it does something different
with code which was utterly broken in the first place)

Of course, if resources were infinite, you would have lots of developers
being able to maintain undocumented features of gcc forever.

As things stand, I'd rather we concentrate on nailing down everything that
the standard wants, plus continuing working on lots of architecture, and 
trying to provide awesome optimizations, and getting a faster compiler.

Of course, this is only my opinion...

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes:

    Marc> As things stand, I'd rather we concentrate on nailing down
    Marc> everything that the standard wants, plus continuing working
    Marc> on lots of architecture, and trying to provide awesome
    Marc> optimizations, and getting a faster compiler.

    Marc> Of course, this is only my opinion...

Mine, too, for what it's worth.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Mo McKinlay]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

# Of course, if resources were infinite, you would have lots of developers
# being able to maintain undocumented features of gcc forever.

AFAIK, statement expressions *are* documented, and have been for some
time. (I was reading about them in the texinfo docs the day before this
discussion arose).

- -- 
Mo McKinlay             Chief Software Architect          inter/open Labs
- -------------------------------------------------------------------------
GnuPG Key: pub  1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5gQwpRcGgB3aidfkRAocIAKDfL76HBd+e9u5oLUdwDAB7bUsXTACg5dM3
g5MKgaDxzunEU84PTp/wJ9A=
=1W0d
-----END PGP SIGNATURE-----

RE: GCC's statement expression extension

[Akbar A.]

hey guys,
i know things are getting really stressful but (this relates somewhat to
extensions ;-),

i _really_ like to write my code as portable as possible (you never know
what your code ends up running on :-)

currently i am writing most of my software code in C++.
I am not using any stl or heavy usage of stuff i think is "icky" or
things i would feel to be non-trivial for compiler writers (if i have to
read spec more than 4 times, it has to be non-trivial for "compiler writers"

these are
templated types
and stl.
is there anything else i should be watching out for?
or should i go full steam with C++, and hope compilers will churn out
correct executables.
btw, when bjarne is writing his c++ book, does he have an actual compiler
that does _ALL_ of the things he does?
i saw at one of the c++ commite sites, that bjarne posted a message saying
there is a compiler problem generating some fault, which is causing his
manual to be false. if this is so, how could he write a book about a
"feature" (diffren compiler?)


so many thanks.

peace.
akbar A.

"We want technology for the sake of the story, not for its own sake. When
you look back, say 10 years from now, current technology will seem quaint"
Pixars' Edwin Catmull.


-----Original Message-----
From: gcc-owner@gcc.gnu.org [ mailto:gcc-owner@gcc.gnu.org]On Behalf Of
Mo McKinlay
Sent: Thursday, July 27, 2000 11:30 PM
To: Marc Espie
Cc: torvalds@transmeta.com; gcc@gcc.gnu.org
Subject: Re: GCC's statement expression extension


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

# Of course, if resources were infinite, you would have lots of developers
# being able to maintain undocumented features of gcc forever.

AFAIK, statement expressions *are* documented, and have been for some
time. (I was reading about them in the texinfo docs the day before this
discussion arose).

- --
Mo McKinlay             Chief Software Architect          inter/open Labs
- -------------------------------------------------------------------------
GnuPG Key: pub  1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5gQwpRcGgB3aidfkRAocIAKDfL76HBd+e9u5oLUdwDAB7bUsXTACg5dM3
g5MKgaDxzunEU84PTp/wJ9A=
=1W0d
-----END PGP SIGNATURE-----

Re: GCC's statement expression extension

[Michael Meissner]

On Fri, Jul 28, 2000 at 05:29:30AM +0100, Mo McKinlay wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> # Of course, if resources were infinite, you would have lots of developers
> # being able to maintain undocumented features of gcc forever.
> 
> AFAIK, statement expressions *are* documented, and have been for some
> time. (I was reading about them in the texinfo docs the day before this
> discussion arose).

In fact, they predate my involvement with GCC (summer/fall 1987), and have been
in the documentation forever.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: GCC's statement expression extension

[Linus Torvalds]

On Fri, 28 Jul 2000, Marc Espie wrote:
> 
> >How about a new warning instead:
> 
> >	strange.c:14: warning: programmer appears seriously deranged
> 
> >and then let users decide themselves if they really want to use local
> >labels inside expression statements..
> 
> In the long run, I believe that this approach loses.
> 
> Extensions need to have properly defined semantics, and anything that does
> not have fixed down semantics would need to be flagged as a bug, and downright
> not compile at all (not possible in the real world, of course).

Why?

Think about a basic C (and C++) expression:

	++i + ++i

What does the C standard say about the above?

Right. It has undefined behavior. It can return 42. It can format your
harddisk. And the compiler is still strictly conforming, and yes, you get
the occasional "bug-report" about it, but everybody agrees that it _is_
undefined behaviour, and everybody even agrees on _why_ it is undefined
behaviour, and there is really no problem.

What's so different about extensions?

I don't think anybody can really claim that statement expressions do not
fit the C language "spirit". They are _very_ much in spirit with the
language, and work like anonymous inline functions, and allow doing a lot
of very C-like things. It's definitely not an ugly wart on the language in
that sense (basically, what I'm trying to say is that people could imagine
that statement expressions could have been in the original K&R - they are
not fundamentally against the grain of C the way nested functions are).

And yes, like the expression "++i + ++i", there are undefined things. A
branch to within a statement expression is undefined behaviour, and a nice
and polite compiler will tell the programmer that he seems to be doing
something stupid - the same way it might be really nice if gcc actually
warned about "++i + ++i" so that the occasional bug-reports would fade..

> See, the issue is that those constructs only have an implementation-defined 
> meaning that might change from one release to the next because, well,
> because it's not documented, and it's hard to keep track of what other changes
> to that big fat gcc program are going to do.

Statement expressions are extremely well documented. They've been in gcc
(and documented) at least since I started using gcc in -90. And they do
NOT have "implementation-defined meaning that might change from one
release to the next".

Are you suggesting that the "++" operator should be removed because it can
be used in ways that make the result undefined? The result of bad use of
"++" can, right now, change not only from compiler version to compiler
version, but even with the same compiler depending on what the instruction
schedule ended up being (either due to different optimizations or due to
different code _around_ the offending use).

No, you're obviously not suggesting that. But you ARE using the very same
arguments against statement expressions.  You should probably look at your
arguments again.

		Linus

Re: GCC's statement expression extension

[Marc Espie]

I did not think you would be so daft as to take ++i behavior into this
discussion.  C programmers know about it, unless they are fairly stupid.

What I was arguing about to start with is NOT expression statements per se, 
but some aspects of it which don't work, and that can bring some more such 
nonsense to C.  And this is something C programmers usually do not know 
that much about, since this is not a part of standard C. 

I am not really a fan of the `hey, I know what I'm doing. Stupid compiler,
shut up.' school.  Especially recently.

As compilers get better.

As rules get more complicated.

And there's also the fact that you always, always, find people out there
who play fast and loose with the rules, when the compiler allows it.

And it breaks software.

Sometimes important software.
And in some cases, people get stuck with an older compiler version, as the
broken software is very popular...

I've seen some fairly atrocious code. I'll protect the guilty, and not give
any names.  But having more warnings and errors is a good thing.

As far as extensions go, there is one very important difference: they are 
not part of the standard.  As a compiler implementor, you can draw the line
where you please, including erroring out on nonsense that accidentally happens
to do something. Whereas the C standard needs to be implemented, including
nonsense when it contains nonsense.

There is one very good point about being steady about it: instead of 
harboring further problems linked to not well-defined semantics, it is 
possible to just stop compiling when the result becomes ill-defined.
If an extension of the extension would be useful, then it will be 
discussed, and implemented. 

There will be PRESSURE to do that. 

Pressure which simply does not exist if that aspect of the existing 
implementation does useful, undocumented things.  As people will use it as
is. 

And then the pressure is to keep the status-quo: go on supporting a 
non-feature that was an accidental result of side-effects in an 
implementation aiming at other actual features.  Which may be poorly 
thought-out, and detrimental to further progress.

(It's probably fair to take further discussion off the list at this point, btw).

Re: GCC's statement expression extension

[Linus Torvalds]

On Fri, 28 Jul 2000, Marc Espie wrote:
>
> I did not think you would be so daft as to take ++i behavior into this
> discussion.  C programmers know about it, unless they are fairly stupid.

Ehh.. I think the replies I got to it showed that no, not all C
programmers _do_ know about it.

And go back to the original "bug-report" in question. 

You have to be a REALLY stupid programmer to put a local label inside a
stateemnt expression and expect that to work. I think the "i++" example is
much less obviously a bug: "i++ + i++" _might_ have valid semantics.
Jumping into the middle of an expression obviously does not really have
valid semantics (which is not to say that it might not result in usable
code: I could imagine a diffs-device-like thing that might be fairly
atrocious, but I think gcc maintainers can safely ignore that).

Nobody hos shown any reasonable problem with the current statement
expressions in C. Yes, C++ may have problems. I think C++ has problems
regardless of statement expressions. Yet people have seriously proposed
making statement expressions deprecated in gcc (even in the C side of
things), even though they don't actually have any real problems associated
with them.

So what's the problem? Why do people hate it?

		Linus

Re: GCC's statement expression extension

[Marc Espie]

On Fri, Jul 28, 2000 at 09:27:58PM -0700, Linus Torvalds wrote:
> Nobody hos shown any reasonable problem with the current statement
> expressions in C. Yes, C++ may have problems. I think C++ has problems
> regardless of statement expressions. Yet people have seriously proposed
> making statement expressions deprecated in gcc (even in the C side of
> things), even though they don't actually have any real problems associated
> with them.

The largest problem C++ currently has is C stuff that does not compile in C++
and shows up in C headers. That makes those headers useless for C++.

Statement expressions is part of the problem.

The other part is that statement expressions are gcc extensions. And thus,
not compilable with anything but gcc... as long as they're defined in
gcc-only include fragments, with a suitable fragment elsewhere, they could
be fine.

In practice, within some highly visible software, the alternative won't be
tested often (if it exists).
Hence it won't be robust at all, and will break fairly often.

This results in a tight coupling between a compiler, a language and a system.

Show me how this can be a good thing.

Re: GCC's statement expression extension

[Linus Torvalds]

On Sat, 29 Jul 2000, Marc Espie wrote:
> 
> The largest problem C++ currently has is C stuff that does not compile in C++
> and shows up in C headers. That makes those headers useless for C++.
> 
> Statement expressions is part of the problem.

Ok.

So it's purely a C++ problem. 

> This results in a tight coupling between a compiler, a language and a system.
> 
> Show me how this can be a good thing.

Show me how "the world is set in stone - we have standards, and we will
never exit the boundaries of those standards" will ever be a good thing.

Any system whose only goal in life is to just adhere to standards is
essentially dead. Gcc should explore more than just standards. In fact,
gcc has become a standard of it's own - and one that other compilers are
measured up to. And that is _good_.

Things like inline functions didn't use to be part of the C standard. They
are now (or will be soon). And that's because people dared go outside the
rigid rules. That's how a language evolves, and that is what makes a
language _alive_. Judging extensions as something automatically bad is
something that old fogies do when they are afraid of change.

Now, that does NOT mean that every extension should be considered a good
one. I'm not arguing anything like that. But I do think that your
standpoint that "it is an extension so it must be bad" is narrow-minded
and ultimately stupid. Extensions must be judged on _other_ criteria.

I don't think anybody can seriously claim that statement expressions are
"bad C". A lot of people agree that they are very useful and allow for a
clean syntax for doing things that are somewhere in between a macro and an
inline function, having some of the good sides of both. C++ has templates,
but those simply would not fit into C - they are against the grain of the
language. Unlike statement expressions.

And it's a sad day indeed when a C feature gets judged on how bad it is
for C++. Like it or not, there are people who think that C++ is not the
ultimate language.

But I do understand the problem: if you want to make statement expressions
illegal in C++ (which I have no real opinion of - it's a language I don't
care for), you're screwing up one of the original advantages of C++: the
backwards compatibility with a language I _do_ care about, and one that I
want to see live on rather than die the horrid death of being forever
entomed in the cobwebs of standardization.

Could somebody explain why C++ has so many problems with statement
expressions? Maybe there is some solution to this - something that might
involve a form of statement expression-like behaviour that works on both C
and C++?

I'm not married to the syntax of statement expressions, but I think the
power they have is very useful. Maybe there is a better syntax that is
equally useful and has better semantics for C++? Exactly because the
statement expression is an extension of the language, we do have the
freedom to _improve_ on it - and if it is done well, people who used to
use the current format of statement expressions will be more than happy to
switch to a new and better way of doing the same thing.

Basically, I'm arguing for the _richness_ of the C language. But I don't
want to be arguing against C++ - and I hate the fact that you argue
against C by using C++ arguments. Maybe there is a common ground?

		Linus

Re: GCC's statement expression extension

[Joseph S. Myers]

On Wed, 26 Jul 2000, Mark Mitchell wrote:

> (Actually, I bet you can write those functions with only __typeof__
> and not statement-expressions:
> 
>   # define __TGMATH_UNARY_REAL_ONLY(Val, Fct) \

Actually I've concluded on examining the specification of the <tgmath.h>
macros that glibc's versions are broken and the GCC's current facilities
don't seem to be sufficient to implement them anyway.  More on this later.  
(Quite how the standards committee thought the type-generic macros fitted
in with the spirit of C, I don't know.)

> Does that do the trick?  The __typeof__ extension is far less
> problematic than statement-expressions -- although even __typeof__ has
> serious issues in C++, where the type of an expression can depend on
> its context.)

Perhaps these facilities can be deprecated / removed first in the C++
compiler.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC's statement expression extension

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On Wed, 26 Jul 2000, Mark Mitchell wrote:
| 
| > (Actually, I bet you can write those functions with only __typeof__
| > and not statement-expressions:
| > 
| >   # define __TGMATH_UNARY_REAL_ONLY(Val, Fct) \
| 
| Actually I've concluded on examining the specification of the <tgmath.h>
| macros that glibc's versions are broken and the GCC's current facilities
| don't seem to be sufficient to implement them anyway.  More on this later.  
| (Quite how the standards committee thought the type-generic macros fitted
| in with the spirit of C, I don't know.)

Well, if you come up with a good understanding of how that should be done,
please ping me: I'm curious about how the C committee thought <tgmath.h>
could be implemented. 

| > Does that do the trick?  The __typeof__ extension is far less
| > problematic than statement-expressions -- although even __typeof__ has
| > serious issues in C++, where the type of an expression can depend on
| > its context.)
| 
| Perhaps these facilities can be deprecated / removed first in the C++
| compiler.

That seems to me to be good step.

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

Re: GCC's statement expression extension

[Mark Mitchell]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

    Joseph> Perhaps these facilities can be deprecated / removed first
    Joseph> in the C++ compiler.

I agree -- that's the conclusion I'm leaning towards.  That's where
the problems are most severe, where the language provides other
alternatives, and where the user community is least invested in these
language features.  We do need buy-in from the glibc people, and
probably the Linux kernel people, if we're going to do that, since
those headers wind up in lots of C++ programs.

This isn't really my call (which is a good thing).  I'm just finding
out how many people agree.  Even before touching C++, I'd want Jason
Merrill's agreement.  Before doing anything to C, we'd certainly need
the SC to sign off -- and I don't plan on raising the issue, at least
in C, based on these discussions.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC's statement expression extension

[Michael Meissner]

On Thu, Jul 27, 2000 at 09:42:31AM -0700, Mark Mitchell wrote:
> >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
> 
>     Joseph> Perhaps these facilities can be deprecated / removed first
>     Joseph> in the C++ compiler.
> 
> I agree -- that's the conclusion I'm leaning towards.  That's where
> the problems are most severe, where the language provides other
> alternatives, and where the user community is least invested in these
> language features.  We do need buy-in from the glibc people, and
> probably the Linux kernel people, if we're going to do that, since
> those headers wind up in lots of C++ programs.
> 
> This isn't really my call (which is a good thing).  I'm just finding
> out how many people agree.  Even before touching C++, I'd want Jason
> Merrill's agreement.  Before doing anything to C, we'd certainly need
> the SC to sign off -- and I don't plan on raising the issue, at least
> in C, based on these discussions.

Speaking for the users, I would argue that removal of statement expressions,
even in C++ only, is a supremely bad idea.  I would hesitate to guess how many
people use these features right now, but I would be willing to bet it more than
the people reading this mailing list.  Misdesigned or not, it is an incredibly
useful feature, and people use it.  Even if there are better ways of doing it,
won't change all of the extant code out in the world.  We are still supporting
(unhappily perhaps) non-ISO C in the compiler, 10 1/2 years after the first
ANSI C standard was ratified.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: GCC's statement expression extension

[Alexandre Oliva]

On Jul 27, 2000, "Joseph S. Myers" <jsm28@cam.ac.uk> wrote:

> Perhaps these facilities can be deprecated / removed first in the C++
> compiler.

But even C++ code #includes glibc headers.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC's statement expression extension

[Per Bothner]

Mark Mitchell <mark@codesourcery.com> writes:

> There are certainly things that one can do with statement-expressions
> that one cannot do without them.  However, I don't believe this
> justifies keeping them indefinitely, given that their many
> limitations.

One use I've found for statement-expressions: Suppose you want to
implement an expression-oriented language, i.e. a language where there
is no real distinction between expressions and statements, which
category includes all functional languages as well as other languages
such as Algol68.  A classic strategy is to compile into C.  It is
very easy to compile incoming abstract syntax tree structure into C -
if you can use statements expressions.  It becomes a trivial mapping.
If you can't use statement expressions, it becomes much messier.

If your language has objects or non-trivial data-types, it is
nice to be able to use C++ rather than C as your target language.

We should keep statement expressions in both C and C++.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: GCC's statement expression extension

[Jamie Lokier]

Per Bothner wrote:
> One use I've found for statement-expressions...

Another use I've found is when you want a local label in a big macro.
This is because the __label__ extension works only in statement
expressions.  So I've seen:

  #define foo(a1,a2) \
    do ({ __label__ l1, l2, l3; /* code... */; }) while(0)

Why doesn't __label__ work inside an ordinary statement block?

-- Jamie