[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type

[dobonachea at lbl dot gov]

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

[dobonachea at lbl dot gov]

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

[dobonachea at lbl dot gov]

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] New: LTO: Bogus -Wlto-type-mismatch warning for pointer to incomplete type

[dobonachea at lbl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954

Bug ID: 83954
   Summary: LTO: Bogus -Wlto-type-mismatch warning for pointer to
incomplete type
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Keywords: diagnostic, lto
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dobonachea at lbl dot gov
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 43198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43198&action=edit
Source code and preprocessed output

I'm seeing bogus -Wlto-type-mismatch warnings in C for an array of pointers to
incomplete type with gcc 7.2.0 -flto.

Source files (also attached):

==> lto.h <==
struct foo;
extern struct foo *FOO_PTR;
extern struct foo *FOO_PTR_ARR[1];
extern int*INT_PTR_ARR[1];

==> lto1.c <==
#include "lto.h"

int main() { 
  // just to prevent symbol removal
  FOO_PTR = 0;
  FOO_PTR_ARR[1] = 0;
  return 0;
}

==> lto2.c <==
#include "lto.h"

struct foo {
 int x;
};
struct foo *FOO_PTR = 0;
struct foo *FOO_PTR_ARR[1] = { 0 };
int*INT_PTR_ARR[1] = { 0 };

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/pkg/gcc/7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr/local/pkg/gcc/7.2.0
Thread model: posix
gcc version 7.2.0 (GCC) 

$ uname -a
Linux  3.10.0-693.1.1.el7.x86_64 #1 SMP Tue Aug 15 08:36:44 CDT 2017
x86_64 x86_64 x86_64 GNU/Linux

$  gcc -pedantic -flto -fuse-linker-plugin lto1.c lto2.c
lto.h:3:20: warning: type of 'FOO_PTR_ARR' does not match original declaration
[-Wlto-type-mismatch]
 extern struct foo *FOO_PTR_ARR[1];
^
lto2.c:7:13: note: 'FOO_PTR_ARR' was previously declared here
 struct foo *FOO_PTR_ARR[1] = { 0 };
 ^
lto2.c:7:13: note: code may be misoptimized unless -fno-strict-aliasing is used

Note the warning only occurs for the array-of-pointer-to-incomplete-type, and
not for the analogous pointer-to-incomplete-type or array-of-pointer-to-int.