[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #6 from Eric Gallager --- (In reply to Sam James from comment #5) > FWIW, after doing more of this work, I've decided I don't really care that > much about this one. > > I still think FP mismatches are often worse, but there's enough junk pointer > type mismatches that I'm not sure we should provide this (it's not like one > case is OK and the other is way less scary or something). I mean, I might still use just one but not the other in a case where I've got a huge project, and need to narrow down the warnings so that I can just focus on a manageable subset, rather than being overwhelmed by having to try to look at all of them at once.
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #5 from Sam James --- FWIW, after doing more of this work, I've decided I don't really care that much about this one. I still think FP mismatches are often worse, but there's enough junk pointer type mismatches that I'm not sure we should provide this (it's not like one case is OK and the other is way less scary or something).
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #4 from Sam James --- (In reply to Eric Gallager from comment #3) > I thought that there was already a separate bug for this, but it turns out > that I was thinking of bug 87379, which is for something different... Good catch. I think that'd actually address some (not all, ofc) of the concerns I have about these.
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- I thought that there was already a separate bug for this, but it turns out that I was thinking of bug 87379, which is for something different...
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #2 from Sam James ---
Okay, fair point, I gave examples but not *motivating* examples.
I have some non-harmless examples:
1.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e0e5c4d289004fa779c86da9319cf2bb18548b1
(a nasty one)
2.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=71ae0b143a55fd45d4fd56cff13438cdbc602089
(sort example)
3.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=996809c0e52057ec8e5f32dd1d9f8f9bea559c18
(interesting example wrt attributes)
4.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=573dae0ef553e180e7f5c85a333adce34237f59b
(completely wrong)
I can dig some more for general examples I've seen, but I tried to pick out
those above w/ different characteristics.
I've seen a lot of e.g. qsort mismatched signatures but struggled for a bit
with finding ABI concerns (SA I feel is something which is hard to manifest as
a problem here because you need that "second order" manipulation which isn't
that common.) But David Seifert (cc'd) came up with this wrt ABI:
```
#include
void fun(long long x, long long y) {
printf("x = %lld, y = %lld\n", x, y);
}
void (*fun_ptr)(int, int) = fun;
int main() {
int x = 1;
int y = 2;
fun_ptr(x, y);
}
```
... which gives different results on x86_64-unknown-linux-gnu vs
x86_64-unknown-linux-gnu -m32, but the only warning you get is
-Wincompatible-pointer-types with GCC, rather than anything about the mismatch.
I'll spend some more time reviewing -Wincompatible-pointer-types results when
used on a global build but the last time I tried, it was unreasonably noisy
given the other work we have ahead of us.
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #1 from Florian Weimer --- Presumably the idea is to enable -Werror=incompatible-function-pointer-types (in spirit) because it is more severe than -Wincompatible-pointer-types? I'm not sure this is actually true. Your first example will not have ABI problems or strict-aliasing issues. It seems rather harmless. Your second example (even with “int x;” instead, which we do not warn about by default) is likely to introduce strict-aliasing issues (obviously not in this minimal fragment, but still). If we want to error on incompatible-function-pointer-types by default, I think we need to make some effort to refine what such incompatible function pointers should be.
