[Bug c++/71458] New: ICE with -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71458 Bug ID: 71458 Summary: ICE with -fsanitize=bounds Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: barto at cambridgesemantics dot com Target Milestone: --- Created attachment 38663 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38663&action=edit preprocessed file that fails Seen with the released 5.4.0 build for Linux Version: GCC 5.4 System Type: Linux barto-VirtualBox 3.16.0-69-generic #89~14.04.1-Ubuntu SMP Thu Mar 17 20:51:04 UTC 2016 x86_64 GNU/Linux Options when configured ../configure --prefix=/opt/ubuntu-tools-5.4 \ --program-suffix=-5.4.0 \ --disable-multilib \ --with-system-zlib \ --enable-lto \ --enable-tls \ --enable-libmpx \ --enable-languages=c,c++ Command line /home/barto/UnixEnvironment/CSI/asan/toolchain/ubuntu-tools-5.4/bin/g++-5.4.0 -DUSE_GCC54 -c -o /home/barto/UnixEnvironment/CSI/asan/obj/tools/enum_scraper.o -ggdb -DGCC5=1 -DLINUX=1 -DUSE_ADDRESS_SANITIZER -DUSE_SANTYPE_BOUNDS -fsanitize=bounds -fcheck-pointer-bounds -mmpx -fPIE -pie -fno-omit-frame-pointer -fno-optimize-sibling-calls -pipe -march=core2 -m64 -funroll-loops -funit-at-a-time -finline-functions -fweb -frename-registers -funswitch-loops -ftree-vrp -ftree-vectorize -ftree-slp-vectorize -mfpmath=sse -fstack-protector-strong -shared -finline-limit=4000 -DFRAME_SIZE -Werror -Wsign-compare -Wno-long-long -Wreturn-type -Wno-variadic-macros -Wignored-qualifiers -Wparentheses -Wuninitialized -Wno-unused-function -Wall -Wextra -Winvalid-pch -Wsign-promo -Wreorder -Warray-bounds -fdiagnostics-show-option -fno-strict-aliasing -D_BSD_SOURCE -std=gnu++11 -ggdb -UGPROF -I. -DUSE_DLMALLOC -DUSE_STD_MUTEX -D_GLIBCXX_USE_DEPRECATED=0 -DFULL_RESERVATIONS -DMEM_LIMIT_LEAK_CHECKING -UBIG_CLUSTER -UCOMM2A -Wno-type-limits -DUSE_ADDRESS_SANITIZER -DUSE_SANTYPE_BOUNDS -fsanitize=bounds -fcheck-pointer-bounds -mmpx -fPIE -pie -fno-omit-frame-pointer -fno-optimize-sibling-calls -DLINUX -DSYS=B4_2 -I/home/barto/UnixEnvironment/CSI/asan/obj/tools /home/barto/UnixEnvironment/CSI/asan/source/tools/enum_scraper.cpp Output: /home/barto/UnixEnvironment/CSI/asan/source/tools/enum_scraper.cpp:276:1: internal compiler error: Segmentation fault } ^ 0xaa024f crash_signal ../../gcc/toplev.c:383 0xb1df68 chkp_walk_pointer_assignments ../../gcc/tree-chkp.c:3693 0xb1f56f chkp_finish_file() ../../gcc/tree-chkp.c:3803 Preprocessed file: enum_scraper.ii
[Bug preprocessor/81515] New: C pre-processor allows invalid words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81515
Bug ID: 81515
Summary: C pre-processor allows invalid words
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: barto at cambridgesemantics dot com
Target Milestone: ---
The following will parse successfully
#if BADTEST
#include
#ele
#include
#endif
#include
int main(int, char **)
{
exit(0);
}
[Bug preprocessor/81515] C pre-processor allows invalid words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81515 --- Comment #5 from David Barto --- This is about the #ele which I would expect to either generate a parse error or a warning of some kind.
[Bug sanitizer/78028] ASAN doesn't find memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028 David Barto changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from David Barto --- OK to close by me. Thanks for the research.
[Bug c++/82505] New: g++ -O3 -funroll-loops generates weird code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82505
Bug ID: 82505
Summary: g++ -O3 -funroll-loops generates weird code
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barto at cambridgesemantics dot com
Target Milestone: ---
Created attachment 42334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42334&action=edit
Assembly output from g++ -O3 -funroll-loops -S
In the following code, the first two tests generate much the same code when
compiled
with g++ -O3 -funroll-loops.
The third test generates an excess of loads and moves. Assembly attached.
extern char *dest;
extern char *src;
int t0()
{
for (int i = 0; i < 5; ++i)
{
dest[i] = src[i];
}
}
int t1()
{
dest[0] = src[0];
dest[1] = src[1];
dest[2] = src[2];
dest[3] = src[3];
dest[4] = src[4];
}
int t2()
{
for (int i = 0; i < 5; ++i)
{
*dest = *src;
++dest;
++src;
}
}
[Bug c++/82505] g++ -O3 -funroll-loops generates weird code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82505 --- Comment #1 from David Barto --- This is gcc-mp-7 pre-built object from MacPorts. Should have mentioned that.
[Bug c++/82505] g++ -O3 -funroll-loops generates weird code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82505 --- Comment #3 from David Barto --- I understand that it can't optimize much, my major concern is that the pointer version of the code is so much worse than the index version of the code.
[Bug sanitizer/78028] New: ASAN doesn't find memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028 Bug ID: 78028 Summary: ASAN doesn't find memory leak Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: barto at cambridgesemantics 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 Target Milestone: --- Checking address sanitizer leaks lead me to https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer and the sample code therein. I copied/pasted it and ran it on my Ubuntu 14.04 box. The leak for FooBar was detected and reported. So I added the suppression file and got no leak reported. I then removed the allocation code in the FooBar function and still had no report of a memory leak. 516_ g++ -fsanitize=address lsan-suppressed.cc 517_ ./a.out = ==4471==ERROR: LeakSanitizer: detected memory leaks 519_ ASAN_OPTIONS=detect_leaks=1 LSAN_OPTIONS=suppressions=suppressions=suppr.txt ./a.out - Suppressions used: count bytes template 1 7 FooBar But no error for Baz as noted on the webpage. Removing the allocation in FooBar will then pass without the suppression file applied.
[Bug sanitizer/78028] ASAN doesn't find memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028 --- Comment #3 from David Barto --- If it is restricted to 5.2, then we can close this as "won't fix"
[Bug c++/68023] New: 4.8.4 generates good code where 5.2 generates bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68023
Bug ID: 68023
Summary: 4.8.4 generates good code where 5.2 generates bad code
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barto at cambridgesemantics dot com
Target Milestone: ---
Created attachment 36543
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36543&action=edit
Configuration for GCC 4.8.4
The following code:
template
inline
SPORef::SPORef
/// Constructor: increment pointed to T's reference count.
( T* p///< Pointer to the T to be managed
)
: rep_(p)
{
badcode();
if (rep_)
rep_->incReferences();
}
template
inline
SPORef::~SPORef
/// Destructor: decrement pointed to T's reference count, possibly
/// triggering its destruction.
()
{
badcode();
if (rep_) {
rep_->decReferences();
rep_ = 0;
}
}
when compiled optimized with GCC 4.8.4 runs properly when compiled -O3.
Changing the compiler (and associated tool chain) from 4.8 to 5.2 causes the
code generated from these functions to cause the system to crash. Changing the
optimization around these 2 methods only by using:
#pragma GCC push_options
#pragma GCC optimize("O0")
#pragma GCC pop_options
and the gcc 5.2 compiler will successfully compile the code.
Attached are the .ii files for 4.8 and 5.2 as well as the configuration files
for 4.8 and 5.2.
[Bug c++/68023] 4.8.4 generates good code where 5.2 generates bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68023 --- Comment #1 from David Barto --- Created attachment 36544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36544&action=edit Configuration for GCC 5.2
[Bug c++/68023] 4.8.4 generates good code where 5.2 generates bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68023 --- Comment #2 from David Barto --- Created attachment 36545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36545&action=edit compressed gcc 4.8 output
[Bug c++/68023] 4.8.4 generates good code where 5.2 generates bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68023 --- Comment #3 from David Barto --- Created attachment 36546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36546&action=edit Compressed gcc 5.2 output
[Bug c++/68023] 4.8.4 generates good code where 5.2 generates bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68023 David Barto changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from David Barto --- The code uses so many un-aligned access operations (legal in x86 code) that using -fsanitize=undefined causes the code to stop execution very early in the startup. If, after fixing this, the problem still exists, I'll be back to re-open the bug.
