[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #9 from Jan Hubicka --- Author: hubicka Date: Tue Jan 30 13:17:40 2018 New Revision: 257183 URL: https://gcc.gnu.org/viewcvs?rev=257183=gcc=rev Log: PR lto/83954 * lto-symtab.c (warn_type_compatibility_p): Silence false positive for type match warning on arrays of pointers. * gcc.dg/lto/pr83954.h: New testcase. * gcc.dg/lto/pr83954_0.c: New testcase. * gcc.dg/lto/pr83954_1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr83954.h trunk/gcc/testsuite/gcc.dg/lto/pr83954_0.c trunk/gcc/testsuite/gcc.dg/lto/pr83954_1.c Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-symtab.c trunk/gcc/testsuite/ChangeLog
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #8 from Dan Bonachea --- (In reply to Jan Hubicka from comment #7) > This should silence the warning. > Index: lto-symtab.c > === > --- lto-symtab.c(revision 257048) > +++ lto-symtab.c(working copy) > @@ -285,7 +285,9 @@ warn_type_compatibility_p (tree prevaili >alias_set_type set2 = get_alias_set (prevailing_type); > >if (set1 && set2 && set1 != set2 > - && (!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type) > + && (((!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type)) > + && (TREE_CODE (type) != ARRAY_TYPE > + || TREE_CODE (prevailing_type) != ARRAY_TYPE)) > || (set1 != TYPE_ALIAS_SET (ptr_type_node) > && set2 != TYPE_ALIAS_SET (ptr_type_node > lev |= 5; Thanks Jan! I've confirmed this patch is sufficient to silence the warning when applied to gcc 7.3.0, for both this reduced test case and the original program. Can we get this merged into the gcc development branch(es)?
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #7 from Jan Hubicka --- It is not going to produce wrong code. GCC knows that pointers to incomplete types alias with pointers to complete types and it also handles array by alias sets of their elements. What is wrong here is that the warning conditional rules out the false positive for pointers but not for arrays of pointers. This should silence the warning. Index: lto-symtab.c === --- lto-symtab.c(revision 257048) +++ lto-symtab.c(working copy) @@ -285,7 +285,9 @@ warn_type_compatibility_p (tree prevaili alias_set_type set2 = get_alias_set (prevailing_type); if (set1 && set2 && set1 != set2 - && (!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type) + && (((!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type)) + && (TREE_CODE (type) != ARRAY_TYPE + || TREE_CODE (prevailing_type) != ARRAY_TYPE)) || (set1 != TYPE_ALIAS_SET (ptr_type_node) && set2 != TYPE_ALIAS_SET (ptr_type_node lev |= 5;
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #6 from Martin Liška --- (In reply to Dan Bonachea from comment #5) > (In reply to Martin Liška from comment #4) > > > Assuming it's the latter, can anyone suggest any non-intrusive > > > workarounds? > > > (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing) > > > > Yes, the warning should not produce bogus warnings. Proper solution is not > > to break strict aliasing. Note that it can help optimization to make more > > aggressive optimizations. > > I'm confused - are you saying the test program actually breaks C's strict > aliasing rules? My understanding was this is a correct (spec-compliant) C > program that is being mishandled by gcc. My question was whether this > mishandling could generally result in actual incorrect optimization of > programs encountering this defect, and it sounds like you are saying it > might? Yes, it's a valid C program. And yes, it's mishandled by GCC. I believe considering these two types as having different alias sets can result in an incorrect optimization.
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #5 from Dan Bonachea --- (In reply to Martin Liška from comment #4) > > Assuming it's the latter, can anyone suggest any non-intrusive workarounds? > > (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing) > > Yes, the warning should not produce bogus warnings. Proper solution is not > to break strict aliasing. Note that it can help optimization to make more > aggressive optimizations. I'm confused - are you saying the test program actually breaks C's strict aliasing rules? My understanding was this is a correct (spec-compliant) C program that is being mishandled by gcc. My question was whether this mishandling could generally result in actual incorrect optimization of programs encountering this defect, and it sounds like you are saying it might?
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #4 from Martin Liška --- > Assuming it's the latter, can anyone suggest any non-intrusive workarounds? > (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing) Yes, the warning should not produce bogus warnings. Proper solution is not to break strict aliasing. Note that it can help optimization to make more aggressive optimizations.
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #3 from Martin Liška ---
Slightly reduced test-case:
$ cat lto.h
struct foo;
extern struct foo *FOO_PTR_ARR[1];
$ cat lto1.c
#include "lto.h"
int main() {
// just to prevent symbol removal
FOO_PTR_ARR[1] = 0;
return 0;
}
$ cat lto2.c
#include "lto.h"
struct foo {
int x;
};
struct foo *FOO_PTR_ARR[1] = { 0 };
We end up comparison following 2 types in ODR mismatch:
(gdb) p debug_tree(type)
pointer_to_this chain >
unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 1 structural-equality>
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 1 structural-equality
domain unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >
pointer_to_this >
$3 = void
(gdb) p debug_tree(prevailing_type)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76a0ddc8 fields context
pointer_to_this chain >
unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 2 structural-equality>
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 2 structural-equality
domain unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >>
Honza can you please take a look?
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #2 from Dan Bonachea --- Thanks Mr. Liška! If possible it would be useful for our project to know whether this defect is solely a spurious warning, or whether it could affect analysis in a way that might result in incorrect code generation on affected compiler versions (as suggested by the warning text). Assuming it's the latter, can anyone suggest any non-intrusive workarounds? (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing)
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |8.0 Summary|LTO: Bogus |[6/7/8 Regression] LTO: |-Wlto-type-mismatch warning |Bogus -Wlto-type-mismatch |for array of pointer to |warning for array of |incomplete type |pointer to incomplete type Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r231239. Let me take a look.
