from:"euloanty at live dot com via Gcc\-bugs"

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

2020-12-16 Thread 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

2020-12-16 Thread 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  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.

2020-12-15 Thread 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.

2020-12-15 Thread 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.

2020-12-15 Thread 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.

2020-12-15 Thread 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.

2020-12-15 Thread 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.

2020-12-15 Thread 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.

2020-12-15 Thread 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.

2020-12-15 Thread 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

2020-11-29 Thread 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-inlines-hidden -Werror=date-time -Wall -Wextra

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

2020-10-29 Thread 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

2020-10-29 Thread 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

2020-10-29 Thread 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

2020-10-28 Thread 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

2020-10-28 Thread 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

2020-10-28 Thread 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

2020-10-28 Thread 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

2020-10-28 Thread 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  for instructions.

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

2020-10-23 Thread 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
  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  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

2020-10-19 Thread 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

2020-10-19 Thread 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

2020-10-19 Thread 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

2020-10-19 Thread 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

2020-10-19 Thread 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

2020-10-18 Thread 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

2020-10-18 Thread 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  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

[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

2020-10-18 Thread 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?

2020-10-16 Thread 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?

2020-10-16 Thread 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

2020-10-15 Thread 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

2020-10-15 Thread 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 const&)
movq%rdi, %rax
movq(%rsi), %r8
subq(%rdx),

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

2020-10-14 Thread 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.

2020-10-14 Thread 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.

2020-10-14 Thread 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

2020-10-13 Thread 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

2020-10-13 Thread 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

2020-10-13 Thread 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.

2020-10-13 Thread 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.

2020-10-12 Thread 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.

2020-10-12 Thread 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.

2020-10-12 Thread 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

2020-10-04 Thread 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  for instructions.
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  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  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/qlogging.cpp:61:

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

2020-10-01 Thread 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

2020-10-01 Thread 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

2020-10-01 Thread 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

2020-10-01 Thread 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...

47 matches

Mail list logo