This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
return warning "regressions" on the tree-ssa branch
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: dnovillo at redhat dot com
- Cc: gcc at gcc dot gnu dot org, rth at redhat dot com
- Date: 07 Mar 2003 13:24:30 +0100
- Subject: return warning "regressions" on the tree-ssa branch
Hi,
The regressions we have on the tree-ssa branch since the last merge from
the mainline are the same line number issues that Richard Henderson
plummed the failures on the mainline with this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00018.html
The warnings are reported allright, but they just show up on line
numbers where we do not expect them.
For three different branches (3.3, mainline and tree-ssa) we report the
warnings on different line numbers. The patch by Richard only hides the
problem, but on the tree-ssa branch somehow one of them cannot be fixed
like that (snippet from noreturn-1.c):
1 extern void foo5(void) __attribute__ ((__noreturn__));
2 void
3 foo5(void)
4 {
5 return; /* { dg-warning "`noreturn' has a `return' statement" "detect invalid return" } */
6 } /* { dg-warning "`noreturn' function does return" "detect return from noreturn" } */
GCC reports the dg-warning not on line 6 but instead on line 5.
The 3.3 behavior is the "correct" behavior: All return warnings are on
the line with the closing curly bracket. It always worked like that
before, and the current situation is just all confusing and
inconsistent.
For example, for this snippet:
1 extern void foo1(void) __attribute__ ((__noreturn__));
2 void
3 foo1(void)
4 {
5 } /* { dg-warning "`noreturn' function does return" "detect falling off end of noreturn" } */
we report correctly report the warning on line 5, but for
1 extern void foo2(void) __attribute__ ((__noreturn__));
2 void
3 foo2(void)
4 {
5 exit(0);
6 } /* { dg-bogus "warning:" "this function should not get any warnings" } */
we *still* report the warning on line 5. That is inconsistent (and
therefor wrong IMHO).
The regressions were reported two weeks ago by the apple autocrasher, so
we now roughly which patches are responsible. I guess we should try to
pinpoint which patch exactly is responsible and *really* fix this
problem. Ideas?
Greetz
Steven