[Bug analyzer/95031] New: GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95031 Bug ID: 95031 Summary: GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: noloader at gmail dot com Target Milestone: --- Created attachment 48496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48496&action=edit Preprocessed source file dll.ii Hi Everyone, I'm trying out the analyzer on a C++ project. I'm working on Fedora 32 with GCC 10. $ gcc --version gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.14) Here's what I am seeing: g++ -fPIC -pthread -pipe -DNDEBUG -g2 -O3 -fanalyzer -c dll.cpp g++: fatal error: Terminated signal terminated program cc1plus compilation terminated. make: *** [GNUmakefile:1693: dll.o] Error 1 It is fairly easy to duplicate with live code. Unfortunately, I am not sure what is needed for a reproducer based on the error message. It can be duplicated with live code using: $ git clone https://github.com/weidai11/cryptopp.git $ cd cryptopp $ CXXFLAGS="-DNDEBUG -g2 -O3 -fanalyzer" make dll.o ... g++: fatal error: Terminated signal terminated program cc1plus compilation terminated. Attached is the output with a -save-temps. If someone would kindly provide instructions, then I would be happy to troubleshot it further. The file dll.cpp is a real bastard. It includes a lot of template classes. Its sole purpose is to instantiate a bunch of template classes so the object file has concrete objects in it. I would not be surprised if some sort of resource exhaustion was occurring.
[Bug analyzer/95039] New: GCC 10 Analyzer and ‘‘result_decl’ not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95039 Bug ID: 95039 Summary: GCC 10 Analyzer and ‘‘result_decl’ not supported by dump_expr Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: noloader at gmail dot com Target Milestone: --- Created attachment 48498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48498&action=edit Preprocessed source file ecp.ii Hi Everyone, I'm trying out the analyzer on a C++ project. I'm working on Fedora 32 with GCC 10. $ gcc --version gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.14) Here's what I am seeing: ‘std::_Vector_base >::_M_allocate’ |.. | 346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) : pointer(); | | ~~ | | | | | | | (5) ...to here | | | (6) ‘‘result_decl’ not supported by dump_expr’ is NULL | | (4) following ‘false’ branch (when ‘__n == 0’)... The odd thing (to me) is, std::allocate related functions seem to be analyzed as returning NULL. But in C++ a failed allocation throws, it does not return NULL. It is fairly easy to duplicate with live code. Unfortunately, I am not sure what is needed for a reproducer based on the error message. (I tired to duplicate with a toy example using std::vector, but no joy). It can be duplicated with live code using: $ git clone https://github.com/weidai11/cryptopp.git $ cd cryptopp $ CXXFLAGS="-DNDEBUG -g2 -O3 -fanalyzer -save-temps" make ecp.o ... Attached is the output with a -save-temps. This may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034. == In file included from ecp.h:10, from ecp.cpp:7: integer.h: In static member function ‘static void std::_Destroy_aux< >::__destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = CryptoPP::WindowSlider*; bool = false]’: integer.h:49:20: warning: dereference of NULL ‘__first’ [CWE-690] [-Wanalyzer-null-dereference] 49 | class CRYPTOPP_DLL Integer : private InitializeInteger, public ASN1Object |^~~ ‘std::vector<_Tp, _Alloc>::pointer std::vector<_Tp, _Alloc>::_M_allocate_and_copy(std::vector<_Tp, _Alloc>::size_type, _ForwardIterator, _ForwardIterator) [with _ForwardIterator = const CryptoPP::WindowSlider*; _Tp = CryptoPP::WindowSlider; _Alloc = std::allocator]’: events 1-2 | |/usr/include/c++/10/bits/stl_vector.h:1508:2: | 1508 | _M_allocate_and_copy(size_type __n, | | ^~~~ | | | | | (1) entry to ‘std::vector::_M_allocate_and_copy’ |.. | 1511 |pointer __result = this->_M_allocate(__n); | | ~~ | || | |(2) calling ‘std::_Vector_base >::_M_allocate’ from ‘std::vector::_M_allocate_and_copy’ | +--> ‘std::_Vector_base<_Tp, _Alloc>::pointer std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = CryptoPP::WindowSlider; _Alloc = std::allocator]’: events 3-6 | | 343 | _M_allocate(size_t __n) | | ^~~ | | | | | (3) entry to ‘std::_Vector_base >::_M_allocate’ |.. | 346 | return __n != 0 ? _Tr::allocate(_M_impl, __n) : pointer(); | | ~~ | | | | | | | (5) ...to here | | | (6) ‘‘result_decl’ not supported by dump_expr’ is NULL | | (4) following ‘false’ branch (when ‘__n == 0’)... | <--+ | ‘std::vector<_Tp, _Alloc>::pointer std::vector<_Tp, _Alloc>::_M_allocate_and_copy(std::vector<_Tp, _Alloc>::size_type, _ForwardIterator, _ForwardIterator) [with _ForwardIterator = const CryptoPP::WindowSlider*; _Tp = CryptoPP::WindowSlider; _Alloc = std::allocator]’: event 7 | | 1511 |pointer __result = this->_M_allocate(__n); | | ~^ | || | |(7) return of NULL to ‘
[Bug analyzer/95043] New: GCC 10 Analyzer and false positive on 'memcpy(dest, src, count);'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95043
Bug ID: 95043
Summary: GCC 10 Analyzer and false positive on 'memcpy(dest,
src, count);'
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 48500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48500&action=edit
Preprocessed source file idea.ii
Hi Everyone,
I'm trying out the analyzer on a C++ project. I'm working on Fedora 32 with GCC
10.
$ gcc --version
gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.14)
Here's what I am seeing:
| 527 | if (src && dest)
| | ~~
| | |
| | (9) ...to here
| | (10) following ‘true’ branch...
| 528 | memcpy(dest, src, count);
| |
| | | |
| | | (12) argument 1 (‘dest’) NULL where non-null expected
Here's the source file:
https://github.com/weidai11/cryptopp/blob/master/misc.h#L506. And the function
(with extra noise omitted):
inline void memcpy_s(void *dest, size_t sizeInBytes, const void *src, size_t
count)
{
if (count > sizeInBytes)
throw InvalidArgument("memcpy_s: buffer overflow");
if (src && dest)
memcpy(dest, src, count);
}
I have not been able to reproduce this with a reproducer. The reproducer shown
below fails to tickle the issue.
Attached is the preprocessed source file with the problem, idea.ii.tar.gz.
==
The reproducer shown below fails to reproduce the issue.
$ cat test.cxx
#include
#include
#include
#include
inline void
my_memcpy(void* dest, size_t sizeInBytes, const void* src, size_t count)
{
if (count > sizeInBytes)
throw std::runtime_error("Overflow");
if(dest && src)
memcpy(dest, src, count);
}
int main(int argc, char* argv[])
{
char buf[16];
my_memcpy(NULL, 16, argv[0], strlen(argv[0]));
return 0;
}
[Bug analyzer/95031] GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95031 --- Comment #3 from Jeffrey Walton --- (In reply to David Malcolm from comment #2) > Please note that C++ isn't supported in the -fanalyzer implementation in GCC > 10. I hope to get it working for GCC 11 (but there's a lot of work to do). Oh, sorry about that. That explains a lot. You might want to add that information to https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/. Maybe even add an example of the unexpected beahvior when using C++. I started the Analyzer testing after reading the blog.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #7 from Jeffrey Walton 2012-08-21 22:08:38 UTC --- (In reply to comment #1) > Also using -fPIC instead of -fPIE is always ok. So I doubt there is a really > issue here. Since the differences between PIC and PIE comes down to if > symbols > are overridable. PIC is conservative at optimizing. -fPIC/-pic apparently breaks other GNU tools: ./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC -pic -Wno-unused-parameter -Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now" checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/home/jeffrey/sipwitch-1.3.1': configure: error: C compiler cannot create executables See `config.log' for more details
[Bug other/50610] New: G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt, c++ templates, template class files)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
Bug #: 50610
Summary: G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt,
c++ templates, template class files)
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: noloa...@gmail.com
Created attachment 25407
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25407
Test case for bad code generation at -O2
Attached is a test program which uses a secure vector. The secure vector 'has
a' standard vector, and attempts to do a few extra things to help ensure safe
use (such as check for pointer wrap and zeroization). In addition, the secure
vector uses LeBlanc's SafeInt class to check for wraps and overflows. (SafeInt
uses unsigned, so no undefined behavior should be present).
The test program incorrectly rejects a valid input:
$ g++ -g -O2 -fwrapv -I. TestMain.cpp SecureArray.cpp -o TestMain.exe
$ ./TestMain.exe
Array pointer wrap
$
TestMain is as follows:
try
{
const int arr[] = { 1, 1, 1, 1 };
SecureIntArray vv(arr, COUNTOF(arr));
assert(vv.size() == 4);
}
catch(const std::exception& ex)
{
cerr << ex.what() << endl;
}
The SecureIntArray ctor calls into a helper function:
template
typename SecureArray::SecureVector*
SecureArray::create_secure_array(const T* ptr, size_t cnt)
{
try
{
const size_t base = (size_t)ptr;
SafeInt si(cnt);
si *= sizeof(T);
si += base;
}
catch(const SafeIntException&)
{
throw InvalidArgumentException("Array pointer wrap");
}
return new SecureVector(ptr /*first*/, ptr+cnt /*last*/);
}
*If* I manually check for overflow (ie, no SafeInt use), I get expected
results:
$ g++ -g -O2 -DSECURE_ARRAY_NO_SAFE_INT=1 -I. TestMain.cpp SecureArray.cpp -o
TestMain.exe
$ ./TestMain.exe
$
Defining SECURE_ARRAY_NO_SAFE_INT uses the following rather than SafeInt
objects:
const size_t b = (size_t)ptr;
size_t p = cnt * sizeof(T) + b;
if(!(p >= b))
throw InvalidArgumentException("Array pointer wrap");
Finally, the issue is not present on other versions of GCC. Other versions
include 4.5 from F14 and 4.6 from F15.
I was not able to reduce the test program to something smaller (though I
tried). For example, I know the following will not help the problem: removing
namespaces, removing throws, removing explicit template instantiations, moving
bodies into the header, and a few other items.
I do know that removing everything except the ctor, size(), max_size(), and
operator[] will fix it, but it does not help with a minimum test case.
[Bug other/50610] G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt, c++ templates, template class files)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610 --- Comment #1 from Jeffrey Walton 2011-10-04 04:07:17 UTC --- My bad: jeffrey@studio:~/Desktop/safeint-opt-test$ gcc --version gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 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. jeffrey@studio:~/Desktop/safeint-opt-test$ uname -a Linux studio 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC 2011 x86_64 GNU/Linux jeffrey@studio:~/Desktop/safeint-opt-test$
[Bug other/50610] G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt, c++ templates, template class files)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
--- Comment #2 from Jeffrey Walton 2011-10-04
05:24:20 UTC ---
For this problem, the work around was:
try
{
const T* base = ptr;
base += SafeInt(cnt);
}
catch(const SafeIntException&)
{
throw InvalidArgumentException("Array pointer wrap");
}
It seems LeBlanc had it all the time, but I was not using it. My apologies.
[Bug c/52747] New: No warning from toolchain with nested function and --noexecstack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52747
Bug #: 52747
Summary: No warning from toolchain with nested function and
--noexecstack
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: noloa...@gmail.com
According to GCC docs, nested functions and no-exec stacks are mutually
exclusive. Using both does not generate a warning.
$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 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.
$ uname -a
Linux ubuntu-11-x64 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
$ cat warn-test.c
// gcc -fPIE -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,noexecheap
warn-test.c -o warn-test.exe
#include
int main(int argc, char* argv[])
{
void foo()
{
printf("%d\n", argc);
if(argv)
printf("%p\n", argv);
}
foo();
return 0;
}
$ gcc -fPIE -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,noexecheap
warn-test.c -o warn-test.exe
/usr/bin/ld: warning: -z noexecheap ignored.
$ ./warn-test.exe
[Bug c/52747] No warning from toolchain with nested function and --noexecstack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52747
--- Comment #3 from Jeffrey Walton 2012-03-28
14:33:38 UTC ---
Ah, OK. -Wtrampolines works. But I'm not seeing a warning about the loss of
no-exec stacks:
int main(int argc, char* argv[])
{
(void)argc;
(void)argv;
void foo()
{
printf("main: %p\n", &main);
printf("argv: %p\n", argv);
printf("foo: %p\n", &foo);
}
foo();
return 0;
}
$ gcc -Wall -Wextra -fPIE -Wtrampolines -Wl,-z,relro -Wl,-z,now
-Wl,-z,noexecstack -Wl,-z,noexecheap warn-test.c -o warn-test.exe
warn-test.c: In function ‘main’:
warn-test.c:10:8: warning: trampoline generated for nested function ‘foo’
[-Wtrampolines]
/usr/bin/ld: warning: -z noexecheap ignored.
$ ./warn-test.exe
main: 0x4005c7
argv: 0x7fff65a9a138
foo: 0x7fff65a9a028
[Bug c/52747] No warning from toolchain with nested function and --noexecstack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52747 --- Comment #5 from Jeffrey Walton 2012-03-28 14:52:29 UTC --- My apologies for the additional comments. $ checksec.sh --file ./warn-test.exe RELRO STACK CANARY NXPIE RPATH RUNPATH FILE Full RELRO Canary found NX enabledNo PIE No RPATH No RUNPATH ./warn-test.exe So, it appears I have a trampoline, and NX is enabled? When I run the program, I do not segfault: And PIE caught me off guard considering -fPIE and: $ cat /proc/sys/kernel/randomize_va_space 2
[Bug c/52753] New: GCC not honoring -fPIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52753
Bug #: 52753
Summary: GCC not honoring -fPIE
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: noloa...@gmail.com
It appears GCC 4.6.1 is not honoring -fPIE under all circumstances. Below, I
expect to see "Elf file type is DYN"
$ cat warn-test.c
#include
int main(int argc, char* argv[])
{
(void)argc;
(void)argv;
printf("argc: %d\n", argc);
printf("argv: %p\n", argv);
printf("main: %p\n", &main);
return 0;
}
$ gcc -Wall -Wextra -O2 -fPIE -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
-Wl,-z,noexecheap warn-test.c -o warn-test.exe/usr/bin/ld: warning: -z
noexecheap ignored.
$ ./warn-test.exe
argc: 1
argv: 0x7fffe3139e28
main: 0x400440
$ ./warn-test.exe
argc: 1
argv: 0x7fffbd2864f8
main: 0x400440
$ readelf -l warn-test.exe | grep "Elf file type"
Elf file type is EXEC (Executable file)
$ cat /proc/sys/kernel/randomize_va_space 2
2
$ uname -a
Linux mint-12-x64 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 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.
[Bug c/52753] GCC not honoring -fPIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52753 --- Comment #2 from Jeffrey Walton 2012-03-28 16:18:58 UTC --- Thanks Andreas. Forgive my ignorance, but what does -fPIE do exactly (if not enable Position Independent Executables)?
[Bug other/52885] New: Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 Bug #: 52885 Summary: Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: noloa...@gmail.com When writing makefiles or using automake and friends, its currently not possible to to supply 'generic' set of flags via CFLAGS (or CXXFLAGS) and produce position independent code and utilize layout randomization. For example the following will properly setup makefiles for programs, but not shared objects: $ configure CFLAGS="-Wall -Wextra -Wconversion -fPIE -pie -Wno-unused-parameter -Wformat=2 -Wformat-security -fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now" Others have also felt the discomfort: http://lists.fedoraproject.org/pipermail/devel-announce/2011-August/000821.html. Please provide a switch that allows us to use position independent code and layout randomization that works on both programs and shared objects. I suggest the switch "-aslr" or "-ASLR".
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #3 from Jeffrey Walton 2012-04-24 04:32:35 UTC --- (In reply to comment #2) > GCC is not a mind reader. I kind of knew that. > There is no way for GCC to know if you want to do > PIC or PIE code. Forgive my ignorance, but why does it matter at the code generation stage? How are relocations different in the object code of a program versus a shared object? At code generation, I did not think there was even the concept of program or shared object.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #4 from Jeffrey Walton 2012-04-24 04:34:42 UTC --- (In reply to comment #1) > > Also how can you tell the difference between compiling for executable and > shared library if you don't supply -fPIC? So adding -aslr is not going to be > useful really. The compiler driver would make the determination at link time, and pass the appropriate switch to the linker. I did not think it was a difficult concept. My apologies.
[Bug other/52885] Request: Add -aslr switch that invokes -fPIE/-pie or -fPIC/-shared as appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 --- Comment #6 from Jeffrey Walton 2012-04-24 04:38:54 UTC --- (In reply to comment #5) > >At code generation, I did not think there was even the concept of program or > >shared object. > > And this is where you are wrong. GCC has a concept of program vs shared > library. My apologies. I was not aware that object code had a gender (program versus shared object).
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #12 from Jeffrey Walton --- (In reply to Arseny Solokha from comment #11) > I believe this is irrelevant by now. Yeah, no doubt. May as well close it.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 Jeffrey Walton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #13 from Jeffrey Walton --- Obsolete.
[Bug target/78782] [x86] _mm_loadu_si64 intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78782 --- Comment #1 from Jeffrey Walton --- Also documented in the Intel Intrinsics Guide at https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_loadu_si64. According to the guide, the intrinsic is the movq instruction.
[Bug target/71659] _xgetbv intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659 --- Comment #3 from Jeffrey Walton --- (In reply to postmaster from comment #2) > Portability is one main reason to add missing intrinsics... with combination > of cpuid check and _xgetbv() we can cleanly check if AVX or MPX is available > at run-time. We can also check specific instructions during configure > process to see if we need to add workarounds for bad or missing > functions/intrinsics. +1. We were trying to use Intel's algorithm described at https://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled . We should only need __get_cpuid and _xgetbv. We should not need that nasty GCC inline assembly.
[Bug c++/70413] Class template names in anonymous namespaces are not globally unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70413 --- Comment #4 from Jeffrey Walton --- Bumping this. We ran into a similar issue in GCC 6.3.0 on ARM with -flto. openSUSE enabled LTO by default, so we added a test case for all platforms which support LTO (including Debian with its stale packages that never get updated).
[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481 --- Comment #3 from Jeffrey Walton --- Lloyd's finding can be confirmed on GCC135. For example, gcc135:~$ /opt/at12.0/bin/gcc -O3 -mcpu=power9 -m64 darn.c -o darn gcc135:~$ ./darn 9FBE0B8B6E861BD6 9FBE0B8B6E861BD6 9FBE0B8B6E861BD6 9FBE0B8B6E861BD6 ... I can't find a header with a declaration, though: gcc135:~$ grep -IR builtin_darn /opt/at12.0/ 2>/dev/null gcc135:~$ grep -IR builtin_darn /lib 2>/dev/null gcc135:~$ Does someone know where the header is located?
[Bug c/91744] New: -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744
Bug ID: 91744
Summary: -fno-pie is not honored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
From Initial SUPERCOP Haswell results for round 2
(https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/kiMo-1jBwDI/KS8VtDwWAgAJ):
$ cat x.c
#include
extern int thenumber(void);
int main() { printf("%d\n",thenumber()); return 0; }
$ cat y.c
static int myconstant = 5;
int thenumber(void) { return myconstant; }
And then:
$ gcc -c x.c; clang -c y.c; gcc -o x x.o y.o
/usr/bin/ld: y.o: relocation R_X86_64_32S against `.data' can not be used when
making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
And finally with -fno-pie:
$ gcc -c x.c; clang -c y.c; gcc -fno-pie -o x x.o y.o
/usr/bin/ld: y.o: relocation R_X86_64_32S against `.data' can not be used when
making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
[Bug c/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 --- Comment #1 from Jeffrey Walton --- My bad, this should have been included: $ lsb_release -rd Description:Ubuntu 18.04.3 LTS Release:18.04 $ gcc --version gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 Copyright (C) 2017 Free Software Foundation, Inc.
[Bug other/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 --- Comment #3 from Jeffrey Walton --- (In reply to Andrew Pinski from comment #2) > You want -no-pie; not -fno-pie. > -no-pie turns off the linking and -fno-pie just turns off the compiler > option. Thanks Andrew.
[Bug c++/82209] Compile error "X causes a section type conflict with Y" should provide more information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209 --- Comment #7 from Jeffrey Walton --- (In reply to Eric Gallager from comment #6) > (In reply to Eric Gallager from comment #5) > > (In reply to Jeffrey Walton from comment #4) > > > This is kind of weird... When we tested with C++03 by adding -std=c++03, > > > we > > > got 4 more of them. The check-in of interest is > > > https://github.com/weidai11/cryptopp/commit/7097546cfcf742cf. > > > > > > Is there really no way to troubleshoot or diagnose this? I'd really like > > > to > > > know what the section name is that's causing the problem. > > > > Have you tried using gdb yet as I suggested in comment #3? > > With no backtrace and no testcase, I'm afraid there's nothing I can do to > reproduce this. Closing accordingly, but feel free to reopen if you have > more information. Thanks Eric. For completeness, I asked for an improved diagnostic (and not help with a particular problem). The diagnostic message needs help because it lacks useful information, like the offending section. I still don't know what the problem section is.
[Bug sanitizer/83961] New: AddressSanitizer CHECK failed on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83961
Bug ID: 83961
Summary: AddressSanitizer CHECK failed on Aarch64
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail 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: ---
I'm working on GCC117 which is an Aarch64 machine at the compile farm
(gcc117.fsffrance.org).
$ cat test.cxx
#include
int main(int argc, char* argv[])
{
return argc;
}
$ g++ -fsanitize=address test.cxx -o test.exe
$ ./test.exe
==32239==AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator.h:844
"((res)) < ((kNumPossibleRegions))" (0xaf0, 0x800)
<^C to break>
$ g++ -dumpmachine
aarch64-linux-gnu
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/6/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=aarch64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-arm64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-arm64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-arm64
--with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-multiarch --enable-fix-cortex-a53-843419 --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18)
This may be relevant:
$ command -v g++
/usr/bin/g++
$ /usr/bin/g++ --version
g++ (Debian 6.3.0-18) 6.3.0 20170516
$ dpkg -S libasan
libgcc-6-dev:arm64: /usr/lib/gcc/aarch64-linux-gnu/6/libasan.a
libasan3:arm64: /usr/lib/aarch64-linux-gnu/libasan.so.3.0.0
libasan3:arm64: /usr/lib/aarch64-linux-gnu/libasan.so.3
libgcc-6-dev:arm64: /usr/lib/gcc/aarch64-linux-gnu/6/libasan.so
libgcc-6-dev:arm64: /usr/lib/gcc/aarch64-linux-gnu/6/libasan_preinit.o
libasan3:arm64: /usr/share/doc/libasan3
$ dpkg -S gcc-6 | grep -v doc
gcc-6: /usr/share/lintian/overrides/gcc-6
libstdc++6:arm64: /usr/share/gcc-6/python/libstdcxx/v6/__init__.py
gnat-6: /usr/bin/gcc-6-6
libstdc++6:arm64: /usr/share/gcc-6/python
gcc-6: /usr/bin/gcc-6
libstdc++6:arm64: /usr/share/gcc-6
libstdc++6:arm64: /usr/share/gcc-6/python/libstdcxx
libstdc++6:arm64: /usr/share/gcc-6/python/libstdcxx/__init__.py
libstdc++6:arm64: /usr/share/gcc-6/python/libstdcxx/v6/xmethods.py
gcc-6: /usr/bin/aarch64-linux-gnu-gcc-6
libstdc++6:arm64: /usr/share/gcc-6/python/libstdcxx/v6
libstdc++6:arm64: /usr/share/gcc-6/python/libstdcxx/v6/printers.py
[Bug sanitizer/83961] AddressSanitizer CHECK failed on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83961 --- Comment #1 from Jeffrey Walton --- It looks like it was reported to the Ubuntu folks at https://bugs.launchpad.net/ubuntu/+bug/1709727, but I could not find a GCC report. There is also a gcc-6 patch.
[Bug sanitizer/83961] AddressSanitizer CHECK failed on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83961 --- Comment #3 from Jeffrey Walton --- (In reply to Jakub Jelinek from comment #2) > AFAIK AArch64 has multiple configurable sizes of the virtual address space > and older GCCs like 6 was only supporting one of those sizes, not all of > them. > So, when not using GCC 7 or later, one has to patch libsanitizer when not > using the address space size in the kernel that the library is expecting. > This is a distro problem IMHO. > Marking as fixed in GCC 7, WONTFIX for older versions. Thanks Jakub, I'd like to say GCC should patch 6 but I don't know how big a job that is. It sounds like it is more than a few lines of code so I can't beg for it. I'm guessing libasan never should have been installed in the first place. I guess an uninstall of libasan is in order for GCC117. Would you happen to know how to tell when libasan is not compatible with the host's OS? A related question is, where are the docs on properly configuring libasan during build time? This may be the preferred option, but people need to know how to do it. Thanks.
[Bug c++/91066] New: GCC does not provide XOP functions through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91066
Bug ID: 91066
Summary: GCC does not provide XOP functions through
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This is a tad bit unusual since we can use SSE2, SSE3, ..., AVX, AVX2 as
expected.
According to the GCC docs and -march=bdver1, the arch does enable XOP as
expected (https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/x86-Options.html).
However, the XOP functions are not available through either
(http://www.g-truc.net/post-0359.html) or
(https://docs.microsoft.com/en-us/cpp/intrinsics/x64-amd64-intrinsics-list?view=vs-2019).
bulldozer:cryptopp$ cd ..
bulldozer:~$ g++ -march=bdver1 -msse4.1 test.cxx
test.cxx: In function ‘int main(int, char**)’:
test.cxx:15:9: error: ‘_mm_roti_epi64’ was not declared in this scope
b = _mm_roti_epi64(a, 1);
^~
test.cxx:15:9: note: suggested alternative: ‘_mm_rorv_epi64’
b = _mm_roti_epi64(a, 1);
^~
_mm_rorv_epi64
bulldozer:~$ cat test.cxx
#ifdef __XOP__
#include
#include
#endif
#ifdef __SSE41__
#include
#endif
int main(int argc, char* argv[])
{
__m128i a=_mm_setzero_si128(), b=_mm_setzero_si128(), c;
#ifdef __XOP__
b = _mm_roti_epi64(a, 1);
#endif
#ifdef __SSE41__
c = _mm_blend_epi16(a, b, 0);
#endif
return 0;
}
And:
$ gcc --version
gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
$ lsb_release -a
Distributor ID: Fedora
Description:Fedora release 29 (Twenty Nine)
Release:29
Codename: TwentyNine
[Bug web/87190] New: Feedback on documentation for symbol visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
Bug ID: 87190
Summary: Feedback on documentation for symbol visibility
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This is general feedback on symbol visibility documentation. I feel like the
docs are lacking some important information and it makes a resulting shared
object appear to not meet expectations.
The docs I am referring to:
* https://gcc.gnu.org/wiki/Visibility
* https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
At the highest level, the docs say to use -fvisibility=hidden (and perhaps
-fvisibility-inlines-hidden) to hide all symbols. Then the user is expected to
use DLL_PUBLIC (from the Visibility wiki) to unhide symbols and create a public
API.
This works as expected when a shared object does not depend on other libraries.
Something like:
$ cat bar.c
extern "C" DLL_PUBLIC
int DoBar(int n)
{
...
return 0;
}
$ gcc -fvisibility=hidden -shared bar.c -o libbar.so
The result is something like the following, which is expected. It is consistent
with the documents.
$ nm -gCD libbar.so | grep ' T '
$ 000184e8 T _fini
$ 69d0 T _init
$ 95b0 T DoBar
Now, here's where the problem crops in. Suppose Bar depends on Foo and Foo was
not built with visibility. This is very common, even among some distro provided
libraries. Remember the docs say _all_ symbols are private (not _some_
symbols).
$ gcc -fvisibility=hidden -shared bar.c ./libfoo.a -o libbar.so
The results will be similar to the following. Notice the count grows from 3 to
the number of symbols available in libfoo.a.
$ nm -gCD libbar.so | grep ' T ' | wc -l
816
In the second example GCC drove compile and link but not all symbols were
private. To make them private we have to add linker options:
$ gcc -fvisibility=hidden -shared bar.c ./libfoo.a -o libbar.so
-Wl,--exclude-libs,All
This is the point of contention for me because the docs say all symbols are
private unless DLL_PUBLIC is used (from the Visibility wiki) to unhide symbols.
I think the docs could be more clear on both the GCC options page and the
Visibility wiki. I think two ro three things should be stated for completeness.
First, instead of saying all symbols are private when using the options, maybe
the docs should say "symbols in the translation unit being compiled are
private, and not all symbols in the program or library".
Second, the docs might clearly state -fvisibility=hidden (and friends) only
applies to the compiler. The compiler does not pass down
"-fvisibility=hidden"-like options to the linker.
Third, the docs should say something like "additional linker switches may be
required to hide all symbols in a shared object. For the GNU linker LD, LDFLAGS
should include -Wl,--exclude-libs,All. Other linkers may require additional
options."
The second suggestion may seem obvious but it is not. We are told to use the
compiler to drive link, and the compiler doing so with -fsanitize=undefined or
-fsanitize=address works as expected. That is we don't need to manually add
libraries by hand.
I was looking for some past/similar issues but I did not find a good one. Maybe
no one is using the feature or no one noticed. I did find this one, which seems
to be a symptom of the confusion:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218.
It is fascinating reading Andrew Pinski and H.J. Lu discussing the behavior and
externalities like the ELF specs (I did not even consider the effects of the
ELF specification). But at the end of the day the GCC docs say all the symbols
are private but it is possible to arrive at a program or shared library where
some symbols are private.
If someone is willing to make the leap that GCC should take the
-fvisibility=hidden compiler option and turn it into a linker option like
-Wl,--exclude-libs,All (when driving link), then this could be a GCC issue. I'd
personally like to see it happen, but I am not willing to go that far and make
the leap.
[Bug web/87190] Feedback on documentation for symbol visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190 --- Comment #1 from Jeffrey Walton --- In case it is needed, here's the citation for "Remember the docs say all symbols are private (not some symbols)": https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html: Set the default ELF image symbol visibility to the specified option—all symbols are marked with this unless overridden within the code. Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute...
[Bug sanitizer/84508] New: Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
Bug ID: 84508
Summary: Load of misaligned address using _mm_load_sd
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail 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: ---
According to Intel
(https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no
alignment requirements for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd. For
example, from _mm_load_sd:
Description
Load a double-precision (64-bit) floating-point element from
memory into the lower of dst, and zero the upper element.
mem_addr does not need to be aligned on any particular boundary.
$ gcc --version
gcc (Debian 6.3.0-18) 6.3.0 20170516
$ cat test.c
#include
int main(int argc, char* argv[])
{
unsigned char t[16+1];
__m128i x = _mm_castpd_si128(_mm_load_sd((const double *)(t+1)));
_mm_store_pd((double*)t, _mm_castsi128_pd(x));
return 0;
}
$ gcc -fsanitize=undefined test.c -o test.exe
$ ./test.exe
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:140:10: runtime error: load
of misaligned address 0x7ffc768309b1 for type 'const double', which requires 8
byte alignment
0x7ffc768309b1: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 79 38 ee ca 7f
00 00 98 7e 38 ee ca
^
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #1 from Jeffrey Walton ---
__m128d is a tad bit cleaner. It does not require the casts.
$ cat test.c
#include
int main(int argc, char* argv[])
{
unsigned char t[16+1];
__m128d x = _mm_load_sd((const double *)(t+1));
_mm_store_pd((double*)t, x);
return 0;
}
$ gcc -fsanitize=undefined test.c -o test.exe
$ ./test.exe
/usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:140:10: runtime error: load
of misaligned address 0x7ffd1cf2dd11 for type 'const double', which requires 8
byte alignment
0x7ffd1cf2dd11: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 c0 c8 e0 ba c4
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #8 from Jeffrey Walton --- (In reply to Jeffrey Walton from comment #0) > According to Intel > (https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no > alignment requirements for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd. For > example, from _mm_load_sd: > > Description > > Load a double-precision (64-bit) floating-point element from > memory into the lower of dst, and zero the upper element. > mem_addr does not need to be aligned on any particular boundary. The opening sentence was incorrect. The *_sd functions do not have alignment requirements. Searching through the Intrinsic Guide reveals the following functions do not have the alignment requirements: * _mm_load_sd * _mm_store_sd * _mm_load_ss * _mm_loadh_pi * _mm_loadl_pd * _mm_loadl_pi * _mm_loadu_pd * _mm_loadu_ps * _mm_loadu_si128 * _mm_store_sd * _mm_store_ss * _mm_storeu_pd * _mm_storeu_ps * _mm_storeu_si128 All the functions listed above specifically state "mem_addr does not need to be aligned on any particular boundary." The remaining functions have natural alignment or 16-byte alignment requirements.
[Bug rtl-optimization/84753] New: GCC does not fold xxswapd followed by vperm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753
Bug ID: 84753
Summary: GCC does not fold xxswapd followed by vperm
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on GCC112 from the compile farm. It is ppc64-le machine. It has
both GCC 4.8.5 and GCC 7.2.0 installed. The issue is present on both.
We are trying to recover missing 1 to 2 cpb performance when using Power8 SHA
built-ins. Part of the code to load a message into the message schedule looks
like so:
uint8_t msg[64] = {...};
__vector unsigned char mask = {3,2,1,0, 7,6,5,4, 11,10,9,8, 15,14,13,12};
__vector unsigned int t = vec_vsx_ld(0, msg);
t = vec_perm(t, t, mask);
When I compile at -O3 and disassemble it, I see:
18bc: 99 26 20 7c lxvd2x vs33,0,r4
...
18d0: 57 0a 21 f0 xxswapd vs33,vs33
18d8: 2b 08 21 10 vperm v1,v1,v1,v0
Calling xxswapd followed by vperm seems to be a lot like calling shuffle_epi32
followed by shuffle_epi8 on an x86 machine. It feels like the two permutes
should be folded into one.
On x86 I would manually fold the two shuffles. On PPC I cannot because xxswapd
is generated as part of the load, and then I call vperm. I have not figured out
how to avoid the xxswapd. (I even tried to issue my own xxswapd to cancel out
the one being generated by the compiler).
**
Here's a minimal case, but the optimizer is removing the code of interest. The
real code suffers it, and it can be found at
https://github.com/noloader/SHA-Intrinsics/blob/master/sha256-p8.cxx .
$ cat test.cxx
#include
#if defined(__ALTIVEC__)
# include
# undef vector
# undef pixel
# undef bool
#endif
typedef __vector unsigned char uint8x16_p8;
typedef __vector unsigned int uint32x4_p8;
// Unaligned load
template static inline
uint32x4_p8 VectorLoad32x4u(const T* data, int offset)
{
return vec_vsx_ld(offset, (uint32_t*)data);
}
// Unaligned store
template static inline
void VectorStore32x4u(const uint32x4_p8 val, T* data, int offset)
{
vec_vsx_st(val, offset, (uint32_t*)data);
}
static inline
uint32x4_p8 VectorPermute32x4(const uint32x4_p8 val, const uint8x16_p8 mask)
{
return (uint32x4_p8)vec_perm(val, val, mask);
}
int main(int argc, char* argv[])
{
uint8_t M[64];
uint32_t W[64];
uint8_t* m = M;
uint32_t* w = W;
const uint8x16_p8 mask = {3,2,1,0, 7,6,5,4, 11,10,9,8, 15,14,13,12};
for (unsigned int i=0; i<16; i+=4, m+=4, w+=4)
VectorStore32x4u(VectorPermute32x4(VectorLoad32x4u(m, 0), mask), w, 0);
return 0;
}
[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753 --- Comment #2 from Jeffrey Walton --- (In reply to Bill Schmidt from comment #1) > GCC 4.8.5 is out of service. This is fixed in all in-service versions of > GCC (6.4 and later). Interesting. I'm seeing it in GCC 7.2.0. Are you certain of this?
[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753 --- Comment #3 from Jeffrey Walton --- (In reply to Jeffrey Walton from comment #2) > (In reply to Bill Schmidt from comment #1) > > GCC 4.8.5 is out of service. This is fixed in all in-service versions of > > GCC (6.4 and later). > > Interesting. I'm seeing it in GCC 7.2.0. Are you certain of this? Here's an example to make sure we are on the same page. $ /opt/cfarm/gcc-latest/bin/g++ --version g++ (GCC) 7.2.0 $ /opt/cfarm/gcc-latest/bin/g++ -g3 -O3 -Wall -DTEST_MAIN -mcpu=power8 sha256-p8.cxx -o sha256-p8.exe $ objdump --disassemble sha256-p8.exe | c++filt 1880 : 1880: 03 10 40 3c lis r2,4099 1884: 00 81 42 38 addir2,r2,-32512 1888: f0 ff c1 fb std r30,-16(r1) 188c: f8 ff e1 fb std r31,-8(r1) 1890: fe ff 22 3d addis r9,r2,-2 1894: 10 00 c4 3b addir30,r4,16 1898: 70 8e 29 39 addir9,r9,-29072 189c: 10 00 e3 3b addir31,r3,16 18a0: 20 00 84 39 addir12,r4,32 18a4: 20 00 63 39 addir11,r3,32 18a8: 99 4e 00 7c lxvd2x vs32,0,r9 18ac: 30 00 a3 38 addir5,r3,48 18b0: 40 00 23 39 addir9,r3,64 18b4: c4 ff c0 38 li r6,-60 18b8: c0 ff e0 38 li r7,-64 18bc: 99 26 20 7c lxvd2x vs33,0,r4 18c0: 30 00 84 38 addir4,r4,48 18c4: f8 ff 00 39 li r8,-8 18c8: e4 ff 40 39 li r10,-28 18cc: 57 02 00 f0 xxswapd vs32,vs32 18d0: 57 0a 21 f0 xxswapd vs33,vs33 18d4: 97 05 00 f0 xxlnand vs32,vs32,vs32 18d8: 2b 08 21 10 vperm v1,v1,v1,v0 18dc: 57 0a 21 f0 xxswapd vs33,vs33 18e0: 99 1f 20 7c stxvd2x vs33,0,r3 18e4: 18 00 60 38 li r3,24 18e8: a6 03 69 7c mtctr r3 18ec: 99 f6 20 7c lxvd2x vs33,0,r30 18f0: 57 0a 21 f0 xxswapd vs33,vs33 18f4: 2b 08 21 10 vperm v1,v1,v1,v0 18f8: 57 0a 21 f0 xxswapd vs33,vs33 18fc: 99 ff 20 7c stxvd2x vs33,0,r31 1900: 99 66 20 7c lxvd2x vs33,0,r12 1904: 57 0a 21 f0 xxswapd vs33,vs33 1908: 2b 08 21 10 vperm v1,v1,v1,v0 190c: 57 0a 21 f0 xxswapd vs33,vs33 1910: 99 5f 20 7c stxvd2x vs33,0,r11 1914: 99 26 20 7c lxvd2x vs33,0,r4 1918: 57 0a 21 f0 xxswapd vs33,vs33 191c: 2b 08 01 10 vperm v0,v1,v1,v0 1920: 57 02 00 f0 xxswapd vs32,vs32 1924: 99 2f 00 7c stxvd2x vs32,0,r5 1928: 00 00 00 60 nop 192c: 00 00 42 60 ori r2,r2,0 1930: 99 36 09 7c lxvd2x vs32,r9,r6 1934: 99 3e 89 7d lxvd2x vs44,r9,r7 1938: 99 56 a9 7d lxvd2x vs45,r9,r10 193c: 99 46 29 7c lxvd2x vs33,r9,r8 1940: 82 06 00 10 vshasigmaw v0,v0,0,0 1944: 82 7e 21 10 vshasigmaw v1,v1,0,15 1948: 80 60 00 10 vadduwm v0,v0,v12 194c: 80 68 00 10 vadduwm v0,v0,v13 1950: 80 08 00 10 vadduwm v0,v0,v1 1954: 99 4f 00 7c stxvd2x vs32,0,r9 1958: 08 00 29 39 addir9,r9,8 195c: d4 ff 00 42 bdnz1930 1960: f0 ff c1 eb ld r30,-16(r1) 1964: f8 ff e1 eb ld r31,-8(r1) 1968: 20 00 80 4e blr 196c: 00 00 00 00 .long 0x0 1970: 00 09 00 00 .long 0x900 1974: 00 02 00 00 attn 1978: 00 00 00 60 nop 197c: 00 00 42 60 ori r2,r2,0
[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753
--- Comment #7 from Jeffrey Walton ---
(In reply to Bill Schmidt from comment #4)
> ...
>
> The best performance will be achieved by writing this loop entirely using
> inline asm code, with all data loaded/stored using lxvd2x and stxvd2x (no
> swaps), thus in "big-endian element order" (element 0 in the high-order
> position of the register). Because of the big-endian nature of vshasigmaw,
> this is always going to be the best approach.
Thanks Bill.
We are working on your lxvd2x suggestion using inline assembly.
Related, see "GCC vec_xl_be replacement using inline assembly",
https://stackoverflow.com/q/49215090/608639.
-
I'm not sure if I am doing something wrong, or this is a new issue:
$ cat test.cxx
...
typedef __vector unsigned int uint32x4_p8;
uint32x4_p8 VEC_XL_BE(const uint8_t* data, int offset)
{
#if defined(__xlc__) || defined(__xlC__)
return (uint32x4_p8)vec_xl_be(offset, (uint8_t*)data);
#else
uint32x4_p8 res;
__asm(" lxvd2x %x0, %1, %2\n\t"
: "=wa" (res)
: "g" (data), "g" (offset));
return res;
#endif
}
When I use VEC_XL_BE in real life it results in:
$ g++ -DTEST_MAIN -g3 -O3 -mcpu=power8 sha256-p8.cxx -o sha256-p8.exe
/home/noloader/tmp/ccbDnfFr.s: Assembler messages:
/home/noloader/tmp/ccbDnfFr.s:758: Error: operand out of range (32 is not
between 0 and 31)
/home/noloader/tmp/ccbDnfFr.s:983: Error: operand out of range (48 is not
between 0 and 31)
[Bug c++/88078] New: error: '__float128' was not declared in this scope on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88078
Bug ID: 88078
Summary: error: '__float128' was not declared in this scope on
PowerPC
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on GCC112 from the compile farm. I'm having trouble compiling a
program with the C++ compiler.
$ cat test.cxx
#include
#undef vector
#undef pixel
#undef bool
#include
#include
typedef __vector unsigned char uint8x16_p;
uint8x16_p Foo(const unsigned char* ptr)
{
return vec_ld(0, ptr);
}
=
Compiling results in:
$ /opt/cfarm/gcc-latest/bin/g++ -mcpu=power4 -maltivec -c test.cxx
In file included from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/move.h:55,
from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/stl_pair.h:59,
from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/stl_algobase.h:64,
from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/char_traits.h:39,
from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/string:40,
from test.cxx:6:
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/type_traits:335:39:
error: '__float128' was not declared in this scope
struct __is_floating_point_helper<__float128>
^~
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/type_traits:335:39:
note: suggested alternative: 'vec_float2'
struct __is_floating_point_helper<__float128>
^~
vec_float2
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/type_traits:335:49:
error: template argument 1 is invalid
struct __is_floating_point_helper<__float128>
^
In file included from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/cstdlib:77,
from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/ext/string_conversions.h:41,
from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/basic_string.h:6391,
from
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/string:52,
from test.cxx:6:
/home/iulius/autobuild/bin/gcc-8.2.0/include/c++/8.2.0/bits/std_abs.h:101:3:
error: '__float128' does not name a type; did you mean 'vec_float2'?
__float128
^~
vec_float2
=
And finally:
$ /opt/cfarm/gcc-latest/bin/g++ --version
g++ (GCC) 8.2.0
Copyright (C) 2018 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.
[Bug target/88078] error: '__float128' was not declared in this scope on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88078 --- Comment #3 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #2) > For GCC 8.2 using -std=c++14 instead of -std=gnu++14 will disable the > __float128 specializations, avoiding the problem of long double and > __float128 being the same type. Thanks Jonathan.
[Bug sanitizer/88234] New: UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234
Bug ID: 88234
Summary: UBsan and runtime error: signed integer overflow using
unsigned vector
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail 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: ---
I'm working on GCC135 from the compile farm. I'm experiencing a UBsan runtime
error for signed overflow when using unsigned vectors. The algorithms in the
real program depend on unsigned wrap; and not signed overflow.
gcc135:~$ cat test.cxx
#include
#include
#undef vector
#undef pixel
#undef bool
typedef unsigned char byte;
typedef __vector unsigned char uint8x16_p;
typedef __vector unsigned int uint32x4_p;
int main(int argc, char* argv[])
{
uint32x4_p a = { 1795745381, 0, 0, 0 };
uint32x4_p b = { 1359893119, 0, 0, 0 };
uint32x4_p c = vec_add(a, b);
byte x[16];
vec_vsx_st((uint8x16_p)c, 0, x);
for (size_t i=0; i<16; ++i)
printf("%02x ", x[i]);
printf("\n");
return 0;
}
The data "1795745381" and "1359893119" were taken from the first finding at
https://github.com/weidai11/cryptopp/issues/749.
And:
$ /opt/at12.0/bin/c++ -O1 -fsanitize=undefined -std=c++14 test.cxx -o test.exe
gcc135:~$ ./test.exe
test.cxx:15:25: runtime error: signed integer overflow: 1795745381 + 1359893119
cannot be represented in type 'int'
e4 38 17 bc 00 00 00 00 00 00 00 00 00 00 00 00
Finally:
gcc135:~$ /opt/at12.0/bin/c++ --version
c++ (GCC) 8.2.1 20180813 (Advance-Toolchain-at12.0) [revision 263510]
Copyright (C) 2018 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.
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 --- Comment #8 from Jeffrey Walton --- (In reply to Segher Boessenkool from comment #4) > This is documented in the ELFv2 ABI, linked from > https://gcc.gnu.org/readings.html . > > ... > (The vec_vsx_st doesn't have to do with the problem btw. Not that it is > good or anything ;-) ) Yeah, I tried to convert to the C/C++ pointer dereference pattern several times as shown in the literature. I.e., this: byte x[16]; uint8x16_p cc = (uint8x16_p)c; *(uint8x16_p*) &x[0] = cc; Instead of this: byte x[16]; vec_vsx_st((uint8x16_p)c, 0, x); It breaks a lot of our self tests for certain versions of a particular compiler. I narrowed it down to the loads but I could not take it further and develop a reduced case. I don't have the skill to untangle what is happening in ppc asm at -O3. If you want to see something really obscene, then take a look at https://github.com/weidai11/cryptopp/blob/master/ppc_simd.h#L251 . (If you are talking about something else that is wrong or bad, then please point it out.)
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 --- Comment #12 from Jeffrey Walton --- (In reply to Jakub Jelinek from comment #10) > Author: jakub > Date: Thu Nov 29 14:23:21 2018 > New Revision: 266619 > > URL: https://gcc.gnu.org/viewcvs?rev=266619&root=gcc&view=rev > Log: > PR target/88234 > * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): For > vec_add and vec_sub builtins, perform PLUS_EXPR or MINUS_EXPR > in unsigned_type_for instead of vector integral type where overflow > doesn't wrap. > > * gcc.dg/ubsan/pr88234.c: New test. > ... In case it is useful, here are some additional datapoints from the exyernal bug report. It could help provide a little more coverage for the test case. signed integer overflow: 127 + 1 cannot be represented in type 'signed char' signed integer overflow: 7640891576939301132 + 5840696475078001361 cannot be represented in type 'long int' signed integer overflow: -4942790177534073029 + -7262195936335986787 cannot be represented in type 'long int' signed integer overflow: 6625583534739731862 + 7088136013498015297 cannot be represented in type 'long int' signed integer overflow: -5587509538033248007 + -3814479935187347353 cannot be represented in type 'long int' p
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 --- Comment #13 from Jeffrey Walton --- The issue is cleared in GCC 9 from DEC 08 2018. Our self tests pass where they formerly failed. The failures are the reason I wanted a diagnostic run with UBsan. On GCC110 and GCC112 with gcc-9 located at /home/mik/misc/gcc-9, I was able to confirm there are no UBsan findings. I was not able to confirm the fix on GCC135, which is the original problematic machine. I did not find an updated gcc-8 or gcc-9 on GCC135. Thanks for the help.
[Bug middle-end/48580] missed optimization: integer overflow checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #16 from Jeffrey Walton 2013-02-02 17:01:55 UTC --- (In reply to comment #15) > I agree. The main point of all of this is optimization. And in terms of > optimization, one would want to examine some flag immediately after an > operation setting that flag. One would act upon the flag, and then discard it. I somewhat disagree. A program must be correct; it should be secure; and it can be efficient. I'm interested in "correct" and "secure". If a program silently overflows, its surely not correct. If an adversary can do something with the errant result, its not secure either. What's the point in doing something wrong but doing it quickly? Jeff
[Bug c++/70217] New: Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70217
Bug ID: 70217
Summary: Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a
program with std=c++03
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Cygwin 2.4.1/GCC 5.3.0 can no longer compile a program with std=c++03.
$ uname -r
2.4.1(0.293/5/3)
$ gcc --version
gcc (GCC) 5.3.0
$ cat test.cxx
#include
int main(int argc, char* argv[])
{
return 0;
}
$ g++ -DNDEBUG -g2 -O2 -std=c++03 test.cxx -o test.exe
In file included from
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/bits/stl_algo.h:59:0,
from
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/algorithm:62,
from test.cxx:1:
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:214:11: error:
‘::lldiv_t’ has not been declared
using ::lldiv_t;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:220:11: error:
‘::_Exit’ has not been declared
using ::_Exit;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:224:11: error:
‘::llabs’ has not been declared
using ::llabs;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:226:10: error:
‘lldiv_t’ does not name a type
inline lldiv_t
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:230:11: error:
‘::lldiv’ has not been declared
using ::lldiv;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:241:11: error:
‘::atoll’ has not been declared
using ::atoll;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:242:11: error:
‘::strtoll’ has not been declared
using ::strtoll;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:243:11: error:
‘::strtoull’ has not been declared
using ::strtoull;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:245:11: error: ‘::strto
’ has not been declared
using ::strtof;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:246:11: error:
‘::strtold’ has not been declared
using ::strtold;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:254:22: error:
‘__gnu_cxx::lldiv_t’ has not been declared
using ::__gnu_cxx::lldiv_t;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:256:22: error:
‘__gnu_cxx::_Exit’ has not been declared
using ::__gnu_cxx::_Exit;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:258:22: error:
‘__gnu_cxx::llabs’ has not been declared
using ::__gnu_cxx::llabs;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:259:22: error:
‘__gnu_cxx::div’ has not been declared
using ::__gnu_cxx::div;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:260:22: error:
‘__gnu_cxx::lldiv’ has not been declared
using ::__gnu_cxx::lldiv;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:262:22: error:
‘__gnu_cxx::atoll’ has not been declared
using ::__gnu_cxx::atoll;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:263:22: error:
‘__gnu_cxx::strtof’ has not been declared
using ::__gnu_cxx::strtof;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:264:22: error:
‘__gnu_cxx::strtoll’ has not been declared
using ::__gnu_cxx::strtoll;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:265:22: error:
‘__gnu_cxx::strtoull’ has not been declared
using ::__gnu_cxx::strtoull;
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/c++/cstdlib:266:22: error:
‘__gnu_cxx::strtold’ has not been declared
using ::__gnu_cxx::strtold;
^
[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70217 --- Comment #1 from Jeffrey Walton --- Cygwin bug https://sourceware.org/bugzilla/show_bug.cgi?id=19817.
[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70217 --- Comment #2 from Jeffrey Walton --- Cygwin bug https://sourceware.org/bugzilla/show_bug.cgi?id=19817.
[Bug c++/70217] Cygwin 2.4.1 x86_64/GCC 5.3.0 can no longer compile a program with std=c++03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70217 --- Comment #5 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #3) > dup of PR 70176 ? > > My guess is Cygwin uses a new version of newlib which has stricter C headers > that don't define the C99 functions for __cplusplus < 201103L && > __STRICT_ANSI__ Is there anything I can do to help? Do you need a bug report filed against newlib?
[Bug c++/70974] New: armv8-a+crc does not define __ARM_ACLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70974
Bug ID: 70974
Summary: armv8-a+crc does not define __ARM_ACLE
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working with a HiKey dev board. It provides AArch64.
I'm trying to compile a simple program:
$ cat test.cxx
#if (defined(__ARM_NEON__) || defined(__ARM_NEON))
# define NEON_INTRINSICS_AVAILABLE 1
#else
# define NEON_INTRINSICS_AVAILABLE 0
#endif
#if BOOL_NEON_INTRINSICS_AVAILABLE
# include
# if (__ARM_ACLE >= 200)
# include
# endif
#endif
#include
int main(int argc, char* argv[])
{
uint32_t crc = 0;
crc = __crc32b(crc, (uint8_t)0);
return 0
}
Compiling the program results in:
$ g++ -march=armv8-a+crc test.cxx -o test.exe
test.cxx: In function ‘int main(int, char**)’:
test.cxx:19:33: error: ‘__crc32b’ was not declared in this scope
crc = __crc32b(crc, (uint8_t)0);
^
test.cxx:22:1: error: expected ‘;’ before ‘}’ token
}
^
According to "ARM® C Language Extensions Release 2.0"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf),
it looks like GCC is failing to define the necessary preprocessor macros. For
the CRC32 gear, it looks like GCC needs to -D__ARM_ACLE=200.
Also, I'm using GCC 4.9, so __has_include(x) is not available to me.
--
$ g++ -march=armv8-a+crc -dM -E -
[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317 Jeffrey Walton changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #10 from Jeffrey Walton --- I'm not sure why Bugzilla did not return this result when I searched for the instructions earlier. Adding search terms that might help others find this: ADCX adcx ADOX adox
[Bug c++/82112] New: internal compiler error: in fold_convert_loc, at fold-const.c:2262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82112
Bug ID: 82112
Summary: internal compiler error: in fold_convert_loc, at
fold-const.c:2262
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on GCC112 (gcc112.fsffrance.org on the compile farm).
$ cat test.cxx
#include
typedef unsigned char byte;
typedef vector unsigned char uint8x16_p8;
typedef vector unsigned long long uint64x2_p8;
#define ALIGN_DATA(n) __attribute__((aligned(n)))
int main(int argc, char* argv[])
{
ALIGN_DATA(16) const byte c[16] = {
0,1,2,3, 4,5,6,7, 8,9,10,11, 12,13,14,15
};
const uint64x2_p8 mask = vec_ld(0, c);
return 0;
}
==
$ /opt/cfarm/gcc-latest/bin/g++ -c test.cxx
test.cxx: In function 'int main(int, char**)':
test.cxx:13:39: internal compiler error: in fold_convert_loc, at
fold-const.c:2262
const uint64x2_p8 mask = vec_ld(0, c);
^
0x1057fb4b fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc-7.1.0-src/gcc/fold-const.c:2261
0x103b3363 altivec_resolve_overloaded_builtin(unsigned int, tree_node*, void*)
../../gcc-7.1.0-src/gcc/config/rs6000/rs6000-c.c:6223
0x103632bb resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
../../gcc-7.1.0-src/gcc/c-family/c-common.c:7192
0x102a7713 finish_call_expr(tree_node*, vec**,
bool, bool, int)
../../gcc-7.1.0-src/gcc/cp/semantics.c:2406
0x102399b7 cp_parser_postfix_expression
../../gcc-7.1.0-src/gcc/cp/parser.c:6992
0x1023a57f cp_parser_unary_expression
../../gcc-7.1.0-src/gcc/cp/parser.c:8103
0x1023b883 cp_parser_cast_expression
../../gcc-7.1.0-src/gcc/cp/parser.c:8781
0x1023c207 cp_parser_binary_expression
../../gcc-7.1.0-src/gcc/cp/parser.c:8882
0x1023cac7 cp_parser_assignment_expression
../../gcc-7.1.0-src/gcc/cp/parser.c:9169
0x1023d05b cp_parser_constant_expression
../../gcc-7.1.0-src/gcc/cp/parser.c:9439
0x1023e153 cp_parser_initializer_clause
../../gcc-7.1.0-src/gcc/cp/parser.c:21575
0x1023f5eb cp_parser_initializer
../../gcc-7.1.0-src/gcc/cp/parser.c:21515
0x10256ccf cp_parser_init_declarator
../../gcc-7.1.0-src/gcc/cp/parser.c:19332
0x102574cb cp_parser_simple_declaration
../../gcc-7.1.0-src/gcc/cp/parser.c:12777
0x10258393 cp_parser_block_declaration
../../gcc-7.1.0-src/gcc/cp/parser.c:12602
0x10258eff cp_parser_declaration_statement
../../gcc-7.1.0-src/gcc/cp/parser.c:12212
0x1022d5df cp_parser_statement
../../gcc-7.1.0-src/gcc/cp/parser.c:10699
0x1022e74b cp_parser_statement_seq_opt
../../gcc-7.1.0-src/gcc/cp/parser.c:11031
0x1022e857 cp_parser_compound_statement
../../gcc-7.1.0-src/gcc/cp/parser.c:10985
0x10245643 cp_parser_function_body
../../gcc-7.1.0-src/gcc/cp/parser.c:21432
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.
==
$ /opt/cfarm/gcc-latest/bin/g++ --version
g++ (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
[Bug target/82112] internal compiler error: in fold_convert_loc, at fold-const.c:2262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82112 --- Comment #4 from Jeffrey Walton --- Thank you very much Jakub.
[Bug c++/82209] New: Compile error "X causes a section type conflict with Y" should provide more information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209
Bug ID: 82209
Summary: Compile error "X causes a section type conflict with
Y" should provide more information
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
We are catching a compile error under GCC 6.10 on AIX. The error is shown
below. The diagnostic message does not appear to have enough information to
troubleshoot the issue. After 3 hours of knob turning we are still experiencing
the issue.
This error is not too common, but when it hits people seem to suffer. The
questions on Stack Overflow and around the web seem to point to a gap in the
error message. That is, the error message does not provide enough information
and most people guess at the cause of the problem.
I found one question that actually tried to troubleshoot the issue by
identifying the objects, their section and the attributes. The OP was doing
things like inspecting *.ii and *.s files, but he/she could not identify the
conflict. Also see https://stackoverflow.com/q/30005764/608639.
Telling me the objects are conflicting, the X and Y in "X causes a section type
conflict with Y", is a good start. I'd like to request the error message be
improved to include (1) the section of each conflicting object, and (2) the
attributes of the section that are contributing to the conflict.
==
In file included from bench2.cpp:9:0:
gfpcrypt.h: In function 'CryptoPP::DL_PrivateKey_GFP::~DL_PrivateKey_GFP()
[with GP = CryptoPP::DL_GroupParameters_DSA]':
gfpcrypt.h:519:13: error: CryptoPP::DL_PrivateKey_GFP::~DL_PrivateKey_GFP()
[with GP = CryptoPP::DL_GroupParameters_DSA] causes a section type conflict
with void CryptoPP::AllocatorWithCleanup::deallocate(void*,
CryptoPP::AllocatorWithCleanup::size_type) [with T = unsigned
char; bool T_Align16 = true]
virtual ~DL_PrivateKey_GFP() {}
^
In file included from integer.h:20:0,
from validate.h:8,
from bench2.cpp:6:
secblock.h:217:7: note: 'void CryptoPP::AllocatorWithCleanup::deallocate(void*, CryptoPP::AllocatorWithCleanup::size_type) [with T = unsigned char; bool T_Align16 = true]' was
declared here
void deallocate(void *ptr, size_type size)
^~
GNUmakefile:1026: recipe for target 'bench2.o' failed
[Bug c++/82209] Compile error "X causes a section type conflict with Y" should provide more information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209 --- Comment #2 from Jeffrey Walton --- (In reply to Eric Gallager from comment #1) > Do you have a complete standalone testcase we could use to reproduce? Thanks Eric. We were not able to reduce it to a minimal test case. That was part of the pain for us. We found moving the dtor out-of-line fixed the problem. We have no idea why it fixed the problem. Also see https://github.com/weidai11/cryptopp/commit/51752cb91aa6. We also have no idea what caused the problem. The issue was not present going back one week earlier to commit 67bcdaed9abb. We did not twiddle with things like section alignments or attributes. The one thing that changed between now and then was adding Power8 AES through built-ins. The major commits in the series can be found at https://github.com/weidai11/cryptopp/issues/497. But there's nothing special about the commits; they look like AESNI and ARMv8 intrinsics. Maybe the Power8 AES built-ins caused GCC to take slightly different code paths, and that knocked something loose? It would still be nice to get a better message from the compiler when the error surfaces. We dumb-lucked into the fix. We were trying anything we could think of.
[Bug c++/82209] Compile error "X causes a section type conflict with Y" should provide more information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209 --- Comment #4 from Jeffrey Walton --- This is kind of weird... When we tested with C++03 by adding -std=c++03, we got 4 more of them. The check-in of interest is https://github.com/weidai11/cryptopp/commit/7097546cfcf742cf. Is there really no way to troubleshoot or diagnose this? I'd really like to know what the section name is that's causing the problem.
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202 --- Comment #7 from Jeffrey Walton --- Please forgive my ignorance... What was fixed? The problem statement is/was "Please make all headers for intrinsics be includable without special compiler flags." But it appears the intrinsics are not available. I'm working with Ubuntu 16/GCC 5.4 on an old VIA C7 (SSE and SSE2, and some other extensions): flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en The SSSE3 intrinsics are causing a compile error: g++ -g2 -O2 -march=native -pipe -c test.cpp In file included from /usr/lib/gcc/i686-linux-gnu/5/include/x86intrin.h:37:0, from cpu.h:40, from aria.cpp:8: /usr/lib/gcc/i686-linux-gnu/5/include/tmmintrin.h: In member function void ‘test_ssse3()’: /usr/lib/gcc/i686-linux-gnu/5/include/tmmintrin.h:136:1: error: inlining failed in call to always_inline ‘__m128i _mm_shuffle_epi8(__m128i, __m128i)’: target specific option mismatch _mm_shuffle_epi8 (__m128i __X, __m128i __Y) It appears the intrinsics are not available.
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #9 from Jeffrey Walton ---
On Mon, Apr 17, 2017 at 11:04 AM, glisse at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
>
> --- Comment #8 from Marc Glisse ---
> (In reply to Jeffrey Walton from comment #7)
>> It appears the intrinsics are not available.
>
> They are available for functions compiled for a suitable target, for instance
> because of -march or thanks to the target attribute (see the original report).
> It does not make sense to make them always available.
But that's what this bug report is for - to make the intrinsicsalways
available.
This code still does not work:
if (HasAVX())
{
...
}
else if (HasSSSE3())
{
// Use _mm_shuffle_epi8()
}
else if (HasSSE2)
{
// Use _mm_load_si128()
}
else
{
// Use C/C++
}
When a distro compile with just -march=i686 or -march=x86_64, then the
intrinsics would allow us to easy provide the features for modern
cpus. Because the intrinsics are not available, we're back to that
cursed inline assembly (and its wonderful error messages).
Jeff
[Bug target/80377] gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377 --- Comment #6 from Jeffrey Walton --- (In reply to David Malcolm from comment #5) > Likewise, I tried but failed to reproduce it. > > A hunch: given the "-march=native", is there a chance that this bug is > dependent on the precise CPU flags on the host? Thanks David. Well, that's a good question. I was testing on a Skylake, which is 6th gen. It has AVX and AVX2, but it does not have AVX-512. Is there a way I can test it? Another possibility is Fedora 25 has an older version of the autocomplete library that's producing it.
[Bug sanitizer/78204] ‘no_sanitize’ attribute directive ignored [-Wattributes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
--- Comment #4 from Jeffrey Walton ---
(In reply to Martin Liška from comment #3)
> As I'm reading the source code, there's no option to do that.
> Apart from 'no_sanitize' attribute, GCC supports 'no_sanitize_undefined'
> attribute (clang does not) and clang has 'no_sanitize_memory' (not handled
> by GCC).
>
> I welcome the ability to have finer attributes for sanitizer and I can do
> that.
> What's Jakub thinking about it?
(In reply to Martin Liška from comment #1)
> Ok, do I understand it properly that you're missing support of
> no_sanitize("string literals"), as defined here:
>
> http://clang.llvm.org/docs/AttributeReference.html#no-sanitize-clang-no-
> sanitize
It looks like GCC does not support this feature in any compilers (GCC 4 through
7). Is that correct?
(I'm trying to get some macros tuned based on Clang and GCC versions).
[Bug libstdc++/79017] New: Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
Bug ID: 79017
Summary: Old PowerMac G5, MacPorts GCC 5.4, C++11 and
"std::log2 has not been declared"
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on a PowerMac G5. It runs OS X 10.5.8. It has MacPorts installed
for updated gear.
The program:
$ cat test.cxx
#include
int main(int argc, char* argv[])
{
double d = std::log2(2.3456789f);
return 0;
}
Results:
$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
test.cxx: In function 'int main(int, char**)':
test.cxx:4:16: error: 'log2' is not a member of 'std'
double d = std::log2(2.3456789f);
^
test.cxx:4:16: note: suggested alternative:
In file included from /usr/include/math.h:26:0,
from /opt/local/include/gcc5/c++/cmath:44,
from test.cxx:1:
/usr/include/architecture/ppc/math.h:431:15: note: 'log2'
extern double log2( double );
^
Compiler:
$ /opt/local/bin/g++-mp-5 --version
g++-mp-5 (MacPorts gcc5 5.4.0_0) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
...
***
From JW offlist:
#include
int main() {
typedef double_t my_double_t;
typedef float_t my_float_t;
acosh(0.0);
acoshf(0.0f);
acoshl(0.0l);
asinh(0.0);
asinhf(0.0f);
asinhl(0.0l);
atanh(0.0);
atanhf(0.0f);
atanhl(0.0l);
cbrt(0.0);
cbrtf(0.0f);
cbrtl(0.0l);
copysign(0.0, 0.0);
copysignf(0.0f, 0.0f);
copysignl(0.0l, 0.0l);
erf(0.0);
erff(0.0f);
erfl(0.0l);
erfc(0.0);
erfcf(0.0f);
erfcl(0.0l);
exp2(0.0);
exp2f(0.0f);
exp2l(0.0l);
expm1(0.0);
expm1f(0.0f);
expm1l(0.0l);
fdim(0.0, 0.0);
fdimf(0.0f, 0.0f);
fdiml(0.0l, 0.0l);
fma(0.0, 0.0, 0.0);
fmaf(0.0f, 0.0f, 0.0f);
fmal(0.0l, 0.0l, 0.0l);
fmax(0.0, 0.0);
fmaxf(0.0f, 0.0f);
fmaxl(0.0l, 0.0l);
fmin(0.0, 0.0);
fminf(0.0f, 0.0f);
fminl(0.0l, 0.0l);
hypot(0.0, 0.0);
hypotf(0.0f, 0.0f);
hypotl(0.0l, 0.0l);
ilogb(0.0);
ilogbf(0.0f);
ilogbl(0.0l);
lgamma(0.0);
lgammaf(0.0f);
lgammal(0.0l);
llrint(0.0);
llrintf(0.0f);
llrintl(0.0l);
llround(0.0);
llroundf(0.0f);
llroundl(0.0l);
log1p(0.0);
log1pf(0.0f);
log1pl(0.0l);
log2(0.0);
log2f(0.0f);
log2l(0.0l);
logb(0.0);
logbf(0.0f);
logbl(0.0l);
lrint(0.0);
lrintf(0.0f);
lrintl(0.0l);
lround(0.0);
lroundf(0.0f);
lroundl(0.0l);
nan(0);
nanf(0);
nanl(0);
nearbyint(0.0);
nearbyintf(0.0f);
nearbyintl(0.0l);
nextafter(0.0, 0.0);
nextafterf(0.0f, 0.0f);
nextafterl(0.0l, 0.0l);
nexttoward(0.0, 0.0);
nexttowardf(0.0f, 0.0f);
nexttowardl(0.0l, 0.0l);
remainder(0.0, 0.0);
remainderf(0.0f, 0.0f);
remainderl(0.0l, 0.0l);
remquo(0.0, 0.0, 0);
remquof(0.0f, 0.0f, 0);
remquol(0.0l, 0.0l, 0);
rint(0.0);
rintf(0.0f);
rintl(0.0l);
round(0.0);
roundf(0.0f);
roundl(0.0l);
scalbln(0.0, 0l);
scalblnf(0.0f, 0l);
scalblnl(0.0l, 0l);
scalbn(0.0, 0);
scalbnf(0.0f, 0);
scalbnl(0.0l, 0);
tgamma(0.0);
tgammaf(0.0f);
tgammal(0.0l);
trunc(0.0);
truncf(0.0f);
truncl(0.0l);
return 0;
}
Results in:
$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
test.cxx: In function 'int main()':
test.cxx:53:21: error: 'llrint' was not declared in this scope
llrint(0.0);
^
test.cxx:54:23: error: 'llrintf' was not declared in this scope
llrintf(0.0f);
^
test.cxx:55:23: error: 'llrintl' was not declared in this scope
llrintl(0.0l);
^
test.cxx:56:22: error: 'llround' was not declared in this scope
llround(0.0);
^
test.cxx:57:24: error: 'llroundf' was not declared in this scope
llroundf(0.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #1 from Jeffrey Walton --- Also see Issue 53226 in the MacPorts issue tracker. "gcc5 @5.4: error: 'std::log2' has not been declared", https://trac.macports.org/ticket/53226.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #4 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #3) > Jeffrey, could you please add the output of '/opt/local/bin/g++-mp-5 > -dumpmachine' to the Target field of this bug report? Thanks. $ /opt/local/bin/g++-mp-5 -dumpmachine ppc-apple-darwin9 If it matters, the machine is 32-bit by default: $ getconf LONG_BIT 32 But its capable of 64-bit code with -m64 or -arch ppc64.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #5 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #2) > (In reply to Jeffrey Walton from comment #0) > ... ^ > > Because these six functions are missing we treat all C99 math functions as > missing. We could split the checks into two pieces, so we check for these > separately, which would allow the rest of the C99 math library to be > imported into namespace std. > > But OS X 10.5.8 is pretty old, and this might not be worth doing if it > doesn't affect current versions of OS x. The issue seems to affect Android as well: http://stackoverflow.com/q/22922961. I am not sure if its the exact same issue however. Splitting the checks may benefit more than an ancient PowerMac. For what its worth, I keep the antique hardware around for testing on the PowerPC, which is big-endian. Otherwise it would be retired.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #7 from Jeffrey Walton --- (In reply to Jeffrey Walton from comment #5) > (In reply to Jonathan Wakely from comment #2) > ... > > But OS X 10.5.8 is pretty old, and this might not be worth doing if it > > doesn't affect current versions of OS x. > > The issue seems to affect Android as well: > http://stackoverflow.com/q/22922961. I am not sure if its the exact same > issue however. > > Splitting the checks may benefit more than an ancient PowerMac. > > For what its worth, I keep the antique hardware around for testing on the > PowerPC, which is big-endian. Otherwise it would be retired. Wow, this is a surprising statistic (for me)... OS X 10.5 makes up 29.1% of the MacPorts downloads. Its the largest percentage for the OS group. Confer, http://stats.macports.neverpanic.de/os_statistics#osx_version. Also, according to https://trac.macports.org/ticket/53226#comment:5, the issue affects both PPC and Intel machines. So it affects 100% of the architectures (even though PPC makes up less than 2%). I wonder how many Homebrew or Fink users (et al) have similar statistics.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #8 from Jeffrey Walton --- > Wow, this is a surprising statistic (for me)... OS X 10.5 makes up 29.1% of > the MacPorts downloads. Its the largest percentage for the OS group. Confer, > http://stats.macports.neverpanic.de/os_statistics#osx_version. > > Also, according to https://trac.macports.org/ticket/53226#comment:5, the > issue affects both PPC and Intel machines. So it affects 100% of the > architectures (even though PPC makes up less than 2%). > > I wonder how many Homebrew or Fink users (et al) have similar statistics. My bad... I misread the statistic because both OS X 10.11 and 10.5 use green (thanks CL). According to the statistic, OS X 10.5 appears to account for 5% for the group.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #9 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #2) > (In reply to Jeffrey Walton from comment #0) > > test.cxx:53:21: error: 'llrint' was not declared in this scope > >llrint(0.0); > > ^ > > test.cxx:54:23: error: 'llrintf' was not declared in this scope > >llrintf(0.0f); > >^ > > test.cxx:55:23: error: 'llrintl' was not declared in this scope > >llrintl(0.0l); > >^ > > test.cxx:56:22: error: 'llround' was not declared in this scope > >llround(0.0); > > ^ > > test.cxx:57:24: error: 'llroundf' was not declared in this scope > >llroundf(0.0f); > > ^ > > test.cxx:58:24: error: 'llroundl' was not declared in this scope > >llroundl(0.0l); > > ^ > > Because these six functions are missing we treat all C99 math functions as > missing. We could split the checks into two pieces, so we check for these > separately, which would allow the rest of the C99 math library to be > imported into namespace std. This patch for libc++ may be useful to you for OS X 10.6 and below (thanks to KC): https://github.com/jeremyhu/libcxx/commit/720feba4874d4ca3131753dc31af127e3c509c36
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #11 from Jeffrey Walton ---
> Does this C program compile and link on 10.4 and 10.5?
>
> long long llrint(double x);
> long long llrintf(float x);
> long long llrintl(long double x);
> long long llround(double x);
> long long llroundf(float x);
> long long llroundl(long double x);
>
> int main()
> {
> llrint(0.0);
> llrintf(0.0f);
> llrintl(0.0l);
> llround(0.0);
> llroundf(0.0f);
> llroundl(0.0l);
> return 0;
> }
Confirmed it _did not_ compile on OS X 10.5.8. I tried with/without 'extern',
and with/without '-lm'.
Sorry about the false alarm.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #13 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #12)
> What's the error?
My bad...
$ cat test.cxx
// #include
long long llrint(double x);
long long llrintf(float x);
long long llrintl(long double x);
long long llround(double x);
long long llroundf(float x);
long long llroundl(long double x);
int main()
{
llrint(0.0);
llrintf(0.0f);
llrintl(0.0l);
llround(0.0);
llroundf(0.0f);
llroundl(0.0l);
return 0;
}
$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
Undefined symbols for architecture ppc:
"llrint(double)", referenced from:
_main in ccK6psnG.o
"llrintf(float)", referenced from:
_main in ccK6psnG.o
"llrintl(long double)", referenced from:
_main in ccK6psnG.o
"llround(double)", referenced from:
_main in ccK6psnG.o
"llroundf(float)", referenced from:
_main in ccK6psnG.o
"llroundl(long double)", referenced from:
_main in ccK6psnG.o
ld: symbol(s) not found for architecture ppc
collect2: error: ld returned 1 exit status
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #15 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #14) > OK, thanks. I'm not going to try to add declarations like the libc++ patch > does, as it looks like that would only be correct for Snow Leopard and not > earlier. > > I'll just add more fine-grained configure checks and if they're not declared > in then they won't be available, period. There's only so much we > can do to work around buggy C libraries on the target. Ack, thanks. The MacPorts, Brew, Fink (etc) folks thank you.
[Bug libstdc++/71809] compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71809 Jeffrey Walton changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #5 from Jeffrey Walton --- (In reply to sulit from comment #4) > ok Sulit, I'm seeing the issue under Clang 3.5 on Ubuntu 16. Do you have a LLVM bug report for this issue?
[Bug libstdc++/71809] compile llvm3.8.0 failed by the libstdc++ of gcc6.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71809 --- Comment #6 from Jeffrey Walton --- (In reply to Jeffrey Walton from comment #5) > (In reply to sulit from comment #4) > > ok > > Sulit, I'm seeing the issue under Clang 3.5 on Ubuntu 16. Do you have a LLVM > bug report for this issue? Here's a Ubuntu bug report for the issue: https://bugs.launchpad.net/ubuntu/+bug/1654795.
[Bug driver/79974] New: First line of file is printed with unrecognized -mtune x86 option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79974
Bug ID: 79974
Summary: First line of file is printed with unrecognized -mtune
x86 option
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on a VIA C7-D processor. GCC version is 5.4.0 from Ubuntu. I'm
attempting to use GCC's -mtune=c7 option
(https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html):
$ cat test.cxx
// Test file
int main(int argc, char* argv[])
{
return 0;
}
Attempting to compile results in:
$ g++ -march=native -mtune=c7 test.cxx -o test.exe
test.cxx:1:0: error: bad value (c7) for -mtune= switch
// Test file
^
Flagging line 0 of the file seems unusual, especially since its just a comment.
It seems like the -mtune error should be printed and nothing more because the
comment has nothing to do with the issue.
I recall seeing the unusual output on Cygwin when using -fPIC. The Cygwin
behavior was fixed, IIRC.
**
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenial
[Bug c/80377] New: gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377 Bug ID: 80377 Summary: gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’? Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: noloader at gmail dot com Target Milestone: --- >From the low hanging fruit department... I stumbled upon this on Fedora 25 x86_64 with GCC 6.3.1. I'm actually looking for '-mavx512f' (http://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options): $ gcc -g3 -O3 -std=c99 -march=native -mavx512 rot-test.c -o rot-test.exe gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’? ** $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC)
[Bug target/80377] gcc: error: unrecognized command line option ‘-mavx512’; did you mean ‘-mavx512 ’?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377 --- Comment #2 from Jeffrey Walton --- (In reply to David Malcolm from comment #1) > Thanks for filing this. > > Similar to PR c++/72786, and probably worked-around on trunk by r242965; > presumably has a specific root-cause though. Yes, thanks David. They look very similar. I kind of figured the issue surfaced under another diagnostic message. On thing may be different: the suggestion in this issue appears to have extra trailing whitespace. Its slightly different than the 72786 issue, which does not have the extra whitespace in the suggestion.
[Bug c++/67036] GCC does not warn of throwing destructors in C++11, even when they lack noexcept(false) and std::uncaught_exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67036 --- Comment #4 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #3) > VC++ prints: > > main.cpp(7): warning C4297: 'useless::~useless': function assumed not to > throw an exception but does > main.cpp(7): note: destructor or deallocator has a (possibly implicit) > non-throwing exception specification > main.cpp(10): warning C4100: 'argv': unreferenced formal parameter > > This is roughly equivalent to GCC's (in both cases the warning is because > the destructor is implicitly noexcept, so throwing will terminate). > > So FIXED? Yes, it sounds like it. Thanks.
[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885 Jeffrey Walton changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #8 from Jeffrey Walton --- I don't know how much of this observation applies, but: $ ./configure --help | grep sysroot --with-sysroot[=DIR]Search for dependent libraries within DIR (or the compiler's sysroot if not specified). The description does not say anything about headers; it only says libraries. I am certainly not advocating for it. In fact, I came across this bug report because a --with-sysroot (not --with-build-sysroot) is not being honored, and headers seem to be the problem. By the way, when compiling the compiler, I though --host and --target are used. "Build" indicates the machine the tools are running on. So wouldn't that be --with-host-sysroot or --with-target-sysroot?
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #5 from Jeffrey Walton --- (In reply to Dominique d'Humieres from comment #4) > I see the problem after having updated to Xcode 8.0. I am currently testing > the following patch > Just an FYI... Clang 3.7 and below do not witness the problem. Clang 3.8 and above do. If you are working on OS X and want to avoid iTunes accounts and the App Store, then you can duplicate with MacPorts: # port install clang-3.8 # port install gcc6 # ln -s /opt/local/bin/clang /opt/local/bin/clang-3.8 (My apologies if I got the link backwards; I always do it in real life, too). Then: CC=/opt/local/bin/gcc-mp-6 CFLAGS="-Wa,-q" make Creating the link and using the full path allows you to keep MacPorts off-path. I keep it off-path to avoid cross-pollination in a testing environment.
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #8 from Jeffrey Walton --- (In reply to Iain Sandoe from comment #7) > (In reply to Dominique d'Humieres from comment #4) > > I see the problem after having updated to Xcode 8.0. I am currently testing > > the following patch > > > /* The .text section is generated in varasm.c */ > > DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR, > > -".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0) > > +".section __TEXT,__text,coalesced,pure_instructions", 0) > > actually, we need to come up with a patch that simply emits the text/etc. > section whenever it would have emitted the text_coal/etc. one.. So rather > than adjusting section definitions - we need to change which ones are > selected in config/darwin.c > > .. but this should be conditional on a new enough linker to support it, or > we will break support for folks on ancient systems. Is this repeatable > without xcode8? Yes, it is repeatable with Xcode 8. Someone else mentioned they duplicatd with it. > I have some patches in progress to detect the linker features at > configuration time, be careful here. You use the new linker when -wa,-q is present. The new linker is the one in Clang Integrated Assembler. You use the old Apple ld when -Wa,-q is _not_present. Or maybe mor correctly, you just use ld. > so that we don't need to rely on guessing from the host > system version. I _think_ you can detect which linker at runtime with something like the following: IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) -c "GNU assembler") Now, ld returns the string "GNU assembler". Clang returns the string "clang: error: unsupported argument '--version' to option 'Wa,'". The LLVM folks may have fixed it in https://llvm.org/bugs/show_bug.cgi?id=24200. A quick check with Clang-3.8 using MacPort compiler shows its not fixed: $ /opt/local/bin/clang-mp-3.8 -xc -c /dev/null -Wa,--version -o/dev/null 2>&1 clang: error: unsupported argument '--version' to option 'Wa,' > If this is not detectable by a linker feature, them perhaps > we can determine the earliest linker that can manage without the separate > sections (most likely considerably older than the one from Xcode8). I don't know about some of the other options available to you. Maybe the "safety valve" should be another option? I'm already doing "-Wa,-q"; another `-Wa,-x` won't other me. Jeff
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #10 from Jeffrey Walton --- > than adjusting section definitions - we need to change which ones are >> > selected in config/darwin.c >> > >> I _think_ you can detect which linker at runtime with something like the >> following: >> >> IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) >> -c "GNU assembler") >> >> Now, ld returns the string "GNU assembler". Clang returns the string "clang: >> error: unsupported argument '--version' to option 'Wa,'". > > you are conflating two things (and coming to a mixed conclusion as a result): Ah, you're right Ian. I mixed up the assembler and linker. I expereinced so many problem in the past with Clang's integrated assembler, its burned into my frontal lobe. Sorry about that. Jeff
[Bug c/68081] New: Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
Bug ID: 68081
Summary: Cygwin GCC cannot compile program that uses
__builtin_ia32_rdseed64_step
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm testing on Cygwin64. Cygwin64 provides the 5.2.0 compiler.
Attempting to compile the following results in an error:
$ cat rdseed.c
#include
int main()
{
uint64_t val;
__builtin_ia32_rdseed64_step(&val);
return (int)val;
}
The error is:
$ gcc -mrdseed rdseed.c -o rdseed.exe
...
rdseed.c:6:36: error: '__builtin_ia32_rdseed64_step' was not declared in this
scope.
The expected define appears to be defined:
$ cpp -mrdseed -dM
[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
--- Comment #2 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #1)
> Why are you using the builtin directly? You should be using the intrinsics
> form instead.
Its a cross product of (1) that's what the docs tell me to use for RDRAND and
(2) lack of documentation for RDSEED.
The doc I am referring to is
http://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions
lists. It tells me to use "__builtin_ia32_rdrand{16|32|64}_step" for RDRAND.
But it does not tell me what to use for RDSEED. I made the leap I should use
the *_rdseed variants for RDSEED.
(My apologies for the literal read. If I should be doing something different,
then I need to be told to do so :)
[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
--- Comment #3 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Why are you using the builtin directly? You should be using the intrinsics
> > form instead.
>
> Its a cross product of (1) that's what the docs tell me to use for RDRAND
> and (2) lack of documentation for RDSEED.
>
> The doc I am referring to is
> http://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#x86-Built-in-
> Functions lists. It tells me to use "__builtin_ia32_rdrand{16|32|64}_step"
> for RDRAND. But it does not tell me what to use for RDSEED. I made the leap
> I should use the *_rdseed variants for RDSEED.
>
> (My apologies for the literal read. If I should be doing something
> different, then I need to be told to do so :)
By the way, I tried to find RDRAND and RDSEED intrinsic functions in the past:
http://www.google.com/search?q=RDRAND+intrinsic+site:gnu.org . The best I can
tell, they are undocumented.
I did find H.J. Lu's patches that provide __builtin_ia32_rdseed{X}_step, so I
used them instead. They are documented, so I used them.
Its very important (to me) to find provenance in vendor documentation.
[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081 --- Comment #5 from Jeffrey Walton --- (In reply to Marc Glisse from comment #4) > For intrinsics, gcc mostly considers Intel as the standard, so the > documentation would be https://software.intel.com/en-us/node/523865 . Thanks Andrew. Please don't take this in an argumentative manner... Intel is aggressive at times with respect to anti-competivie practices. Intel builds software that is fast for its processors, and slow or non-existent for other maker's CPUs. Microsoft uses Intel intrinsics too, and they even link back to the Intel docs. Microsoft has lots of footnotes that effectively state "does not work with AMD CPUs". Confer, check out the use of footnote [2] at http://msdn.microsoft.com/en-us/library/hh977022.aspx. Does GCC arbitrarily penalize AMD? Should I just do this in ASM and forgo builtins/intrinsics? I had to do it in ASM on Microsoft platforms precisely because of the anti-competivie practices percolated up from Intel. And using the documented GCC functions is proving to be more trouble than its worth. I just checked another Cygwin installation providing X86, and it can't compile the program either. A copy/paste of the code into NASM is not a hardship.
[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081 --- Comment #7 from Jeffrey Walton --- (In reply to Marc Glisse from comment #6) > This comment makes no sense (sorry, couldn't find a nice way to say it). > > > Intel builds software > > We are talking about gcc, not Intel software. Documentation is not fast or > slow. Yeah, I can understand how it can be confusing. One thing I know is Intel now documents some of the penalties for using AMD. The FTC required it in their settlement. How can we determine what applies, and what does not apply, from the various Intel docs? Maybe it would be better if GCC just documented things on its own, and stopped relying on outside documentation? > ... > I was never in favor of documenting those builtins, it makes people believe > that they can use them... I thought I was allowed to use documented functions; and I was not supposed to use undocumented ones. Yeah, this seems to be turned on its head :)
[Bug c++/68316] New: GCC C++ compiler cannot compile a program using RDESED intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316
Bug ID: 68316
Summary: GCC C++ compiler cannot compile a program using RDESED
intrinsics
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
According the Intel docs, RDSEED intrinsics are available in .
Confer,
http://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=rdseed.
However, GCC cannot compile a program using RDSEED and the advertised header.
The same program compiles fine using RDRAND.
It appears the header needed (in this case) is , which does not
appear to be documented anywhere other than this grep:
$ grep -R rdseed /usr/include
/usr/include/clang/3.4/include/rdseedintrin.h:#error "Never use
directly; include instead."
^
This affects GCC 4.8 and 5.2, perhaps more.
**
$ cat rdseed.cxx
#include
#include
int main()
{
unsigned long long val = 0;
_rdseed64_step(&val);
_rdseed32_step(&val);
_rdseed16_step(&val);
std::cout << val << std::endl;
return !val;
}
$ g++ -mrdseed rdseed.cxx -o rdseed.exe
rdseed.cxx: In function ‘int main()’:
rdseed.cxx:7:22: error: ‘_rdseed64_step’ was not declared in this scope
_rdseed64_step(&val);
^
rdseed.cxx:8:22: error: ‘_rdseed32_step’ was not declared in this scope
_rdseed32_step(&val);
^
rdseed.cxx:9:22: error: ‘_rdseed16_step’ was not declared in this scope
_rdseed16_step(&val);
^
**
$ g++ --version
g++ (Debian 5.2.1-20) 5.2.1 20151002
$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
**
Adding a __has_include to guard appears to open another can of
worms:
$ g++ -mrdseed rdseed.cxx -o rdseed.exe
rdseed.cxx:4:45: error: missing binary operator before token "("
#if defined(__has_include) && (__has_include())
^
[Bug c++/68316] GCC C++ compiler cannot compile a program using RDESED intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316 --- Comment #3 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #1) > As the comment says, you need to include not OK, thanks. Here we were told to follow Intels docs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081. We had to go grepping when that did not work. Its very frustrating to determine what we should be doing when the rules become a moving target. Perhaps GCC could document some of this to remove the confusion and ambiguity.
[Bug c++/66852] New: vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
Bug ID: 66852
Summary: vmovdqa instructions issued on 64-bit aligned array,
causes segfault
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
My apologies for *not* having a minimum working example. Sometimes its hard to
craft them, and this is one of those times.
The C++ code below causes a segfault on [relative] line 10 when using GCC
4.9/x86_64 with -O3. Line 10 is:
((word64*)buf)[i] ^= ((word64*)mask)[i];
>From a disassembly, here's the offending code:
0x00539fae <+206>: vmovdqu (%rcx,%r10,1),%xmm0
0x00539fb4 <+212>: vinsertf128 $0x1,0x10(%rcx,%r10,1),%ymm0,%ymm0
0x00539fbc <+220>: vxorps 0x0(%r13,%r10,1),%ymm0,%ymm0
=> 0x00539fc3 <+227>: vmovdqa %ymm0,0x0(%r13,%r10,1)
Looking at vmovdqa requirements, it appears it requires 128-bit aligned words.
However, the array starts as a 'byte*' (unsigned char) and then is cast
depending on the alignment.
In this case, its cast to a 64-bit word pointer. Here is how word64 is defined:
#if defined(_MSC_VER) || defined(__BORLANDC__)
typedef unsigned __int64 word64;
#define W64LIT(x) x##ui64
#else
typedef unsigned long long word64;
#define W64LIT(x) x##ULL
#endif
**
One system:
$ g++ --version
g++ (Debian 4.9.2-10) 4.9.2
$ uname -a
Linux debian-8-x64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24)
x86_64 GNU/Linux
**
Same problem, another system:
$ g++ --version
g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
$ uname -a
Linux localhost.localdomain 4.0.6-200.fc21.x86_64 #1 SMP Tue Jun 23
13:59:12 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
**
I am able to tame the problem with the following, so I guess its a potential
work around (though I'd be happy to get other suggestions):
#pragma GCC optimize push
#pragma GCC optimize ("-O2")
void xorbuf(byte *buf, const byte *mask, size_t count)
{
...
}
#pragma GCC optimize pop
**
void xorbuf(byte *buf, const byte *mask, size_t count)
{
size_t i;
if (IsAligned(buf) && IsAligned(mask))
{
if (!CRYPTOPP_BOOL_SLOW_WORD64 && IsAligned(buf) &&
IsAligned(mask))
{
for (i=0; i
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #1 from Jeffrey Walton --- This also appears to be an issue with GCC 4.8 and 5.1. See https://groups.google.com/d/msg/cryptopp-users/BlPiQ2eAWhg/IsX18wAT9ZAJ.
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #2 from Jeffrey Walton ---
> My apologies for *not* having a minimum working example.
If you want to duplicate it, then:
git clone https://github.com/weidai11/cryptopp.git
Open GNUmakefile, and change to (around line 3):
OPTIMIZE ?= -O3
Depending on when we checkin the fix, you may (or may not) experience the bug.
I don't know how to tell git to checkout a particular revision because it does
not use them. I guess you should do something to get a version of the sources
prior to Sunday, July 12, 2015.
If the proposed fix is applied, then remove the optimize pragma from misc.cpp
(begins around line 20):
#pragma GCC push_options
#pragma GCC optimize ("-O2")
void xorbuf(byte *buf, const byte *mask, size_t count)
{
...
}
#pragma GCC pop_options
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #9 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #8) > The code in algparam.h is just disgusting. AssignFromHelperClass binds a > reference to NULL just to default-construct a temporary of some type, then > binds a const-reference to that temporary, then casts away const to modify > the value of that temporary. What seems to be a "VC60 workaround" introduces > undefined behaviour by trying to be far too clever. Apparently also too > clever to use compiler warnings. Lol... Yeah, some of the legacy code is awful. I'm not throwing stones because the library supported so many compilers and IDEs back then. I think its time to start cleaning up some of the cruft. I'm going to cite this comment when I propose some of the changes.
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #10 from Jeffrey Walton --- (In reply to Richard Biener from comment #6) > So I suppose the IsAligned template is wrong. So I'm clear (please forgive my ignorance)... According to http://www.felixcloutier.com/x86/MOVDQA.html, vmovdqa requires values double quad word alignment (16-byte). A word64 is aligned on 8-bytes, and does not meet the precondition to use the instruction. Naively, that seems like a problem to me. Will that create problems with GCC and vectorizations?
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #11 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #8) > The code in algparam.h is just disgusting. AssignFromHelperClass binds a > reference to NULL just to default-construct a temporary of some type, then > binds a const-reference to that temporary, then casts away const to modify > the value of that temporary. What seems to be a "VC60 workaround" introduces > undefined behaviour by trying to be far too clever. Apparently also too > clever to use compiler warnings. The project is finally using -Wall, and its not flagging any issues with that code. I know -Wdelete-non-virtual-dtor is a problem (and potential security problem), and I'm trying to figure how how to proceed. Cf.https://groups.google.com/d/msg/cryptopp-users/__m0euOdbEQ/tvINItctzjAJ, What additional warnings would you suggest?
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment #14 from Jeffrey Walton ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Yann Collet from comment #9)
> > Looking at the assembler generated, we see that GCC generates a MOVDQA
> > instruction for it.
> > > movdqa (%rdi,%rax,1),%xmm0
> > > $rdi=0x7fffea4b53e6
> > > $rax=0x0
> >
> > This seems wrong on 2 levels :
> >
> > - The function only wants to copy 8 bytes. MOVDQA works on a full SSE
> > register, which is 16 bytes. This spell troubles, if only for buffer
> > boundaries checks : the algorithm uses 8 bytes because it knows it can
> > safely read/write that size without crossing buffer limits. With 16 bytes,
> > no such guarantee.
>
> The function has been inlined into the callers, like:
> do { LZ4_copy8(d,s); d+=8; s+=8; } while (d and this loop is then vectorized. The vectorization prologue of course has
> to adjust if s is not 16 byte aligned, but it can assume that both s and d
> are 8 byte aligned (otherwise it is undefined behavior)...
Forgive my barging in Jakub. I was referred to this issue and comment from
another issue.
Its not clear to me where the leap is made that its OK use vmovdqa. Are you
stating (unequivocally, for folks like me) that is does *not* matter what the
alignment is in the C-sources; and that the prologue ensures both 's' and 's'
are eventually 16-byte aligned when vmovdqa is invoked. That is, when we see
vmovdqa used, we know the alignment is correct (and at 16-bytes).
Sorry to have to ask.
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 --- Comment #16 from Jeffrey Walton --- (In reply to Jakub Jelinek from comment #15) > I'm saying that if the program does not trigger undefined behavior (e.g. by > accessing misaligned integers without telling the compiler about it (by > using memcpy, or packed attribute or pragma), then it would be a compiler > bug to use an instruction requiring higher alignment than guaranteed in the > source, without ensuring such alignment (through realigning arrays, > introducing a loop for aligning pointers before the vectorized loop, peeling > a few iterations needed to align the pointer(s), or using instructions that > don't require such high alignment). > No testcase has been provided here without having undefined behavior in them > that would show a bug on the compiler side. OK, so you'll have to forgive my ignorance again. So you are saying that it may be a bug to use vmovdqa if the source and/or destination are not 16-byte aligned; but all the user code you have seen has undefined behavior so you're not going to answer. Is that correct? (My apologies if its too sharp a point. I'm just trying to figure out what the preconditions are for vmovdqa, and if it should be used when source or destination is 8-byte aligned).
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #13 from Jeffrey Walton --- A quick update We did out best to take the advice of Jakub, Janathan, Markus and others: https://github.com/weidai11/cryptopp/commit/9bf0eed0f6ff6d0b0a2d277e5401d69dc8c0e394. We are paying for past transgressions, and cleanup is not as easy as we would like. Eventually, we want to enable CRYPTOPP_NO_UNALIGNED_DATA_ACCESS by default. It removes all related undefined behavior flagged by UBsan. The only thing stopping us is the politics of such a move.
[Bug c++/66943] New: GCC warns of Unknown Pragma for OpenMP, even though it support it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
Bug ID: 66943
Summary: GCC warns of Unknown Pragma for OpenMP, even though it
support it.
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
The following source code results in a slew of Unknown Pragma messages. The
problem is, GCC supports OpenMP. GCC responds properly to -fopenmp, and even
defines _OPENMP when it encounters -fopenmp.
This is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431, and
managing warnings with pragmas when using -Wall. The relation to 53431 is: I
can't seem to get "pragma GCC diagnostic" to work to ignore the warnings when
-Wall is in effect.
// Defines GCC_DIAGNOSTIC_AWARE if GCC 4.7 or above.
#define GCC_DIAGNOSTIC_AWARE 1
#if GCC_DIAGNOSTIC_AWARE
# pragma GCC diagnostic ignored "-Wunknown-pragmas"
#endif
...
Integer ModularRoot(const Integer &a, const Integer &dp, const Integer &dq,
const Integer &p, const Integer &q, const Integer &u)
{
Integer p2, q2;
#pragma omp parallel
#pragma omp sections
{
#pragma omp section
p2 = ModularExponentiation((a % p), dp, p);
#pragma omp section
q2 = ModularExponentiation((a % q), dq, q);
}
return CRT(p2, p, q2, q, u);
}
...
**
To duplicate:
git clone https://github.com/weidai11/cryptopp.git cryptopp-warn
cd cryptopp-warn
export CXXFLAGS="-g2 -O3 -DNDEBUG -Wall"
make
[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943 --- Comment #1 from Jeffrey Walton --- I've experienced this issue on Cygwin i386 and x86_64 running GCC 4.8.1; Fedora 21 and 22, i386 and x86_64 running GCC 4.9 and 5.1, and a few others. So it appears to be a widespread issue, and not an isolated case.
