[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #5 from Martin Sebor --- I'm not working on this anymore.
[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00659.html
[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Agreed. Thanks for the test case. I'm working on a patch.
[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718
--- Comment #2 from joseph at codesourcery dot com ---
Note that there are also such cases as
static int x;
struct s { int a[sizeof(x)]; } inline *f (void) { return 0; }
where the reference to x is part of the return type (still syntactically
part of the inline definition, so I think still included in what should be
diagnosed). So it will be necessary to track references to identifiers
with internal linkage in such contexts which might or might not turn out
to be part of an inline definition - not just (for example) in what might
or might not be a function prototype scope for an inline function.
[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88718
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-08
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5,
||4.9.4, 5.4.0, 6.4.0, 7.3.0,
||8.2.0, 9.0
--- Comment #1 from Martin Sebor ---
Confirmed. The first test case was never diagnosed. Suppressing the error for
the second test case would be easy but I agree that we want it in both cases so
that the following is diagnosed as well as I think it should be:
static int x;
inline int f (int (*p)[sizeof x])
{
return sizeof *p;
}
