Summary: | [3.3/3.4/4.0 Regression] ICE with nested functions in parameter declaration | ||
---|---|---|---|
Product: | gcc | Reporter: | Joseph S. Myers <jsm28> |
Component: | c | Assignee: | Richard Henderson <rth> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gcc-bugs, gdr |
Priority: | P2 | Keywords: | ice-on-invalid-code |
Version: | 4.0.0 | ||
Target Milestone: | 3.4.3 | ||
Host: | Target: | ||
Build: | Known to work: | 2.95.3 | |
Known to fail: | 3.0.4 3.3.3 3.2.3 3.4.0 4.0.0 | Last reconfirmed: | 2004-10-07 23:09:18 |
Attachments: | patch to allow nested functions, for mainline |
Description
Joseph S. Myers
2004-08-14 00:12:44 UTC
Confirned, considered a regression because of the ICE. ICEing since at least 2000-12-31. Postponed all ice-on-invalid bugs to GCC 3.4.3. Looks to me as if the nested function has nothing to do with it. Rather, it's the statement expression. Just "int b[({ 1; })]" is enough to crash. Subject: Re: [3.3/3.4/4.0 Regression] ICE with nested functions
in parameter declaration
On Thu, 14 Oct 2004, rth at gcc dot gnu dot org wrote:
> Looks to me as if the nested function has nothing to do with it. Rather,
> it's the statement expression. Just "int b[({ 1; })]" is enough to crash.
I think the plain statement expression case is actually valid code (the
statement expression should be evaluated on function entry just like the
other array size expressions in the parameters).
You do? Hm, in which case I may need to persue a different solution than the one I'm currently testing. Also, if true, I don't see why a nested function wouldn't be acceptable there: int b[({ int h() { return 1; } h(); })] Subject: Re: [3.3/3.4/4.0 Regression] ICE with nested functions
in parameter declaration
On Thu, 14 Oct 2004, rth at gcc dot gnu dot org wrote:
> You do? Hm, in which case I may need to persue a different solution than
> the one I'm currently testing. Also, if true, I don't see why a nested
> function wouldn't be acceptable there:
>
> int b[({ int h() { return 1; } h(); })]
Perhaps you can make nested functions work there, but they seem very
dubious when not actually within a function body. Whereas since array
size expressions can include calls to other functions, or recursively to
the same function, or indeed jump out of the evaluation of array size
expressions with longjmp, statement expressions seem more reasonable there
(though if they attempt to jump into the body of the function that might
be problematic).
Subject: Re: [3.3/3.4/4.0 Regression] ICE with nested functions
in parameter declaration
On Thu, 14 Oct 2004, jsm at polyomino dot org dot uk wrote:
> expressions with longjmp, statement expressions seem more reasonable there
> (though if they attempt to jump into the body of the function that might
> be problematic).
Actually, given that we disallow statement expressions in prototypes
outside a function (even where they only mean [*] and have no further
significance) perhaps it does make sense to be stricter about saying that
old-style parameter declarations don't count as inside a function for this
purpose, and disallowing statement expressions there in general. But if
we do that then we should consider if declarations of parameters to nested
functions likewise are restricted and can't include statement expressions.
Created attachment 7352 [details]
patch to allow nested functions, for mainline
I can see arguments either way. Allowing statement expressions to me means
allowing effectively arbitrary code. If we can handle *any* statement expr,
then we can handle nested functions there as well.
The only thing that would bother me about disallowing statement expressions
here, when we do allow arbitrary function calls, is that glibc headers tend
to have statement expressions hanging about in various macros that implement
various well-known library functions.
Anyway, the attached patch works for mainline. If we are to allow statement
expressions (or nested functions), I don't know if I can make it work for 3.4.
There's a related pr that we closed WONTFIX that is a prerequisite for this.
What do you think?
Subject: Re: [3.3/3.4/4.0 Regression] ICE with nested functions
in parameter declaration
On Thu, 14 Oct 2004, rth at gcc dot gnu dot org wrote:
> Created an attachment (id=7352)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7352&action=view)
> patch to allow nested functions, for mainline
Seems reasonable enough to me as a fix for now if this now works sensibly.
We may need to revisit some of this later if there are other problems (and
it does still seem a little odd in language definition terms that these
things are allowed in old-style function parameter declarations but not in
prototype declarations in the definition, although it makes sense in
implementation terms of not knowing whether the prototype is in a
definition until it is all parsed).
Hum. That is a good point about this patch only mattering for K&R function definitions. In which case I don't really care at all, and so we should probably just go with the first choice to disallow stmt exprs here. That also lets me fix 3.4 with an absolute minimum of effort, which is happy. Subject: Bug 17023 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: rth@gcc.gnu.org 2004-10-14 23:12:53 Modified files: gcc : ChangeLog c-parse.in Log message: PR c/17023 * c-parse.in (compstmt_primary_start): Check last_tree non-null, not current_function_decl non-null. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.661&r2=2.2326.2.662 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parse.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.194.2.5&r2=1.194.2.6 Subject: Bug 17023 CVSROOT: /cvs/gcc Module name: gcc Changes by: rth@gcc.gnu.org 2004-10-14 23:20:58 Modified files: gcc : ChangeLog c-decl.c c-parse.in Added files: gcc/testsuite/gcc.dg: 20041014-1.c Log message: PR c/17023 * c-decl.c (store_parm_decls_oldstyle): Care for parameter type as error_mark_node. * c-parse.in (compstmt_primary_start): Check cur_stmt_list non-null instaed of current_function_decl non-null. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5889&r2=2.5890 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.601&r2=1.602 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parse.in.diff?cvsroot=gcc&r1=1.247&r2=1.248 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20041014-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 Fixed. |