[Bug lto/108389] LTO(plugin) can not find lto-ed symbols

2023-02-18 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108389

--- Comment #4 from BBK  ---
I managed to save the /tmp/*.res file generated by plugin,and there's no such
entry mention strnlen in it.

[Bug lto/108389] LTO(plugin) can not find lto-ed symbols

2023-02-18 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108389

--- Comment #3 from BBK  ---
Also since the libraries are built with fat objects,build the program with
-fno-lto does success.

[Bug lto/108389] LTO(plugin) can not find lto-ed symbols

2023-02-18 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108389

--- Comment #2 from BBK  ---
It truly looks like a plugin problem.
See the output

eebssk1@dEBianKb:~/a$ ~/mingw-gcc/i686-w64-mingw32/bin/i686-w64-mingw32-gcc-nm
*strnlen*
 T _strnlen
eebssk1@dEBianKb:~/a$ ~/mingw-gcc/i686-w64-mingw32/bin/i686-w64-mingw32-nm
*strnlen*
 b .bss
 d .data
 N .debug_abbrev
 N .debug_aranges
 N .debug_info
 N .debug_line
 N .debug_line_str
 r .eh_frame
 r .gnu.lto_.decls.65045144
 r .gnu.lto_.ext_symtab.65045144
 r .gnu.lto_.icf.65045144
 r .gnu.lto_.inline.65045144
 r .gnu.lto_.ipa_modref.65045144
 r .gnu.lto_.ipa_sra.65045144
 r .gnu.lto_.jmpfuncs.65045144
 r .gnu.lto_.lto.65045144
 r .gnu.lto_.opts
 r .gnu.lto_.profile.65045144
 r .gnu.lto_.pureconst.65045144
 r .gnu.lto_.refs.65045144
 r .gnu.lto_strnlen.4.65045144
 r .gnu.lto_.symbol_nodes.65045144
 r .gnu.lto_.symtab.65045144
 r .rdata$zzz
 T _strnlen
 t .text

[Bug ipa/108383] g++ ICE with -O3 and -flto and -fdeclone-ctor-dtor on simple function

2023-02-06 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383

--- Comment #6 from BBK  ---
I will try modify gcc's code to simply return instead of assert error if the
condition does not match to allow the compilation, and then check if the result
binary still woking as expected. This is only solution I came up with in the
mean time since devs are currently not focused on such small bug.

[Bug ipa/108383] g++ ICE with -O3 and -flto and -fdeclone-ctor-dtor on simple function

2023-01-13 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383

--- Comment #4 from eebssk1 at godaftwithebk dot pub ---
The problem occurs at final linking.

x86_64-w64-mingw32-g++  -o src/dxgi/dxgi.dll src/dxgi/dxgi.dll.p/version.o
src/dxgi/dxgi.dll.p/dxgi_adapter.cpp.obj src/dxgi/dxgi.dll.p/dxgi_enums.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_factory.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_format.cpp.obj src/dxgi/dxgi.dll.p/dxgi_main.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_monitor.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_options.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_output.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_surface.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_swapchain.cpp.obj -Wl,--allow-shlib-undefined -Wl,-O1
-shared ../src/dxgi/dxgi.def -Wl,--start-group
-Wl,--out-implib=src/dxgi/dxgi.dll.a -static -static-libgcc -static-libstdc++
-Wl,--file-alignment=4096
-Wl,-O3,--relax,--sort-section=alignment,--sort-common=descending -flto
src/dxvk/libdxvk.a src/util/libutil.a src/spirv/libspirv.a src/wsi/libwsi.a
subprojects/libdisplay-info/libdisplay-info.a src/vulkan/libvkcommon.a -pthread
-lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
-lcomdlg32 -ladvapi32 -Wl,--end-group -freport-bug
lto-wrapper: warning: using serial compilation of 13 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
during GIMPLE pass: alias
../src/dxgi/../util/log/../thread.h: In member function ‘__ct ’:
../src/dxgi/../util/log/../thread.h:110:14: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2494


So uhh I currently have no idea on how to provide a testcase in such case.
Sorry,These compiler thing is not my profession. I just open such ticket as no
cares it before.

[Bug ipa/108383] g++ ICE with -O3 and -flto and -fdeclone-ctor-dtor on simple function

2023-01-13 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383

--- Comment #3 from eebssk1 at godaftwithebk dot pub ---
Exactly same problem with -Os on lto.(Seems reflect the problem in that github
issue)

The project seems only supports mingw target.
I'll get back when have more information.

[Bug lto/108389] LTO(plugin) can not find lto-ed symbols

2023-01-12 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108389

--- Comment #1 from eebssk1 at godaftwithebk dot pub ---
binutils version 2.39

[Bug lto/108389] New: LTO(plugin) can not find lto-ed symbols

2023-01-12 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108389

Bug ID: 108389
   Summary: LTO(plugin) can not find lto-ed symbols
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eebssk1 at godaftwithebk dot pub
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I had compiled mingw32 crt with LTO on (fat objects enabled to maintain
compability).
However when I trying to compile a dll(also with lto),I got undefined reference
at final linking.

like:
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `pthread_once':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../mingw-w64-libraries/winpthreads/src/thread.c:762:
undefined reference to `fprintf'
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `_amsg_exit':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/mingw-w64-crt/../../mingw-w64-crt/crt/ucrtbase_compat.c:106:
undefined reference to `fprintf'
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `rwl_print':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../mingw-w64-libraries/winpthreads/src/rwlock.c:139:
undefined reference to `printf'

from verbose ld:
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)libapi-ms-win-crt-heap-l1-1-0s00025.o
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)libapi-ms-win-crt-heap-l1-1-0s00026.o
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_vfprintf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_vfprintf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_printf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_printf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_fprintf.o:
no new IR symbols to claim

These objects really have lto-ed reference indeed.
lib64_libucrt_extra_a-ucrt_printf.o:
 U __acrt_iob_func
 b .bss
 d .data
 d .data$__imp_printf
 N .debug_abbrev
 N .debug_aranges
 N .debug_frame
 N .debug_info
 N .debug_line
 N .debug_line_str
 r .gnu.lto_.decls.c11a8587d357cea5
 r .gnu.lto_.ext_symtab.c11a8587d357cea5
 r .gnu.lto_.icf.c11a8587d357cea5
 r .gnu.lto___imp_printf.120.c11a8587d357cea5
 r .gnu.lto_.inline.c11a8587d357cea5
 r .gnu.lto_.ipa_modref.c11a8587d357cea5
 r .gnu.lto_.ipa_sra.c11a8587d357cea5
 r .gnu.lto_.jmpfuncs.c11a8587d357cea5
 r .gnu.lto_.lto.c11a8587d357cea5
 r .gnu.lto_.opts
 r .gnu.lto_printf.119.c11a8587d357cea5
 r .gnu.lto_.profile.c11a8587d357cea5
 r .gnu.lto_.pureconst.c11a8587d357cea5
 r .gnu.lto_.refs.c11a8587d357cea5
 r .gnu.lto_.symbol_nodes.c11a8587d357cea5
 r .gnu.lto_.symtab.c11a8587d357cea5
 D __imp_printf
 p .pdata
 T printf
 r .rdata$zzz
 U __stdio_common_vfprintf
 t .text
 r .xdata

If I manually extract these objects and append them at compiler commandline,
then the final linking successed.
It looks like the gcc lto plugin does not want to handle them.

The problem is persist both on linux cross compiling environment and windows
msys2 environemnt.

[Bug c++/108383] g++ ICE with -O3 and -flto on simple function

2023-01-12 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383

--- Comment #1 from eebssk1 at godaftwithebk dot pub ---
It looks like my issue is caused by a extra inconspicuous flag
"-fdeclone-ctor-dtor". The program compiled succefully without it.

I do use this flag on other projects,never have such problem before.

[Bug c++/108383] New: g++ ICE with -O3 and -flto on simple function

2023-01-12 Thread eebssk1 at godaftwithebk dot pub via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383

Bug ID: 108383
   Summary: g++ ICE with -O3 and -flto on simple function
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eebssk1 at godaftwithebk dot pub
  Target Milestone: ---

Getting ICE with O3 when compiling a project.
Using mingw32 cross compiler on linux.
project url: https://github.com/doitsujin/dxvk

x86_64-w64-mingw32-g++  -o src/dxgi/dxgi.dll src/dxgi/dxgi.dll.p/version.o
src/dxgi/dxgi.dll.p/dxgi_adapter.cpp.obj src/dxgi/dxgi.dll.p/dxgi_enums.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_factory.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_format.cpp.obj src/dxgi/dxgi.dll.p/dxgi_main.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_monitor.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_options.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_output.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_surface.cpp.obj
src/dxgi/dxgi.dll.p/dxgi_swapchain.cpp.obj -Wl,--allow-shlib-undefined -Wl,-O1
-shared ../src/dxgi/dxgi.def -Wl,--start-group
-Wl,--out-implib=src/dxgi/dxgi.dll.a -static -static-libgcc -static-libstdc++
-Wl,--file-alignment=4096 src/dxvk/libdxvk.a src/util/libutil.a
src/spirv/libspirv.a src/wsi/libwsi.a
subprojects/libdisplay-info/libdisplay-info.a src/vulkan/libvkcommon.a -pthread
-lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid
-lcomdlg32 -ladvapi32 -Wl,--end-group
lto-wrapper: warning: using serial compilation of 21 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
during GIMPLE pass: alias
../src/dxgi/dxgi_adapter.cpp: In member function
‘RegisterVideoMemoryBudgetChangeNotificationEvent’:
../src/dxgi/dxgi_adapter.cpp:402:61: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2494
  402 |   HRESULT STDMETHODCALLTYPE 
DxgiAdapter::RegisterVideoMemoryBudgetChangeNotificationEvent(
  | ^
0x62d5fd symtab_node::binds_to_current_def_p(symtab_node*)
../../gcc/symtab.cc:2494
0x84ddd7 gimple_call_arg_flags(gcall const*, unsigned int)
../../gcc/gimple.cc:1583
0xce9a84 handle_rhs_call
../../gcc/tree-ssa-structalias.cc:4335
0xcebe1a find_func_aliases_for_call
../../gcc/tree-ssa-structalias.cc:5010
0xcebe1a find_func_aliases
../../gcc/tree-ssa-structalias.cc:5113
0xcee3c6 compute_points_to_sets
../../gcc/tree-ssa-structalias.cc:7536
0xcee3c6 compute_may_aliases()
../../gcc/tree-ssa-structalias.cc:8044
0xa4ff5c execute_function_todo
../../gcc/passes.cc:2057
0xa50c9c do_per_function
../../gcc/passes.cc:1688
0xa50c9c execute_todo
../../gcc/passes.cc:2139
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: x86_64-w64-mingw32-g++ returned 1 exit status
compilation terminated.

and then

../src/dxgi/dxgi_adapter.cpp: In member function
‘RegisterVideoMemoryBudgetChangeNotificationEvent’:
../src/dxgi/dxgi_adapter.cpp:402:71: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2494
  402 |   HRESULT STDMETHODCALLTYPE __attribute__((optimize("no-tree-pta"))) 
DxgiAdapter::RegisterVideoMemoryBudgetChangeNotificationEvent(
  |   ^
0x62d5fd symtab_node::binds_to_current_def_p(symtab_node*)
../../gcc/symtab.cc:2494
0x912baf merge_call_side_effects
../../gcc/ipa-modref.cc:1310
0x913671 analyze_call
../../gcc/ipa-modref.cc:1678
0x913671 analyze_stmt
../../gcc/ipa-modref.cc:1811
0x91a19a analyze
../../gcc/ipa-modref.cc:1900
0x91a19a analyze_function
../../gcc/ipa-modref.cc:3219
0x91c5da execute
../../gcc/ipa-modref.cc:4186

and then

with __attribute__((optimize("no-tree-pta","no-ipa-modref")))
the code unit compiled without ICE.

The optimizations are in O1, however if i simply use
__attribute__((optimize(2))),then the code unit does compile too, which is
really weired.

There's similar(may be same?) issues in here:
https://github.com/msys2/MINGW-packages/issues/11726 , ICE in same gcc code
location (symtab.cc:2494), with different flags though.