| Message ID | 2556813.xd8ElFlcmY@polaris |
|---|---|
| State | New |
| Headers | show |
On Sun, Nov 13, 2016 at 11:31 PM, Eric Botcazou <ebotcazou@adacore.com> wrote: > It's the note issued by the -Wlto-type-mismatch warning: > > q.ads:7:13: warning: type of 'q__proc' does not match original declaration [- > Wlto-type-mismatch] > procedure Proc (A : Arr); > ^ > q.adb:7:3: note: 'q__proc' was previously declared here > procedure Proc (A : Arr) is begin null; end; > ^ > q.adb:7:3: note: code may be misoptimized unless -fno-strict-aliasing is used > > and it's a bit surprising that -fno-strict-aliasing cannot silence it. The issue is that we can have different -fstrict-aliasing status on different functions (from individual TUs). I'm not sure if a -fno-strict-aliasing at link/WPA time will put them to that state. > Tested on x86_64-suse-linux, OK for the mainline and 6 branch? Can you verify that a TU compiled with -fstrict-aliasing will link as if -fno-strict-aliasing if -fno-strict-aliasing is specified at link time? We're also still in a very weird state of fixing TU compile flags via the optimize/target attribute to link time while at the same time still going through lto-opts.c and lto-wrapper "merging" of those options. That said, -Wno-lto-type-mismatch can be used to disable the warning as well. Thanks, Richard. > > 2016-11-13 Eric Botcazou <ebotcazou@adacore.com> > > lto/ > * lto-symtab.c (lto_symtab_merge_decls_2): Only issue note on strict > aliasing if -fstrict-aliasing is enabled. > > -- > Eric Botcazou
> Can you verify that a TU compiled with -fstrict-aliasing will link as > if -fno-strict-aliasing if -fno-strict-aliasing is specified at link time? Yes, it does: eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -c t.c -O2 -flto eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -o t t.o -O2 -save- temps -fverbose-asm && grep strict-aliasing t.ltrans0.s # -fstore-merging -fstrict-aliasing -fstrict-overflow eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -o t t.o -O2 -fno- strict-aliasing -save-temps -fverbose-asm && grep strict-aliasing t.ltrans0.s # -fno-strict-aliasing -fverbose-asm -fltrans t.ltrans0.o > That said, -Wno-lto-type-mismatch can be used to disable the warning as > well. Right, but the wording ("code may be misoptimized") is a bit scaring so I'd rather avoid it when possible. -- Eric Botcazou
On Tue, Nov 15, 2016 at 10:47 AM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> Can you verify that a TU compiled with -fstrict-aliasing will link as >> if -fno-strict-aliasing if -fno-strict-aliasing is specified at link time? > > Yes, it does: > > eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -c t.c -O2 -flto > eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -o t t.o -O2 -save- > temps -fverbose-asm && grep strict-aliasing t.ltrans0.s > # -fstore-merging -fstrict-aliasing -fstrict-overflow > eric@polaris:~/build/gcc/native> ~/install/gcc/bin/gcc -o t t.o -O2 -fno- > strict-aliasing -save-temps -fverbose-asm && grep strict-aliasing t.ltrans0.s > # -fno-strict-aliasing -fverbose-asm -fltrans t.ltrans0.o Yes, I know -fno-strict-aliasing is globally set, but will all -fstrict-aliasing optimization attributes on functions be "overwritten"? That is, are you sure that when optimizing a function originally compiled with -fstrict-aliasing that -fno-strict-aliasing is in effect? >> That said, -Wno-lto-type-mismatch can be used to disable the warning as >> well. > > Right, but the wording ("code may be misoptimized") is a bit scaring so I'd > rather avoid it when possible. > > -- > Eric Botcazou
> Yes, I know -fno-strict-aliasing is globally set, but will all > -fstrict-aliasing optimization attributes on functions be "overwritten"? > That is, are you sure that when optimizing a function originally compiled > with -fstrict-aliasing that -fno-strict-aliasing is in effect? Do you mean with the "optimize" attribute or somesuch? If so, I suppose not, if the attributes are properly saved and restored; otherwise, I don't really understand the question because I don't think that LTO saves the entire option state on a per-function basis. -- Eric Botcazou
On Tue, Nov 15, 2016 at 1:19 PM, Eric Botcazou <ebotcazou@adacore.com> wrote: >> Yes, I know -fno-strict-aliasing is globally set, but will all >> -fstrict-aliasing optimization attributes on functions be "overwritten"? >> That is, are you sure that when optimizing a function originally compiled >> with -fstrict-aliasing that -fno-strict-aliasing is in effect? > > Do you mean with the "optimize" attribute or somesuch? If so, I suppose not, > if the attributes are properly saved and restored; otherwise, I don't really > understand the question because I don't think that LTO saves the entire option > state on a per-function basis. Yes, it does since GCC 5 (or was it 6?). Richard. > -- > Eric Botcazou
commit 934002ff6d710418af4b7f993f6216e9406d82c2
Author: Eric Botcazou <ebotcazou@adacore.com>
Date: Sun Nov 13 11:36:32 2016 +0100
Fix for PB12-008 (disable LTO note on misoptimization with strict aliasing).
diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c
index 94b919b..c8848a5 100644
--- a/gcc/lto/lto-symtab.c
+++ b/gcc/lto/lto-symtab.c
@@ -698,7 +698,7 @@ lto_symtab_merge_decls_2 (symtab_node *first, bool diagnosed_p)
if (diagnosed_p)
inform (DECL_SOURCE_LOCATION (prevailing->decl),
"%qD was previously declared here", prevailing->decl);
- if (tbaa_p)
+ if (tbaa_p && flag_strict_aliasing)
inform (DECL_SOURCE_LOCATION (prevailing->decl),
"code may be misoptimized unless "
"-fno-strict-aliasing is used");
It's the note issued by the -Wlto-type-mismatch warning: q.ads:7:13: warning: type of 'q__proc' does not match original declaration [- Wlto-type-mismatch] procedure Proc (A : Arr); ^ q.adb:7:3: note: 'q__proc' was previously declared here procedure Proc (A : Arr) is begin null; end; ^ q.adb:7:3: note: code may be misoptimized unless -fno-strict-aliasing is used and it's a bit surprising that -fno-strict-aliasing cannot silence it. Tested on x86_64-suse-linux, OK for the mainline and 6 branch? 2016-11-13 Eric Botcazou <ebotcazou@adacore.com> lto/ * lto-symtab.c (lto_symtab_merge_decls_2): Only issue note on strict aliasing if -fstrict-aliasing is enabled. -- Eric Botcazou