[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Segher Boessenkool changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #44 from Segher Boessenkool --- This was fixed on 9 and later. Closing.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Jakub Jelinek changed: What|Removed |Added Target Milestone|10.4|10.5 --- Comment #43 from Jakub Jelinek --- GCC 10.4 is being released, retargeting bugs to GCC 10.5.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added Target Milestone|10.3|10.4 --- Comment #42 from Richard Biener --- GCC 10.3 is being released, retargeting bugs to GCC 10.4.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added Target Milestone|10.2|10.3 --- Comment #41 from Richard Biener --- GCC 10.2 is released, adjusting target milestone.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Jakub Jelinek changed: What|Removed |Added Target Milestone|10.0|10.2 --- Comment #40 from Jakub Jelinek --- GCC 10.1 has been released.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #39 from luoxhu at gcc dot gnu.org --- Author: luoxhu Date: Mon Aug 26 08:53:27 2019 New Revision: 274921 URL: https://gcc.gnu.org/viewcvs?rev=274921=gcc=rev Log: Backport r274411 from trunk to gcc-9-branch Backport r274411 of "Enable math functions linking with static library for LTO" from mainline to gcc-9-branch. Bootstrapped/Regression-tested on Linux POWER8 LE. gcc/ChangeLog 2019-08-26 Xiong Hu Luo Backport r274411 from trunk to gcc-9-branch. 2019-08-14 Xiong Hu Luo PR lto/91287 * builtins.c (builtin_with_linkage_p): New function. * builtins.h (builtin_with_linkage_p): New function. * symtab.c (write_symbol): Remove redundant assert. * lto-streamer-out.c (symtab_node::output_to_lto_symbol_table_p): Remove FIXME and use builtin_with_linkage_p. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/builtins.c branches/gcc-9-branch/gcc/builtins.h branches/gcc-9-branch/gcc/lto-streamer-out.c branches/gcc-9-branch/gcc/symtab.c
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #38 from luoxhu at gcc dot gnu.org --- Author: luoxhu Date: Wed Aug 14 02:18:33 2019 New Revision: 274411 URL: https://gcc.gnu.org/viewcvs?rev=274411=gcc=rev Log: Enable math functions linking with static library for LTO In LTO mode, if static library and dynamic library contains same function and both libraries are passed as arguments, linker will link the function in dynamic library no matter the sequence. This patch will output LTO symbol node as UNDEF if BUILT_IN_NORMAL function FNDECL is a math function, then the function in static library will be linked first if its sequence is ahead of the dynamic library. gcc/ChangeLog 2019-08-14 Xiong Hu Luo PR lto/91287 * builtins.c (builtin_with_linkage_p): New function. * builtins.h (builtin_with_linkage_p): New function. * symtab.c (write_symbol): Remove redundant assert. * lto-streamer-out.c (symtab_node::output_to_lto_symbol_table_p): Remove FIXME and use builtin_with_linkage_p. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.h trunk/gcc/lto-streamer-out.c trunk/gcc/symtab.c
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #37 from rguenther at suse dot de ---
On August 8, 2019 3:35:26 AM GMT+02:00, "luoxhu at cn dot ibm.com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
>--- Comment #34 from Xiong Hu XS Luo ---
>(In reply to rguent...@suse.de from comment #32)
>> On Mon, 5 Aug 2019, luoxhu at cn dot ibm.com wrote:
>>
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>> >
>> > --- Comment #31 from Xiong Hu XS Luo ---
>> > (In reply to rguent...@suse.de from comment #30)
>> > > On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
>> > >
>> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>> > > >
>> > > > --- Comment #28 from Xiong Hu XS Luo
>---
>> > > > (In reply to Richard Biener from comment #24)
>> > > > > Btw, this is controlled by
>symtab_node::output_to_lto_symbol_table_p which
>> > > > > has
>> > > > >
>> > > > > /* FIXME: Builtins corresponding to real functions probably
>should have
>> > > > > symbol table entries. */
>> > > > > if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p
>(decl))
>> > > > > return false;
>> > > > >
>> > > > > we could try to do sth like
>> > > > >
>> > > > > if (TREE_CODE (decl) == FUNCTION_DECL
>> > > > > && (fndecl_built_in_p (decl, BUILT_IN_MD)
>> > > > > || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
>> > > > > && !associated_internal_fn (decl
>> > > > > return false;
>> > > > >
>> > > > > but that would still leave us with too many undefineds I
>guess
>> > > > > (gcc_unreachable for one).
>> > > > >
>> > > > > We do not currently track builtins that do have a library
>implementation
>> > > > > (whether that it is used in the end is another thing, but
>less important).
>> > > > >
>> > > > > What we definitely can do is put a whitelist above like via
>the following
>> > > > > which also catches the case of definitions of builtins.
>> > > > >
>> > > > > Index: gcc/symtab.c
>> > > > >
>===
>> > > > > --- gcc/symtab.c(revision 273968)
>> > > > > +++ gcc/symtab.c(working copy)
>> > > > > @@ -2375,10 +2375,24 @@
>symtab_node::output_to_lto_symbol_table_
>> > > > > first place. */
>> > > > >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
>> > > > > return false;
>> > > > > +
>> > > > >/* FIXME: Builtins corresponding to real functions
>probably should have
>> > > > > symbol table entries. */
>> > > > > - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p
>(decl))
>> > > > > -return false;
>> > > > > + if (TREE_CODE (decl) == FUNCTION_DECL
>> > > > > + && !definition
>> > > > > + && fndecl_built_in_p (decl))
>> > > > > +{
>> > > > > + if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
>> > > > > + switch (DECL_FUNCTION_CODE (decl))
>> > > > > + {
>> > > > > + CASE_FLT_FN (BUILT_IN_ATAN2):
>> > > > > + CASE_FLT_FN (BUILT_IN_SIN):
>> > > > > + return true;
>> > > > > + default:
>> > > > > + break;
>> > > > > + }
>> > > > > + return false;
>> > > > > +}
>> > > > >
>> > > > >/* We have real symbol that should be in symbol table.
>However try to
>> > > > > trim
>> > > > > down the refernces to libraries bit more because linker
>will otherwise
>> > > >
>> > > > Hi Richard, no undefineds generated with below code, what's
>your opinion about
>> > > > the updated code, please? Thanks.
>> > >
>> > > It will break code calling __builtin_unreachable for example
>since
>> > > we'll emit an UNDEF that cannot be satisfied.
>> >
>> > Thanks. I tried to add __builtin_unreachable() in the test case, it
>can also
>> > works. As BUILT_IN_UNREACHABLE is defined in buitins.def instead of
>> > internal-fn.def, so associated_internal_fn will return IFN_LAST for
>it, then no
>> > UNDEF of __builtin_unreachable will be emitted to object file.
>> >
>> > Most of functions in internal-fn.def are math functions, I am not
>sure whether
>> > you mean the BUILT_IN_NOP or something else?
>>
>> OK, so a specific example woul dbe __builtin_clz. IIRC the
>> DECL_ASSEMBLER_NAME of the functions which have a libgcc fallback is
>> _not_ the symbol in libgcc (you'd have to double-check).
>>
>> That said, using associated_internal_fn is probably mostly safe but
>> not a complete fix since we have builtins like __builtin_strcpy
>> as well (but of course the C library is always linked).
>>
>> But I'm fine with an approach that incrementally improves things
>> here, but without possibly causing link-failures due to bogus
>> UNDEFs
>
>Add x = __builtin_clz(x); and __builtin_strcpy(str, "test\n") to the
>test code,
>the object file's symbol will be:
>luoxhu@genoa lto $ ~/workspace/gcc-git/gcc-master_debug/gcc/gcc-nm
>-B/home/luoxhu/workspace/gcc-git/gcc-master_debug/gcc/ atan2bashzowie.o
> U atan2
> U __builtin_clz
That shows
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #36 from rguenther at suse dot de --- On August 8, 2019 10:27:38 AM GMT+02:00, "rsandifo at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > >rsandifo at gcc dot gnu.org changed: > > What|Removed |Added > >CC||rsandifo at gcc dot gnu.org > >--- Comment #35 from rsandifo at gcc dot gnu.org gnu.org> --- >I might be missing the point, but tying this decision to internal >functions seems conceptually wrong. The main distinguishing >feature of internal functions is that they're purely compiler- >internal and have no linkage. It seems odd to use them to decide >whether a built-in function actually does have linkage. ;-) Yes indeed. Fact is we do not have the information whether a builtin has linkage or not readily available. >E.g. we only really have an internal function for things like >atan2 because of (the rarely used?) -mfancy-math-387. We should >be free to remove the internal function if we ever drop the >associated 387 support.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #35 from rsandifo at gcc dot gnu.org --- I might be missing the point, but tying this decision to internal functions seems conceptually wrong. The main distinguishing feature of internal functions is that they're purely compiler- internal and have no linkage. It seems odd to use them to decide whether a built-in function actually does have linkage. ;-) E.g. we only really have an internal function for things like atan2 because of (the rarely used?) -mfancy-math-387. We should be free to remove the internal function if we ever drop the associated 387 support.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #34 from Xiong Hu XS Luo ---
(In reply to rguent...@suse.de from comment #32)
> On Mon, 5 Aug 2019, luoxhu at cn dot ibm.com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >
> > --- Comment #31 from Xiong Hu XS Luo ---
> > (In reply to rguent...@suse.de from comment #30)
> > > On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > > >
> > > > --- Comment #28 from Xiong Hu XS Luo ---
> > > > (In reply to Richard Biener from comment #24)
> > > > > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p
> > > > > which
> > > > > has
> > > > >
> > > > > /* FIXME: Builtins corresponding to real functions probably should
> > > > > have
> > > > > symbol table entries. */
> > > > > if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > > > return false;
> > > > >
> > > > > we could try to do sth like
> > > > >
> > > > > if (TREE_CODE (decl) == FUNCTION_DECL
> > > > > && (fndecl_built_in_p (decl, BUILT_IN_MD)
> > > > > || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> > > > > && !associated_internal_fn (decl
> > > > > return false;
> > > > >
> > > > > but that would still leave us with too many undefineds I guess
> > > > > (gcc_unreachable for one).
> > > > >
> > > > > We do not currently track builtins that do have a library
> > > > > implementation
> > > > > (whether that it is used in the end is another thing, but less
> > > > > important).
> > > > >
> > > > > What we definitely can do is put a whitelist above like via the
> > > > > following
> > > > > which also catches the case of definitions of builtins.
> > > > >
> > > > > Index: gcc/symtab.c
> > > > > ===
> > > > > --- gcc/symtab.c(revision 273968)
> > > > > +++ gcc/symtab.c(working copy)
> > > > > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> > > > > first place. */
> > > > >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> > > > > return false;
> > > > > +
> > > > >/* FIXME: Builtins corresponding to real functions probably should
> > > > > have
> > > > > symbol table entries. */
> > > > > - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > > > -return false;
> > > > > + if (TREE_CODE (decl) == FUNCTION_DECL
> > > > > + && !definition
> > > > > + && fndecl_built_in_p (decl))
> > > > > +{
> > > > > + if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > > > > + switch (DECL_FUNCTION_CODE (decl))
> > > > > + {
> > > > > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > > > > + CASE_FLT_FN (BUILT_IN_SIN):
> > > > > + return true;
> > > > > + default:
> > > > > + break;
> > > > > + }
> > > > > + return false;
> > > > > +}
> > > > >
> > > > >/* We have real symbol that should be in symbol table. However
> > > > > try to
> > > > > trim
> > > > > down the refernces to libraries bit more because linker will
> > > > > otherwise
> > > >
> > > > Hi Richard, no undefineds generated with below code, what's your
> > > > opinion about
> > > > the updated code, please? Thanks.
> > >
> > > It will break code calling __builtin_unreachable for example since
> > > we'll emit an UNDEF that cannot be satisfied.
> >
> > Thanks. I tried to add __builtin_unreachable() in the test case, it can also
> > works. As BUILT_IN_UNREACHABLE is defined in buitins.def instead of
> > internal-fn.def, so associated_internal_fn will return IFN_LAST for it,
> > then no
> > UNDEF of __builtin_unreachable will be emitted to object file.
> >
> > Most of functions in internal-fn.def are math functions, I am not sure
> > whether
> > you mean the BUILT_IN_NOP or something else?
>
> OK, so a specific example woul dbe __builtin_clz. IIRC the
> DECL_ASSEMBLER_NAME of the functions which have a libgcc fallback is
> _not_ the symbol in libgcc (you'd have to double-check).
>
> That said, using associated_internal_fn is probably mostly safe but
> not a complete fix since we have builtins like __builtin_strcpy
> as well (but of course the C library is always linked).
>
> But I'm fine with an approach that incrementally improves things
> here, but without possibly causing link-failures due to bogus
> UNDEFs
Add x = __builtin_clz(x); and __builtin_strcpy(str, "test\n") to the test code,
the object file's symbol will be:
luoxhu@genoa lto $ ~/workspace/gcc-git/gcc-master_debug/gcc/gcc-nm
-B/home/luoxhu/workspace/gcc-git/gcc-master_debug/gcc/ atan2bashzowie.o
U atan2
U __builtin_clz
T main
U rand
T rand_finite_double
C str
T zowie
_builtin_clz is also defined in internal-fn.def, it could be linked
successfully with libgcc.
__builtin_strcpy
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #33 from Kewen Lin --- (In reply to rguent...@suse.de from comment #27) > On Fri, 2 Aug 2019, linkw at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > > > Kewen Lin changed: > > > >What|Removed |Added > > > > CC||linkw at gcc dot gnu.org > > > > --- Comment #26 from Kewen Lin --- > > > The odd thing is that if you omit libfoo1.so then it will consider > > > libfoo.a later but not when it can resolve from libfoo1.so. > > > > > > That's a bit inconsistent but arguably the bug is with GCCs > > > symbol table creation of the LTO IR. > > > > Do we have option to dump the actual final linking command to link all > > ltrans > > objects? I can only see the command to generate ltrans object with as. Is it > > possible a library order issue in final linking? > > The ld invocation for the final link is the same as the one spawning the > LTO WPA and LTRANS phases - the LTO plugin feeds back extra objects > for the re-link done by the very same ld process. > > Not sure if ld prints anything like an "effective final link command" > when adding verbosity (try -Wl,-v -Wl,-debug etc.). > > So - there isn't something like a "final linking command" and the final > linking approach also differs from BFD and gold for example. Thanks Richard! My local repo is old and doesn't pick up commit r271202 which respects save-temps to save output objects after LTRANS. The linking process with plugin is quite different from my stale knowledge on general lto linking, as you mentioned the objects out from LTRANS are fed back into the linking process by using plugin/ld interface. This issue seems use-linker-plugin only, I disabled it by -fno-use-linker-plugin and got the expected result, but it will miss all befenits from tight integration with ld. It's bad and just a workaround try. Another workaround with -Wl,--whole-archive -lmass -Wl,--no-whole-archive is also not practical due to code bloat and possible cache impact etc.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #32 from rguenther at suse dot de ---
On Mon, 5 Aug 2019, luoxhu at cn dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #31 from Xiong Hu XS Luo ---
> (In reply to rguent...@suse.de from comment #30)
> > On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > >
> > > --- Comment #28 from Xiong Hu XS Luo ---
> > > (In reply to Richard Biener from comment #24)
> > > > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p
> > > > which
> > > > has
> > > >
> > > > /* FIXME: Builtins corresponding to real functions probably should
> > > > have
> > > > symbol table entries. */
> > > > if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > > return false;
> > > >
> > > > we could try to do sth like
> > > >
> > > > if (TREE_CODE (decl) == FUNCTION_DECL
> > > > && (fndecl_built_in_p (decl, BUILT_IN_MD)
> > > > || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> > > > && !associated_internal_fn (decl
> > > > return false;
> > > >
> > > > but that would still leave us with too many undefineds I guess
> > > > (gcc_unreachable for one).
> > > >
> > > > We do not currently track builtins that do have a library implementation
> > > > (whether that it is used in the end is another thing, but less
> > > > important).
> > > >
> > > > What we definitely can do is put a whitelist above like via the
> > > > following
> > > > which also catches the case of definitions of builtins.
> > > >
> > > > Index: gcc/symtab.c
> > > > ===
> > > > --- gcc/symtab.c(revision 273968)
> > > > +++ gcc/symtab.c(working copy)
> > > > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> > > > first place. */
> > > >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> > > > return false;
> > > > +
> > > >/* FIXME: Builtins corresponding to real functions probably should
> > > > have
> > > > symbol table entries. */
> > > > - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > > -return false;
> > > > + if (TREE_CODE (decl) == FUNCTION_DECL
> > > > + && !definition
> > > > + && fndecl_built_in_p (decl))
> > > > +{
> > > > + if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > > > + switch (DECL_FUNCTION_CODE (decl))
> > > > + {
> > > > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > > > + CASE_FLT_FN (BUILT_IN_SIN):
> > > > + return true;
> > > > + default:
> > > > + break;
> > > > + }
> > > > + return false;
> > > > +}
> > > >
> > > >/* We have real symbol that should be in symbol table. However try
> > > > to
> > > > trim
> > > > down the refernces to libraries bit more because linker will
> > > > otherwise
> > >
> > > Hi Richard, no undefineds generated with below code, what's your opinion
> > > about
> > > the updated code, please? Thanks.
> >
> > It will break code calling __builtin_unreachable for example since
> > we'll emit an UNDEF that cannot be satisfied.
>
> Thanks. I tried to add __builtin_unreachable() in the test case, it can also
> works. As BUILT_IN_UNREACHABLE is defined in buitins.def instead of
> internal-fn.def, so associated_internal_fn will return IFN_LAST for it, then
> no
> UNDEF of __builtin_unreachable will be emitted to object file.
>
> Most of functions in internal-fn.def are math functions, I am not sure whether
> you mean the BUILT_IN_NOP or something else?
OK, so a specific example woul dbe __builtin_clz. IIRC the
DECL_ASSEMBLER_NAME of the functions which have a libgcc fallback is
_not_ the symbol in libgcc (you'd have to double-check).
That said, using associated_internal_fn is probably mostly safe but
not a complete fix since we have builtins like __builtin_strcpy
as well (but of course the C library is always linked).
But I'm fine with an approach that incrementally improves things
here, but without possibly causing link-failures due to bogus
UNDEFs
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #31 from Xiong Hu XS Luo ---
(In reply to rguent...@suse.de from comment #30)
> On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >
> > --- Comment #28 from Xiong Hu XS Luo ---
> > (In reply to Richard Biener from comment #24)
> > > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> > > has
> > >
> > > /* FIXME: Builtins corresponding to real functions probably should have
> > > symbol table entries. */
> > > if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > return false;
> > >
> > > we could try to do sth like
> > >
> > > if (TREE_CODE (decl) == FUNCTION_DECL
> > > && (fndecl_built_in_p (decl, BUILT_IN_MD)
> > > || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> > > && !associated_internal_fn (decl
> > > return false;
> > >
> > > but that would still leave us with too many undefineds I guess
> > > (gcc_unreachable for one).
> > >
> > > We do not currently track builtins that do have a library implementation
> > > (whether that it is used in the end is another thing, but less important).
> > >
> > > What we definitely can do is put a whitelist above like via the following
> > > which also catches the case of definitions of builtins.
> > >
> > > Index: gcc/symtab.c
> > > ===
> > > --- gcc/symtab.c(revision 273968)
> > > +++ gcc/symtab.c(working copy)
> > > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> > > first place. */
> > >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> > > return false;
> > > +
> > >/* FIXME: Builtins corresponding to real functions probably should have
> > > symbol table entries. */
> > > - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > -return false;
> > > + if (TREE_CODE (decl) == FUNCTION_DECL
> > > + && !definition
> > > + && fndecl_built_in_p (decl))
> > > +{
> > > + if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > > + switch (DECL_FUNCTION_CODE (decl))
> > > + {
> > > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > > + CASE_FLT_FN (BUILT_IN_SIN):
> > > + return true;
> > > + default:
> > > + break;
> > > + }
> > > + return false;
> > > +}
> > >
> > >/* We have real symbol that should be in symbol table. However try to
> > > trim
> > > down the refernces to libraries bit more because linker will
> > > otherwise
> >
> > Hi Richard, no undefineds generated with below code, what's your opinion
> > about
> > the updated code, please? Thanks.
>
> It will break code calling __builtin_unreachable for example since
> we'll emit an UNDEF that cannot be satisfied.
Thanks. I tried to add __builtin_unreachable() in the test case, it can also
works. As BUILT_IN_UNREACHABLE is defined in buitins.def instead of
internal-fn.def, so associated_internal_fn will return IFN_LAST for it, then no
UNDEF of __builtin_unreachable will be emitted to object file.
Most of functions in internal-fn.def are math functions, I am not sure whether
you mean the BUILT_IN_NOP or something else?
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #30 from rguenther at suse dot de ---
On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #28 from Xiong Hu XS Luo ---
> (In reply to Richard Biener from comment #24)
> > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> > has
> >
> > /* FIXME: Builtins corresponding to real functions probably should have
> > symbol table entries. */
> > if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > return false;
> >
> > we could try to do sth like
> >
> > if (TREE_CODE (decl) == FUNCTION_DECL
> > && (fndecl_built_in_p (decl, BUILT_IN_MD)
> > || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> > && !associated_internal_fn (decl
> > return false;
> >
> > but that would still leave us with too many undefineds I guess
> > (gcc_unreachable for one).
> >
> > We do not currently track builtins that do have a library implementation
> > (whether that it is used in the end is another thing, but less important).
> >
> > What we definitely can do is put a whitelist above like via the following
> > which also catches the case of definitions of builtins.
> >
> > Index: gcc/symtab.c
> > ===
> > --- gcc/symtab.c(revision 273968)
> > +++ gcc/symtab.c(working copy)
> > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> > first place. */
> >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> > return false;
> > +
> >/* FIXME: Builtins corresponding to real functions probably should have
> > symbol table entries. */
> > - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > -return false;
> > + if (TREE_CODE (decl) == FUNCTION_DECL
> > + && !definition
> > + && fndecl_built_in_p (decl))
> > +{
> > + if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > + switch (DECL_FUNCTION_CODE (decl))
> > + {
> > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > + CASE_FLT_FN (BUILT_IN_SIN):
> > + return true;
> > + default:
> > + break;
> > + }
> > + return false;
> > +}
> >
> >/* We have real symbol that should be in symbol table. However try to
> > trim
> > down the refernces to libraries bit more because linker will otherwise
>
> Hi Richard, no undefineds generated with below code, what's your opinion about
> the updated code, please? Thanks.
It will break code calling __builtin_unreachable for example since
we'll emit an UNDEF that cannot be satisfied.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #29 from Xiong Hu XS Luo ---
(In reply to Xiong Hu XS Luo from comment #28)
> (In reply to Richard Biener from comment #24)
> > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> > has
> >
> > /* FIXME: Builtins corresponding to real functions probably should have
> > symbol table entries. */
> > if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > return false;
> >
> > we could try to do sth like
> >
> > if (TREE_CODE (decl) == FUNCTION_DECL
> > && (fndecl_built_in_p (decl, BUILT_IN_MD)
> > || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> > && !associated_internal_fn (decl
> > return false;
> >
> > but that would still leave us with too many undefineds I guess
> > (gcc_unreachable for one).
> >
> > We do not currently track builtins that do have a library implementation
> > (whether that it is used in the end is another thing, but less important).
> >
> > What we definitely can do is put a whitelist above like via the following
> > which also catches the case of definitions of builtins.
> >
> > Index: gcc/symtab.c
> > ===
> > --- gcc/symtab.c(revision 273968)
> > +++ gcc/symtab.c(working copy)
> > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> > first place. */
> >if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> > return false;
> > +
> >/* FIXME: Builtins corresponding to real functions probably should have
> > symbol table entries. */
> > - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > -return false;
> > + if (TREE_CODE (decl) == FUNCTION_DECL
> > + && !definition
> > + && fndecl_built_in_p (decl))
> > +{
> > + if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > + switch (DECL_FUNCTION_CODE (decl))
> > + {
> > + CASE_FLT_FN (BUILT_IN_ATAN2):
> > + CASE_FLT_FN (BUILT_IN_SIN):
> > + return true;
> > + default:
> > + break;
> > + }
> > + return false;
> > +}
> >
> >/* We have real symbol that should be in symbol table. However try to
> > trim
> > down the refernces to libraries bit more because linker will otherwise
>
> Hi Richard, no undefineds generated with below code, what's your opinion
> about the updated code, please? Thanks.
I mean "too many undefineds" here. with below modification, symbols will be
output to object file, then linker could link static library as expected.
>
> diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
> index 47a9143ae26..9d42a57b4b6 100644
> --- a/gcc/lto-streamer-out.c
> +++ b/gcc/lto-streamer-out.c
> @@ -2644,7 +2644,10 @@ write_symbol (struct streamer_tree_cache_d *cache,
>
>gcc_checking_assert (TREE_PUBLIC (t)
>&& (TREE_CODE (t) != FUNCTION_DECL
> - || !fndecl_built_in_p (t))
> + || !fndecl_built_in_p (t, BUILT_IN_MD))
> + && (TREE_CODE (t) != FUNCTION_DECL
> + || !fndecl_built_in_p (t, BUILT_IN_NORMAL)
> + || associated_internal_fn (t) != IFN_LAST)
>&& !DECL_ABSTRACT_P (t)
>&& (!VAR_P (t) || !DECL_HARD_REGISTER (t)));
>
> diff --git a/gcc/symtab.c b/gcc/symtab.c
> index 63e2820eb93..ce74589b291 100644
> --- a/gcc/symtab.c
> +++ b/gcc/symtab.c
> @@ -2377,7 +2377,10 @@ symtab_node::output_to_lto_symbol_table_p (void)
> return false;
>/* FIXME: Builtins corresponding to real functions probably should have
> symbol table entries. */
> - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> + if (TREE_CODE (decl) == FUNCTION_DECL
> + && (fndecl_built_in_p (decl, BUILT_IN_MD)
> + || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> + && IFN_LAST == associated_internal_fn (decl
> return false;
>
>/* We have real symbol that should be in symbol table. However try to
> trim
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #28 from Xiong Hu XS Luo ---
(In reply to Richard Biener from comment #24)
> Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> has
>
> /* FIXME: Builtins corresponding to real functions probably should have
> symbol table entries. */
> if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> return false;
>
> we could try to do sth like
>
> if (TREE_CODE (decl) == FUNCTION_DECL
> && (fndecl_built_in_p (decl, BUILT_IN_MD)
> || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> && !associated_internal_fn (decl
> return false;
>
> but that would still leave us with too many undefineds I guess
> (gcc_unreachable for one).
>
> We do not currently track builtins that do have a library implementation
> (whether that it is used in the end is another thing, but less important).
>
> What we definitely can do is put a whitelist above like via the following
> which also catches the case of definitions of builtins.
>
> Index: gcc/symtab.c
> ===
> --- gcc/symtab.c(revision 273968)
> +++ gcc/symtab.c(working copy)
> @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> first place. */
>if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> return false;
> +
>/* FIXME: Builtins corresponding to real functions probably should have
> symbol table entries. */
> - if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> -return false;
> + if (TREE_CODE (decl) == FUNCTION_DECL
> + && !definition
> + && fndecl_built_in_p (decl))
> +{
> + if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> + switch (DECL_FUNCTION_CODE (decl))
> + {
> + CASE_FLT_FN (BUILT_IN_ATAN2):
> + CASE_FLT_FN (BUILT_IN_SIN):
> + return true;
> + default:
> + break;
> + }
> + return false;
> +}
>
>/* We have real symbol that should be in symbol table. However try to
> trim
> down the refernces to libraries bit more because linker will otherwise
Hi Richard, no undefineds generated with below code, what's your opinion about
the updated code, please? Thanks.
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 47a9143ae26..9d42a57b4b6 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -2644,7 +2644,10 @@ write_symbol (struct streamer_tree_cache_d *cache,
gcc_checking_assert (TREE_PUBLIC (t)
&& (TREE_CODE (t) != FUNCTION_DECL
- || !fndecl_built_in_p (t))
+ || !fndecl_built_in_p (t, BUILT_IN_MD))
+ && (TREE_CODE (t) != FUNCTION_DECL
+ || !fndecl_built_in_p (t, BUILT_IN_NORMAL)
+ || associated_internal_fn (t) != IFN_LAST)
&& !DECL_ABSTRACT_P (t)
&& (!VAR_P (t) || !DECL_HARD_REGISTER (t)));
diff --git a/gcc/symtab.c b/gcc/symtab.c
index 63e2820eb93..ce74589b291 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -2377,7 +2377,10 @@ symtab_node::output_to_lto_symbol_table_p (void)
return false;
/* FIXME: Builtins corresponding to real functions probably should have
symbol table entries. */
- if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
+ if (TREE_CODE (decl) == FUNCTION_DECL
+ && (fndecl_built_in_p (decl, BUILT_IN_MD)
+ || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
+ && IFN_LAST == associated_internal_fn (decl
return false;
/* We have real symbol that should be in symbol table. However try to trim
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #27 from rguenther at suse dot de --- On Fri, 2 Aug 2019, linkw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > Kewen Lin changed: > >What|Removed |Added > > CC||linkw at gcc dot gnu.org > > --- Comment #26 from Kewen Lin --- > > The odd thing is that if you omit libfoo1.so then it will consider > > libfoo.a later but not when it can resolve from libfoo1.so. > > > > That's a bit inconsistent but arguably the bug is with GCCs > > symbol table creation of the LTO IR. > > Do we have option to dump the actual final linking command to link all ltrans > objects? I can only see the command to generate ltrans object with as. Is it > possible a library order issue in final linking? The ld invocation for the final link is the same as the one spawning the LTO WPA and LTRANS phases - the LTO plugin feeds back extra objects for the re-link done by the very same ld process. Not sure if ld prints anything like an "effective final link command" when adding verbosity (try -Wl,-v -Wl,-debug etc.). So - there isn't something like a "final linking command" and the final linking approach also differs from BFD and gold for example.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #26 from Kewen Lin --- > The odd thing is that if you omit libfoo1.so then it will consider > libfoo.a later but not when it can resolve from libfoo1.so. > > That's a bit inconsistent but arguably the bug is with GCCs > symbol table creation of the LTO IR. Do we have option to dump the actual final linking command to link all ltrans objects? I can only see the command to generate ltrans object with as. Is it possible a library order issue in final linking?
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #25 from rguenther at suse dot de ---
On Wed, 31 Jul 2019, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #19 from H.J. Lu ---
> (In reply to Richard Biener from comment #17)
> > (In reply to Richard Biener from comment #16)
> > > (In reply to Richard Biener from comment #15)
> > > > Honza probably knows where we output the LTO symtab and why we do not
> > > > put
> > > > undefs for builtins there.
> > >
> > > #include
> > > double y, z;
> > > void foo ();
> > > int main()
> > > {
> > > volatile double x = atan2 (y, z);
> > > foo ();
> > > }
> > >
> > > > gcc-8 -c t.c -flto
> > > > gcc-nm t.o
> > > U foo
> > > T main
> > > C y
> > > C z
> > >
> > > where's the
> > >
> > > U atan2
> > >
> > > ?
> >
> > For
> >
> > double atan2 (double x, double y) { return x + y; }
> >
> > it doesn't appear either, this CU has an empty symbol table...
> >
> > I do remember quite some "funs" with builtin handling though, so the
> > current handling may be the least bad of all choices...
>
> [hjl@gnu-cfl-1 pr91287]$ cat foo1.c
> #include
>
> float
> atan2f (float x, float y)
> {
> abort ();
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat foo.c
> float
> atan2f (float x, float y)
> {
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat bar.c
> #include
>
> extern float x, y, z;
>
> void
> bar (void)
> {
> x = atan2f (y, z);
> }
> [hjl@gnu-cfl-1 pr91287]$ cat main.c
> #include
>
> extern void bar (void);
>
> float x, y = 1, z =1;
>
> int
> main (void)
> {
> x = atan2f (y, z);
> bar ();
> return 0;
> }
> [hjl@gnu-cfl-1 pr91287]$ make
> cc -O3 -c -o foo.o foo.c
> ar rc libfoo.a foo.o
> cc -O3 -fpic -c -o bar.o bar.c
> cc -O3 -fpic -c -o foo1.o foo1.c
> ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
> ld -shared -o libbar.so bar.o libfoo1.so
> cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> ./y
> ./x
> make: *** [Makefile:9: all] Aborted
> [hjl@gnu-cfl-1 pr91287]$
>
> Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
> libfoo.a. atan2f is resolved to definition in libfoo1.so later.
The odd thing is that if you omit libfoo1.so then it will consider
libfoo.a later but not when it can resolve from libfoo1.so.
That's a bit inconsistent but arguably the bug is with GCCs
symbol table creation of the LTO IR.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #24 from Richard Biener ---
Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which has
/* FIXME: Builtins corresponding to real functions probably should have
symbol table entries. */
if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
return false;
we could try to do sth like
if (TREE_CODE (decl) == FUNCTION_DECL
&& (fndecl_built_in_p (decl, BUILT_IN_MD)
|| (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
&& !associated_internal_fn (decl
return false;
but that would still leave us with too many undefineds I guess
(gcc_unreachable for one).
We do not currently track builtins that do have a library implementation
(whether that it is used in the end is another thing, but less important).
What we definitely can do is put a whitelist above like via the following
which also catches the case of definitions of builtins.
Index: gcc/symtab.c
===
--- gcc/symtab.c(revision 273968)
+++ gcc/symtab.c(working copy)
@@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
first place. */
if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
return false;
+
/* FIXME: Builtins corresponding to real functions probably should have
symbol table entries. */
- if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
-return false;
+ if (TREE_CODE (decl) == FUNCTION_DECL
+ && !definition
+ && fndecl_built_in_p (decl))
+{
+ if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
+ switch (DECL_FUNCTION_CODE (decl))
+ {
+ CASE_FLT_FN (BUILT_IN_ATAN2):
+ CASE_FLT_FN (BUILT_IN_SIN):
+ return true;
+ default:
+ break;
+ }
+ return false;
+}
/* We have real symbol that should be in symbol table. However try to trim
down the refernces to libraries bit more because linker will otherwise
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Bill Schmidt changed: What|Removed |Added Known to fail||7.4.0 --- Comment #23 from Bill Schmidt --- Xiong Hu confirmed this is also broken on GCC 7. I may have been mistaken about this having worked before; we may just never have realized we weren't getting the benefit of the scalar MASS functions.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #22 from Xiong Hu XS Luo ---
(In reply to Xiong Hu XS Luo from comment #21)
> (In reply to H.J. Lu from comment #19)
> > (In reply to Richard Biener from comment #17)
> > > (In reply to Richard Biener from comment #16)
> > > > (In reply to Richard Biener from comment #15)
> > > > > Honza probably knows where we output the LTO symtab and why we do not
> > > > > put
> > > > > undefs for builtins there.
> > > >
> > > > #include
> > > > double y, z;
> > > > void foo ();
> > > > int main()
> > > > {
> > > > volatile double x = atan2 (y, z);
> > > > foo ();
> > > > }
> > > >
> > > > > gcc-8 -c t.c -flto
> > > > > gcc-nm t.o
> > > > U foo
> > > > T main
> > > > C y
> > > > C z
> > > >
> > > > where's the
> > > >
> > > > U atan2
> > > >
> > > > ?
> > >
> > > For
> > >
> > > double atan2 (double x, double y) { return x + y; }
> > >
> > > it doesn't appear either, this CU has an empty symbol table...
> > >
> > > I do remember quite some "funs" with builtin handling though, so the
> > > current handling may be the least bad of all choices...
> >
> > [hjl@gnu-cfl-1 pr91287]$ cat foo1.c
> > #include
> >
> > float
> > atan2f (float x, float y)
> > {
> > abort ();
> > return x * y;
> > }
> > [hjl@gnu-cfl-1 pr91287]$ cat foo.c
> > float
> > atan2f (float x, float y)
> > {
> > return x * y;
> > }
> > [hjl@gnu-cfl-1 pr91287]$ cat bar.c
> > #include
> >
> > extern float x, y, z;
> >
> > void
> > bar (void)
> > {
> > x = atan2f (y, z);
> > }
> > [hjl@gnu-cfl-1 pr91287]$ cat main.c
> > #include
> >
> > extern void bar (void);
> >
> > float x, y = 1, z =1;
> >
> > int
> > main (void)
> > {
> > x = atan2f (y, z);
> > bar ();
> > return 0;
> > }
> > [hjl@gnu-cfl-1 pr91287]$ make
> > cc -O3 -c -o foo.o foo.c
> > ar rc libfoo.a foo.o
> > cc -O3 -fpic -c -o bar.o bar.c
> > cc -O3 -fpic -c -o foo1.o foo1.c
> > ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
> > ld -shared -o libbar.so bar.o libfoo1.so
> > cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> > cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> > ./y
> > ./x
> > make: *** [Makefile:9: all] Aborted
> > [hjl@gnu-cfl-1 pr91287]$
> >
> > Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
> > libfoo.a. atan2f is resolved to definition in libfoo1.so later.
> Thanks for your test case.
> If remove the libfoo1.so when build x, it will link libfoo.a. And run x will
> not abort.
>
> luoxhu@genoa pr91287 $ ~/local/gcc_t/bin/gcc -flto -O3 -o x main.c libfoo.a
> libbar.so -Wl,-R,.
> luoxhu@genoa pr91287 $ ./x
>
> Since x can link the libfoo.a if libfoo1.so not exists, not quite understand
> why "atan2f isn't referenced in IR"?
>
> Acutually my test case shows that binary built with LTO can link libmass.a
> first when use gcc, but failed to link libmass.a if use gfortran(link
> libm.so finally).
>
> PS: My test case (gcc LTO link libmass.a first) doesn't match with your case
> result(gcc LTO link libfoo1.so instead of libfoo.a).
BTW, the link sequence is quite important, switch libbar.so and libfoo.a, then
x will link atan2 in libfoo.a instead of libfoo1.so, which matches my test
case:
~/local/gcc_t/bin/gcc -flto -O3 -o x main.c libbar.so libfoo.a libfoo1.so
-Wl,-R,.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #21 from Xiong Hu XS Luo ---
(In reply to H.J. Lu from comment #19)
> (In reply to Richard Biener from comment #17)
> > (In reply to Richard Biener from comment #16)
> > > (In reply to Richard Biener from comment #15)
> > > > Honza probably knows where we output the LTO symtab and why we do not
> > > > put
> > > > undefs for builtins there.
> > >
> > > #include
> > > double y, z;
> > > void foo ();
> > > int main()
> > > {
> > > volatile double x = atan2 (y, z);
> > > foo ();
> > > }
> > >
> > > > gcc-8 -c t.c -flto
> > > > gcc-nm t.o
> > > U foo
> > > T main
> > > C y
> > > C z
> > >
> > > where's the
> > >
> > > U atan2
> > >
> > > ?
> >
> > For
> >
> > double atan2 (double x, double y) { return x + y; }
> >
> > it doesn't appear either, this CU has an empty symbol table...
> >
> > I do remember quite some "funs" with builtin handling though, so the
> > current handling may be the least bad of all choices...
>
> [hjl@gnu-cfl-1 pr91287]$ cat foo1.c
> #include
>
> float
> atan2f (float x, float y)
> {
> abort ();
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat foo.c
> float
> atan2f (float x, float y)
> {
> return x * y;
> }
> [hjl@gnu-cfl-1 pr91287]$ cat bar.c
> #include
>
> extern float x, y, z;
>
> void
> bar (void)
> {
> x = atan2f (y, z);
> }
> [hjl@gnu-cfl-1 pr91287]$ cat main.c
> #include
>
> extern void bar (void);
>
> float x, y = 1, z =1;
>
> int
> main (void)
> {
> x = atan2f (y, z);
> bar ();
> return 0;
> }
> [hjl@gnu-cfl-1 pr91287]$ make
> cc -O3 -c -o foo.o foo.c
> ar rc libfoo.a foo.o
> cc -O3 -fpic -c -o bar.o bar.c
> cc -O3 -fpic -c -o foo1.o foo1.c
> ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
> ld -shared -o libbar.so bar.o libfoo1.so
> cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
> ./y
> ./x
> make: *** [Makefile:9: all] Aborted
> [hjl@gnu-cfl-1 pr91287]$
>
> Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
> libfoo.a. atan2f is resolved to definition in libfoo1.so later.
Thanks for your test case.
If remove the libfoo1.so when build x, it will link libfoo.a. And run x will
not abort.
luoxhu@genoa pr91287 $ ~/local/gcc_t/bin/gcc -flto -O3 -o x main.c libfoo.a
libbar.so -Wl,-R,.
luoxhu@genoa pr91287 $ ./x
Since x can link the libfoo.a if libfoo1.so not exists, not quite understand
why "atan2f isn't referenced in IR"?
Acutually my test case shows that binary built with LTO can link libmass.a
first when use gcc, but failed to link libmass.a if use gfortran(link libm.so
finally).
PS: My test case (gcc LTO link libmass.a first) doesn't match with your case
result(gcc LTO link libfoo1.so instead of libfoo.a).
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #20 from Xiong Hu XS Luo ---
(In reply to rguent...@suse.de from comment #11)
> On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >
> > --- Comment #10 from wschmidt at linux dot ibm.com ---
> > On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > >
> > > --- Comment #9 from rguenther at suse dot de
> > > ---
> > > On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> > >
> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > >>
> > >> --- Comment #8 from Xiong Hu XS Luo ---
> > >> (In reply to Thomas Koenig from comment #6)
> > >>> (In reply to Xiong Hu XS Luo from comment #4)
> > >>>
> > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> > :(.text+0x114): undefined reference to `_gfortran_st_write'
> > :(.text+0x12c): undefined reference to
> > `_gfortran_transfer_character_write'
> > >>> You're not linkging against libgfortran.
> > >>>
> > >>> Either use gfortran as command for compiling or linking, or
> > >>> add the appropriate libraries (-lgfortran -lquadmath) to
> > >>> the linking step.
> > >> Thanks Thomas and Richard. Sorry that I am not familiar with fortran.
> > >> The
> > >> regression was fixed by Martin's new change.
> > >>
> > >> The c code included math.h actually.
> > >>
> > >> cat atan2bashzowie.c
> > >> #include
> > >> #include
> > >> #include
> > >>
> > >> double __attribute__((noinline)) zowie (double x, double y, double z)
> > >> {
> > >> return atan2 (x * y, z);
> > >> }
> > >>
> > >> double __attribute__((noinline)) rand_finite_double (void)
> > >> {
> > >> union {
> > >> double d;
> > >> unsigned char uc[sizeof(double)];
> > >> } u;
> > >> do {
> > >> for (unsigned i = 0; i < sizeof u.uc; i++) {
> > >> u.uc[i] = (unsigned char) rand();
> > >> }
> > >> } while (!isfinite(u.d));
> > >> return u.d;
> > >> }
> > >>
> > >> int main ()
> > >> {
> > >> double a = rand_finite_double ();
> > >> printf ("%lf\n", zowie (a, 4.5, 2.2));
> > >> return 0;
> > >> }
> > >> cat build.sh
> > >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> > >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8
> > >> -o a.out
> > >> nm a.out | grep atan2
> > >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> > >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv
> > >> -lmassvp8 -o
> > >> a.out
> > >> nm a.out | grep atan2
> > >> ./build.sh
> > >> 1700 T atan2
> > >> 1700 T _atan2
> > >> 17e0 T atan2
> > >> 17e0 T _atan2
> > > Err, but [_]atan2 are surely not vector variants. Also is massv a static
> > > library here? It looks more like you are not getting the code vectorized
> > > with -flto but without and both variants end up using massv (the -flto
> > > variant using the scalar atan2)?
> > >
> > > That said, you have to do more detailed analysis of what actually
> > > happens and what you _want_ to happen. The bugreport summary
> > > doesn't really match what you show.
> > >
> > Agree that there's some unnecessary confusion here. I think the
> > temporary ICE and the build issues obscured the original intent of the bug.
> >
> > There are two libraries provided with the MASS project. libmass
> > provides scalar replacements for corresponding libm scalar math
> > functions. libmassv provides the vectorized versions of those
> > functions. For this bug we are only concerned about libmass and scalar
> > math functions.
>
> OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is
> linking -lmassv or -lmass_smidp8 then I guess.
>
> > With the C version of the code, we correctly generate symbols atan2 and
> > _atan2 that will be satisfied by libmass. With the Fortran version of
> > the code and without -flto, we again generate symbols atan2f and _atan2f
> > that will be satisfied by libmass. When we add -flto to the Fortran
> > version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
> > disallowing libmass from satisfying them.
> >
> > We see different behavior in the "visibility" LTO pass between the C and
> > Fortran versions, which seems to be a clue.
>
> I see (on x86) atan2f being used for the fortran testcase since
> you are calling atan2 with real() arguments. If you do not use
> -fdefault-real-8 you are then comparing apples and oranges.
>
> Maybe MASS doesn't have any float variants?
update the fortran case to use real*8 to call atan2 instead of atan2f,
-mveclibabi=mass and -lmassv are unnecessary to reproduce it:
luoxhu@genoa lto $ cat hellofortran.f90
recursive subroutine square_cube(i,isquare,icube)
REAL*8 j
REAL*8, DIMENSION(0:1):: vector
integer, intent(in) :: i ! input
integer, intent(out) :: isquare,icube !
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #19 from H.J. Lu ---
(In reply to Richard Biener from comment #17)
> (In reply to Richard Biener from comment #16)
> > (In reply to Richard Biener from comment #15)
> > > Honza probably knows where we output the LTO symtab and why we do not put
> > > undefs for builtins there.
> >
> > #include
> > double y, z;
> > void foo ();
> > int main()
> > {
> > volatile double x = atan2 (y, z);
> > foo ();
> > }
> >
> > > gcc-8 -c t.c -flto
> > > gcc-nm t.o
> > U foo
> > T main
> > C y
> > C z
> >
> > where's the
> >
> > U atan2
> >
> > ?
>
> For
>
> double atan2 (double x, double y) { return x + y; }
>
> it doesn't appear either, this CU has an empty symbol table...
>
> I do remember quite some "funs" with builtin handling though, so the
> current handling may be the least bad of all choices...
[hjl@gnu-cfl-1 pr91287]$ cat foo1.c
#include
float
atan2f (float x, float y)
{
abort ();
return x * y;
}
[hjl@gnu-cfl-1 pr91287]$ cat foo.c
float
atan2f (float x, float y)
{
return x * y;
}
[hjl@gnu-cfl-1 pr91287]$ cat bar.c
#include
extern float x, y, z;
void
bar (void)
{
x = atan2f (y, z);
}
[hjl@gnu-cfl-1 pr91287]$ cat main.c
#include
extern void bar (void);
float x, y = 1, z =1;
int
main (void)
{
x = atan2f (y, z);
bar ();
return 0;
}
[hjl@gnu-cfl-1 pr91287]$ make
cc -O3 -c -o foo.o foo.c
ar rc libfoo.a foo.o
cc -O3 -fpic -c -o bar.o bar.c
cc -O3 -fpic -c -o foo1.o foo1.c
ld -shared -o libfoo1.so foo1.o # --version-script foo1.v
ld -shared -o libbar.so bar.o libfoo1.so
cc -flto -O3 -o x main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
cc -O3 -o y main.c libfoo.a libbar.so libfoo1.so -Wl,-R,.
./y
./x
make: *** [Makefile:9: all] Aborted
[hjl@gnu-cfl-1 pr91287]$
Since atan2f isn't referenced in IR, linker doesn't extract atan2f from
libfoo.a. atan2f is resolved to definition in libfoo1.so later.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #18 from Richard Biener --- So the linker issue would be that during computing of the resolution when the linker decides a whole archive isn't necessary it doesn't re-consider it for the final actual link (which is where GCC exposes the atan2 UNDEF). Instead it happily resolves it to libm which libgfortran drags in? For C and without -lm it doesn't find it and thus _does_ re-consider the previously unused -lmass. I would have expected the link to fail with an unresolved symbol - so the behavior is at least inconsistent.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-07-31
Ever confirmed|0 |1
--- Comment #17 from Richard Biener ---
(In reply to Richard Biener from comment #16)
> (In reply to Richard Biener from comment #15)
> > Honza probably knows where we output the LTO symtab and why we do not put
> > undefs for builtins there.
>
> #include
> double y, z;
> void foo ();
> int main()
> {
> volatile double x = atan2 (y, z);
> foo ();
> }
>
> > gcc-8 -c t.c -flto
> > gcc-nm t.o
> U foo
> T main
> C y
> C z
>
> where's the
>
> U atan2
>
> ?
For
double atan2 (double x, double y) { return x + y; }
it doesn't appear either, this CU has an empty symbol table...
I do remember quite some "funs" with builtin handling though, so the
current handling may be the least bad of all choices...
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #15)
> Honza probably knows where we output the LTO symtab and why we do not put
> undefs for builtins there.
#include
double y, z;
void foo ();
int main()
{
volatile double x = atan2 (y, z);
foo ();
}
> gcc-8 -c t.c -flto
> gcc-nm t.o
U foo
T main
C y
C z
where's the
U atan2
?
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #15 from Richard Biener --- Honza probably knows where we output the LTO symtab and why we do not put undefs for builtins there.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #14 from rguenther at suse dot de --- On Wed, 31 Jul 2019, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > Bill Schmidt changed: > >What|Removed |Added > > Known to fail||10.0, 8.3.0, 9.1.0 > > --- Comment #13 from Bill Schmidt --- > It dates back to at least 2018-04-12, when it was reported internally on a > SPEC > test. I'll mark known-to-fail for GCC 8 going forward. Note it can also be a binutils issue, there used to be issues with static library handling and builtins eventually not appearing in the LTO symbol table. Indeed for the fortran example I see 1 t.o 8 334 a12b0c6fed53f76a PREVAILING_DEF_IRONLY square_cube_ 348 a12b0c6fed53f76a PREVAILING_DEF main 363 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write_done 372 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_integer_write 381 a12b0c6fed53f76a RESOLVED_DYN _gfortran_transfer_character_write 383 a12b0c6fed53f76a RESOLVED_DYN _gfortran_st_write 391 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_options 396 a12b0c6fed53f76a RESOLVED_DYN _gfortran_set_args and for a corresponding C testcase 1 t.o 3 198 af89597965b857af PREVAILING_DEF main 211 af89597965b857af PREVAILING_DEF_IRONLY z 213 af89597965b857af PREVAILING_DEF_IRONLY y so no atan2 but an external function foo appears. So the linker probably decides MASS is not needed at all and in the end atan2 comes in via libgfortran linking to libm.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Bill Schmidt changed: What|Removed |Added Known to fail||10.0, 8.3.0, 9.1.0 --- Comment #13 from Bill Schmidt --- It dates back to at least 2018-04-12, when it was reported internally on a SPEC test. I'll mark known-to-fail for GCC 8 going forward.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #12 from Bill Schmidt --- (In reply to rguent...@suse.de from comment #11) > On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote: > > OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is > linking -lmassv or -lmass_smidp8 then I guess. That's correct. That was just our standard set of flags for linking with MASS/MASSV. It was confusing. > > > With the C version of the code, we correctly generate symbols atan2 and > > _atan2 that will be satisfied by libmass. With the Fortran version of > > the code and without -flto, we again generate symbols atan2f and _atan2f > > that will be satisfied by libmass. When we add -flto to the Fortran > > version of the code, we instead generate symbols for atan2f@@GLIBC_2.17, > > disallowing libmass from satisfying them. > > > > We see different behavior in the "visibility" LTO pass between the C and > > Fortran versions, which seems to be a clue. > > I see (on x86) atan2f being used for the fortran testcase since > you are calling atan2 with real() arguments. If you do not use > -fdefault-real-8 you are then comparing apples and oranges. > > Maybe MASS doesn't have any float variants? No, this used to work. It looks like this started happening a couple of releases ago. We need to drill down on that.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #11 from rguenther at suse dot de ---
On Wed, 31 Jul 2019, wschmidt at linux dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #10 from wschmidt at linux dot ibm.com ---
> On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >
> > --- Comment #9 from rguenther at suse dot de ---
> > On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> >
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> >>
> >> --- Comment #8 from Xiong Hu XS Luo ---
> >> (In reply to Thomas Koenig from comment #6)
> >>> (In reply to Xiong Hu XS Luo from comment #4)
> >>>
> /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> :(.text+0x114): undefined reference to `_gfortran_st_write'
> :(.text+0x12c): undefined reference to
> `_gfortran_transfer_character_write'
> >>> You're not linkging against libgfortran.
> >>>
> >>> Either use gfortran as command for compiling or linking, or
> >>> add the appropriate libraries (-lgfortran -lquadmath) to
> >>> the linking step.
> >> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
> >> regression was fixed by Martin's new change.
> >>
> >> The c code included math.h actually.
> >>
> >> cat atan2bashzowie.c
> >> #include
> >> #include
> >> #include
> >>
> >> double __attribute__((noinline)) zowie (double x, double y, double z)
> >> {
> >> return atan2 (x * y, z);
> >> }
> >>
> >> double __attribute__((noinline)) rand_finite_double (void)
> >> {
> >> union {
> >> double d;
> >> unsigned char uc[sizeof(double)];
> >> } u;
> >> do {
> >> for (unsigned i = 0; i < sizeof u.uc; i++) {
> >> u.uc[i] = (unsigned char) rand();
> >> }
> >> } while (!isfinite(u.d));
> >> return u.d;
> >> }
> >>
> >> int main ()
> >> {
> >> double a = rand_finite_double ();
> >> printf ("%lf\n", zowie (a, 4.5, 2.2));
> >> return 0;
> >> }
> >> cat build.sh
> >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
> >> a.out
> >> nm a.out | grep atan2
> >> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> >> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv
> >> -lmassvp8 -o
> >> a.out
> >> nm a.out | grep atan2
> >> ./build.sh
> >> 1700 T atan2
> >> 1700 T _atan2
> >> 17e0 T atan2
> >> 17e0 T _atan2
> > Err, but [_]atan2 are surely not vector variants. Also is massv a static
> > library here? It looks more like you are not getting the code vectorized
> > with -flto but without and both variants end up using massv (the -flto
> > variant using the scalar atan2)?
> >
> > That said, you have to do more detailed analysis of what actually
> > happens and what you _want_ to happen. The bugreport summary
> > doesn't really match what you show.
> >
> Agree that there's some unnecessary confusion here. I think the
> temporary ICE and the build issues obscured the original intent of the bug.
>
> There are two libraries provided with the MASS project. libmass
> provides scalar replacements for corresponding libm scalar math
> functions. libmassv provides the vectorized versions of those
> functions. For this bug we are only concerned about libmass and scalar
> math functions.
OK, so -mveclibabi=mass isn't needed to reproduce the issue, nor is
linking -lmassv or -lmass_smidp8 then I guess.
> With the C version of the code, we correctly generate symbols atan2 and
> _atan2 that will be satisfied by libmass. With the Fortran version of
> the code and without -flto, we again generate symbols atan2f and _atan2f
> that will be satisfied by libmass. When we add -flto to the Fortran
> version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
> disallowing libmass from satisfying them.
>
> We see different behavior in the "visibility" LTO pass between the C and
> Fortran versions, which seems to be a clue.
I see (on x86) atan2f being used for the fortran testcase since
you are calling atan2 with real() arguments. If you do not use
-fdefault-real-8 you are then comparing apples and oranges.
Maybe MASS doesn't have any float variants?
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #10 from wschmidt at linux dot ibm.com ---
On 7/31/19 2:25 AM, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #9 from rguenther at suse dot de ---
> On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>>
>> --- Comment #8 from Xiong Hu XS Luo ---
>> (In reply to Thomas Koenig from comment #6)
>>> (In reply to Xiong Hu XS Luo from comment #4)
>>>
/tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
:(.text+0x114): undefined reference to `_gfortran_st_write'
:(.text+0x12c): undefined reference to
`_gfortran_transfer_character_write'
>>> You're not linkging against libgfortran.
>>>
>>> Either use gfortran as command for compiling or linking, or
>>> add the appropriate libraries (-lgfortran -lquadmath) to
>>> the linking step.
>> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
>> regression was fixed by Martin's new change.
>>
>> The c code included math.h actually.
>>
>> cat atan2bashzowie.c
>> #include
>> #include
>> #include
>>
>> double __attribute__((noinline)) zowie (double x, double y, double z)
>> {
>> return atan2 (x * y, z);
>> }
>>
>> double __attribute__((noinline)) rand_finite_double (void)
>> {
>> union {
>> double d;
>> unsigned char uc[sizeof(double)];
>> } u;
>> do {
>> for (unsigned i = 0; i < sizeof u.uc; i++) {
>> u.uc[i] = (unsigned char) rand();
>> }
>> } while (!isfinite(u.d));
>> return u.d;
>> }
>>
>> int main ()
>> {
>> double a = rand_finite_double ();
>> printf ("%lf\n", zowie (a, 4.5, 2.2));
>> return 0;
>> }
>> cat build.sh
>> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
>> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
>> a.out
>> nm a.out | grep atan2
>> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
>> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8
>> -o
>> a.out
>> nm a.out | grep atan2
>> ./build.sh
>> 1700 T atan2
>> 1700 T _atan2
>> 17e0 T atan2
>> 17e0 T _atan2
> Err, but [_]atan2 are surely not vector variants. Also is massv a static
> library here? It looks more like you are not getting the code vectorized
> with -flto but without and both variants end up using massv (the -flto
> variant using the scalar atan2)?
>
> That said, you have to do more detailed analysis of what actually
> happens and what you _want_ to happen. The bugreport summary
> doesn't really match what you show.
>
Agree that there's some unnecessary confusion here. I think the
temporary ICE and the build issues obscured the original intent of the bug.
There are two libraries provided with the MASS project. libmass
provides scalar replacements for corresponding libm scalar math
functions. libmassv provides the vectorized versions of those
functions. For this bug we are only concerned about libmass and scalar
math functions.
With the C version of the code, we correctly generate symbols atan2 and
_atan2 that will be satisfied by libmass. With the Fortran version of
the code and without -flto, we again generate symbols atan2f and _atan2f
that will be satisfied by libmass. When we add -flto to the Fortran
version of the code, we instead generate symbols for atan2f@@GLIBC_2.17,
disallowing libmass from satisfying them.
We see different behavior in the "visibility" LTO pass between the C and
Fortran versions, which seems to be a clue.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #9 from rguenther at suse dot de ---
On Wed, 31 Jul 2019, luoxhu at cn dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
> --- Comment #8 from Xiong Hu XS Luo ---
> (In reply to Thomas Koenig from comment #6)
> > (In reply to Xiong Hu XS Luo from comment #4)
> >
> > > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> > > :(.text+0x114): undefined reference to `_gfortran_st_write'
> > > :(.text+0x12c): undefined reference to
> > > `_gfortran_transfer_character_write'
> >
> > You're not linkging against libgfortran.
> >
> > Either use gfortran as command for compiling or linking, or
> > add the appropriate libraries (-lgfortran -lquadmath) to
> > the linking step.
>
> Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
> regression was fixed by Martin's new change.
>
> The c code included math.h actually.
>
> cat atan2bashzowie.c
> #include
> #include
> #include
>
> double __attribute__((noinline)) zowie (double x, double y, double z)
> {
> return atan2 (x * y, z);
> }
>
> double __attribute__((noinline)) rand_finite_double (void)
> {
> union {
> double d;
> unsigned char uc[sizeof(double)];
> } u;
> do {
> for (unsigned i = 0; i < sizeof u.uc; i++) {
> u.uc[i] = (unsigned char) rand();
> }
> } while (!isfinite(u.d));
> return u.d;
> }
>
> int main ()
> {
> double a = rand_finite_double ();
> printf ("%lf\n", zowie (a, 4.5, 2.2));
> return 0;
> }
> cat build.sh
> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o
> a.out
> nm a.out | grep atan2
> ~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
> -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8
> -o
> a.out
> nm a.out | grep atan2
> ./build.sh
> 1700 T atan2
> 1700 T _atan2
> 17e0 T atan2
> 17e0 T _atan2
Err, but [_]atan2 are surely not vector variants. Also is massv a static
library here? It looks more like you are not getting the code vectorized
with -flto but without and both variants end up using massv (the -flto
variant using the scalar atan2)?
That said, you have to do more detailed analysis of what actually
happens and what you _want_ to happen. The bugreport summary
doesn't really match what you show.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #8 from Xiong Hu XS Luo ---
(In reply to Thomas Koenig from comment #6)
> (In reply to Xiong Hu XS Luo from comment #4)
>
> > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__':
> > :(.text+0x114): undefined reference to `_gfortran_st_write'
> > :(.text+0x12c): undefined reference to
> > `_gfortran_transfer_character_write'
>
> You're not linkging against libgfortran.
>
> Either use gfortran as command for compiling or linking, or
> add the appropriate libraries (-lgfortran -lquadmath) to
> the linking step.
Thanks Thomas and Richard. Sorry that I am not familiar with fortran. The
regression was fixed by Martin's new change.
The c code included math.h actually.
cat atan2bashzowie.c
#include
#include
#include
double __attribute__((noinline)) zowie (double x, double y, double z)
{
return atan2 (x * y, z);
}
double __attribute__((noinline)) rand_finite_double (void)
{
union {
double d;
unsigned char uc[sizeof(double)];
} u;
do {
for (unsigned i = 0; i < sizeof u.uc; i++) {
u.uc[i] = (unsigned char) rand();
}
} while (!isfinite(u.d));
return u.d;
}
int main ()
{
double a = rand_finite_double ();
printf ("%lf\n", zowie (a, 4.5, 2.2));
return 0;
}
cat build.sh
~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
-L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -lmass_simdp8 -lmassv -lmassvp8 -o a.out
nm a.out | grep atan2
~/local/gcc_t/bin/gcc -O3 -mcpu=power9 atan2bashzowie.c -mveclibabi=mass
-L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8 -o
a.out
nm a.out | grep atan2
./build.sh
1700 T atan2
1700 T _atan2
17e0 T atan2
17e0 T _atan2
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #7 from Xiong Hu XS Luo --- Created attachment 46647 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46647=edit fortran_lto_verbose log
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #6 from Thomas Koenig --- (In reply to Xiong Hu XS Luo from comment #4) > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__': > :(.text+0x114): undefined reference to `_gfortran_st_write' > :(.text+0x12c): undefined reference to > `_gfortran_transfer_character_write' You're not linkging against libgfortran. Either use gfortran as command for compiling or linking, or add the appropriate libraries (-lgfortran -lquadmath) to the linking step.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #5 from rguenther at suse dot de --- On Tue, 30 Jul 2019, luoxhu at cn dot ibm.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > --- Comment #4 from Xiong Hu XS Luo --- > (In reply to Martin Liška from comment #3) > > (In reply to Xiong Hu XS Luo from comment #1) > > > Martin's commit 4ee64e30659a9125a47eeea882d8044e690ce334 will cause ICE. > > > > > > It's a REGRESSION not related to this current issue. > > > > > > ~/local/gcc_t/bin/gfortran -O3 -mcpu=power9 hellofortran.f90 > > > -mveclibabi=mass -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto > > > -lmass_simdp8 > > > -lmassv -lmassvp8 > > > lto1: internal compiler error: bytecode stream: expected tag > > > identifier_node > > > instead of LTO_UNKNOWN > > > > > > It's not fixed even updated to commit > > > cf474017fbb8fbb71d69b0ca4b4b34260cfe5ab3 (Mon Jul 29, Fix ICE seen in > > > tree-ssa-dce.c for new/delete pair.). > > > > > > > > > commit 4ee64e30659a9125a47eeea882d8044e690ce334 > > > Author: marxin > > > Date: Thu Jul 25 09:36:38 2019 + > > > > > > Extend DCE to remove unnecessary new/delete-pairs (PR c++/23383). > > > > > > 2019-07-25 Martin Liska > > > > Which should be hopefully fixed by: > > https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01761.html > > Still fail to build after applying your changes, but different from before: > > ~/workspace/gcc-git/gcc-master_build/gcc/xgcc > -B/home/luoxhu/workspace/gcc-git/gcc-master_build/gcc/ -O3 -mcpu=power9 > hellofortran.f90 -mveclibabi=mass -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto > -lmass_simdp8 -lmassv -lmassvp8 > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__': > :(.text+0x114): undefined reference to `_gfortran_st_write' > :(.text+0x12c): undefined reference to > `_gfortran_transfer_character_write' > :(.text+0x140): undefined reference to > `_gfortran_transfer_integer_write' > :(.text+0x154): undefined reference to > `_gfortran_transfer_integer_write' > :(.text+0x168): undefined reference to > `_gfortran_transfer_integer_write' > :(.text+0x174): undefined reference to `_gfortran_st_write_done' > /tmp/cctrpu2h.ltrans0.ltrans.o: In function `main': > :(.text.startup+0x14): undefined reference to `_gfortran_set_args' > :(.text.startup+0x28): undefined reference to > `_gfortran_set_options' > collect2: error: ld returned 1 exit status Those are obviously unrelated and you are doing something wrong, like not appropriately rebuilding your work tree or linking against the wrong libraries.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #4 from Xiong Hu XS Luo --- (In reply to Martin Liška from comment #3) > (In reply to Xiong Hu XS Luo from comment #1) > > Martin's commit 4ee64e30659a9125a47eeea882d8044e690ce334 will cause ICE. > > > > It's a REGRESSION not related to this current issue. > > > > ~/local/gcc_t/bin/gfortran -O3 -mcpu=power9 hellofortran.f90 > > -mveclibabi=mass -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 > > -lmassv -lmassvp8 > > lto1: internal compiler error: bytecode stream: expected tag identifier_node > > instead of LTO_UNKNOWN > > > > It's not fixed even updated to commit > > cf474017fbb8fbb71d69b0ca4b4b34260cfe5ab3 (Mon Jul 29, Fix ICE seen in > > tree-ssa-dce.c for new/delete pair.). > > > > > > commit 4ee64e30659a9125a47eeea882d8044e690ce334 > > Author: marxin > > Date: Thu Jul 25 09:36:38 2019 + > > > > Extend DCE to remove unnecessary new/delete-pairs (PR c++/23383). > > > > 2019-07-25 Martin Liska > > Which should be hopefully fixed by: > https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01761.html Still fail to build after applying your changes, but different from before: ~/workspace/gcc-git/gcc-master_build/gcc/xgcc -B/home/luoxhu/workspace/gcc-git/gcc-master_build/gcc/ -O3 -mcpu=power9 hellofortran.f90 -mveclibabi=mass -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8 /tmp/cctrpu2h.ltrans0.ltrans.o: In function `MAIN__': :(.text+0x114): undefined reference to `_gfortran_st_write' :(.text+0x12c): undefined reference to `_gfortran_transfer_character_write' :(.text+0x140): undefined reference to `_gfortran_transfer_integer_write' :(.text+0x154): undefined reference to `_gfortran_transfer_integer_write' :(.text+0x168): undefined reference to `_gfortran_transfer_integer_write' :(.text+0x174): undefined reference to `_gfortran_st_write_done' /tmp/cctrpu2h.ltrans0.ltrans.o: In function `main': :(.text.startup+0x14): undefined reference to `_gfortran_set_args' :(.text.startup+0x28): undefined reference to `_gfortran_set_options' collect2: error: ld returned 1 exit status
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #3 from Martin Liška --- (In reply to Xiong Hu XS Luo from comment #1) > Martin's commit 4ee64e30659a9125a47eeea882d8044e690ce334 will cause ICE. > > It's a REGRESSION not related to this current issue. > > ~/local/gcc_t/bin/gfortran -O3 -mcpu=power9 hellofortran.f90 > -mveclibabi=mass -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 > -lmassv -lmassvp8 > lto1: internal compiler error: bytecode stream: expected tag identifier_node > instead of LTO_UNKNOWN > > It's not fixed even updated to commit > cf474017fbb8fbb71d69b0ca4b4b34260cfe5ab3 (Mon Jul 29, Fix ICE seen in > tree-ssa-dce.c for new/delete pair.). > > > commit 4ee64e30659a9125a47eeea882d8044e690ce334 > Author: marxin > Date: Thu Jul 25 09:36:38 2019 + > > Extend DCE to remove unnecessary new/delete-pairs (PR c++/23383). > > 2019-07-25 Martin Liska Which should be hopefully fixed by: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01761.html
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Richard Biener changed: What|Removed |Added Keywords|wrong-code |missed-optimization --- Comment #2 from Richard Biener --- Do you have the pre-include of the glibc libmvec "fortran header"? That is, please provide -v output of the compile (which should hopefully expose the specs processing). Also interesting to see is the linker resolution which ultimatively decides here. But I guess that -mveclibabi should disable the pre-including of the libmvec "header". I wonder how it does that for C when you include math.h? ISTR we have set up the vectorizer to prefer -mveclibabi before considering OpenMP SIMD ABI style processing. That should work for fortran as well.
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 --- Comment #1 from Xiong Hu XS Luo --- Martin's commit 4ee64e30659a9125a47eeea882d8044e690ce334 will cause ICE. It's a REGRESSION not related to this current issue. ~/local/gcc_t/bin/gfortran -O3 -mcpu=power9 hellofortran.f90 -mveclibabi=mass -L/opt/mass/8.1.3/Linux_LE/lib/ -lmass -flto -lmass_simdp8 -lmassv -lmassvp8 lto1: internal compiler error: bytecode stream: expected tag identifier_node instead of LTO_UNKNOWN It's not fixed even updated to commit cf474017fbb8fbb71d69b0ca4b4b34260cfe5ab3 (Mon Jul 29, Fix ICE seen in tree-ssa-dce.c for new/delete pair.). commit 4ee64e30659a9125a47eeea882d8044e690ce334 Author: marxin Date: Thu Jul 25 09:36:38 2019 + Extend DCE to remove unnecessary new/delete-pairs (PR c++/23383). 2019-07-25 Martin Liska
[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 Bill Schmidt changed: What|Removed |Added Keywords||lto, wrong-code Target||ppc64*-*-* CC||tkoenig at gcc dot gnu.org Target Milestone|--- |10.0
