[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
--- Comment #14 from zenith432 at users dot sourceforge.net ---
(In reply to H.J. Lu from comment #13)
>
> But the symbol in question won't be USED by lto1 at all.
Ok. I didn't completely check the logic for resolutions in ld.bfd so didn't
understand that it *knows* the symbol won't be used.
If ld knows a symbol in the IR won't be used and wants to trick lto1 into
discarding the symbol - it can do so by setting the resolution to
LDPR_PREEMPTED_REG. lto1 has no way of verifying whether the symbol is defined
outside the IR or not - so will simply respond to this resolution by discarding
the symbol.
There is an example of this in gold in
Pluginobj::get_symbol_resolution_info
> if (static_cast(nsyms) > this->symbols_.size())
>{
> // We never decided to include this object. We mark all symbols as
> // preempted.
> gold_assert(this->symbols_.size() == 0);
> for (int i = 0; i < nsyms; i++)
>syms[i].resolution = LDPR_PREEMPTED_REG;
> return version > 2 ? LDPS_NO_SYMS : LDPS_OK;
>}
I did not completely follow the gold code as to why it may decide not to
include the object, but if gold decides not to include the object after it's
been claimed - this is how it gets all its symbols to be discarded by lto1.
Note that there are cases of multiple defs in the IR of an unused symbol where
the linker still has to stop with an error. For example - if the duplicate def
is a regular kind (non-common, non-weak) and the obj files all appear on the
command-line (not archive) - this is a duplicate symbol error even if the
symbol is unreferenced. The linker can either print the error itself - or
leave multiple prevailing defs for lto1 to print the error :)
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #12 from zenith432 at users dot sourceforge.net --- Fair enough, it's a gold bug in the sense that gold's algorithm for selecting a prevailing def among multiple defs has an error. If an IR symbol has multiple definitions as LDPK_COMMON and a single definition as LDPK_DEF then the one marked as LDPK_DEF should be resolved as LDPR_PREVAILING_DEF_IRNONLY and the other defintions as PREEMPTED_IR. However, the limitation of a single prevailing def is documented... http://gcc.gnu.org/wiki/whopr/driver In the subsection The "All Symbols Read" Event "In the case of a symbol that is defined in more than one IR file, WPA will need to know which definition to use and which definitions to ignore." Logically, it is the linker's job to make this decision, because the prevailing def depends on the order that object files are given on the command line, on whether the object file has to be included in the link (i.e. it's on the command line) - or it's in a library and is optional. And also on whether it's a common def or not. lto1 cannot make this decision by itself. It is not possible to leave multiple prevailing defs for lto1 just because the linker doesn't need the symbol and considers it discardable - because an IR symbol may be referenced from inside the IR by another part needed in the link. In that case lto1 will need to generate the multiply defined symbol, and can't decide which one to use - for example because it doesn't know the order of the object files in the libraries given on the linker command line.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #10 from zenith432 at users dot sourceforge.net --- Followup on what gold does... First, it reads the symbol table from the archive (w/o using the plugin) - and if it doesn't need any of the symbols in an LTO member of the archive - it doesn't call the plugin's claim_file_handler on the member. Second, even if it needs an LTO member from an archive - it first adds all the LTO object's symbols to its own symbol table during the add_symbols callback from the plugin. For each symbol, it remembers which object file it first was seen in and whether that first object file is claimed by a plugin. Later, when get_symbols callback is called from the plugin to get resolutions - it sets LDPR_PREVAILING_DEF_IRONLY for symbols it doesn't need, but only if the symbol was first seen in the same object file. If it was first seen in another object file, it sets the resolution to either LDPR_PREEMPTED_IR or LDPR_PREEMPTED_REG, depending on whether the symbol's first source is claimed by a plugin or not. This algorithm makes sure each IRONLY symbol only gets a single PREVAILING_DEF.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490
--- Comment #9 from zenith432 at users dot sourceforge.net ---
It is worth studying what gold is doing, because it's not just skipping the
object files in the archives.
If you link with
gcc -flto -save-temps -fuse-ld=gold -o x main.o libfoo.a libbar.a
The res file shows resolutions only for main.o.
Now link with
gcc -flto -save-temps -fuse-ld=gold -u bar -o x main.o libfoo.a libbar.a
The res file shows resolutions for main.o and exactly one of libfoo.a or
libbar.a.
Now add definitions as follows
void f1() {} to foo.c
void f2() {} to bar.c
so you can tell them apart.
Now link with
gcc -flto -save-temps -fuse-ld=gold -u f1 -o x main.o libfoo.a libbar.a
gcc -flto -save-temps -fuse-ld=gold -u f2 -o x main.o libfoo.a libbar.a
each time, the resolution file shows gold resolving just one of the .a files
which was requested with the -u.
Now link with
gcc -flto -save-temps -fuse-ld=gold -u f1 -u f2 -o x main.o libfoo.a libbar.a
to link all in.
This does give an error, but it's a gold error for multiple defs, not an lto1
error for multiple prevailing defs. Look at the res file you'll see
resolutions for all three input files, but there is just one prevailing def for
symbol bar - the other instance of bar gets resolution PREEMPTED_IR.
[Bug lto/70955] [6 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 zenith432 at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #29 from zenith432 at users dot sourceforge.net --- verified as working long ago.
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 zenith432 at users dot sourceforge.net changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|MOVED |FIXED --- Comment #6 from zenith432 at users dot sourceforge.net --- This bug is fixed in binutils master. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=94d401b8b88a76b1372ce44e805516756a4f737b
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 --- Comment #5 from zenith432 at users dot sourceforge.net --- This is a bug in ld.bfd. It's setting the resolution for entry symbols to LDPR_PREVAILING_DEF_IRONLY_EXP instead of LDPR_PREVAILING_DEF. gold handles them right. I posted a patch in the sourceware bugzilla linked above at comment 3.
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 zenith432 at users dot sourceforge.net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from zenith432 at users dot sourceforge.net --- Done. https://sourceware.org/bugzilla/show_bug.cgi?id=23309
[Bug lto/86175] LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
With ld 2.30 it seems to work for me with a simple
void foo () {}
int main() { return 0; }
> gcc-8 t.c -flto -O -Wl,-u,foo,--gc-sections -ffunction-sections
--- Comment #2 from zenith432 at users dot sourceforge.net ---
It's the visibility that breaks it.
Try
gcc-8 t.c -flto -O -Wl,-u,foo,--gc-sections -ffunction-sections
-fvisibility=hidden
Here's a full summary of observed behavior
Without '-u foo', foo gets discarded for both LTO, non-LTO build and with any
visibility.
With '-u foo'
On non-LTO build, foo always gets forced in regardless of visibility. The
symbol's visibility is not supposed to play a role in the decision-making of
applying the '-u foo'.
On LTO build
- if foo's visibility is either default or protected, it gets forced in.
- if foo's visibility is either hidden or internal, it gets discarded.
The reason I opened this bug against GCC and not LD - is that LD does not
complain about an undefined foo even if '--require-defined=foo' is used in
place of '-u foo'. LD believes it is force-including foo, but really gets an
empty blob from the LTO plugin for foo.
[Bug lto/86175] New: LTO code generator does not respect ld -u option to force symbol inclusion in the link product
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175 Bug ID: 86175 Summary: LTO code generator does not respect ld -u option to force symbol inclusion in the link product Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: zenith432 at users dot sourceforge.net CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 44288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44288=edit Test case to demonstrate bug Please see test case in attached file that contains Makefile test.c GCC is 8.1.1 ld is from binutils 2.29.1 Compiling with -flto and attempting to force inclusion of a symbol with hidden visibility. The symbol is discarded. make gcc -o test1 -fvisibility=default -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test1 | grep This This string should appear in the executable. gcc -o test2 -flto -fvisibility=default -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test2 | grep This This string should appear in the executable. gcc -o test3 -fvisibility=hidden -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test3 | grep This This string should appear in the executable. gcc -o test4 -flto -fvisibility=hidden -ffunction-sections -Wl,--gc-sections,-u,KeepMe test.c strings test4 | grep This make: [Makefile:18: test4] Error 1 (ignored)
[Bug target/83334] __builtin_ms_va_copy used in function with sysv_abi is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83334 --- Comment #5 from zenith432 at users dot sourceforge.net --- I looked at the source a bit, and I see what's going on. __builtin_ms_va_copy and __builtin_sysv_va_copy are treated both the same as __builtin_va_copy, which is implemented in gcc/builtins.s by expand_builtin_va_copy This function then calls targetm.fn_abi_va_list (cfun->decl) to get the type of va_list associated to the containing function. this leads to ix86_fn_abi_va_list which identifies it as either an ms_va_list_type_node or sysv_va_list_type_node based on the abi of the containing function.
[Bug target/83334] __builtin_ms_va_copy used in function with sysv_abi is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83334
--- Comment #4 from zenith432 at users dot sourceforge.net ---
It's not PR 50818
Here's the source code for sample1
=
#include
#define MS_ABI __attribute__((ms_abi))
int funcc(int c, __builtin_ms_va_list ap)
{
int i, s;
for (s = 0, i = 0; i < c; ++i)
s += __builtin_va_arg(ap, int);
return s;
}
int funcb(int c, __builtin_ms_va_list ap)
{
__builtin_ms_va_list ap2;
int r;
__builtin_ms_va_copy(ap2, ap);
r = funcc(c, ap2);
__builtin_ms_va_end(ap2);
return r;
}
int MS_ABI funca(int c, ...)
{
__builtin_ms_va_list ap;
int r;
__builtin_ms_va_start(ap, c);
r = funcb(c, ap);
__builtin_ms_va_end(ap);
return r;
}
int main(int argc, char** argv)
{
printf("%d\n", funca(3, 1, 2, 3));
return 0;
}
=
funcb is a sysv-abi function that obtains an explicitly typed
__builtin_ms_va_list as a parameter. The code generated for its invocation of
__builtin_ms_va_copy is incorrect. I didn't attach the object code, but can be
easily obtained with objdump -d.
PR 50818 began in 2011 as a bug report because at the time the __builtin_ms_va*
family didn't exist. In code compiled with -mabi=sysv, there was no way to
handle varargs inside a function defined as __attribute__((ms_abi)).
Nowadays, the __builtin_ms_va* family exists, so what remains of
PR 50818 is a feature request that __builtin_va* family behave like the ABI of
the function it is embedded in instead of according to the global -mabi.
This report is about...
- Passing a __builtin_ms_va_list to a sysv_abi function ... works!
- Calling __builtin_var_arg on a __builtin_ms_va_list inside a sysv_abi
function ... works!
- Calling __builtin_ms_va_copy on a __builtin_ms_va_list inside a sysv_abi
function... doesn't work.
Is this a bug? An unimplemented feature? It's your call.
[Bug target/83334] __builtin_ms_va_copy used in function with sysv_abi is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83334 --- Comment #2 from zenith432 at users dot sourceforge.net --- You're misquoting my summary. It does not say sysv ABI varargs function. It says sys ABI function. Check the samples. A __builtin_ms_va_list is constructed (__builtin_ms_va_started) in an ms ABI varargs function, then passed as an argument to a sysv ABI function. sysv ABI functions can already iterate over __builtin_ms_va_lists today with __builtin_va_arg. But using __builtin_ms_va_copy on a __builtin_ms_va_list in a sysv ABI function (that got one passed in as a parameter) emits incorrect code. These features are all non-standard and undocumented, so it is difficult to separate a "bug report" from a "feature request". A __builtin_ms_va_list is a char*, and calling __builtin_ms_va_copy on it is just to assign the pointer to another pointer. It is the same complexity as passing it as an argument. On the other hand, iterating over a __builtin_ms_va_list (with __builtin_va_arg) emits more complicated code, and this can already be done in a sysv ABI function. So it seems like an omission or bug that __builtin_ms_va_copy doesn't work in a sysv ABI function.
[Bug target/83334] New: __builtin_ms_va_copy used in function with sysv_abi is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83334 Bug ID: 83334 Summary: __builtin_ms_va_copy used in function with sysv_abi is broken Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zenith432 at users dot sourceforge.net Target Milestone: --- Created attachment 42818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42818=edit sample1.c and sample2.c in zip file gcc -v === Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) = Attached are sample source files sample1.c, sample2.c. The only difference is that funcb is ms_abi in sample2.c and sysv_abi in sample1.c gcc -o sample1 sample1.c gcc -o sample2 sample2.c ./sample2 6 ./sample1 Segmentation fault (core dumped)
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #10 from zenith432 at users dot sourceforge.net --- (In reply to vries from comment #8) > Created attachment 38453 [details] > tentative patch vries, thank you very much. I verified and looks good. Built GCC 6.1.0 with patch from released sources on ftp.gnu.org. [moved the patch to the right place of course] Built a fairly large UEFI-based project with a good number of ms_va_list. Checked the disassembly manually for 1 instance. Code is right + tested it to run ok in various scenarios I know to use __builtin_va_arg. Bug can be changed to resolved as far as I'm concerned. Not sure whether it has to wait for commit, so leaving it to TPTB.
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
--- Comment #6 from zenith432 at users dot sourceforge.net ---
(In reply to H.J. Lu from comment #5)
> This may be related to PR 50818.
PR 50818 has morphed into a feature request that the canonical
__builtin_va_{list,start,end,copy} builtins behave according to the ABI of the
function they're in. Today they behave according to the '-mabi=' setting on
the command line.
This is bug report that the specialized __builtin_ms_va_{list,start,end,copy}
builtins have stopped working when -flto is used. They worked until gcc 5.3,
both with or without -flto. In gcc 6.1 with -flto, the canonical iterator
__builtin_va_arg ignores them and works on a sysv_va_list. To be precise, it's
__builtin_va_arg in the context of -flto that's broken, not the specialized
builtins. __builtin_va_arg has always been a polymorphic builtin that changes
its behavior based on the type of va_list it's given as an argument. Without
this polymorphic behavior, there's no way to iterate over an ms_va_list.
[Bug target/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 zenith432 at users dot sourceforge.net changed: What|Removed |Added Component|c |target --- Comment #3 from zenith432 at users dot sourceforge.net --- This only happens when compiling with -flto. Attached is a standalone sample (va_main.c + va_test.c) gcc -v COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.1.1 20160427 (Red Hat 6.1.1-1) (GCC) gcc -o prog va_main.c va_test.c ./prog sum == 15 gcc -o prog_flto -flto va_main.c va_test.c ./prog_flto Segmentation fault (core dumped)
[Bug c/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #2 from zenith432 at users dot sourceforge.net --- Created attachment 38417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38417=edit va_test.c
[Bug c/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #1 from zenith432 at users dot sourceforge.net --- Created attachment 38416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38416=edit va_main.c
[Bug c/70955] New: regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Bug ID: 70955 Summary: regression in code generation for __builtin_ms_va_list in GCC 6.1 Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zenith432 at users dot sourceforge.net Target Milestone: --- I've tried on GCC 6.1.0 built for OS X, and GCC 6.1.1 on Fedora 23 supplied by their rawhide. Same behavior. - variadic function with x86-64 ms_abi calling convention. - defines local variable of type __builtin_ms_va_list. - iterates with __builtin_va_arg (note: there is no corresponding __builtin_ms_va_arg). - __builtin_va_arg treats the __builtin_ms_va_list variable as a sysv va_list, and goes berserk. I've anaylzed this by looking at the code generated. Same wrong code generated if __builtin_va_list is used inside an ms_abi function instead of __builtin_ms_va_list. This functionality worked on both GCC 5.3 and GCC 4.9, so this is a regression. I've compared the resulting code generated to GCC 5.3. The code generated on GCC 5.3 is good. As mentioned above, there is no __builtin_ms_va_arg, and never was. The function __builtin_va_arg has previously been used to iterate on all types of __builtin_*_va_list.
