[Bug c++/36408] [4.3/4.4 regression] ICE with statement expression in template

[dodji at gcc dot gnu dot org]

------- Comment #9 from dodji at gcc dot gnu dot org  2008-08-01 13:32 -------
Created an attachment (id=15991)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15991&action=view)
updated patch

>  - the error message we give in this case is pretty poor. Here we have an
>empty initializer, but the error message we get back is "void value not ignored
>as it ought to be", which really doesn't tell us much of anything about the
>problem.

I agree. Though I think addressing that should be best done in another bug
that we can open straight away when we close this one, if you agree.

>The real issue here is that the statement expression has no return
>value, so we should say as such. This same problem can occur with non-empty
>statement expressions whose last statement does not produce a value, right?
>We
>should test this case, too.

I think the problem (g++ not issuing any warning)
is due to the tsubsted initializer yielding NULL.
An expression made of a statement list which last statement
does not return any value whould be tsubsted to a statement list
of type VOID_TYPE, I believe.

For instance the current g++ 4.3.0 issues the warning for the
following code snippet:
----
void foo ();
void bar ();

void
func ()
{
  int y = 0;
  int i = ({ foo (); if (y) bar (); });
}
----
/home/dodji/devel/src/test.cc: In function 'void func()':
/home/dodji/devel/src/test.cc:8: error: void value not ignored as it ought to
be

>
>  - since the statement-expression is obviously empty, can we produce this
>error message at template definition time, rather than waiting until
>instantiation time? (If the answer isn't a quick "yes", don't worry about it;
>I'll eventually be going through the initialization bits to check more of them
>at template definition time anyway.)

Yes, that would be handy. Though here again, I think we should be opening
another bug to track that.

>
>  - is_pack_expansion_node_p is a pretty general name for a function that is
>specific to initializer lists (in general, a TREE_LIST with a pack expansion in
>its TREE_VALUE isn't necessarily an "expansion node"). I suggest calling this
>"initializer_is_pack_expansion_p".
>

Right. This updated patch addresses that.

>  - Please put some braces inside the if (init && !t) block. Omitting the
>braces for "then" and "else" is okay for small one-liner bodies, but shouldn't
>be done when there are if-elses nested inside.

Fixed in this udpated patch.

>
>  - parse/empty-statement.C is a strange place to put this check, which deals
>with template instantiation. Perhaps call it template/empty-init-statement.C?

Yup. Fixed.
>
>  - In the top of the testcase, "PR c++/P36408" should be "PR c++/36408"

Fixed as well.

Thank you for your comments.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #15989|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36408