[Bug c++/98327] C++ Module ICE on Linux

[euloanty at live dot com via Gcc-bugs]

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

fdlbxtqi  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from fdlbxtqi  ---
module;
#include 
#include 
export module hello;
export inline void greeter (std::string_view name) noexcept
{
  std::cout << "Hello " << name << "!\n";
}

[Bug c++/98327] New: C++ Module ICE on Linux

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 98327
   Summary: C++ Module ICE on Linux
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

cqwrteur@Home-Server:~/w/working$ g++ -o hello hello.cc -std=c++20
-fmodules-ts
hello.cc:4:8: internal compiler error: Segmentation fault
4 | export module hello;
  |^~
0x10ab5cf crash_signal
../../gcc/gcc/toplev.c:327
0x9f8667 has_definition
../../gcc/gcc/cp/module.cc:11361
0xa0a867 depset::hash::make_dependency(tree_node*, depset::entity_kind)
../../gcc/gcc/cp/module.cc:12531
0xa0af44 depset::hash::add_dependency(tree_node*, depset::entity_kind)
../../gcc/gcc/cp/module.cc:12669
0xa11f9a trees_out::decl_node(tree_node*, walk_kind)
../../gcc/gcc/cp/module.cc:8569
0xa12702 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9132
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
0xa164d4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8939
0xa12564 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9137
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
0xa164d4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8939
0xa12564 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9137
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
0xa164d4 trees_out::tree_value(tree_node*)
../../gcc/gcc/cp/module.cc:8939
0xa12564 trees_out::tree_node(tree_node*)
../../gcc/gcc/cp/module.cc:9137
0xa13131 trees_out::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:5990
0xa164d4 trees_out::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7124
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
cqwrteur@Home-Server:~/w/working$

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #9 from fdlbxtqi  ---
(In reply to Nathan Sidwell from comment #6)
> Created attachment 49769 [details]
> potential patch
> 
> Care to give this patch a try?

hello??

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #8 from fdlbxtqi  ---
(In reply to Nathan Sidwell from comment #6)
> Created attachment 49769 [details]
> potential patch
> 
> Care to give this patch a try?

make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/libcc1'
../../gcc-git/c++tools/server.cc: In function 'void crash_signal(int)':
../../gcc-git/c++tools/server.cc:216:32: error: 'strsignal' was not declared in
this scope; did you mean 'strsigno'?
  216 |   internal_error ("signal %s", strsignal (sig));
  |^
  |strsigno
../../gcc-git/c++tools/server.cc:217:1: warning: 'noreturn' function does
return
  217 | }
  | ^
make[2]: *** [Makefile:72: server.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/c++tools'
make[1]: *** [Makefile:10586: all-c++tools] Error 2
make[1]: *** Waiting for unfinished jobs
configure: creating cache ./config.cache
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for x86_64-w64-mingw32-ar... /mingw64/x86_64-w64-mingw32/bin/ar
checking for x86_64-w64-mingw32-lipo... lipo
checking for x86_64-w64-mingw32-nm...
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/nm
checking for x86_64-w64-mingw32-ranlib...
/mingw64/x86_64-w64-mingw32/bin/ranlib
checking for x86_64-w64-mingw32-strip... /mingw64/x86_64-w64-mingw32/bin/strip
checking whether ln -s works... no, using cp -pR
checking for x86_64-w64-mingw32-gcc...
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-includeaccepts -g... yes
checking for
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-includeoption to accept ISO C89... none
needed
checking how to run the C preprocessor...
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include-E
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking size of double... 8
checking size of long double... 16
checking for inttypes.h... yes
checking for stdint.h... yes
checking for stdlib.h... yes
checking for ftw.h... yes
checking for unistd.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for string.h... yes
checking for strings.h... yes
checking for memory.h... yes
checking for sys/auxv.h... no
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking whether decimal floating point is supported... yes
checking whether fixed-point is supported... no
checking whether the compiler is configured for setjmp/longjmp exceptions... no
checking for CET support... no
checking if the linker
(/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/collect-ld)
is GNU ld... yes
checking for thread model used by GCC... mcf
checking whether assembler supports CFI directives... yes
checking for target glibc version... 0.0
checking for __attribute__((visibility("hidden")))... no
checking for 

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #7 from fdlbxtqi  ---
(In reply to Nathan Sidwell from comment #6)
> Created attachment 49769 [details]
> potential patch
> 
> Care to give this patch a try?

I will help you. no problem.

BTW. Welcome to join discord so I can show you details.

https://discord.gg/vMKhB9Q

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #5 from fdlbxtqi  ---
(In reply to Nathan Sidwell from comment #3)
> Hm, I thought there was sufficient #ifing to prevent that ...


BTW. I tried the example you showed on the GCC module webpage on Linux. It
fails to compile. why?

cqwrteur@Home-Server:~/myhome/test_module$ vim hello.cc
cqwrteur@Home-Server:~/myhome/test_module$ vim a.cc
cqwrteur@Home-Server:~/myhome/test_module$ g++ -fmodules-ts hello.cc main.cc
-Ofast -std=c++20 -s
/usr/bin/ld: /tmp/ccQUwe74.o: in function `_GLOBAL__sub_I_main':
main.cc:(.text.startup+0x31): undefined reference to `_ZGIW5helloEv'
collect2: error: ld returned 1 exit status



My MinGW-w64 msys2 build script

Just run
makepkg-mingw

in the msys2 console and the compiler will get built.


https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #4 from fdlbxtqi  ---
(In reply to Nathan Sidwell from comment #3)
> Hm, I thought there was sufficient #ifing to prevent that ...

Try the compiler I build before to guard against this.

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #2 from fdlbxtqi  ---
Here was an older version (GCC11 20201204) that can be used for bootstrapping.
Please, thank you for fixing this issue ASAP.


https://bitbucket.org/ejsvifq_mabmip/mingw-gcc/src/master/

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

fdlbxtqi  changed:

   What|Removed |Added

 Target||x86_64-msys2-mingw-w64,
   ||windows 10
   Host||x86_64-msys2-mingw-w64,
   ||windows 10
 CC||euloanty at live dot com

--- Comment #1 from fdlbxtqi  ---
The assumption of libcody of POSIX apis do not actually exist on windows.
Windows does not represent socket as fd.

There is no O_CLOEXEC on Windows. O_INHERIT can be a replacement.

no sys/mman.h on Windows

[Bug bootstrap/98300] New: GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 98300
   Summary: GCC 11 failed to build on Windows 10. I guess the new
module completely breaks this.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

x86_64-w64-mingw32-g++  -fno-PIE -c  -DIN_GCC_FRONTEND -march=x86-64
-mtune=generic -O2 -pipe -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Icp -I../../gcc-git/gcc
-I../../gcc-git/gcc/cp -I../../gcc-git/gcc/../include
-I../../gcc-git/gcc/../libcpp/include -I../../gcc-git/gcc/../libcody
-I/mingw64/include -I/mingw64/include -I/mingw64/include 
-I../../gcc-git/gcc/../libdecnumber -I../../gcc-git/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc-git/gcc/../libbacktrace -I/mingw64/include
-D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -o cp/name-lookup.o -MT
cp/name-lookup.o -MMD -MP -MF cp/.deps/name-lookup.TPo
../../gcc-git/gcc/cp/name-lookup.c
In file included from ../../gcc-git/gcc/cp/mapper-resolver.cc:27:
../../gcc-git/gcc/cp/../../c++tools/resolver.cc:31:10: fatal error: sys/mman.h:
No such file or directory
   31 | #include 
  |  ^~~~
compilation terminated.
make[2]: *** [Makefile:1127: cp/mapper-resolver.o] Error 1
make[2]: *** Waiting for unfinished jobs
../../gcc-git/gcc/cp/mapper-client.cc: In static member function 'static
module_client* module_client::open_module_client(location_t, const char*, void
(*)(const char*), const char*)':
../../gcc-git/gcc/cp/mapper-client.cc:171:42: error: 'O_CLOEXEC' was not
declared in this scope
  171 |   ? O_RDWR | O_CLOEXEC : O_RDONLY |
O_CLOEXEC;
  |  ^
../../gcc-git/gcc/cp/mapper-client.cc:188:42: error: 'O_CLOEXEC' was not
declared in this scope
  188 |   ? O_RDWR | O_CLOEXEC : O_WRONLY |
O_CLOEXEC;
  |  ^
../../gcc-git/gcc/cp/mapper-client.cc:260:50: error: 'O_CLOEXEC' was not
declared in this scope
  260 | int fd = open (name.c_str (), O_RDONLY | O_CLOEXEC);
  |  ^
make[2]: *** [Makefile:1127: cp/mapper-client.o] Error 1
../../gcc-git/gcc/cp/module.cc: In member function 'void
bytes_out::printf(const char*, ...)':
../../gcc-git/gcc/cp/module.cc:1088:56: warning: function 'void
bytes_out::printf(const char*, ...)' might be a candidate for 'gnu_printf'
format attribute [-Wsuggest-attribute=format]
 1088 |   size_t actual = vsnprintf (ptr, len, format, args) + 1;
  |^
../../gcc-git/gcc/cp/module.cc: In member function 'const char*
elf_in::read(data*, unsigned int, unsigned int)':
../../gcc-git/gcc/cp/module.cc:1659:45: warning: comparison of integer
expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
 1659 |   if (::read (fd, data->buffer, data->size) != length)
  |   ~~^
../../gcc-git/gcc/cp/module.cc: In member function 'unsigned int
elf_out::write(const data&)':
../../gcc-git/gcc/cp/module.cc:2051:47: warning: comparison of integer
expressions of different signedness: 'int' and 'const unsigned int'
[-Wsign-compare]
 2051 |   if (::write (fd, buffer.buffer, buffer.pos) != buffer.pos)
  |   ^
../../gcc-git/gcc/cp/module.cc:2066:40: warning: comparison of integer
expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
 2066 |   if (::write (fd, , padding) != padding)
  |   ~^~
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/gcc'
make[1]: *** [Makefile:4446: all-gcc] Error 2
make[1]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

[Bug c++/98057] New: ICE when build clang

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 98057
   Summary: ICE when build clang
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

|   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
[1031/4271] Building CXX object
lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/Native/PDBFileBuilder.cpp.o
In file included from ../include/llvm/DebugInfo/PDB/Native/HashTable.h:12,
 from ../include/llvm/DebugInfo/PDB/Native/NamedStreamMap.h:16,
 from ../include/llvm/DebugInfo/PDB/Native/PDBFileBuilder.h:15,
 from ../lib/DebugInfo/PDB/Native/PDBFileBuilder.cpp:9:
../include/llvm/ADT/SparseBitVector.h: In member function 'void
llvm::pdb::PDBFileBuilder::commitSrcHeaderBlock(llvm::WritableBinaryStream&,
const llvm::msf::MSFLayout&)':
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h: In member function 'void
llvm::pdb::HashTable::grow(TraitsT&) [with TraitsT =
llvm::pdb::StringTableHashTraits; ValueT = llvm::pdb::SrcHeaderBlockEntry]':
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h: In member function 'llvm::Error
llvm::pdb::PDBFileBuilder::finalizeMsfLayout()':
../include/llvm/ADT/SparseBitVector.h:138:15: warning: array subscript
4294967295 is above array bounds of 'const BitWord [2]' {aka 'const long
unsigned int [2]'} [-Warray-bounds]
  138 |   if (Bits[Idx] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h:138:15: warning: array subscript
4294967295 is above array bounds of 'const BitWord [2]' {aka 'const long
unsigned int [2]'} [-Warray-bounds]
  138 |   if (Bits[Idx] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
[1035/4271] Building CXX object
lib/DebugInfo/PDB/CMakeFiles/LLVMDebugInfoPDB.dir/Native/TpiStream.cpp.o
In file included from ../include/llvm/DebugInfo/PDB/Native/HashTable.h:12,
 from ../include/llvm/DebugInfo/PDB/Native/TpiStream.h:13,
 from ../lib/DebugInfo/PDB/Native/TpiStream.cpp:9:
../include/llvm/ADT/SparseBitVector.h: In member function 'llvm::Error
llvm::pdb::HashTable::load(llvm::BinaryStreamReader&) [with ValueT =
llvm::support::detail::packed_endian_specific_integral]':
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
../include/llvm/ADT/SparseBitVector.h:129:15: warning: array subscript 2 is
above array bounds of 'const BitWord [2]' {aka 'const long unsigned int [2]'}
[-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
../include/llvm/ADT/SparseBitVector.h:54:11: note: while referencing
'llvm::SparseBitVectorElement<128>::Bits'
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
[1084/4271] Building CXX object
lib/ExecutionEngine/RuntimeDyld/CMakeFiles/LLVMRuntimeDyld.dir/RTDyldMemoryManager.cpp.
FAILED:
lib/ExecutionEngine/RuntimeDyld/CMakeFiles/LLVMRuntimeDyld.dir/RTDyldMemoryManager.cpp.o
/usr/local/bin/g++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/ExecutionEngine/RuntimeDyld
-I../lib/ExecutionEngine/RuntimeDyld -Iinclude -I../include -fPIC
-fvisibility-

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

[euloanty at live dot com via Gcc-bugs]

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

fdlbxtqi  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a bug?
> Yes, it prints the opening quote, then
>   while (deref_depth-- > 0)
> pp_star (_name);
> prints some * characters and finally
>   pp_quote (_name);
> prints the closing '

Because the compiler warns about it.

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a bug?
> Yes, it prints the opening quote, then
>   while (deref_depth-- > 0)
> pp_star (_name);
> prints some * characters and finally
>   pp_quote (_name);
> prints the closing '

Shouldn't that be "\'" instead of "'"?

[Bug bootstrap/97622] New: ubsan ' unterminated quote character ''' in format

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97622
   Summary: ubsan '  unterminated quote character ''' in format
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

'%s%s%s. no. it should be \'%s%s%s%s%s%s%s???

  pp_printf (_name, "'%s%s%s%s%s%s%s",
 TYPE_VOLATILE (type2) ? "volatile " : "",
 TYPE_READONLY (type2) ? "const " : "",
 TYPE_RESTRICT (type2) ? "restrict " : "",
 TYPE_ATOMIC (type2) ? "_Atomic " : "",
 TREE_CODE (type2) == RECORD_TYPE
 ? "struct "
 : TREE_CODE (type2) == UNION_TYPE
   ? "union " : "", tname,
 deref_depth == 0 ? "" : " ");

[Bug bootstrap/97550] libgcc ICE on x86_64-linux-gnu compiler hosted on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #2 from fdlbxtqi  ---
  cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o
cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o
cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o
cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o
cp/logic.o cp/mangle.o cp/method.o cp/name-lookup.o cp/optimize.o cp/parser.o
cp/pt.o cp/ptree.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o
cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o incpath.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o
c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o
c-family/c-spellcheck.o i386-c.o glibc-c.o cc1plus-checksum.o libbackend.a
main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a  -liconv
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr -lgmp   -L./../zlib -lz
-lzstd
echo | /gcc_x86_64_build/./gcc/xgcc -B/gcc_x86_64_build/./gcc/ -E -dM - | \
  sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
 -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
  sort -u > tmp-macro_list
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
/bin/sh ../../gcc/gcc/../move-if-change tmp-macro_list macro_list
echo timestamp > s-macro_list

[Bug tree-optimization/97620] -fexec-charset=IBM16804 triggers ICE

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Martin Sebor from comment #2)
> This is almost certainly caused by an incomplete charset, same as in pr82700.
> 
> *** This bug has been marked as a duplicate of bug 82700 ***

Then provide a better error message. Use -fexec-charset=IBM-12712 instead for
example.

Is that possible to detect fexec-charset from macros?

[Bug analyzer/97620] -fexec-charset=IBM16804 triggers ICE

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #1 from fdlbxtqi  ---
Program:

#include

int main()
{
printf("Hello World %d\n",6);
}

[Bug analyzer/97620] New: -fexec-charset=IBM16804 triggers ICE

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97620
   Summary: -fexec-charset=IBM16804 triggers ICE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

gcc -o stdio stdio.c -s -O2 -fexec-charset=IBM16804
during GIMPLE pass: strlen
stdio.c: In function 'main':
stdio.c:7: internal compiler error: converting to execution character set:
Invalid or incomplete multibyte or wide character
0x8f21da c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level,
cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1])
../../gcc/gcc/c-family/c-common.c:6366
0x192798d cpp_diagnostic_at
../../gcc/libcpp/errors.c:42
0x192798d cpp_diagnostic
../../gcc/libcpp/errors.c:75
0x1927a79 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...)
../../gcc/libcpp/errors.c:89
0x1921214 cpp_host_to_exec_charset(cpp_reader*, unsigned int)
../../gcc/libcpp/charset.c:798
0x8f22e3 c_common_to_target_charset(long)
../../gcc/gcc/c-family/c-common.c:6384
0x178f119 init_target_to_host_charmap
../../gcc/gcc/gimple-ssa-sprintf.c:199
0x178f119 handle_printf_call(gimple_stmt_iterator*, range_query*)
../../gcc/gcc/gimple-ssa-sprintf.c:4301
0xfdabfb strlen_check_and_optimize_call
../../gcc/gcc/tree-ssa-strlen.c:5473
0xfdabfb check_and_optimize_stmt
../../gcc/gcc/tree-ssa-strlen.c:5641
0xfdabfb strlen_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-strlen.c:5874
0x1737467 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:309
0xfcfd91 printf_strlen_execute
../../gcc/gcc/tree-ssa-strlen.c:5940
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/97550] New: libgcc ICE on x86_64-linux-gnu compiler hosted on msys2

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97550
   Summary: libgcc ICE on x86_64-linux-gnu compiler hosted on
msys2
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

during RTL pass: expand
../../../gcc/libgcc/libgcc2.c: In function '__mulxc3':
../../../gcc/libgcc/libgcc2.c:1989:10: internal compiler error: Segmentation
fault
 1989 |   if (isinf (a) || isinf (b))
  |  ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See/build-gcc/./gcc/xgcc -B/build-gcc/./gcc/ -B/x86_64-linux/x86_64-linux/bin/
-B/x86_64-linux/x86_64-linux/lib/ -isystem /x86_64-linux/x86_64-linux/include
-isystem /x86_64-linux/x86_64-linux/sys-include-g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include -I../../../gcc/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _clrsbsi2_s.o -MT
_clrsbsi2_s.o -MD -MP -MF _clrsbsi2_s.dep -DSHARED -DL_clrsbsi2 -c
../../../gcc/libgcc/libgcc2.c
 <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [Makefile:507: _mulxc3_s.o] Error 1
make[2]: *** Waiting for unfinished jobs
during RTL pass: expand
../../../gcc/libgcc/libgcc2.c: In function '__divxc3':
../../../gcc/libgcc/libgcc2.c:1950:33: internal compiler error: Segmentation
fault
 1950 | #define COPYSIGNCONCAT2(__builtin_copysign, CEXT)
  | ^
../../../gcc/libgcc/libgcc2.c:1940:25: note: in definition of macro '_CONCAT2'
 1940 | #define _CONCAT2(A,B)   A##B
  | ^
../../../gcc/libgcc/libgcc2.c:1950:25: note: in expansion of macro 'CONCAT2'
 1950 | #define COPYSIGNCONCAT2(__builtin_copysign, CEXT)
  | ^~~
../../../gcc/libgcc/libgcc2.c:2067:15: note: in expansion of macro 'COPYSIGN'
 2067 |   x = COPYSIGN (INFINITY, c) * a;
  |   ^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [Makefile:507: _divxc3_s.o] Error 1
make[2]: Leaving directory '/build-gcc/x86_64-linux/libgcc'
make[1]: *** [Makefile:13415: all-target-libgcc] Error 2
make[1]: Leaving directory '/build-gcc'
make: *** [Makefile:974: all] Error 2

[Bug bootstrap/97499] build dos cross compiler ICE

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #1 from fdlbxtqi  ---
/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/sys-include-g -O2 -O2  -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o fixunstfsi.o -MT fixunstfsi.o -MD
-MP -MF fixunstfsi.dep  -c ../../../gcc/libgcc/soft-fp/fixunstfsi.c
../../../gcc/libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../gcc/libgcc/config/i386/sfp-exceptions.c:71:7: internal compiler error:
Segmentation fault
   71 |   float f = 1.0f, g = 0.0f;
  |   ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed sour/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/sys-include-g -O2 -O2  -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o floatsitf.o -MT floatsitf.o -MD -MP
-MF floatsitf.dep  -c ../../../gcc/libgcc/soft-fp/floatsitf.c
ce if appropriate.
See  for instructions.
/gcc_dos_build/./gcc/xgcc -B/gcc_dos_build/./gcc/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/bin/
-B/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/lib/ -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/include -isystem
/i586-pc-msdosdjgpp/i586-pc-msdosdjgpp/sys-include-g -O2 -O2  -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I. -I../.././gcc
-I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o floatunsitf.o -MT floatunsitf.o -MD
-MP -MF floatunsitf.dep  -c ../../../gcc/libgcc/soft-fp/floatunsitf.c
make[1]: *** [../../../gcc/libgcc/static-object.mk:17: sfp-exceptions.o] Error
1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/gcc_dos_build/i586-pc-msdosdjgpp/libgcc'
make: *** [Makefile:12394: all-target-libgcc] Error 2

[Bug bootstrap/97499] New: build dos cross compiler ICE

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97499
   Summary: build dos cross compiler ICE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

../../../gcc/libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../gcc/libgcc/config/i386/sfp-exceptions.c:71:7: internal compiler error:
Segmentation fault
   71 |   float f = 1.0f, g = 0.0f;
  |   ^
libbacktrace could not find executable to open
Please submit a full bug report,

[Bug target/97481] GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #5 from fdlbxtqi  ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target.  You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu.  Both compilers
> support both word sizes, the only difference is which is the default word
> size.  This may be part of the reason why it failed.
> 
> The attachment doesn't show any ICE.  It is just a config.log file, and I
> don't see anything interesting in there.
> 
> Note that mingw64 builds of a linux toolchain are unlikely to work as glibc
> requires a case sensitive file system.  I'd suggest using WSL2 as something
> more likely to work, but I haven't tried that myself.
> 
> It looks like you have a badly broken compiler build.  You will need to
> figure out why it is broken.  This doesn't seem to be a gcc problem, but
> rather a build problem on your side.


unlvs@DESKTOP-DFHPDC1 MINGW64 /glibc_riscv64_build
$ ../glibc_riscv64/configure --prefix=${PREFIX}/${TARGET} --build=$(gcc
-dumpmachine) --host=${TARGET} --target=${TARGET} --disable-multilib
--disable-werror libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes
--enable-add-ons
configure: loading site script /mingw64/etc/config.site
checking build system type... x86_64-w64-mingw32
checking host system type... riscv64-unknown-linux-gnu
checking for riscv64-linux-gcc... riscv64-linux-gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether riscv64-linux-gcc accepts -g... yes
checking for gcc... gcc
checking for riscv64-linux-readelf... riscv64-linux-readelf
checking for riscv64-linux-g++... riscv64-linux-g++
checking whether we are using the GNU C++ compiler... yes
checking whether riscv64-linux-g++ accepts -g... yes
checking whether riscv64-linux-g++ can link programs... no
checking for sysdeps preconfigure fragments... aarch64 alpha arc arm csky hppa
i386 m68k microblaze checking for grep that handles long lines and -e...
/usr/bin/grep
checking for egrep... /usr/bin/grep -E
mips nios2 powerpc riscv : internal compiler error: Segmentation
fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Unable to determine XLEN

unlvs@DESKTOP-DFHPDC1 MINGW64 /glibc_riscv64_build

I have tried riscv64. same issues.

[Bug target/97481] GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #4 from fdlbxtqi  ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target.  You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu.  Both compilers
> support both word sizes, the only difference is which is the default word
> size.  This may be part of the reason why it failed.
> 
> The attachment doesn't show any ICE.  It is just a config.log file, and I
> don't see anything interesting in there.
> 
> Note that mingw64 builds of a linux toolchain are unlikely to work as glibc
> requires a case sensitive file system.  I'd suggest using WSL2 as something
> more likely to work, but I haven't tried that myself.
> 
> It looks like you have a badly broken compiler build.  You will need to
> figure out why it is broken.  This doesn't seem to be a gcc problem, but
> rather a build problem on your side.

Maybe I should try riscv64-linux-gnu. Thank you

[Bug target/97481] GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Jim Wilson from comment #2)
> riscv-unknown-linux-gnu is not a supported target.  You must use either
> riscv32-unknown-linux-gnu or riscv64-unknwon-linux-gnu.  Both compilers
> support both word sizes, the only difference is which is the default word
> size.  This may be part of the reason why it failed.
> 
> The attachment doesn't show any ICE.  It is just a config.log file, and I
> don't see anything interesting in there.
> 
> Note that mingw64 builds of a linux toolchain are unlikely to work as glibc
> requires a case sensitive file system.  I'd suggest using WSL2 as something
> more likely to work, but I haven't tried that myself.
> 
> It looks like you have a badly broken compiler build.  You will need to
> figure out why it is broken.  This doesn't seem to be a gcc problem, but
> rather a build problem on your side.

I have successfully built that by fixing problems by myself for both
x86_64-linux-gnu and aarch64-linux-gnu. While on riscv, it fails at the
configure for glibc since the compiler encounters ICE.

Here is the proof
https://gcc.gnu.org/pipermail/libstdc++/2020-October/051219.html
https://github.com/riscv/riscv-gnu-toolchain/issues/523#issuecomment-711457612

And this is my detailed building process.

https://github.com/expnkx/GCC-cross-compilation-scripts/blob/master/windows%20hosted/aarch64-linux-gnu.txt

[Bug bootstrap/97481] GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #1 from fdlbxtqi  ---
Created attachment 49395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49395=edit
riscv ICE

[Bug bootstrap/97481] New: GCC ice when build with RISCV on msys2

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97481
   Summary: GCC ice when build with RISCV on msys2
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

unlvs@DESKTOP-DFHPDC1 MINGW64 /glibc_riscv_build
$ ../glibc_riscv/configure --prefix=${PREFIX}/${TARGET} --build=$(gcc
-dumpmachine) --host=${TARGET} --target=${TARGET} --disable-werror
libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes --enable-add-ons
--disable-multilib
configure: loading site script /mingw64/etc/config.site
checking build system type... x86_64-w64-mingw32
checking host system type... riscv-unknown-linux-gnu
checking for riscv-linux-gcc... riscv-linux-gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether riscv-linux-gcc accepts -g... yes
checking for gcc... gcc
checking for riscv-linux-readelf... riscv-linux-readelf
checking for riscv-linux-g++... riscv-linux-g++
checking whether we are using the GNU C++ compiler... yes
checking whether riscv-linux-g++ accepts -g... yes
checking whether riscv-linux-g++ can link programs... no
checking for sysdeps preconfigure fragments... aarch64 alpha arc arm csky hppa
i386 m68k microblaze checking for grep that handles long lines and -e...
/usr/bin/grep
checking for egrep... /usr/bin/grep -E
mips nios2 powerpc riscv : internal compiler error: Segmentation
fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
: internal compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Unable to determine XLEN

[Bug sanitizer/97478] New: Cross Build from windows to linux. It looks like the sys/timeb.h header file does not exist in latest glibc any more

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97478
   Summary: Cross Build from windows to linux. It looks like the
sys/timeb.h header file does not exist in latest glibc
any more
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

libtool: compile:  /build-gcc/./gcc/xgcc -shared-libgcc -B/build-gcc/./gcc
-nostdinc++ -L/build-gcc/x86_64-linux/libstdc++-v3/src
-L/build-gcc/x86_64-linux/libstdc++-v3/src/.libs
-L/build-gcc/x86_64-linux/libstdc++-v3/libsupc++/.libs
-Bd:/msys64/x86_64-linux/x86_64-linux/bin/
-Bd:/msys64/x86_64-linux/x86_64-linux/lib/ -isystem
d:/msys64/x86_64-linux/x86_64-linux/include -isystem
d:/msys64/x86_64-linux/x86_64-linux/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../gcc/libsanitizer/sanitizer_common -I.. -I
../../../../gcc/libsanitizer/include -I ../../../../gcc/libsanitizer -isystem
../../../../gcc/libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-linux
-I../../../../gcc/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++14
-fcf-protection -mshstk -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
../../../../gcc/libsanitizer/../libbacktrace -I ../libbacktrace -I
../../../../gcc/libsanitizer/../include -include
../../../../gcc/libsanitizer/libbacktrace/backtrace-rename.h -g -O2
-D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF
.deps/sanitizer_platform_limits_posix.Tpo -c
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
 -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o
d:\msys64\gcc\libsanitizer\sanitizer_common\sanitizer_platform_limits_posix.cpp:63:10:
fatal error: sys/timeb.h: No such file or directory
   63 | #include 
  |  ^
compilation terminated.
make[4]: *** [Makefile:614: sanitizer_platform_limits_posix.lo] Error 1
make[4]: Leaving directory
'/build-gcc/x86_64-linux/libsanitizer/sanitizer_common'
make[3]: *** [Makefile:528: all-recursive] Error 1
make[3]: Leaving directory '/build-gcc/x86_64-linux/libsanitizer'
make[2]: *** [Makefile:415: all] Error 2
make[2]: Leaving directory '/build-gcc/x86_64-linux/libsanitizer'
make[1]: *** [Makefile:11865: all-target-libsanitizer] Error 2
make[1]: *** Waiting for unfinished jobs
make[2]: Entering directory '/build-gcc/x86_64-linux/libitm'
make  all-recursive
make[3]: Entering directory '/build-gcc/x86_64-linux/libitm'
Making all in testsuite
make[4]: Entering directory '/build-gcc/x86_64-linux/libitm/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/build-gcc/x86_64-linux/libitm/testsuite'
make[4]: Entering directory '/build-gcc/x86_64-linux/libitm'
true  DO=all multi-do # make
make[4]: Leaving directory '/build-gcc/x86_64-linux/libitm'
make[3]: Leaving directory '/build-gcc/x86_64-linux/libitm'
make[2]: Leaving directory '/build-gcc/x86_64-linux/libitm'
make[1]: Leaving directory '/build-gcc'
make: *** [Makefile:974: all] Error 2


https://github.com/bminor/glibc/blob/0f09154c64005e78b61484ae87b5ea2028051ea0/NEWS

[Bug libstdc++/97465] cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Jonathan Wakely from comment #2)
> e.g. what kind of cross build? We're not psychic.

I try to build x86_64-linux-gnu to x86_64-linux-gnu lol since I do not want vtv
to ruin my ABIs.

However, after I disabled vtv, the build is successful without any problems.
The new toolchain works just fine.

[Bug libstdc++/97465] New: cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97465
   Summary: cross build gcc with vtv enabled failed. Cannot find
out headers in glibc why?
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

./../libstdc++-v3/include/x86_64-cross-linux/bits/os_defines.h:39:10: fatal
error: features.h: No such file or directory
   39 | #include 
  |  ^~~~
compilation terminated.
Makefile:604: recipe for target 'vtv_malloc.lo' failed
make[4]: *** [vtv_malloc.lo] Error 1
mv -f .deps/rwlock.Tpo .deps/rwlock.Plo
libtool: compile:  /home/cqwrteur/gcc_build/./gcc/xgcc
-B/home/cqwrteur/gcc_build/./gcc/ "-DPACKAGE_NAME=\"GNU Vtable Verification
Runtime Library\"" -DPACKAGE_TARNAME=\"libvtv\" -DPACKAGE_VERSION=\"1.0\"
"-DPACKAGE_STRING=\"GNU Vtable Verification Runtime Library 1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\;
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1
-D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1
-DPACKAGE=\"libvtv\" -DVERSION=\"1.0\" -DHAVE_SECURE_GETENV=1
-DHAVE___FORTIFY_FAIL=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
-DHAVE__OBSTACK_BEGIN=1 -I. -I../../../gcc/libvtv
-I../../../gcc/libvtv/../include -D_GNU_SOURCE -Wall -Wextra -fno-exceptions
-fcf-protection -mshstk -I./../libstdc++-v3/include
-I./../libstdc++-v3/include/x86_64-cross-linux
-I../../../gcc/libvtv/../libstdc++-v3/libsupc++
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -g -O2 -D_GNU_SOURCE -MT
vtv_utils.lo -MD -MP -MF .deps/vtv_utils.Tpo -c
../../../gcc/libvtv/vtv_utils.cc  -fPIC -DPIC -o .libs/vtv_utils.o
mv -f .deps/aatree.Tpo .deps/aatree.Plo
../../../gcc/libvtv/vtv_utils.cc:28:10: fatal error: sys/types.h: No such file
or directory
   28 | #include 
  |  ^
compilation terminated.

[Bug target/97437] builtins subcarry and addcarry still not generate the right code. Not get optimized to immediate value

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #4 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> I don't see anything undesirable on that.  The 0 aka %rax is used in 7
> different instructions later on besides the move, so either we just clear
> %ecx (can't use xorl for that as the flags register needs to be live), or
> clear %eax and copy to %ecx (3 bytes more), but then gain 7 bytes back
> because we don't really use an immediate form.

Hello Jakub.

std::uint64_t a{};//must assign as 0 or it is UB.
sub_borrow(borrow,a,a,a);

sbbq %any_new_rigster,%any_new_rigster

means
std::uint64_t a;
if(borrow)
a=std::numeric_limits::max();
else
a=0;

but faster, use less instructions and without any branch (to prevent side
channel attack)

And all those 

sub_borrow(borrow,f[2],zero,f[3]);

So, you do not need to use %rax register for the calculations at all. %rax
would just be used for RVO.

clang does not do the right thing either if I do not write

constexpr unsigned_type zero{};

to tell compiler it is zero, it does not know that either.

I think because _addcarry_, _subborrow_ was not frequently used in GCC, it
lacks many optimizations points here. That is probably why GMP, OpenSSL etc,
they frequently rewrote assemblies for doing the stuff since the compiler does
not guarantee the instructions that got generated as optimal. I know this is
probably the cost of any abstraction, particularly here I combine the usage of
OOP, concepts, templates, if constexpr, constant_evaluated(), RVO and intrinsic
together. Probably interfere with the compiler optimizations. it does not
guarantee to generate the assembly that is optimal compared to assembly.

[Bug rtl-optimization/97437] New: builtins subcarry and addcarry still not generate the right code. Not get optimized to immediate value

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97437
   Summary: builtins subcarry and addcarry still not generate the
right code. Not get optimized to immediate value
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

#include
#include
#if defined(_MSC_VER)
#include
#elif defined(__x86_64__) || defined(__i386__)
#include
#endif

struct field_number
{
using value_type =
std::conditional_t=8,std::uint64_t,std::uint32_t>;
value_type content[32/sizeof(value_type)];
inline constexpr value_type const& operator[](std::size_t pos) const
noexcept
{
return content[pos];
}
inline constexpr value_type& operator[](std::size_t pos) noexcept
{
return content[pos];
}
};

namespace intrinsics
{
template
#if __cpp_lib_concepts >= 202002L
requires (std::unsigned_integral)
#endif
inline constexpr bool sub_borrow(bool borrow,T a,T b,T& out) noexcept
{
#if defined(_MSC_VER) || defined(__x86_64__) || defined(__i386__)
#if __cpp_lib_is_constant_evaluated >= 201811L
if(std::is_constant_evaluated())
return (out=a-b-borrow)>=a;
else
#endif
{
if constexpr(sizeof(T)==8)
#if defined(__x86_64__)
return _subborrow_u64(borrow,a,b,
#if !defined(__INTEL_COMPILER ) &&(defined(__GNUC__) || defined(__clang__))
reinterpret_cast());
#else
);
#endif
#else
return (out=a-b-borrow)>=a;
#endif

if constexpr(sizeof(T)==4)
return
_subborrow_u32(borrow,a,b,reinterpret_cast());
else if constexpr(sizeof(T)==2)
return
_subborrow_u16(borrow,a,b,reinterpret_cast());
else if constexpr(sizeof(T)==1)
return
_subborrow_u8(borrow,a,b,reinterpret_cast());
}
#else
return (out=a-b-borrow)>=a;
#endif
}

}


field_number operator-(field_number const& x,field_number const& y) noexcept
{
using namespace intrinsics;
using unsigned_type = field_number::value_type;
constexpr unsigned_type zero{};
field_number f;
bool borrow{sub_borrow(false,x[0],y[0],f[0])};
borrow=sub_borrow(borrow,x[1],y[1],f[1]);
borrow=sub_borrow(borrow,x[2],y[2],f[2]);
borrow=sub_borrow(borrow,x[3],y[3],f[3]);
unsigned_type v{};
sub_borrow(borrow,v,v,v);
v&=static_cast(38);
borrow=sub_borrow(false,f[0],v,f[0]);
borrow=sub_borrow(borrow,f[1],zero,f[1]);
borrow=sub_borrow(borrow,f[2],zero,f[2]);
borrow=sub_borrow(borrow,f[3],zero,f[3]);
sub_borrow(borrow,v,v,v);
v&=static_cast(38);
borrow=sub_borrow(false,f[0],v,f[0]);
borrow=sub_borrow(borrow,f[1],zero,f[1]);
borrow=sub_borrow(borrow,f[2],zero,f[2]);
borrow=sub_borrow(borrow,f[2],zero,f[3]);
return f;
}

https://godbolt.org/z/xM8xef

operator-(field_number const&, field_number const&):
movq(%rsi), %r9
subq(%rdx), %r9
movq%rdi, %r8
movq%rdx, %rax
movq%r9, (%rdi)
movq8(%rsi), %rdi
sbbq8(%rdx), %rdi
movq%rdi, 8(%r8)
movq16(%rsi), %rdx
sbbq16(%rax), %rdx
movq%rdx, 16(%r8)
movq24(%rax), %rax
movq24(%rsi), %rsi
sbbq%rax, %rsi

//Here is an output dependency. No need movl 0 to %eax.
movl$0, %eax
movq%rax, %rcx
sbbq%rax, %rcx
andl$38, %ecx
subq%rcx, %r9
sbbq%rax, %rdi// why sbbq %rax,%rdi instead of sbbq 0 %rdi 
//The %rax register should not get allocated or used in GCC
sbbq%rax, %rdx
sbbq%rax, %rsi
sbbq%rcx, %rcx
andl$38, %ecx
subq%rcx, %r9
sbbq%rax, %rdi
movq%r9, (%r8)
sbbq%rax, %rdx
movq%rdi, 8(%r8)
movq%rdx, 16(%r8)
sbbq%rax, %rdx
movq%r8, %rax
movq%rdx, 24(%r8)
ret


The assembly GCC generated is still worse than clang. although clang does not
generate the optimal one either.

The subborrow instruction in GCC does not get optimized as immediate value

The "correct" assembly it generates should be like what clang generates (you
can use different registers no problem) minus that xorl%ecx, %ecx clean up
instruction.


operator-(field_number const&, field_number const&):#
@operator-(field_number const&, field_number 

[Bug target/97387] we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #14 from fdlbxtqi  ---
(In reply to fdlbxtqi from comment #13)
> https://godbolt.org/z/fqGrz1
> 
> After this patch, the assembly generated is much better now. However, it
> still contains many optimization problems.
> 
> The problem is the code like this.
> 
> Let's just walk through the assembly and see the problems here.
> 
> field_number operator-(field_number const& x,field_number const& y) noexcept
> {
>   using namespace intrinsics;
>   using unsigned_type = field_number::value_type;
>   constexpr unsigned_type zero{};
> field_number f;
> bool borrow{sub_borrow(false,x[0],y[0],f[0])};
> borrow=sub_borrow(borrow,x[1],y[1],f[1]);
> borrow=sub_borrow(borrow,x[2],y[2],f[2]);
> borrow=sub_borrow(borrow,x[3],y[3],f[3]);
> unsigned_type v{};
> sub_borrow(borrow,v,v,v);
> v&=static_cast(38);
> borrow=sub_borrow(false,f[0],v,f[0]);
> borrow=sub_borrow(borrow,f[1],zero,f[1]);
> borrow=sub_borrow(borrow,f[2],zero,f[2]);
> borrow=sub_borrow(borrow,f[3],zero,f[3]);
> sub_borrow(borrow,v,v,v);
> v&=static_cast(38);
> borrow=sub_borrow(false,f[0],v,f[0]);
> borrow=sub_borrow(borrow,f[1],zero,f[1]);
> borrow=sub_borrow(borrow,f[2],zero,f[2]);
> borrow=sub_borrow(borrow,f[2],zero,f[3]);
> return f;
> }
> 
> 
> _ZN7fast_io10curve25519miERKNS0_12field_numberES3_:
> .LFB5431:
>   .cfi_startproc
>   .cfi_personality 0x3,__gxx_personality_v0
>   movq%rsi, %rcx
>   movq%rdx, %rax
>   movq%rdi, %r8
>   movq(%rsi), %rdi
>   movq24(%rcx), %r9
>   subq(%rdx), %rdi
>   movq8(%rsi), %rsi
>   sbbq8(%rdx), %rsi
>   movq16(%rcx), %rdx
>   sbbq16(%rax), %rdx
>   movq24(%rax), %rax
>   sbbq%rax, %r9
> 
>   movl$0, %eax
>   movq%rax, %rcx
> //The value of sbbq to itself does not matter I should be sbbq %r9 %r9 and
> you are done.
> 
>   sbbq%rax, %rcx
>   andl$38, %ecx
>   subq%rcx, %rdi
> 
> //The 2nd problems are these %rax stuffs. The should be just imm 0
> // sbbq $0,%rsi
>   sbbq%rax, %rsi
>   sbbq%rax, %rdx
>   sbbq%rax, %r9
>   sbbq%rcx, %rcx
>   andl$38, %ecx
>   subq%rcx, %rdi
>   sbbq%rax, %rsi
>   movq%rdi, -40(%rsp)
>   sbbq%rax, %rdx
>   movq%rsi, -32(%rsp)
>   movdqa  -40(%rsp), %xmm0
>   movq%rdx, -24(%rsp)
>   sbbq%rax, %rdx
>   movq%r8, %rax
>   movq%rdx, -16(%rsp)
>   movdqa  -24(%rsp), %xmm1
>   movups  %xmm0, (%r8)
>   movups  %xmm1, 16(%r8)
>   ret
> 
> https://godbolt.org/z/nKPWx3

I think the optimal instruction number should be 26.

[Bug target/97387] we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #13 from fdlbxtqi  ---
https://godbolt.org/z/fqGrz1

After this patch, the assembly generated is much better now. However, it still
contains many optimization problems.

The problem is the code like this.

Let's just walk through the assembly and see the problems here.

field_number operator-(field_number const& x,field_number const& y) noexcept
{
using namespace intrinsics;
using unsigned_type = field_number::value_type;
constexpr unsigned_type zero{};
field_number f;
bool borrow{sub_borrow(false,x[0],y[0],f[0])};
borrow=sub_borrow(borrow,x[1],y[1],f[1]);
borrow=sub_borrow(borrow,x[2],y[2],f[2]);
borrow=sub_borrow(borrow,x[3],y[3],f[3]);
unsigned_type v{};
sub_borrow(borrow,v,v,v);
v&=static_cast(38);
borrow=sub_borrow(false,f[0],v,f[0]);
borrow=sub_borrow(borrow,f[1],zero,f[1]);
borrow=sub_borrow(borrow,f[2],zero,f[2]);
borrow=sub_borrow(borrow,f[3],zero,f[3]);
sub_borrow(borrow,v,v,v);
v&=static_cast(38);
borrow=sub_borrow(false,f[0],v,f[0]);
borrow=sub_borrow(borrow,f[1],zero,f[1]);
borrow=sub_borrow(borrow,f[2],zero,f[2]);
borrow=sub_borrow(borrow,f[2],zero,f[3]);
return f;
}


_ZN7fast_io10curve25519miERKNS0_12field_numberES3_:
.LFB5431:
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
movq%rsi, %rcx
movq%rdx, %rax
movq%rdi, %r8
movq(%rsi), %rdi
movq24(%rcx), %r9
subq(%rdx), %rdi
movq8(%rsi), %rsi
sbbq8(%rdx), %rsi
movq16(%rcx), %rdx
sbbq16(%rax), %rdx
movq24(%rax), %rax
sbbq%rax, %r9

movl$0, %eax
movq%rax, %rcx
//The value of sbbq to itself does not matter I should be sbbq %r9 %r9 and you
are done.

sbbq%rax, %rcx
andl$38, %ecx
subq%rcx, %rdi

//The 2nd problems are these %rax stuffs. The should be just imm 0
// sbbq $0,%rsi
sbbq%rax, %rsi
sbbq%rax, %rdx
sbbq%rax, %r9
sbbq%rcx, %rcx
andl$38, %ecx
subq%rcx, %rdi
sbbq%rax, %rsi
movq%rdi, -40(%rsp)
sbbq%rax, %rdx
movq%rsi, -32(%rsp)
movdqa  -40(%rsp), %xmm0
movq%rdx, -24(%rsp)
sbbq%rax, %rdx
movq%r8, %rax
movq%rdx, -16(%rsp)
movdqa  -24(%rsp), %xmm1
movups  %xmm0, (%r8)
movups  %xmm1, 16(%r8)
ret

https://godbolt.org/z/nKPWx3

[Bug target/97387] we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #12 from fdlbxtqi  ---
(In reply to CVS Commits from comment #11)
> The master branch has been updated by Jakub Jelinek :
> 
> https://gcc.gnu.org/g:06bec55e80d98419121f3998d98d969990a75b0b
> 
> commit r11-3882-g06bec55e80d98419121f3998d98d969990a75b0b
> Author: Jakub Jelinek 
> Date:   Wed Oct 14 17:14:47 2020 +0200
> 
> i386: Improve chaining of _{addcarry,subborrow}_u{32,64} [PR97387]
> 
> These builtins have two known issues and this patch fixes one of them.
> 
> One issue is that the builtins effectively return two results and
> they make the destination addressable until expansion, which means
> a stack slot is allocated for them and e.g. with -fstack-protector*
> DSE isn't able to optimize that away.  I think for that we want to use
> the technique of returning complex value; the patch doesn't handle that
> though.  See PR93990 for that.
> 
> The other problem is optimization of successive uses of the builtin
> e.g. for arbitrary precision arithmetic additions/subtractions.
> As shown PR93990, combine is able to optimize the case when the first
> argument to these builtins is 0 (the first instance when several are used
> together), and also the last one if the last one ignores its result (i.e.
> the carry/borrow is dead and thrown away in that case).
> As shown in this PR, combiner refuses to optimize the rest, where it
> sees:
> (insn 10 9 11 2 (set (reg:QI 88 [ _31 ])
> (ltu:QI (reg:CCC 17 flags)
> (const_int 0 [0]))) "include/adxintrin.h":69:10 785
> {*setcc_qi}
>  (expr_list:REG_DEAD (reg:CCC 17 flags)
> (nil)))
> - set pseudo 88 to CF from flags, then some uninteresting insns that
> don't modify flags, and finally:
> (insn 17 15 18 2 (parallel [
> (set (reg:CCC 17 flags)
> (compare:CCC (plus:QI (reg:QI 88 [ _31 ])
> (const_int -1 [0x]))
> (reg:QI 88 [ _31 ])))
> (clobber (scratch:QI))
> ]) "include/adxintrin.h":69:10 350 {*addqi3_cconly_overflow_1}
>  (expr_list:REG_DEAD (reg:QI 88 [ _31 ])
> (nil)))
> to set CF in flags back to what we saved earlier.  The combiner just
> punts
> trying to combine the 10, 17 and following addcarrydi (etc.) instruction,
> because
>   if (i1 && !can_combine_p (i1, i3, i0, NULL, i2, NULL, , ))
> {
>   if (dump_file && (dump_flags & TDF_DETAILS))
> fprintf (dump_file, "Can't combine i1 into i3\n");
>   undo_all ();
>   return 0;
> }
> fails - the 3 insns aren't all adjacent and
>   || (! all_adjacent
>   && (((!MEM_P (src)
> || ! find_reg_note (insn, REG_EQUIV, src))
>&& modified_between_p (src, insn, i3))
> src (flags hard register) is modified between the first and third insn -
> in
> the second insn.
> 
> The following patch optimizes this by optimizing just the two insns,
> 10 and 17 above, i.e. save CF into pseudo, set CF from that pseudo, into
> a nop.  The new define_insn_and_split matches how combine simplifies
> those
> two together (except without the ix86_cc_mode change it was choosing
> CCmode
> for the destination instead of CCCmode, so had to change that function
> too,
> and also adjust costs so that combiner understand it is beneficial).
> 
> With this, all the testcases are optimized, so that the:
> setc%dl
> ...
> addb$-1, %dl
> insns in between the ad[dc][lq] or s[ub]b[lq] instructions are all
> optimized
> away (sure, if something would clobber flags in between they wouldn't,
> but
> there is nothing that can be done about that).
> 
> 2020-10-14  Jakub Jelinek  
> 
> PR target/97387
> * config/i386/i386.md (CC_CCC): New mode iterator.
> (*setcc_qi_addqi3_cconly_overflow_1_): New
> define_insn_and_split.
> * config/i386/i386.c (ix86_cc_mode): Return CCCmode
> for *setcc_qi_addqi3_cconly_overflow_1_ pattern operands.
> (ix86_rtx_costs): Return true and *total = 0;
> for *setcc_qi_addqi3_cconly_overflow_1_ pattern.  Use op0
> and
> op1 temporaries to simplify COMPARE checks.
> 
> * gcc.target/i386/pr97387-1.c: New test.
> * gcc.target/i386/pr97387-2.c: New test.

awesome

[Bug bootstrap/97409] riscv cross toolchain build fails

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #4 from fdlbxtqi  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to fdlbxtqi from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Sounds like the binutils does not have the needed support for (32bit)
> > > multilib.
> > 
> > so I should build binutils with --disable-multilib?
> 
> No, what I am saying is you don't have a new enough binutils.

I am using the latest binutils. 

#define BFD_VERSION_DATE 20201013

/* The date below is automatically updated every day by a bot.  During
   development, we include the date in the tools' version strings
   (visible in 'ld -v' etc.) because people build binutils from a
   variety of sources - git, tarballs, distro sources - and we want
   something that can easily identify the source they used when they
   report bugs.  The bfd version plus date is usually good enough for
   that purpose.

   During development, this date ends up in libbfd and libopcodes
   sonames because people naturally expect shared libraries with the
   same soname to have compatible ABIs.  We could bump the bfd version
   on every ABI change, but that's just another thing contributors and
   maintainers would need to remember.  Instead, it's much easier for
   all if the soname contains the date.  This is not perfect but is
   good enough.

   In releases, the date is not included in either version strings or
   sonames.  */
#define BFD_VERSION_DATE 20201013
#define BFD_VERSION @bfd_version@
#define BFD_VERSION_STRING  @bfd_version_package@ @bfd_version_string@
#define REPORT_BUGS_TO @report_bugs_to@
~  
~

[Bug bootstrap/97409] riscv cross toolchain build fails

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Andrew Pinski from comment #1)
> Sounds like the binutils does not have the needed support for (32bit)
> multilib.

so I should build binutils with --disable-multilib?

[Bug bootstrap/97409] New: riscv cross toolchain build fails

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97409
   Summary: riscv cross toolchain build fails
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

rsion-script=libgcc.map -o lib32/ilp32/libgcc_s.so.1.tmp -g -O2 -march=rv32imac
-mabi=ilp32 -B./ _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o
_ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o
_absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o
_mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o
_clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o
_mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunsxfsi_s.o _fixxfdi_s.o _fixunsxfdi_s.o _floatdixf_s.o _floatundixf_s.o
_divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o
_udivmoddi4_s.o _udiv_w_sdiv_s.o adddf3_s.o divdf3_s.o eqdf2_s.o gedf2_s.o
ledf2_s.o muldf3_s.o negdf2_s.o subdf3_s.o unorddf2_s.o fixdfsi_s.o
fixunsdfsi_s.o floatsidf_s.o floatunsidf_s.o fixdfdi_s.o fixunsdfdi_s.o
floatdidf_s.o floatundidf_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o
letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o addsf3_s.o divsf3_s.o eqsf2_s.o gesf2_s.o
lesf2_s.o mulsf3_s.o negsf2_s.o subsf3_s.o unordsf2_s.o fixsfsi_s.o
fixunssfsi_s.o floatsisf_s.o floatunsisf_s.o fixsfdi_s.o fixunssfdi_s.o
floatdisf_s.o floatundisf_s.o extendsfdf2_s.o extendsftf2_s.o extenddftf2_s.o
truncdfsf2_s.o trunctfsf2_s.o trunctfdf2_s.o save-restore_s.o muldi3_s.o
multi3_s.o div_s.o atomic_s.o enable-execute-stack_s.o unwind-dw2_s.o
unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc &&
rm -f lib32/ilp32/libgcc_s.so && if [ -f lib32/ilp32/libgcc_s.so.1 ]; then mv
-f lib32/ilp32/libgcc_s.so.1 lib32/ilp32/libgcc_s.so.1.backup; else true; fi &&
mv lib32/ilp32/libgcc_s.so.1.tmp lib32/ilp32/libgcc_s.so.1 && (echo "/* GNU ld
script"; echo "   Use the shared library, but some functions are only in"; echo
"   the static library.  */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) >
lib32/ilp32/libgcc_s.so
/usr/local/riscv-linux/bin/ld: unrecognised emulation mode: elf32lriscv_ilp32
Supported emulations: elf32lriscv elf64lriscv
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:995: libgcc_s.so] Error 1
make[3]: Leaving directory
'/home/cqwrteur/myhome/gcc_riscv/riscv-linux/lib32/ilp32/libgcc'
make[2]: *** [Makefile:1213: multi-do] Error 1
make[2]: Leaving directory '/home/cqwrteur/myhome/gcc_riscv/riscv-linux/libgcc'
make[1]: *** [Makefile:127: all-multi] Error 2
make[1]: Leaving directory '/home/cqwrteur/myhome/gcc_riscv/riscv-linux/libgcc'
make: *** [Makefile:13945: all-target-libgcc] Error 2

[Bug target/97387] we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #7 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #6)
> Trying 10, 17 -> 18:
>10: r88:QI=ltu(flags:CCC,0)
>   REG_DEAD flags:CCC
>17: {flags:CCC=cmp(r88:QI-0x1,r88:QI);clobber scratch;}
>   REG_DEAD r88:QI
>18:
> {flags:CCC=cmp(zero_extend(ltu(flags:CCC,0)+r106:DI+r107:DI),
> zero_extend(r107:DI)+ltu(flags:CCC,0));r109:DI=ltu(flags:CCC,0)+r106:DI+r107:
> DI
> ;}
>   REG_DEAD r107:DI
>   REG_DEAD r106:DI
> Can't combine i1 into i3


BTW.

clang does not remove the
movl$0, %esi
before
sbbq%rsi, %rsi

sbbq itself does not matter what the value itself is.

https://godbolt.org/z/szYb55

I do not know whether GCC would remove this after patch. If you can optimize
this away, I would thank you.

[Bug rtl-optimization/97387] we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Hongtao.liu from comment #2)
> Same issue as PR93990?

many of them. It has been reported similar bugs since 2015.

[Bug rtl-optimization/97387] we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #1 from fdlbxtqi  ---
All these instructions generated by GCC are very very wrong.

https://gcc.godbolt.org/z/asMrKv

[Bug rtl-optimization/97387] New: we are near 2021, add carry intrinsic still does the wrong thing and generates silly code.

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97387
   Summary: we are near 2021, add carry intrinsic still does the
wrong thing and generates silly code.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

#include 
#include 

void add256(uint64_t a[4], uint64_t b[4]){
  uint8_t carry = 0;
  for (int i = 0; i < 4; ++i)
carry = _addcarry_u64(carry, a[i], b[i], [i]);
}

People have reported the issue for many many times but the carry is still
buggy.

https://gcc.godbolt.org/z/TnM8cv

[Bug c++/97284] New: internal compiler error: 'global_options' are modified in local context

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97284
   Summary: internal compiler error: 'global_options' are modified
in local context
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

This happens when I build qtbase.

/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/pmmintrin.h:129:9:
internal compiler error: 'global_options' are modified in local context
  129 | #pragma GCC pop_options
  | ^~~
g++ -c -include .pch/Qt5Core -pipe -O3 -std=c++1z -fvisibility=hidden
-fvisibility-inlines-hidden -Wall -Wextra -Wvla -Wdate-time -Wshift-overflow=2
-Wduplicated-cond -Wno-stringop-overflow -Wno-format-overflow -D_REENTRANT
-fPIC -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_USING_NAMESPACE
-DQT_NO_FOREACH -DQFLOAT16_INCLUDE_FAST
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\"
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_DEPRECATED_WARNINGS_SINCE=0x06
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/corelib -I. -Iglobal
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty/md5
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty/md4
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty/sha3
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty/double-conversion/include
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty/harfbuzz/src
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty/forkfd
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/3rdparty/tinycbor/src
-I.rcc -I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/include
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/include/QtCore -I../../include
-I../../include/QtCore
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/include/QtCore/5.15.1
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/include/QtCore/5.15.1/QtCore
-I../../include/QtCore/5.15.1 -I../../include/QtCore/5.15.1/QtCore -I.moc
-I.tracegen -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/mkspecs/linux-g++ -o
.obj/qrunnable.o
/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/corelib/thread/qrunnable.cpp
0xa28421 cp_parser_pragma
../../gcc/gcc/cp/parser.c:44093
0xa28421 cp_parser_pragma
../../gcc/gcc/cp/parser.c:44093
0xa5957b cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4793
0xa5957b cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4793
0xa5957b c_parse_file()
../../gcc/gcc/cp/parser.c:44152
0xa5957b c_parse_file()
../../gcc/gcc/cp/parser.c:44152
0xb76cdd c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1188
0xb76cdd c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [Makefile:22373: .obj/qendian.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [Makefile:22979: .obj/qfloat16.o] Error 1
0xf75bdb cl_optimization_compare(gcc_options*, gcc_options*)
/home/cqwrteur/myhome/gcc_build/gcc/options-save.c:11304
0xb790dd handle_pragma_pop_options
../../gcc/gcc/c-family/c-pragma.c:1093
0xa28421 cp_parser_pragma
../../gcc/gcc/cp/parser.c:44093
0xa5957b cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4793
0xa5957b c_parse_file()
../../gcc/gcc/cp/parser.c:44152
0xb76cdd c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [Makefile:23464: .obj/qrandom.o] Error 1
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/immintrin.h:33,
 from
/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/include/QtCore/5.15.1/QtCore/private/../../../../../src/corelib/tools/qsimd_p.h:191,
 from
/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/include/QtCore/5.15.1/QtCore/private/qsimd_p.h:1,
 from
/home/cqwrteur/qt/qtbase-everywhere-src-5.15.1/src/corelib/global/qloggin

[Bug bootstrap/97262] Build GCC fail: error: cast from 'const ana::region*' to 'long int' loses precision

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
Change the line of (long)m_region to this. Compile success. the type long just
considered harmful

  hashval_t hash () const
  {
return (binding_key::impl_hash () ^ reinterpret_cast(m_region));
  }

[Bug bootstrap/97262] Build GCC fail: error: cast from 'const ana::region*' to 'long int' loses precision

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #2 from fdlbxtqi  ---
Let's face it. std::size_t should be the default integer type in both C and
C++. type like long should never EVER be used.

[Bug bootstrap/97262] rror: cast from 'const ana::region*' to 'long int' loses precision

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #1 from fdlbxtqi  ---
You cannot cast pointer this way. How do you guys control your code quality
now?

[Bug bootstrap/97262] New: rror: cast from 'const ana::region*' to 'long int' loses precision

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97262
   Summary: rror: cast from 'const ana::region*' to 'long int'
loses precision
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

c/../libbacktrace -I/mingw64/include -D__USE_MINGW_ANSI_STDIO=1
-I/mingw64/include -o analyzer/pending-diagnostic.o -MT
analyzer/pending-diagnostic.o -MMD -MP -MF
analyzer/.deps/pending-diagnostic.TPo
../../gcc-git/gcc/analyzer/pending-diagnostic.cc
In file included from ../../gcc-git/gcc/analyzer/checker-path.cc:52:
../../gcc-git/gcc/analyzer/store.h: In member function 'hashval_t
ana::symbolic_binding::hash() const':
../../gcc-git/gcc/analyzer/store.h:272:41: error: cast from 'const
ana::region*' to 'long int' loses precision [-fpermissive]
  272 | return (binding_key::impl_hash () ^ (long)m_region);
  | ^~
In file included from ../../gcc-git/gcc/analyzer/engine.cc:45:
../../gcc-git/gcc/analyzer/store.h: In member function 'hashval_t
ana::symbolic_binding::hash() const':
../../gcc-git/gcc/analyzer/store.h:272:41: error: cast from 'const
ana::region*' to 'long int' loses precision [-fpermissive]
  272 | return (binding_key::impl_hash () ^ (long)m_region);
  | ^~
In file included from ../../gcc-git/gcc/analyzer/diagnostic-manager.cc:48:
../../gcc-git/gcc/analyzer/store.h: In member function 'hashval_t
ana::symbolic_binding::hash() const':
../../gcc-git/gcc/analyzer/store.h:272:41: error: cast from 'const
ana::region*' to 'long int' loses precision [-fpermissive]
  272 | return (binding_key::impl_hash () ^ (long)m_region);
  | ^~
make[2]: *** [Makefile:1123: analyzer/checker-path.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from ../../gcc-git/gcc/analyzer/constraint-manager.cc:47:
../../gcc-git/gcc/analyzer/store.h: In member function 'hashval_t
ana::symbolic_binding::hash() const':
../../gcc-git/gcc/analyzer/store.h:272:41: error: cast from 'const
ana::region*' to 'long int' loses precision [-fpermissive]
  272 | return (binding_key::impl_hash () ^ (long)m_region);
  | ^~
make[2]: *** [Makefile:1123: analyzer/constraint-manager.o] Error 1
make[2]: *** [Makefile:1123: analyzer/diagnostic-manager.o] Error 1
make[2]: *** [Makefile:1123: analyzer/engine.o] Error 1
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[2]: Leaving directory
'/home/unlvs/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/gcc'
make[1]: *** [Makefile:4408: all-gcc] Error 2
make[1]: Leaving directory
'/home/unlvs/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32'
make: *** [Makefile:971: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

[Bug rtl-optimization/96738] New: GCC generates worse assembly than clang and It fails to vectorized code compared to clang

[euloanty at live dot com]

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

Bug ID: 96738
   Summary: GCC generates worse assembly than clang and It fails
to vectorized code compared to clang
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

https://godbolt.org/z/9K3369

#include
#include

struct number
{
std::array num;


inline constexpr std::uint64_t& operator[](std::size_t position)
noexcept
{
return num[position];
}
inline constexpr std::uint64_t const& operator[](std::size_t position)
const noexcept
{
return num[position];
}
};


number add_reduce(number const& a,number const& b) noexcept
{
constexpr auto reduce_mask_51{(static_cast(1) << 51) - 1};
number out;
std::uint64_t c{(a[0] + b[0])>>51};
out[1] = a[1] + b[1] + c; c = (out[1] >> 51); out[1] &= reduce_mask_51;
out[2] = a[2] + b[2] + c; c = (out[2] >> 51); out[2] &= reduce_mask_51;
out[3] = a[3] + b[3] + c; c = (out[3] >> 51); out[3] &= reduce_mask_51;
out[4] = a[4] + b[4] + c; c = (out[4] >> 51); out[4] &= reduce_mask_51;
out[0] = c * 19;
return out;
}


gcc:

add_reduce(number const&, number const&):
movq(%rdx), %rax
addq(%rsi), %rax
movq%rdi, %r8
movq%rdx, %rdi
shrq$51, %rax
movq8(%rdx), %rdx
addq8(%rsi), %rdx
movq%rsi, %rcx
movabsq $2251799813685247, %rsi
addq%rdx, %rax
movq%rax, %rdx
shrq$51, %rax
andq%rsi, %rdx
movq%rdx, 8(%r8)
movq16(%rdi), %rdx
addq16(%rcx), %rdx
addq%rdx, %rax
movq%rax, %rdx
shrq$51, %rax
andq%rsi, %rdx
movq%rdx, 16(%r8)
movq24(%rdi), %rdx
addq24(%rcx), %rdx
addq%rax, %rdx
movq%rdx, %rax
shrq$51, %rdx
andq%rsi, %rax
movq%rax, 24(%r8)
movq32(%rdi), %rax
addq32(%rcx), %rax
addq%rdx, %rax
andq%rax, %rsi
shrq$51, %rax
leaq(%rax,%rax,8), %rdx
movq%rsi, 32(%r8)
leaq(%rax,%rdx,2), %rax
movq%rax, (%r8)
movq%r8, %rax
ret

clang:
add_reduce(number const&, number const&): # @add_reduce(number
const&, number const&)
movq%rdi, %rax
movq(%rdx), %rcx
movq8(%rdx), %rdi
addq(%rsi), %rcx
shrq$51, %rcx
addq8(%rsi), %rdi
addq%rcx, %rdi
movq%rdi, %rcx
shrq$51, %rcx
movabsq $2251799813685247, %r8  # imm = 0x7
andq%r8, %rdi
movq%rdi, 8(%rax)
movq16(%rdx), %rdi
addq16(%rsi), %rdi
addq%rcx, %rdi
movq%rdi, %rcx
shrq$51, %rcx
andq%r8, %rdi
movq%rdi, 16(%rax)
movq24(%rdx), %rdi
addq24(%rsi), %rdi
addq%rcx, %rdi
movq%rdi, %rcx
andq%r8, %rdi
movq%rdi, 24(%rax)
movq32(%rdx), %rdx
addq32(%rsi), %rdx
shrq$51, %rcx
addq%rcx, %rdx
movq%rdx, %rcx
shrq$51, %rcx
andq%r8, %rdx
movq%rdx, 32(%rax)
leaq(%rcx,%rcx,8), %rdx
leaq(%rcx,%rdx,2), %rcx
movq%rcx, (%rax)
retq

clang with -march=native

.LCPI0_0:
.quad   2251799813685247
add_reduce(number const&, number const&): # @add_reduce(number
const&, number const&)
movq%rdi, %rax
movq(%rdx), %rcx
movq8(%rdx), %rdi
addq(%rsi), %rcx
shrq$51, %rcx
addq8(%rsi), %rdi
addq%rcx, %rdi
vmovq   %rdi, %xmm0
shrq$51, %rdi
movq16(%rdx), %rcx
addq16(%rsi), %rcx
addq%rdi, %rcx
vmovq   %rcx, %xmm1
shrq$51, %rcx
movq24(%rdx), %rdi
addq24(%rsi), %rdi
addq%rcx, %rdi
vmovq   %rdi, %xmm2
shrq$51, %rdi
movq32(%rdx), %rcx
addq32(%rsi), %rcx
addq%rdi, %rcx
vpunpcklqdq %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0],xmm1[0]
vmovq   %rcx, %xmm1
vpunpcklqdq %xmm1, %xmm2, %xmm1 # xmm1 = xmm2[0],xmm1[0]
vinserti128 $1, %xmm1, %ymm0, %ymm0
vpandq  .LCPI0_0(%rip){1to4}, %ymm0, %ymm0
shrq$51,

[Bug c++/96577] New: template binary bloat of two std::sort as an example. It looks like colonization is doing the wrong thing

[euloanty at live dot com]

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

Bug ID: 96577
   Summary: template binary bloat of two std::sort as an example.
It looks like colonization is doing the wrong thing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

https://godbolt.org/z/haG4E7
https://godbolt.org/z/M8e7Kb

First:

#include
#include
#include

template
void f(Iter a,Iter b)
{
std::sort(a,b);
}

void g(std::vector::iterator b,std::vector::iterator e)
{
f(b,e);
}

void h(int* b,int* e)
{
f(b,e);
}

Second:


#include
#include
#include

template
void f(Iter a,Iter b)
{
std::sort(a,b);
}

void g(std::vector::iterator b,std::vector::iterator e)
{
f(std::to_address(b),std::to_address(e));
}

void h(int* b,int* e)
{
f(b,e);
}


The two sort function should generate exactly the same binary. However the
first which is none to_address version generates twice as much as code as the
second one.

BTW, inline function is not ABI stable, there is no reason not to collapse that
abstraction

[Bug c++/96531] New: ICE for concepts here.

[euloanty at live dot com]

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

Bug ID: 96531
   Summary: ICE for concepts here.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

#include
#include

template struct pack {};
template struct uv : std::false_type {};
template struct uv> {
using type = pack;
};

template 
concept is_any_of_impl_4 = requires(pack) {
requires (std::same_as || ...);
};

inline std::variant v;

template 
requires is_any_of_impl_4::type>
void bar() {}

int main() {
bar();
}

https://godbolt.org/z/WPdePT
: In instantiation of 'void bar() [with T = int]':

:22:14:   required from here

:12:14: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12924

   12 | requires (std::same_as || ...);

  | ~^~

Please submit a full bug report,

with preprocessed source if appropriate.

See <https://gcc.gnu.org/bugs/> for instructions.

Compiler returned: 1

[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.

[euloanty at live dot com]

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

--- Comment #6 from fdlbxtqi  ---
(In reply to Iain Sandoe from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > Jonathan. I am MAD at you. This is absolutely your fault. I told you to
> > always write inline and you guys do not then allow Herb Sutter to ban me.
> > Here is the fault in your own controlled codebase. Are you satisfied?
> > 
> > https://github.com/isocpp/CppCoreGuidelines/issues/1630
> > 
> > YES! INLINE ALL YOUR FUNCTIONS. AVOID function pointers and virtual
> > functions as plagues.
> 
> 1. jonathan did not write this header - I did,
> 2. we all make mistakes, shouting at folks isn't the optimum way to get them
> fixed
> 3. this bloat can only occur IF you include a header you are NOT using.
> 
> i.e.
> #include 
> in a source that has no coroutines.

Iain, you did a great job on implementing coroutines.

I am here to show the examples.

https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux.cc
https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux.s
https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux_writev.cc
https://github.com/expnkx/fast_io/blob/master/testsuites/0005.freestanding/0002.println/helloworld_linux_writev.s

 Of course, I disabled exceptions and RTTI.
I can compile this on one computer and fail on another since it introduced
libsupc++ again with std:: bad_alloc, global new for examples. This is serious
if people are using C++ for making operating systems.

[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.

[euloanty at live dot com]

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

--- Comment #5 from fdlbxtqi  ---
(In reply to Iain Sandoe from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > Jonathan. I am MAD at you. This is absolutely your fault. I told you to
> > always write inline and you guys do not then allow Herb Sutter to ban me.
> > Here is the fault in your own controlled codebase. Are you satisfied?
> > 
> > https://github.com/isocpp/CppCoreGuidelines/issues/1630
> > 
> > YES! INLINE ALL YOUR FUNCTIONS. AVOID function pointers and virtual
> > functions as plagues.
> 
> 1. jonathan did not write this header - I did,
> 2. we all make mistakes, shouting at folks isn't the optimum way to get them
> fixed
> 3. this bloat can only occur IF you include a header you are NOT using.
> 
> i.e.
> #include 
> in a source that has no coroutines.

Sorry. It is not your fault. What I am complaining about is that GCC now has
the 
 exactly the problem I talked about 10 days ago and he and Herb Sutter banned
me on C++ Core Guideline.

C++ Core Guideline is absolutely wrong here.

[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.

[euloanty at live dot com]

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

--- Comment #3 from fdlbxtqi  ---
Jonathan. I am MAD at you. This is absolutely your fault. I told you to always
write inline and you guys do not then allow Herb Sutter to ban me. Here is the
fault in your own controlled codebase. Are you satisfied?

https://github.com/isocpp/CppCoreGuidelines/issues/1630

YES! INLINE ALL YOUR FUNCTIONS. AVOID function pointers and virtual functions
as plagues.

[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.

[euloanty at live dot com]

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

--- Comment #2 from fdlbxtqi  ---
This makes me mad.

I compiled this under freestanding mode. Now coroutine causes binary bloat
which is completely unacceptable for me.

The problem of C++ is that you have to always write inline to undo the brain
damage of the extern static shit of WG21.

[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.

[euloanty at live dot com]

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

--- Comment #1 from fdlbxtqi  ---

  void __dummy_resume_destroy() __attribute__((__weak__));
  void __dummy_resume_destroy() {}

  struct __noop_coro_frame
  {
void (*__r)() = __dummy_resume_destroy;
void (*__d)() = __dummy_resume_destroy;
struct noop_coroutine_promise __p;
  } __noop_coro_fr __attribute__((__weak__));


Please inline ALL your functions.

inline this variable PLEASE.

[Bug c++/95917] New: coroutine functions leak under freestanding mode causing dependencies and binary bloat.

[euloanty at live dot com]

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

Bug ID: 95917
   Summary: coroutine functions leak under freestanding mode
causing dependencies and binary bloat.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

.file   "helloworld_linux_writev.cc"
.text
.p2align 4
.weak   _ZNSt7__n486122__dummy_resume_destroyEv
.type   _ZNSt7__n486122__dummy_resume_destroyEv, @function
_ZNSt7__n486122__dummy_resume_destroyEv:
.LFB13483:
.cfi_startproc
ret
.cfi_endproc
.LFE13483:
.size   _ZNSt7__n486122__dummy_resume_destroyEv,
.-_ZNSt7__n486122__dummy_resume_destroyEv
.section   
.text._ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_,"axG",@progbits,_ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_,comdat
.p2align 4
.weak  
_ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_
.type  
_ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_,
@function
_ZN7fast_io7details14print_fallbackILb1ENS_23basic_posix_io_observerIcEEJRA13_KciRA5_S4_EEEvRT0_DpOT1_:
.LFB14746:

.file   "helloworld_linux_writev.cc" .text .p2align 4  
  .weak   _ZNSt7__n486122__dummy_resume_destroyEv .type  
_ZNSt7__n486122__dummy_resume_destroyEv, @function
_ZNSt7__n486122__dummy_resume_destroyEv: .LFB13480:

[Bug bootstrap/95402] freebsd make: "/usr/home/cqwrteur/gcc_build/Makefile" line 26: Missing dependency operator

[euloanty at live dot com]

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

--- Comment #4 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> As mentioned in https://gcc.gnu.org/install/prerequisites.html one needs to
> use GNU make to build gcc, are you sure make is a GNU make?

g++  -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/usr/local/include -I/home/cqwrteur/gcc_build/./mpfr/src
-I/home/cqwrteur/gcc/mpfr/src -I/home/cqwrteur/gcc/mpc/src 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace
-I/home/cqwrteur/gcc_build/./isl/include -I/home/cqwrteur/gcc/isl/include
-I/usr/local/include -o final.o -MT final.o -MMD -MP -MF ./.deps/final.TPo
../../gcc/gcc/final.c
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
gmake[2]: *** [Makefile:1123: final.o] Error 1
gmake[2]: *** Waiting for unfinished jobs
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
gmake[2]: *** [Makefile:1123: expr.o] Error 1
gmake[2]: Leaving directory '/usr/home/cqwrteur/gcc_build/gcc'
gmake[1]: *** [Makefile:4408: all-gcc] Error 2
gmake[1]: Leaving directory '/usr/home/cqwrteur/gcc_build'
gmake: *** [Makefile:967: all] Error 2

well lol. Still have issues.

[Bug bootstrap/95402] freebsd make: "/usr/home/cqwrteur/gcc_build/Makefile" line 26: Missing dependency operator

[euloanty at live dot com]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> As mentioned in https://gcc.gnu.org/install/prerequisites.html one needs to
> use GNU make to build gcc, are you sure make is a GNU make?

So sad nowadays LLVM just copy-pastes everything GNU has with shitty quality.

Think about how bad C++20 support for LLVM is. 10x Worse than even msvc.

[Bug bootstrap/95402] freebsd make: "/usr/home/cqwrteur/gcc_build/Makefile" line 26: Missing dependency operator

[euloanty at live dot com]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> As mentioned in https://gcc.gnu.org/install/prerequisites.html one needs to
> use GNU make to build gcc, are you sure make is a GNU make?

Really? LLVM also provides a make?? LOL. What a freaking joke.

[Bug bootstrap/95402] New: freebsd make: "/usr/home/cqwrteur/gcc_build/Makefile" line 26: Missing dependency operator

[euloanty at live dot com]

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

Bug ID: 95402
   Summary: freebsd make: "/usr/home/cqwrteur/gcc_build/Makefile"
line 26: Missing dependency operator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

$ ../gcc/configure --with-pkgversion=cqwrteur --enable-multilib
--enable-languages=c,c++,fortran,lto --disable-bootstrap --disable-nls
checking build system type... x86_64-unknown-freebsd12.1
checking host system type... x86_64-unknown-freebsd12.1
checking target system type... x86_64-unknown-freebsd12.1
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
$ make -j30
make: "/usr/home/cqwrteur/gcc_build/Makefile" line 26: Missing dependency
operator
make: "/usr/home/cqwrteur/gcc_build/Makefile" line 27: Need an operator
make: "/usr/home/cqwrteur/gcc_build/Makefile" line 28: Need an operator
make: "/usr/home/cqwrteur/gcc_build/Makefile" line 880: Missing dependency
operator
make: "/usr/home/cqwrteur/gcc_build/Makefile" line 881: Could not find
make: "/usr/home/cqwrteur/gcc_build/Makefile" line 882: Need an operator
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/home/cqwrteur/gcc_build

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #10 from fdlbxtqi  ---
What about adding another check when BUFSIZ is smaller than 4KB? If it is
smaller than 4kb, adjust the filebuf size to 4kb at least.

[Bug c++/95286] -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.

[euloanty at live dot com]

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

--- Comment #5 from fdlbxtqi  ---
I tried other architectures. Same issues here. WHY???

cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=x86-64
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476032
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=haswell
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476035
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=skylake
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476035
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -m32
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476032
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -m32 -march=na
tive
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476035

[Bug c++/95286] -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.

[euloanty at live dot com]

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

--- Comment #4 from fdlbxtqi  ---
I test on another Amd ryzen computer. Same issue here. Why???

cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc  -Ofast -std=c++20 -s -march=native
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476035
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ g++ -o dontagree
dontagree.cc  -Ofast -std=c++20 -s
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476032
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ clang++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=native
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476035
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ clang++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476032
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ clang++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=native -stdlib=libc++
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476035
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ clang++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s -march=native
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476035
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ clang++ -o dontagree
dontagree.cc -Ofast -std=c++20 -s
cqwrteur@Home-Server:~/fast_io_all/fast_io/helpers/fp$ ./dontagree
3298476032

[Bug c++/95286] -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.

[euloanty at live dot com]

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

--- Comment #3 from fdlbxtqi  ---
#include
#include
#include

int main()
{
std::mt19937_64 eng;
std::uniform_real_distribution dis(-1.0f,1.0f);
float v{};
for(std::size_t i(0);i!=36;++i)
v=dis(eng);
static_assert(sizeof(float)==sizeof(std::uint32_t));
std::uint32_t puned;
memcpy(std::addressof(puned),std::addressof(v),sizeof(std::uint32_t));
std::cout<

[Bug c++/95286] -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.

[euloanty at live dot com]

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

fdlbxtqi  changed:

   What|Removed |Added

 Target|Amd ryzen 2700. Linux,  |Amd ryzen 3600. Linux,
   |MinGW-w64 Windows   |MinGW-w64 Windows
   Host|Amd ryzen 2700. Linux,  |Amd ryzen 3600. Linux,
   |MinGW-w64 Windows   |MinGW-w64 Windows

--- Comment #2 from fdlbxtqi  ---
The same result under Linux. -march=native is wrong for Ryzen 3600 here.

cqwrteur@DESKTOP-C4VAUFM:~/fast_io/helpers/fp$ g++ -o dontagree dontagree.cc 
-Ofast -std=c++20 -s
cqwrteur@DESKTOP-C4VAUFM:~/fast_io/helpers/fp$ dontagree^C
cqwrteur@DESKTOP-C4VAUFM:~/fast_io/helpers/fp$ ./dontagree
3298476032
cqwrteur@DESKTOP-C4VAUFM:~/fast_io/helpers/fp$ g++ -o dontagree dontagree.cc 
-Ofast -std=c++20 -s -march=native
cqwrteur@DESKTOP-C4VAUFM:~/fast_io/helpers/fp$ ./dontagree
3298476035

[Bug c++/95286] -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.

[euloanty at live dot com]

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

fdlbxtqi  changed:

   What|Removed |Added

   Host|amd ryzen 2700. Linux,  |Amd ryzen 2700. Linux,
   |MinGW-w64 Windows   |MinGW-w64 Windows
 Target|amd ryzen 2700. Linux,  |Amd ryzen 2700. Linux,
   |MinGW-w64 Windows   |MinGW-w64 Windows

--- Comment #1 from fdlbxtqi  ---
My platform is Amd Ryzen 2700

[Bug c++/95286] New: -march=native causes mt19937_64 + uniform_real_distribution generating wrong result.

[euloanty at live dot com]

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

Bug ID: 95286
   Summary: -march=native causes mt19937_64 +
uniform_real_distribution generating wrong result.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

#include
#include

int main()
{
std::mt19937_64 eng;
std::uniform_real_distribution dis(-1.0f,1.0f);
float v{};
for(std::size_t i(0);i!=36;++i)
v=dis(eng);
static_assert(sizeof(float)==sizeof(std::uint32_t));
std::uint32_t puned;
memcpy(std::addressof(puned),std::addressof(v),sizeof(std::uint32_t));
std::cout<g++ -o dontagree dontagree.cc -Ofast -std=c++20 -s
-Ofast

D:\hg\fast_io\helpers\fp>dontagree
3298476032

D:\hg\fast_io\helpers\fp>g++ -o dontagree dontagree.cc -Ofast -std=c++20 -s
-march=native

D:\hg\fast_io\helpers\fp>dontagree
3298476035

I test the same thing under Linux. Same problem here.

[Bug libstdc++/95170] GetTickCount64 cannot get found in KERNEL32.dll on Legacy Windows Platforms like Windows XP, 2000

[euloanty at live dot com]

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

--- Comment #1 from fdlbxtqi  ---
Created attachment 48550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48550=edit
Picture bug

printf works while iostream does not since it links to GetTickCount64.

[Bug libstdc++/95170] New: GetTickCount64 cannot get found in KERNEL32.dll on Legacy Windows Platforms like Windows XP, 2000

[euloanty at live dot com]

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

Bug ID: 95170
   Summary: GetTickCount64 cannot get found in KERNEL32.dll on
Legacy Windows Platforms like Windows XP, 2000
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

libstdc++ could not work on the old win32 operating systems (32 bit) because
dll does not have GetTickCount64. Any solutions?

[Bug bootstrap/92008] Build failure on cygwin

[euloanty at live dot com]

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

--- Comment #7 from fdlbxtqi  ---
(In reply to Andrew Pinski from comment #6)
> https://github.com/zerovm/glibc/commit/9f3f5229848390ae921f77c92f666ca6f0bff
> 
> is more the correct fix.
> Or use an older version of Bison.

But I am using windows. So?? I should contact MSYS2 for fixing it?

[Bug bootstrap/94601] Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE

[euloanty at live dot com]

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

--- Comment #4 from fdlbxtqi  ---
Created attachment 48276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48276=edit
Let me try whether this patch works.

[Bug preprocessor/94601] Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE

[euloanty at live dot com]

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

--- Comment #1 from fdlbxtqi  ---
Can you guys stop using macros and migrate to namespace?

[Bug bootstrap/94601] New: Build Latest GCC on MinGW-w64 failed. Conflict macro PLURAL_PARSE

[euloanty at live dot com]

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

Bug ID: 94601
   Summary: Build Latest GCC on MinGW-w64 failed. Conflict macro
PLURAL_PARSE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

In file included from ../../gcc-git/intl/plural.y:35:
../../gcc-git/intl/plural-exp.h:102:23: error: conflicting types for
'libintl_gettextparse'
  102 | # define PLURAL_PARSE libintl_gettextparse
  |   ^~~~
../../gcc-git/intl/plural.y:40:25: note: x86_64-w64-mingw32-gcc -c
-D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=generic -O2
 -pipe -D__USE_MINGW_ACCESS -DHAVE_CONFIG_H  -I. -I../../gcc-git/intl
../../gcc-git/intl/relocatex.c
in expansion of macro 'no
PLURAL_PARSEx86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1
-I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS
-
DHAVE_CONFIG  '
   40 | # define __gettextparse
PLURAL_PARSE
  | ^~~~
x86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include
-march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS -DHAVE_CONFIG
_H  -I. -I../../gcc-git/intl ../../gcc-git/intl/localename.c
plural.c:199:5: note: in expansion of macro '__gettextparse'
  199 | int x86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1
-I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS
-
DHAVE_CONFIG_H  -I. -I../../gcc-git/intl ../../gcc-git/intl/log.c
__gettextparse (void);
  | x86_64-w64-mingw32-gcc -c -D__USE_MINGW_ANSI_STDIO=1
-I/mingw64/include -march=x86-64 -mtune=generic -O2 -pipe -D__USE_MINGW_ACCESS
-
DHAVE_CONFIG_H  -I. -I../../gcc-git/intl
../../gcc-git/intl/osdep.c^~

../../gcc-git/intl/plural-exp.h:102:23: note: previous declaration of
'libintl_gettextparse' was here
  102 | # define PLURAL_PARSE libintl_gettextparsex86_64-w64-mingw32-gcc -c
-D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include -march=x86-64 -mtune=ge
neric -O2 -pipe -D__USE_MINGW_ACCESS -DHAVE_CONFIG_H  -I. -I../../gcc-git/intl
../../gcc-git/intl/intl-compat.c

  |   ^~~~
../../gcc-git/intl/plural-exp.h:114:12: note: in expansion of macro
'PLURAL_PARSE'
  114 | extern int PLURAL_PARSE PARAMS ((void *arg));
  |^~~~
../../gcc-git/intl/plural-exp.h:102:23: error: conflicting types for
'libintl_gettextparse'
  102 | # define PLURAL_PARSE no
libintl_gettextparse
  |   ^~~~
 
../../gcc-git/intl/plural.y:40:25: no
note: in expansion of macro 'PLURAL_PARSE'
   40 | # define __gettextparse PLURAL_PARSE
  | ^~~~
plural.c:67:25: note: in expansion of macro '__gettextparse'
   67 | #define yyparse __gettextparse
  | ^~
plural.c:1220:1: note: in expansion of macro 'yyparse'
 1220 | yyparse (void)
  | ^~~
../../gcc-git/intl/plural-exp.h:102:23: note: previous declaration of
'libintl_gettextparse' was here
  102 | # define PLURAL_PARSE libintl_gettextparseconfig.status: creating
Makefile

  |   ^~~~
../../gcc-git/intl/plural-exp.h:114:12: note: in expansion of macro
'PLURAL_PARSE'
  114 | extern int PLURAL_PARSE PARAMS ((void *arg));
  |^~~~
plural.c: In function 'libintl_gettextparse':
plural.c:68:25: error: too few arguments to function '__gettextlex'
   68 | #define yylex   __gettextlex
  | ^~~~
checking for stpncpy... plural.c:1398:16: note: in expansion of macro 'checking
for stpncpy... yylex'
 1398 |   yychar = yylex ();
  |^
plural.c:68:25: note: declared here
   68 | #define yylex   __gettextlex
  | ^~~~
../../gcc-git/intl/plural.y:69:12: note: in expansion of macro 'yylex'
   69 | static int yylex PARAMS ((YYSTYPE *lval, const char **pexp));
  |^
../../gcc-git/intl/plural.y:178:29: error: 'arg' undeclared (first use in this
function)
  178 |  ((struct parse_args *) arg)->res = $1;
  | ^~~
../../gcc-git/intl/plural.y:178:29: note: each undeclared identifier is
reported only once for each function it appears in
make[2]: *** [Makefile:139: plural.o] Error 1
make[2]: *** Waiting for unfinished jobs
config.status: creating backtrace-supported.h
no
checking whether putchar_unlocked is declared... config.status: creating
install-debuginfo-for-buildid.sh
no
no
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/i

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #9 from fdlbxtqi  ---
https://github.com/microsoft/WSL/issues/3898

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #8 from fdlbxtqi  ---
Well. These links are dead. Repost them.
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/benchmarks/.10m_size_t/unit/filebuf_io_observer.cc
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/benchmarks/.10m_size_t/unit/streambuf_io_observer___gnu_cxx_stdio_filebuf.cc
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/benchmarks/.10m_size_t/unit/c_file_unlocked.cc

https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/include/fast_io_legacy_impl/cpp/libstdc%2B%2B_libc%2B%2B.h
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/include/fast_io_legacy_impl/cpp/general.h
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/include/fast_io_legacy_impl/cpp/streambuf_io_observer.h
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/master/include/fast_io_legacy_impl/c/msvcrt.h

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #7 from fdlbxtqi  ---
I rebuilt a new GCC with this patch. The performance improves for 10 times for
output integer. 3 times for input integer. Definitely worth it.

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>gcc --version
gcc (master HEAD with MCF thread model, built by cqwrteur.) 10.0.1 20200323
(experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>g++ -o filebuf_io_observer
filebuf_io_observer.cc -Ofast -std=c++2a -s

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>filebuf_io_observer
output: 0.047s
input:  0.085998s

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>g++ -o filebuf_io_observer
filebuf_io_observer.cc -Ofast -std=c++2a -s -flto

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>filebuf_io_observer
output: 0.042999s
input:  0.086012s


Ther performance is now nearly as good as my buffer implementation. Though it
is still slower due to hacking. It is actually usable.
g++ -o iobuf_file iobuf_file.cc -Ofast -std=c++2a -s -flto


./iobuf_file.exe
output: 0.044004s
input:  0.076s

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #6 from fdlbxtqi  ---
Created attachment 48086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48086=edit
simple patch

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #5 from fdlbxtqi  ---
Here is the proof.

https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/benchmarks/.10m_size_t/unit/streambuf_io_observer___gnu_cxx_stdio_filebuf.cc

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #4 from fdlbxtqi  ---
(In reply to fdlbxtqi from comment #3)
> I have found out the reason. It is because the buffer size is too small on
> the windows. BUFSIZ == 512
> 
> You need to set the value to 4096 at least. I think even 65536 is something
> should be done since the windows syscall is extremely expensive. I have
> tested with WriteFile, the maximum performance needs to set to 131072
> buffer_size with my library.
> 
> I think I can fix this bug easily.

The most efficient one is 1048576. However, I think it should be set to at
least 65536, although 4096 can already fix most of the problems. Windows
syscall is expensive.

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #3 from fdlbxtqi  ---
I have found out the reason. It is because the buffer size is too small on the
windows. BUFSIZ == 512

You need to set the value to 4096 at least. I think even 65536 is something
should be done since the windows syscall is extremely expensive. I have tested
with WriteFile, the maximum performance needs to set to 131072 buffer_size with
my library.

I think I can fix this bug easily.

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

--- Comment #2 from fdlbxtqi  ---
The hacking code is here.

https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/include/fast_io_legacy_impl/cpp/libstdc%2B%2B_libc%2B%2B.h
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/include/fast_io_legacy_impl/cpp/general.h
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/include/fast_io_legacy_impl/cpp/streambuf_io_observer.h

[Bug libstdc++/94268] std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

fdlbxtqi  changed:

   What|Removed |Added

   Host||Windows 10. MinGW-W64
 Target||gcc 10.0

--- Comment #1 from fdlbxtqi  ---
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc/src/master/
You can try with this MinGW-GCC 10. I have found this issue for a very long
time. It looks like std::filebuf does not set buffer size correctly or other
weird issues with underlining msvcrt.

[Bug libstdc++/94268] New: std::filebuf is extremely (at least 10x) slow on windows compared to Linux. Even much slower MSVC STL with terrible ABI.

[euloanty at live dot com]

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

Bug ID: 94268
   Summary: std::filebuf is extremely (at least 10x) slow on
windows compared to Linux. Even much slower MSVC STL
with terrible ABI.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

Even the hacks work the same result.

https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/benchmarks/.10m_size_t/unit/filebuf_io_observer.cc

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>g++ -o filebuf_io_observer
filebuf_io_observer.cc -Ofast -std=c++2a -s

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>filebuf_io_observer
output: 0.51300601s
input:  0.256011s

running the same program on Linux WSL2

cqwrteur@Home-Server:~/myhome/fast_io/benchmarks/.10m_size_t/unit$ g++ -o
filebuf_io_observer filebuf_io_observer.cc
 -Ofast -std=c++2a -s
cqwrteur@Home-Server:~/myhome/fast_io/benchmarks/.10m_size_t/unit$
./filebuf_io_observer
output: 0.058395978s
input:  0.0660342670001s

It is not possible to be an optimization problem since my code has no
difference on windows and linux. I think the only reason is FILE*'s issue.
I guess the problem is just that code relies on unknown libc does not correctly
on windows. One explanation might be the underlining FILE* buffer size's
problem. I think you guys need to try larger buffer size.

Same program builds with MSVC STL (Their ABIs are terrible)
MSVC STL with hacking:
D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>filebuf_io_observer
output: 0.119666s
input:  0.2497127s

Other comparison benchmarks

GCC 10.0.1 with msvcrt hacking.
https://bitbucket.org/ejsvifq_mabmip/fast_io/src/reserver_test/include/fast_io_legacy_impl/c/msvcrt.h

D:\hg\w4\f8\fast_io\benchmarks\.10m_size_t\unit>c_file_unlocked
output: 0.092166001s
input:  0.122307001s

GCC

[Bug libstdc++/94013] [10 Regression] library algos need to work around cwg 2094

[euloanty at live dot com]

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

--- Comment #5 from fdlbxtqi  ---
(In reply to fdlbxtqi from comment #4)
> I noticed LLVM's libc++ has the same issue when I did the test to libstdc++.
> However, their bug reporting port has closed. How can I report that?
> 
> It is amazing that two mainstream C++ standard library implementations
> create the same bug here.

It looks like libstdc++ introduced this bug from GCC 10 while libc++ always has
this issue.

[Bug libstdc++/94013] [10 Regression] library algos need to work around cwg 2094

[euloanty at live dot com]

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

--- Comment #4 from fdlbxtqi  ---
I noticed LLVM's libc++ has the same issue when I did the test to libstdc++.
However, their bug reporting port has closed. How can I report that?

It is amazing that two mainstream C++ standard library implementations create
the same bug here.

[Bug libstdc++/94013] [10 Regression] library algos need to work around cwg 2094

[euloanty at live dot com]

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

--- Comment #1 from fdlbxtqi  ---
Yeah. It looks like libc++ has the same bug. LOL.

volatile is really stupid tbh.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #45 from fdlbxtqi  ---
(In reply to Jonathan Wakely from comment #43)
> (In reply to fdlbxtqi from comment #39)
> > const auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=> 0;
> 
> Are you mistakenly reading this as dereferencing &*begin and &*end of an
> iterator range? Because that's not what it does. It dereferences the begin
> iterator of two separate non-empty ranges.
> 
> There is no past-the-end iterator in this statement.

But I still think &* is not a good idea tbh. Better just call
to_address(__first) to avoid potential issues of a contiguous iterator.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #41 from fdlbxtqi  ---
(In reply to Jonathan Wakely from comment #38)
> We could also use memcmp for std::equal when it's using std::equal_to<> or
> std::equal_to<_ValueType1> or std::equal_to<_ValueType2>, and for
> std::lexicographical_compare when it's using std::less<> or
> std::less<_ValueType1> or std::less<_ValueType2> (as long as the existing
> conditions are also met).
> 
> Currently we only use memcmp when those algos are used without a comparison
> function.

And the volatile bugs haven't fixed either. The code works fine in GCC 9.0. Now
it failed to work. Even I swap the standard to C++17, it still does not work.
Does deprecate volatile work in this case in C++20?? However, even that is the
case, C++17 should still work.

#include
auto f(std::array arr)
{
decltype(arr) arr2;
std::copy(arr.begin(),arr.end(),arr2.begin());
}

https://godbolt.org/z/Tn87r5

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #39 from fdlbxtqi  ---
(In reply to Jonathan Wakely from comment #38)
> We could also use memcmp for std::equal when it's using std::equal_to<> or
> std::equal_to<_ValueType1> or std::equal_to<_ValueType2>, and for
> std::lexicographical_compare when it's using std::less<> or
> std::less<_ValueType1> or std::less<_ValueType2> (as long as the existing
> conditions are also met).
> 
> Currently we only use memcmp when those algos are used without a comparison
> function.

Hi Jonathan. Another bug I found before and you haven't fixed:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algobase.h#L1706

const auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=> 0;


You cannot call &*__first, &*__first2 for contiguous_iterator since a lot of
implementations of contiguous iterators will check bounds at debugging mode
(for example MSVC's STL vector implementation). Yours will break code. __second
is not allowed to dereference, that is UB.

Instead, you should call to_address(__first),to_address(__second)

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #40 from fdlbxtqi  ---
to_address(__first),to_address(__second)

to_address(__first1),to_address(__first2)

[Bug c++/93688] New: Add mcf thread model to GCC on windows for supporting C++11 std::thread?

[euloanty at live dot com]

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

Bug ID: 93688
   Summary: Add mcf thread model to GCC on windows for supporting
C++11 std::thread?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

MCF gthread is an NT syscall level of std::thread on windows to support POSIX
semantics. 

https://github.com/lhmouse/mcfgthread/wiki

https://github.com/lhmouse/MINGW-packages/commit/e9d259d606ff9e6e5353ea8834d2689e752bb67e

https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/9000-master-Added-mcf-thread-model-support-from-mcfgthread.patch

https://gcc-mcf.lhmouse.com/

I think this patch should be merged into GCC trunk to support mcf thread model
on windows. Or GCC won't magically compile on windows because lack of
std::thread support

[Bug c++/93687] New: Add mcf thread model to GCC on windows for supporting C++11 std::thread?

[euloanty at live dot com]

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

Bug ID: 93687
   Summary: Add mcf thread model to GCC on windows for supporting
C++11 std::thread?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

Created attachment 47819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47819=edit
Officially support std::thread on windows

MCF gthread is an NT syscall level of std::thread on windows to support POSIX
semantics. 

https://github.com/lhmouse/mcfgthread/wiki

https://github.com/lhmouse/MINGW-packages/commit/e9d259d606ff9e6e5353ea8834d2689e752bb67e

https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/9000-master-Added-mcf-thread-model-support-from-mcfgthread.patch

https://gcc-mcf.lhmouse.com/

I think this patch should be merged into GCC trunk to support mcf thread model
on windows. Or GCC won't magically compile on windows because lack of
std::thread support

[Bug c++/93668] constexpr delete[]

[euloanty at live dot com]

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

--- Comment #7 from fdlbxtqi  ---
I mean it is a bug.

constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}

int main()
{
constexpr auto w(f());
}

I mean this is UB so it should not compile. However, it compiles on the latest
GCC.

Not detecting this is a series of security vulnerabilities if people using it
at runtime.

[Bug c++/93668] constexpr delete[]

[euloanty at live dot com]

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

--- Comment #1 from fdlbxtqi  ---
constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}

int main()
{
constexpr auto w(f());
}

[Bug c++/93668] New: constexpr delete[]

[euloanty at live dot com]

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

Bug ID: 93668
   Summary: constexpr delete[]
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

//This code should not compile because it is UB. delete a int[1]

constexpr int f()
{
auto p(new int[1]);
delete p;
return 4;
}

int main()
{
constexpr auto w(f());
}

//

constexpr int f()
{
auto p(new int);
delete[] p;
return 4;
}

int main()
{
constexpr auto w(f());
}

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[euloanty at live dot com]

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

--- Comment #5 from fdlbxtqi  ---
(In reply to Martin Liška from comment #4)
> (In reply to fdlbxtqi from comment #3)
> > (In reply to Martin Liška from comment #2)
> > > Thanks for the report. Can you please send us the command line used for 
> > > the
> > > compilation? Ideally output of -v option.
> > 
> > g++ -o xxx xxx.cc -Ofast -std=c++2a -s -msse2 -maes -msha
> 
> Fine and what tells gcc -v?

D:\hg\w4\fast_io\testsuites\0003.hash>g++ -o sha1 sha1.cc -Ofast -std=c++2a -s
-maes -msse2 -msha -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-git/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --with-arch=x86-64 --with-tune=nocona
--enable-languages=c,lto,c++ --enable-shared --enable-static
--enable-threads=mcf --enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --enable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64
--with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='master HEAD with MCF
thread model, built by cqwrteur.' --with-bugurl=https://gcc-mcf.lhmouse.com/
--with-gnu-as --with-gnu-ld --disable-tls --enable-plugin --disable-bootstrap
Thread model: mcf
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200119 (experimental) (master HEAD with MCF thread model,
built by cqwrteur.)
COLLECT_GCC_OPTIONS='-o' 'sha1.exe' '-Ofast' '-std=c++2a' '-s' '-maes' '-msse2'
'-msha' '-v' '-shared-libgcc' '-mtune=nocona' '-march=x86-64'
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/cc1plus.exe -quiet -v
-U_REENTRANT sha1.cc -quiet -dumpbase sha1.cc -maes -msse2 -msha -mtune=nocona
-march=x86-64 -auxbase sha1 -Ofast -std=c++2a -version -o
C:\Users\unlvs\AppData\Local\Temp\ccx2i3tH.s
GNU C++17 (master HEAD with MCF thread model, built by cqwrteur.) version
10.0.1 20200119 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 10.0.0 20200109 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "D:/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include/c++/10.0.1

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include/c++/10.0.1/x86_64-w64-mingw32

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include/c++/10.0.1/backward
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/include
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../include
 D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/include-fixed

D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/10.0.1/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C++17 (master HEAD with MCF thread model, built by cqwrteur.) version
10.0.1 20200119 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 10.0.0 20200109 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 377d01f7dcdda995e91288532e243e65
sha1.cc: In function 'int main()':
sha1.cc:7:90: internal compiler error: in set_constraints, at
cp/constraint.cc:1176
7 |  fast_io::osha
s(std::piecewise_construct,std::forward_as_tuple(),std::forward_as_tuple());
  |
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/93343] New: coroutine ICE

[euloanty at live dot com]

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

Bug ID: 93343
   Summary: coroutine  ICE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

g++ -o coroutine_epoll coroutine_epoll.cc -Ofast -std=c++2a -s -fcoroutines

coroutine_epoll.cc: In function ‘void
_Z6listenRN7fast_io16basic_tcp_serverILb1EEE.actor(listen(fast_io::async_tcp_server&)::_Z6listenRN7fast_io16basic_tcp_serverILb1EEE.frame*)’:
coroutine_epoll.cc:38:2: internal compiler error: in gimplify_expr, at
gimplify.c:14378
   38 |  co_await awaitable(acc);
  |  ^~~~
0x7619c8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:14378
0xd924cb gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:6822
0xd7a395 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13973
0xd7cee6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd78ce4 gimplify_and_add(tree_node*, gimple**)
../../gcc/gcc/gimplify.c:486
0xd78ce4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13932
0xd7cee6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd7a7ab gimplify_statement_list
../../gcc/gcc/gimplify.c:1869
0xd7a7ab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:14025
0xd7cee6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd7dcbb gimplify_bind_expr
../../gcc/gcc/gimplify.c:1424
0xd7a3d4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:13782
0xd91aa5 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:6822
0xd91aa5 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:14830
0xd91ea3 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:14974
0xbdc377 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:669
0xbdee6f analyze_functions
../../gcc/gcc/cgraphunit.c:1210
0xbdfa32 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2956
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[euloanty at live dot com]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Martin Liška from comment #2)
> Thanks for the report. Can you please send us the command line used for the
> compilation? Ideally output of -v option.

g++ -o xxx xxx.cc -Ofast -std=c++2a -s -msse2 -maes -msha

[Bug c++/93297] internal compiler error: in set_constraints, at cp/constraint.cc:

[euloanty at live dot com]

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

fdlbxtqi  changed:

   What|Removed |Added

 CC||euloanty at live dot com

--- Comment #1 from fdlbxtqi  ---
Created attachment 47662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47662=edit
preprocessed file

[Bug c++/93297] New: internal compiler error: in set_constraints, at cp/constraint.cc:

[euloanty at live dot com]

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

Bug ID: 93297
   Summary: internal compiler error: in set_constraints, at
cp/constraint.cc:
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-invalid-code, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

sha1.cc: In function ‘int main()’:
sha1.cc:7:90: internal compiler error: in set_constraints, at
cp/constraint.cc:1176
7 |  fast_io::osha
s(std::piecewise_construct,std::forward_as_tuple(),std::forward_as_tuple());
  |
 ^
0x658b55 set_constraints(tree_node*, tree_node*)
../../gcc/gcc/cp/constraint.cc:1176
0xa23457 alias_ctad_tweaks
../../gcc/gcc/cp/pt.c:28284
0xa23457 deduction_guides_for
../../gcc/gcc/cp/pt.c:28395
0xa2377b do_class_deduction
../../gcc/gcc/cp/pt.c:28500
0xa2377b do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:28629
0x9584ec cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7463
0x9fe844 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20768
0x9e07c2 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13629
0x9e251a cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:13061
0x9e30b7 cp_parser_statement
../../gcc/gcc/cp/parser.c:11383
0x9e4098 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11745
0x9e4178 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11699
0x9fab65 cp_parser_function_body
../../gcc/gcc/cp/parser.c:22907
0x9fab65 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:22958
0x9fde3d cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:28745
0x9fee46 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:28661
0x9fee46 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20536
0x9e07c2 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13629
0xa091a2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13328
0xa0991a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4723
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


on windows MinGW-w64
sha1.cc: In function 'int main()':
sha1.cc:7:90: internal compiler error: in set_constraints, at
cp/constraint.cc:1177
7 |  fast_io::osha
s(std::piecewise_construct,std::forward_as_tuple(),std::forward_as_tuple());
  |
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc-mcf.lhmouse.com/> for instructions.