https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Joseph S. Myers <jsm28 at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2020-11-17 Target Milestone|--- |8.5 Status|UNCONFIRMED |NEW Summary|Segmentation Fault on |[8/9/10/11 Regression] |improper redeclaration of |Segmentation Fault on |function |improper redeclaration of | |function Ever confirmed|0 |1 --- Comment #1 from Joseph S. Myers <jsm28 at gcc dot gnu.org> --- Looks like a regression in GCC 7 relative to GCC 6. Whether this code is valid or invalid GNU C is a tricky question, but I'm inclined to say that when the incomplete enum type extension is used, we should *not* count such enums as compatible with unsigned int since we don't know what members the enum will have once completed. So, for example, I think we ought to reject extern enum foo *x; unsigned int *x; and certainly ought to reject extern enum foo *x; unsigned int *x; enum foo { A = -1 }; where the enum ends up compatible with int rather than unsigned int. (But a patch involving rejecting such code might not be such a good idea for backporting, given the risk of breaking user programs that build OK with the release branch compilers.) (A C11 defect fix incorporated in C17 means a qualifier on a function return type is ignored, so whether the code is valid is not affected by the "const" in the original test case.)