[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393



David Abdurachmanov  changed:



   What|Removed |Added



 CC||david.abdurachmanov at

   ||gmail dot com



--- Comment #22 from David Abdurachmanov  
2013-04-07 08:44:21 UTC ---

Has this been resolved in the final 4.8.0 (r196952)? I checked some changes and

they seems to be in.



I have a number (<100) C++/C packages (incl. boost 1.51.00) compiled w/o

address sanitizer and I am only enabling it for the main software using all

these packages.  Yet compilation fails of the main software segflaut from

boost. Reminder, that boost and ROOT is not compiled w/ address sanitizer.



I tried -static-libasan, yet in that case linker cannot resolve asan symbols

while shared library is being created. libasan_preinit.o, libasan.so, and

libasan.a is in my GCC package under ./lib64.



I added the following options to default CXXFLAGS, which also ended up on

LDFLAGS: -static-libasan -fsanitize=address -fno-omit-frame-pointer -g -O0



### SEGFAULT ###



The lines below might hint at the cause of the crash.

If they do not help you then please submit a bug report at

http://root.cern.ch/bugs. Please post the ENTIRE stack trace

from above as an attachment in addition to anything else

that might help us fixing this issue.

===

#5  0x2b33b9930d8a in

boost::exception_detail::get_static_exception_object

() at /build/davidlt/test-asan/a/slc6_amd64_gcc480/external/boost

/1.51.0-cms2/include/boost/exception/detail/exception_ptr.hpp:117

#6  0x2b33ba70685c in _GLOBAL__sub_I_future.cpp () from

/build/davidlt/test-asan/a/tmp/BUILDROOT/2c73b4475e8345752c405e046bb5182f/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2

_X_2013-04-06-0200/external/slc6_amd64_gcc480/lib/libboost_thread.so.1.51.0

#7  0x003326c0e57f in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2

#8  0x003326c12c25 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2

#9  0x003326c0e196 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2

#10 0x003326c1246a in _dl_open () from /lib64/ld-linux-x86-64.so.2

#11 0x003327400f66 in dlopen_doit () from /lib64/libdl.so.2

#12 0x003326c0e196 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2

#13 0x00332740129c in _dlerror_run () from /lib64/libdl.so.2

#14 0x003327400ee1 in dlopen



### UNDEFINED REFERENCES ###



/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetFileFormatVersion.cc:5:

error: undefined reference to

'__asan_init_v1'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:8:

error: undefined reference to

'__asan_report_load1'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:11:

error: undefined reference to

'__asan_unregister_globals'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:11:

error: undefined reference to

'__asan_init_v1'/build/davidlt/test-asan/a/tmp/BUILDROOT/eea1b2b6d889c55f315fbba1ee425ca6/opt/cmssw/slc6_amd64_gcc480/cms/cmssw/CMSSW_6_2_X_2013-04-06-0200-cms/src/FWCore/Version/src/GetReleaseVersion.cc:11:

error: undefined reference to '__asan_register_globals'

[Bug driver/54563] New: [4.7][C++11] MacOS 10.8, ICE in redirect_eh_edge_1, at tree-eh.c:2215

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54563

 Bug #: 54563
   Summary: [4.7][C++11] MacOS 10.8, ICE in redirect_eh_edge_1, at
tree-eh.c:2215
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.abdurachma...@gmail.com


Created attachment 28184
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28184
Pre-processed testcase

Tested with 190338 (pre-4.7.2) and 188597 (4.7.1). It only happens with double
and float. If you switch to int and pow function instead of powf it works fine.
It crashes only on C++11. Compiled files with -ansi (no C++11), exit code 0.

Current workaround/fix is to use std::pow() in the code.

GCC compiled with LLVM/clang on Mac OS X 10.8, Xcode 4.4 (build: 4F250)

$ clang -v
Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.0.0
Thread model: posix

sw_vers
ProductName:Mac OS X
ProductVersion: 10.8
BuildVersion:   12A269

## Detailed information about GCC ##

c++: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=/Volumes/build1/davidlt/test-4.7.0/a/osx108_amd64_gcc470/external/gcc/4.7.0-cms/bin/c++
Target: x86_64-apple-darwin12.0.0
Configured with: ../configure
--prefix=/Volumes/build1/davidlt/test-4.7.0/a/tmp/BUILDROOT/28dac03f73e4471589c20bae3c32fbc1/opt/cmssw/osx108_amd64_gcc470/external/gcc/4.7.0-cms
--disable-multilib --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++
--with-gmp=/Volumes/build1/davidlt/test-4.7.0/a/tmp/BUILDROOT/28dac03f73e4471589c20bae3c32fbc1/opt/cmssw/osx108_amd64_gcc470/external/gcc/4.7.0-cms
--with-mpfr=/Volumes/build1/davidlt/test-4.7.0/a/tmp/BUILDROOT/28dac03f73e4471589c20bae3c32fbc1/opt/cmssw/osx108_amd64_gcc470/external/gcc/4.7.0-cms
--with-mpc=/Volumes/build1/davidlt/test-4.7.0/a/tmp/BUILDROOT/28dac03f73e4471589c20bae3c32fbc1/opt/cmssw/osx108_amd64_gcc470/external/gcc/4.7.0-cms
--with-ppl=/Volumes/build1/davidlt/test-4.7.0/a/tmp/BUILDROOT/28dac03f73e4471589c20bae3c32fbc1/opt/cmssw/osx108_amd64_gcc470/external/gcc/4.7.0-cms
--with-cloog=/Volumes/build1/davidlt/test-4.7.0/a/tmp/BUILDROOT/28dac03f73e4471589c20bae3c32fbc1/opt/cmssw/osx108_amd64_gcc470/external/gcc/4.7.0-cms
--enable-cloog-backend=isl --enable-shared CC='clang -fPIC' CXX='clang++ -fPIC'
CPP='clang -E' CXXCPP='clang++ -E'
Thread model: posix
gcc version 4.7.1 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.8.0' '-v' '-save-temps' '-c' '-D'
'GNU_GCC' '-D' '_GNU_SOURCE' '-D' '__STDC_LIMIT_MACROS' '-D'
'__STDC_FORMAT_MACROS' '-O2' '-pedantic' '-ansi' '-pthread' '-pipe' '-Wno-vla'
'-m64' '-std=c++11' '-msse3' '-ftree-vectorize' '-Wno-strict-overflow'
'-Werror=array-bounds' '-Werror=format-contains-nul' '-Werror=type-limits'
'-fvisibility-inlines-hidden' '-fno-math-errno' '--param'
'vect-max-version-for-alias-checks=50' '-fipa-pta' '-felide-constructors'
'-fmessage-length=0' '-ftemplate-depth=300' '-Wall' '-Wno-non-template-friend'
'-Wno-long-long' '-Wreturn-type' '-Wunused' '-Wparentheses' '-Wno-deprecated'
'-Werror=return-type' '-Werror=missing-braces' '-Werror=unused-value'
'-Werror=address' '-Werror=format' '-Werror=sign-compare'
'-Werror=write-strings' '-fdiagnostics-show-option' '-fPIC' '-MMD' '-o'
'osx108-ice-testcase.o' '-shared-libgcc' '-mtune=core2'

/Volumes/build1/davidlt/test-4.7.0/a/osx108_amd64_gcc470/external/gcc/4.7.0-cms/bin/../libexec/gcc/x86_64-apple-darwin12.0.0/4.7.1/cc1plus
-E -quiet -v -iprefix
/Volumes/build1/davidlt/test-4.7.0/a/osx108_amd64_gcc470/external/gcc/4.7.0-cms/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.1/
-MMD osx108-ice-testcase.d -MQ osx108-ice-testcase.o -D__DYNAMIC__ -D_REENTRANT
-D GNU_GCC -D _GNU_SOURCE -D __STDC_LIMIT_MACROS -D __STDC_FORMAT_MACROS
./osx108-ice-testcase.cc -fPIC -mmacosx-version-min=10.8.0 -m64 -msse3
-mtune=core2 -ansi -std=c++11 -pedantic -Wno-vla -Wno-strict-overflow
-Werror=array-bounds -Werror=format-contains-nul -Werror=type-limits -Wall
-Wno-non-template-friend -Wno-long-long -Wreturn-type -Wunused -Wparentheses
-Wno-deprecated -Werror=return-type -Werror=missing-braces -Werror=unused-value
-Werror=address -Werror=format -Werror=sign-compare -Werror=write-strings
-ftree-vectorize -fvisibility-inlines-hidden -fno-math-errno -fipa-pta
-felide-constructors -fmessage-length=0 -ftemplate-depth=300
-fdiagnostics-show-option -fPIC -O2 -fpch-preprocess -o osx108-ice-testcase.ii
ignoring nonexistent directory
"/Volumes/build1/davidlt/test-4.7.0/a/osx108_amd64_gcc470/external/gcc/4.7.0-cms/bin/../lib/gcc/x86_64-apple-darwin12.0.0/4.7.1/../../../../x86_64-apple-darwin12.0.0/include"
ignoring duplicate directory
"/Volumes/build1/davidlt/test-4.7.0/a/osx108_amd64_gcc470/external/gcc/4.7.0-cms/bin/../lib/gcc/../../lib/gcc/x86_64-apple-darwin12.0.0/4.7.1/../../../../include/c++/4.7.1"
ign

[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393

--- Comment #25 from David Abdurachmanov  
---
I downloaded GCC 4.8.1 (final) and binutils 2.23.1 (default ld.gold). The
problem is that boost and a lot other C/C++ packages are not compiled w/ ASan.
One way would be to guarantee every single C/C++ RPM package correctly
compiling w/ ASan (quite some effort). I prefer to instrument the main software
(+ some critical C/C++ packages in future) for now.

I assume I cannot use -static-libasan for shared objects (-shared) as
PREINIT_ARRAY section would be a duplicate. Then -static-libasan should be only
used for the final executable binary? 

I tried something like that:

c++ -fsanitize=address -shared -Wl,-E -Wl,-z,defs -Wl,-v ./test.o -o libtest.so
-static-libasan

I see it doesn't pass to linker:

/lib64/libasan_preinit.o -Bstatic --whole-archive -lasan
--no-whole-archive -Bdynamic

And linker dies w/ undefined references of ASan.

Do I need to make sure that **only** executable binaries gets ASan linked
statically (-static-libasan)? (Thus they always have PREINIT_ARRAY section
initializing ASan).

david

[Bug c++/55149] capturing VLA in lambda

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #9 from David Abdurachmanov  
---
I am looking into 55520, which is marked a being duplicate of this ticket.

The example 1 below from 55520, still ICE on 4.9.0 (r199649). Yet it's marked
as RESOLVED FIXED. Jason, w/ 4.8.{0,1} VLA capture by reference in lambda works
fine, or at least compiles. Yet it now fails w/ 4.9.0. Details in example 2.

1. Is 55520 and this bug really RESOLVED FIXED? Example 1 produces ICE under
4.9.0.
2. Does capturing VLA by reference works **only** in 4.9.0? Example 2 compiles
under 4.8.{0,1}.
3. Looking at example 2, I would say capturing VLA by reference doesn't work in
4.9.0, or am I missing something here? Should I file a bug report?

### EXAMPLE 1 ###

int main(int argc, char** argv)
{
int x[1][argc];

[&x](int i)
{
x[0][i]  = 0;
}(5);

return 0;
}

### GCC OUTPUT ###

test2.cxx: In lambda function:
test2.cxx:7:15: internal compiler error: in expand_expr_real_1, at expr.c:9361
 x[0][i]  = 0;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


### EXAMPLE 2 ###

134   uint32_t index[nt];
135   float e[nt];
136   for (std::size_t k=0; k!=nt; ++k) {
137 e[k]=towers[k].eta();
138 index[k]=k;
139 std::push_heap(index,index+k+1,[&e](uint32_t i, uint32_t j){ return
e[i]

[Bug c++/55149] capturing VLA in lambda

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149

--- Comment #11 from David Abdurachmanov  
---
(In reply to Jason Merrill from comment #10)

Hi Jason,

Compiled fine in 4.8.0, fails in 4.9.0 (r199649). That's the smallest I could
get in this time. It produces two errors for the same line.

david

cat <<\EOF > test.cxx

template
 struct SA
 {
   SA (const int & PA);
   int nt;
 };

template
 inline void
 test(TB aa)
 {
   ;
 }

template
 inline
 SA::SA(const int & PA)
 {
   float e[nt];
   test([&e](int i, int j){ return e[i] < e[j]; });
 }

int main()
{
 int d;
 SA<2> iso(d);
 return 0;
}
EOF

### GCC COMMAND ###

c++ -c -DGNU_GCC -D_GNU_SOURCE -O2 -pthread -pipe -Werror=main
-Werror=pointer-arith -Werror=overlength-strings -Wno-vla -Wno-overflow
-Wno-strict-overflow -std=c++0x -msse3 -ftree-vectorize -Wno-strict-overflow
-Werror=array-bounds -Werror=format-contains-nul -Werror=type-limits
-fvisibility-inlines-hidden -fno-math-errno --param
vect-max-version-for-alias-checks=50 -fipa-pta -felide-constructors
-fmessage-length=0 -ftemplate-depth-300 -Wall -Wno-non-template-friend
-Wno-long-long -Wreturn-type -Wunused -Wparentheses -Wno-deprecated
-Werror=return-type -Werror=missing-braces -Werror=unused-value -Werror=address
-Werror=format -Werror=sign-compare -Werror=write-strings
-Werror=delete-non-virtual-dtor -Werror=maybe-uninitialized
-Werror=strict-aliasing -Werror=narrowing -Werror=uninitialized
-Werror=unused-but-set-variable -Werror=reorder -Werror=unused-variable
-Werror=conversion-null -Werror=switch -fdiagnostics-show-option
-Wno-unused-local-typedefs -Wabi -fPIC test.cxx -o test.o

### GCC OUTPUT ###

test.cxx: In instantiation of 'struct SA::SA(const int&) [with unsigned int
TA = 2u]::':
test.cxx:20:50:   required from 'SA::SA(const int&) [with unsigned int TA =
2u]'
test.cxx:26:13:   required from here
test.cxx:20:11: error: size of array is not an integral constant-expression
test([&e](int i, int j){ return e[i] < e[j]; });
   ^
test.cxx: In instantiation of 'SA::SA(const int&) [with unsigned int TA =
2u]':
test.cxx:26:13:   required from here
test.cxx:20:9: error: invalid initialization of reference of type 'float
(&)[1]' from expression of type 'float [((SA<2u>*)this)->SA<2u>::nt]'
test([&e](int i, int j){ return e[i] < e[j]; });
 ^

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #17 from David Abdurachmanov  
---
Just for the record.

I hit the same bug on Cortex-A9 NEON GCC 4.8.1 hard floats, while compiling
scipy 0.8.0 RPM. There was not issue on 4.8.0 and pre-4.9.0 w/o NEON as FPU.

scipy/spatial/ckdtree.c: In function
'__pyx_f_5scipy_7spatial_7ckdtree_7cKDTree___query':
scipy/spatial/ckdtree.c:4194:66: internal compiler error: in expand_assignment,
at expr.c:4761
 (__pyx_v_inf2->side_distances[__pyx_v_inode->split_dim]) =
__pyx_f_5scipy_7spatial_7ckdtree_dabs((__pyx_v_inode->split -
(__pyx_v_x[__pyx_v_inode->split_dim])));
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
error: Command "gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv
-O3 -Wall -Wstrict-prototypes -fPIC
-I/build/davidlt/481-ext/a/fc18_armv7hl_gcc481/external/py2-numpy/1.6.1/lib/python2.7/site-packages/numpy/core/include
-I/build/davidlt/481-ext/a/fc18_armv7hl_gcc481/external/python/2.7.3/include/python2.7
-c scipy/spatial/ckdtree.c -o
build/temp.linux-armv7l-2.7/scipy/spatial/ckdtree.o" failed with exit status 1

### GCC configuration ###

Target: armv7hl-redhat-linux-gnueabi
Configured with: ../configure
--prefix=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--disable-multilib --disable-nls --with-zlib=no
--enable-languages=c,c++,fortran --enable-gold=yes --enable-ld=default
--enable-lto
--with-gmp=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-mpfr=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-mpc=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-isl=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-cloog=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--enable-checking=release --build=armv7hl-redhat-linux-gnueabi
--host=armv7hl-redhat-linux-gnueabi --enable-libstdcxx-time=rt
--enable-bootstrap --enable-threads=posix --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--enable-linker-build-id --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-cpu=cortex-a9 --with-tune=cortex-a9
--with-arch=armv7-a --with-float=hard --with-fpu=neon --with-abi=aapcs-linux
--disable-sjlj-exceptions --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'
CPP=cpp CXXCPP='c++ -E'
Thread model: posix

[Bug target/58065] ARM MALLOC_ABI_ALIGNMENT is wrong

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #5 from David Abdurachmanov  
---
malloc() [glibc implementation] default alignment is sizeof(long double) or 2 *
sizeof(size_t) if I remember correctly, which is 8 bytes for ARMv7. I think,
based on C and C++ standard you have to make sure that alignment is good for
whatever primitive type, which means alignment size being the size of the
biggest primitive type (long double).

Reference bug ticket(9 years old):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795

Quote from C standard (identical or similar exist in C++):

The pointer returned if the allocation succeeds is suitably aligned so that
it may be assigned to a pointer to any type of object and then used to
access such an object or an array of such objects in the space allocated
(until the space is explicitly deallocated).

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #18 from David Abdurachmanov  
---
Tested the patch on top of final 4.8.1 Cortex-A9 NEON FPU. GCC no more ICE'ing
while compiling scipy.

[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #7 from David Abdurachmanov  
---
Ping.

@Paolo, any ETA for this entering a trunk?

[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at
   ||gmail dot com

--- Comment #4 from David Abdurachmanov  
2012-04-06 19:39:18 UTC ---
I can confirm the issue. Run into the problem when re-compiling a project with
C++11.

Works fine in C++98/03, does not compile in C++11. Both work-arounds suggested
in the first comment works.

[Bug libstdc++/83662] std::aligned_alloc() not available

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om, jwakely.gcc at gmail dot 
com

--- Comment #4 from David Abdurachmanov  
---
I hit the same issue on a few days old build of GCC 7 (close to 7.3.0) while
compiling a file with -std=c++17 / -std=c++1z.

vecgeom-v00.05.00/USolids/../base/Global.h:39:31: error: 'aligned_alloc' is not
a member of 'std'

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #1 from David Abdurachmanov  
---
I am using bdba439399552531c0fe82da5037386715f07940 (git) or r258481 (svn) and
I hit the same issue:

../../gcc/calls.c: In function ‘poly_int64 compute_argument_block_size(int,
args_size*, tree, tree, int)’:   
../../gcc/calls.c:2201:60: error: comparison of integer expressions of
different signedness: ‘int’ and ‘unsigned int’ [-Werror=sign-compare]   
   if (ACCUMULATE_OUTGOING_ARGS && preferred_stack_boundary > STACK_BOUNDARY)

[Bug driver/85142] New: Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib

[david.abdurachmanov at gmail dot com]

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

Bug ID: 85142
   Summary: Wrong -print-multi-os-directory & -print-multi-lib
output for riscv64 + multilib
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

GCC 7.3.1 is available in Fedora RISC-V stage4 and is configured with multilib,
but only one ABI is selected. This is done to provide multilib paths, which are
required by glibc.

# gcc -print-multi-directory   
.
# gcc -print-multi-lib
.;
lib64/lp64d;@march=rv64imafdc@mabi=lp64d
# gcc -print-multi-os-directory
.

Based on GCC man page -print-multi-os-directory should return ../lib64/lp64d

ppp packages uses: LIBDIR = $(DESTDIR)/lib/$(shell gcc
-print-multi-os-directory 2> /dev/null)

Thus wrongly installs libraries in /usr/lib directory, instead of in
/usr/lib/../lib64/lp64d.

I am also concerned by -print-multi-lib output.

Instead of:

lib64/lp64d;@march=rv64imafdc@mabi=lp64d

We should have:

../lib64/lp64d;@march=rv64imafdc@mabi=lp64d

All the paths seem to be related to "some lib directory" (/usr/lib) according
to man page.

[Bug libstdc++/55413] New: [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55413



 Bug #: 55413

   Summary: [LTO] hashtable.h:1648 '__bbegin_bkt' may be used

uninitialized in this function

[-Werror=maybe-uninitialized]

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: david.abdurachma...@gmail.com





Hi,



I have enabled -Werror=maybe-uninitialized and normal builds works fine. LTO

builds crashed with error coming from hashtable.h. According to he code,

__bbegin_bkt is not explicitly initialized to anything.



1637   std::size_t __bbegin_bkt;



1648 __new_buckets[__bbegin_bkt] = __p; 

1649 __bbegin_bkt = __bkt;



Similar issues MIGHT be on the next (in file) template.



1678   std::size_t __bbegin_bkt;



1724 __new_buckets[__bbegin_bkt] = __p;

1725   __bbegin_bkt = __bkt;



This is a minor issue, but comments would be welcomed. Is LTO + diagnostics

issue or STL issue? Is the a way to silence them from user-code side? (I tried

GCC diagnostics pragma w/o results).



Attaching *.ii.



## GCC VERSION ##



Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../configure

--prefix=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--disable-multilib --disable-nls --enable-languages=c,c++,fortran

--enable-gold=yes --enable-lto

--with-gmp=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-mpfr=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-mpc=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-ppl=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--with-cloog=/build/davidlt/build-BOOTSTRAP_slc5_amd64_gcc472/b/tmp/BUILDROOT/3526ecf0ad2656770a1b0f9f5e8d92a9/opt/cmssw/slc5_amd64_gcc472/external/gcc/4.7.2

--enable-cloog-backend=isl --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'

CPP=cpp CXXCPP='c++ -E'

Thread model: posix

gcc version 4.7.2 (GCC)



## FULL ERROR ##



In file included from

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/stl_algobase.h:1026:0,

 from :97:

test.cc: In function 'main':

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/hashtable.h:1648:3:

error: '__bbegin_bkt' may be used uninitialized in this function

[-Werror=maybe-uninitialized]

In file included from

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/stl_algobase.h:1017:0,

 from :97:

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/hashtable.h:1637:19:

note: '__bbegin_bkt' was declared here

lto1: some warnings being treated as errors

lto-wrapper: /afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/c++

returned 1 exit status

/afs/cern.ch/cms/slc5_amd64_gcc472/external/gcc/4.7.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/bin/ld:

fatal error: lto-wrapper failed

collect2: error: ld returned 1 exit status



## TESTCASE ##



#include 

struct S {  int id;  S(): id(0) {} };

int main(void) {

  std::unordered_map tmap;

  S & res = tmap[0];

  return 0;

}



## COMPILE LINE ##



c++ -v -save-temps -c -DGNU_GCC -D_GNU_SOURCE -O2 -pedantic -pthread -pipe

-Wno-vla -Werror=overflow -Wstrict-overflow -std=c++0x -msse3 -ftree-vectorize

-Wno-strict-overflow -Werror=array-bounds -Werror=format-contains-nul

-Werror=type-limits -fvisibility-inlines-hidden -fno-math-errno --param

vect-max-version-for-alias-checks=50 -felide-constructors -fmessage-length=0

-ftemplate-depth-300 -Wall -Wno-non-template-friend -Wno-long-long

-Wreturn-type -Wunused -Wparentheses -Wno-deprecated -Werror=return-type

-Werror=missing-braces -Werror=unused-value -Werror=address -Werror=format

-Werror=sign-compare -Werror=write-strings -Werror=delete-non-virtual-dtor

-Werror=maybe-uninitialized -Werror=strict-aliasing -Werror=narrowing

-We

[Bug libstdc++/55413] [LTO] hashtable.h:1648 '__bbegin_bkt' may be used uninitialized in this function [-Werror=maybe-uninitialized]

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55413



--- Comment #1 from David Abdurachmanov  
2012-11-20 14:07:57 UTC ---

Created attachment 28743

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28743

Testcase used.

[Bug c++/55652] New: [C++11][4.8] ICE (segfault) with templates and structs

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55652



 Bug #: 55652

   Summary: [C++11][4.8] ICE (segfault) with templates and structs

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: david.abdurachma...@gmail.com





Created attachment 28929

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28929

testcase used.



Hi folks,



I have started re-compiling my RPMs with GNU GCC 4.8.0 (revision 194323) to

check the status.



Below your will find the smallest test case I currently could produce showing

setfault (ICE). Yet I am still not fully sure what is causing it. I compiles w/

C++03, but not w/ C++11. It also compiles w/ GCC 4.7.2.



I am attaching *.ii.



## TESTCASE ##



#include 



template 

struct P {

  T1 first;

  T2 second;

  P() : first(T1()), second(T2()) {}

};



struct E {

};



struct B {

  B();

  B(const B &obj) throw(E);

};



int main(void) {

  P > a;

  return 0;

}



## COMPILE LINE ##



g++ -v -save-temps -std=c++11 -c -o test.o ./test.cxx



## GCC OUTPUT ##



./test.cxx: In function 'int main()':

./test.cxx:19:25: internal compiler error: Segmentation fault

   P > a;

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



## GCC FULL OUTPUT ##



Using built-in specs.

COLLECT_GCC=g++

Target: x86_64-unknown-linux-gnu

Configured with: ../configure

--prefix=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--disable-multilib --disable-nls --enable-languages=c,c++,fortran

--enable-gold=yes --enable-lto

--with-gmp=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-mpfr=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-mpc=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-isl=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-cloog=/build/davidlt/gcc480/b/tmp/BUILDROOT/48f7c7c6aea9a202503cd9453105a971/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--disable-isl-version-check --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'

CPP=cpp CXXCPP='c++ -E'

Thread model: posix

gcc version 4.8.0 20121208 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-o' 'test.o'

'-shared-libgcc' '-mtune=generic' '-march=x86-64'



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus

-E -quiet -v -iprefix

/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/

-D_GNU_SOURCE ./test.cxx -mtune=generic -march=x86-64 -std=c++11

-fpch-preprocess -o test.ii

ignoring nonexistent directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed"

ignoring nonexistent directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"

#include "..." search starts here:

#include <...> search starts here:



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu

[Bug c++/55753] New: [C++11][4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753



 Bug #: 55753

   Summary: [C++11][4.8 Regression] ICE constexpr ctor,

tsubst_copy_and_build, at cp/pt.c:14336

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: david.abdurachma...@gmail.com





Created attachment 29011

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29011

Testcase used.



Hi all,



Here is another C++11 regression in 4.8, I believe. Tested with GNU GCC 4.8.0

(r194629). Compiles fine if constexpr is removed from struct C ctor. Also

compiles fine on 4.7.2.



In addition tested with -Wall -Wextra and -fno-strict-aliasing -fwrapv, which

yielded the same results.



Originally noticed in code using std::complex, i.e., C could be replaced with

std::complex. E.g.,



std::complex cpl = std::complex((true ? 1.0 :

std::complex()));



I am attaching *.ii test case.



Cheers,

david



### TESTCASE ###



template 

struct C {

  constexpr C(const Tp& r) { }

};



template 

struct B {

  B() {

C cpl = C((true ? 1.0 : C()));

  }

};



### COMPILATION LINE ###



g++ -m64 -O2 -std=c++11 -c testcase.cpp -fPIC -g -o ./testcase.o



### ICE ###



testcase.cpp: In constructor 'B::B()':

testcase.cpp:9:55: internal compiler error: in tsubst_copy_and_build, at

cp/pt.c:14336

 C cpl = C((true ? 1.0 : C()));

   ^



### VERBOSE OUTPUT ###



Using built-in specs.

COLLECT_GCC=g++

Target: x86_64-unknown-linux-gnu

Configured with: ../configure

--prefix=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--disable-multilib --disable-nls --enable-languages=c,c++,fortran

--enable-gold=yes --enable-lto

--with-gmp=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-mpfr=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-mpc=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-isl=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-cloog=/build/davidlt/gcc480/b/tmp/BUILDROOT/b0fc97fddd2f40bb6a475bc4cb2eec22/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--disable-isl-version-check --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'

CPP=cpp CXXCPP='c++ -E'

Thread model: posix

gcc version 4.8.0 20121220 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-std=c++11' '-c' '-fPIC'

'-o' './testcase.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'



/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus

-E -quiet -v -iprefix

/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/

-D_GNU_SOURCE testcase.cpp -m64 -mtune=generic -march=x86-64 -std=c++11 -fPIC

-O2 -fpch-preprocess -o testcase.ii

ignoring nonexistent directory

"/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"

ignoring duplicate directory

"/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0"

ignoring duplicate directory

"/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu"

ignoring duplicate directory

"/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward"

ignoring duplicate directory

"/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include"

ignoring duplicate directory

"/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed"

ignoring nonexistent directory

"/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"

#include "..." search starts here:

#include <...> search starts here:



/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0



/build/davidlt/gcc480/b/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-l

[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753



--- Comment #3 from David Abdurachmanov  
2012-12-23 12:31:40 UTC ---

I tried reverting (on r194703):

- r173680: Compiles. But still ICE'd as reported.

- r173680 && r173679: Does not compile, xgcc ICE'd

- r173680 && r173679 && r173678: Same as previous. 



Not the smartest why to check, but maybe it partially rules out r173680.



/build/davidlt/gcc480/b/BUILD/slc5_amd64_gcc480/external/gcc/4.8.0/gcc-trunk-194703/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:114:39:

internal compiler error: unexpected expression '(std::size_t)((-1))' of kind

cast_expr

   { return size_t(-1) / sizeof(_Tp); }

   ^

[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753



--- Comment #4 from David Abdurachmanov  
2012-12-24 12:48:01 UTC ---

I did some more testing of the trunk. Compiles fine with r173678 [g++ (GCC)

4.7.0 20110511 (experimental)], but starts ICE'ing with r173679. gcc_assert

(TREE_CONSTANT (t)); (ICE line) was added in r166592 [1]. I tried passing

--enable-checking=none or touching gcc/DEV-PHASE, but bootstrap comparison was

always failing.



I looked at gcc/configure.ac. trunk has DEV-PHASE set to experimental thus

ac_checking_flags=yes, which sets ac_checking=1. If ac_checking_flags=release

then ac_checking= is not set. If ac_checking is set, it defines ENABLE_CHECKING

macro, I believe. That would probably explain why it works for me with 4.7.2

(final).



Probably this is the part [2] causing the ICE.



Merry Christmas in advance!

david



[1]

http://gcc.gnu.org/viewcvs/trunk/gcc/cp/pt.c?r1=166592&r2=166591&pathrev=166592

[2]

http://gcc.gnu.org/viewcvs/trunk/gcc/cp/pt.c?r1=173679&r2=173678&pathrev=173679

[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753



--- Comment #8 from David Abdurachmanov  
2013-01-04 11:31:21 UTC ---

I have tested  the trunk, rev 194883. Seems to compile the test case #1, but it

still fails in the original program, Sherpa [1].



I am attaching pre-processed test case #2. Sadly, it includes .



[1] https://sherpa.hepforge.org/trac/wiki



### ICE, SEGFAULT ###



testcase.cpp: In constructor 'B::B()':

testcase.cpp:6:61:   in constexpr expansion of 'std::complex(1.0e+0)'

testcase.cpp:6:61: internal compiler error: Segmentation fault

 std::complex((true ? 1.0 : std::complex()));

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.



### COMPILE LINE ###



g++ -m64 -O2 -std=c++11 -c testcase.cpp -fPIC -g -o ./testcase.o



### TEST CASE ###



#include 



template 

struct B {

  B() {

std::complex((true ? 1.0 : std::complex()));

  }

};



### GCC FULL OUTPUT ###



Using built-in specs.

COLLECT_GCC=g++

Target: x86_64-unknown-linux-gnu

Configured with: ../configure

--prefix=/build/davidlt/gcc480/b/tmp/BUILDROOT/b27d27381a0266701ed8b36f187c62dd/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--disable-multilib --disable-nls --enable-languages=c,c++,fortran

--enable-gold=yes --enable-lto

--with-gmp=/build/davidlt/gcc480/b/tmp/BUILDROOT/b27d27381a0266701ed8b36f187c62dd/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-mpfr=/build/davidlt/gcc480/b/tmp/BUILDROOT/b27d27381a0266701ed8b36f187c62dd/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-mpc=/build/davidlt/gcc480/b/tmp/BUILDROOT/b27d27381a0266701ed8b36f187c62dd/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-isl=/build/davidlt/gcc480/b/tmp/BUILDROOT/b27d27381a0266701ed8b36f187c62dd/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--with-cloog=/build/davidlt/gcc480/b/tmp/BUILDROOT/b27d27381a0266701ed8b36f187c62dd/opt/cmssw/slc5_amd64_gcc480/external/gcc/4.8.0

--disable-isl-version-check --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'

CPP=cpp CXXCPP='c++ -E'

Thread model: posix

gcc version 4.8.0 20130104 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-std=c++11' '-c' '-fPIC'

'-g' '-o' './testcase.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus

-E -quiet -v -iprefix

/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/

-D_GNU_SOURCE testcase.cpp -m64 -mtune=generic -march=x86-64 -std=c++11 -fPIC

-g -fworking-directory -O2 -fpch-preprocess -o testcase.ii

ignoring nonexistent directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include"

ignoring duplicate directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed"

ignoring nonexistent directory

"/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include"

#include "..." search starts here:

#include <...> search starts here:



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/x86_64-unknown-linux-gnu



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/backward



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed

 /usr/local/include



/build/davidlt/gcc480/test/slc5_amd64_gcc480/external/gcc/4.8.0/bin/../lib/gcc/../../include

[Bug c++/55753] [C++11][4.7/4.8 Regression] ICE constexpr ctor, tsubst_copy_and_build, at cp/pt.c:14336

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55753



--- Comment #9 from David Abdurachmanov  
2013-01-04 11:32:39 UTC ---

Created attachment 29082

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29082

testcase #2

[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374



David Abdurachmanov  changed:



   What|Removed |Added



 CC||david.abdurachmanov at

   ||gmail dot com



--- Comment #16 from David Abdurachmanov  
2013-01-29 08:54:14 UTC ---

Ping.



I noticed a patch ([PATCH] Put -lasan always very early on the ld command line

(PR sanitizer/55374)) posted on gcc-patches. There was not ACK yet from RM.



Any ideas if the patch manages to get into the trunk? It does seem quite

important for ASan usage.

[Bug c++/70106] New: [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long

[david.abdurachmanov at gmail dot com]

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

Bug ID: 70106
   Summary: [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr
<< (var)] cause error: invalid static_cast from type
'const size_t {aka const long unsigned int}' to type
'size_t& {aka long unsigned int&}'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
      Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

Created attachment 37878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37878&action=edit
test case

I came across this while recompiling our repositories with GCC 6.0.0 (r233941,
a couple of days old already). Only happens with C++11 or above. Seems to
affect GCC 4.9.3, 5.3.0, and GCC 6.0.0. Works fine with Clang 3.7.0 and the
latest version of ICC (16.0.2 20160204).

I did run C-Reduce and then did some additional manual minimisation.

Test case attached.

### COMPILING ###

g++ -std=c++14 -Wno-deprecated -c ratext_worker_min_new.cpp -fPIC  -o
ratext_worker.o

### ERROR ###

ratext_worker_min_new.cpp: In instantiation of ‘const int&
momentum_configuration<  >::p(size_t) const [with
 = int; size_t = long unsigned int]’:
ratext_worker_min_new.cpp:22:25:   required from ‘void momentum_configuration<
 >::mom(size_t) [with  = int;
size_t = long unsigned int]’
ratext_worker_min_new.cpp:53:3:   required from ‘void triangle_Rat_plusminus<
,
RatTriSpecs>::get_sub_terms_work(momentum_configuration&, const
std::vector&, triangle_param&) [with T = int;  = rat_worker; RatTriSpecs =
Higgs_RatTri_Specification]’
ratext_worker_min_new.cpp:58:50:   required from here
ratext_worker_min_new.cpp:28:13: error: invalid static_cast from type ‘const
size_t {aka const long unsigned int}’ to type ‘size_t& {aka long unsigned
int&}’
   std::cerr << (momentum_configuration::nbr);
 ^

### EXPECTATIONS ###

The issue is this line:

 28   std::cerr << (momentum_configuration::nbr);

Removing parenthesis resolves the issue:

 28   std::cerr << momentum_configuration::nbr;

Clang and ICC compile the code in C++14 with and without the parenthesis.

[Bug c++/21802] Two-stage name lookup fails for operators

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #8 from David Abdurachmanov  
---
While looking at the last compilation issues while reg testing GCC 6.0.0, I
bumped into this one. The code compiles file with GCC 5.3.0. The code compiles
fine with Clang 3.7.0 (have not checked 3.8.0 or ICC yet, but can be done on
request).

git bisect pointed me to this fix (full bisect log is below).

d175f0193ed47b61eafd213ca2d3dde73f8f5996 is the first bad commit
commit d175f0193ed47b61eafd213ca2d3dde73f8f5996
Author: ppalka 
Date:   Tue Dec 15 03:33:53 2015 +

Fix PR c++/21802 (two-stage name lookup fails for operators)

Failing file (pre-processed) is attached and I am running C-Reduce to get
something more minimal. I am currently not sure if this a compiler issue or not
thus not creating a separate BZ item.

### COMPILE LINE ###

c++ -c -ansi -fPIC -O2  Algorithm.ii

Removing -ansi seems to solve compilation issue.

### ERROR ### 

Algorithm.cc: In instantiation of 'Algorithm::grammar::grammar()
[with Iterator = __gnu_cxx::__normal_iterator >]':
Algorithm.cc:119:11:   required from here
Algorithm.cc:76:16: error: invalid initialization of non-const reference of
type 'boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>&' from an rvalue of type
'boost::spirit::terminal >::result::type {aka
boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>}'
   = lexeme[+char_("a-zA-Z0-9{}[],_.+-")]
^~~~
In file included from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/core.hpp:26:0,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/proto.hpp:12,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/support/meta_compiler.hpp:19,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi/meta_compiler.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi/action/action.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi/action.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/home/qi.hpp:14,
 from
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/spirit/include/qi.hpp:16,
 from Algorithm.cc:7:

/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/operators.hpp:116:5:
note:   initializing argument 1 of 'const typename
boost::proto::detail::enable_unary,
boost::proto::tagns_::tag::unary_plus, Arg&>::type
boost::proto::exprns_::operator+(Arg&) [with Arg =
boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>; typename
boost::proto::detail::enable_unary,
boost::proto::tagns_::tag::unary_plus, Arg&>::type =
boost::proto::exprns_::expr, boost::fusion::vector1 > >, 0l>&>, 1l>]'
 operator OP(Arg &arg BOOST_PROTO_UNARY_OP_IS_POSTFIX_ ## POST)
 \
 ^
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/operators.hpp:236:5:
note: in expansion of macro 'BOOST_PROTO_DEFINE_UNARY_OPERATOR'
 BOOST_PROTO_DEFINE_UNARY_OPERATOR(+, boost::proto::tag::unary_plus, TRAIT,
DOMAIN, 0)   \
 ^
/home/david.abdurachmanov/gcc600/test/fc22_ppc64le_gcc600/external/boost/1.57.0/include/boost/proto/operators.hpp:295:9:
note: in expansion of macro 'BOOST_PROTO_DEFINE_OPERATORS'
 BOOST_PROTO_DEFINE_OPERATORS(is_extension, deduce_domain)
 ^~~~

### BISECT LOG ###

git bisect start
# good: [c05c1b41d370b14bc94421f138d13e76831253d1] [5/n] Fix minor SSA_NAME
leaks
git bisect good c05c1b41d370b14bc94421f138d13e76831253d1
# bad: [078970398ca084fe81435464b0434dcdd4a56fc7] Daily bump.
git bisect bad 078970398ca084fe81435464b0434dcdd4a56fc7
# bad: [141d7d6e93a44d509f0be246231b46939e728c97] 2015-12-16  Richard Biener 

git bisect bad 141d7d6e93a44d509f0be246231b46939e728c97
# good: [296008a9d4e2305dbf691ffcae802abcb0fe29a9] missed error format change
in previous commit
git bisect good 296008a9d4e2305dbf691ffcae802abcb0fe29a9
# good: [5a9e96d29263540947275d331b2b3efc0b0b4536] [AArch64] Add builtins for
ARMv8.1 Adv.SIMD instructions.
git bisect good 5a9e96d29263540947275d331b2b3efc0b0b4536

[Bug c++/21802] Two-stage name lookup fails for operators

[david.abdurachmanov at gmail dot com]

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

--- Comment #9 from David Abdurachmanov  
---
Created attachment 38230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38230&action=edit
Failing file (pre-processed)

[Bug c++/70610] New: [6 regression] error: invalid initialization of non-const reference of type

[david.abdurachmanov at gmail dot com]

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

Bug ID: 70610
   Summary: [6 regression] error: invalid initialization of
non-const reference of type
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

This is a follow up of comment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802#c8

Caused by:

d175f0193ed47b61eafd213ca2d3dde73f8f5996 is the first bad commit
commit d175f0193ed47b61eafd213ca2d3dde73f8f5996
Author: ppalka 
Date:   Tue Dec 15 03:33:53 2015 +

Fix PR c++/21802 (two-stage name lookup fails for operators)

Works fine with GCC 5.3.0, Clang 3.7.0 and ICC (16.0.2 20160204).

Minimal reproducer by Patrick Palka:

struct A { };

A operator+ (A &) { return A (); }
A operator+ (const A &) { return A (); }


template 
void
foo ()
{
  +A ();
}

void
bar ()
{
  foo ();
}

$ g++ -c -ansi test.cc
test.cc: In instantiation of 'void foo() [with T = int]':
test.cc:17:13:   required from here
test.cc:11:3: error: invalid initialization of non-const reference of type 'A&'
from an rvalue of type 'A'
   +A ();
   ^
test.cc:3:3: note:   initializing argument 1 of 'A operator+(A&)'
 A operator+ (A &) { return A (); }
   ^~~~

Note, that removing -ansi solves the issue.

[Bug target/70750] [6/7 Regression] Load and call no longer combined for indirect calls on x86

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #1 from David Abdurachmanov  
---
I have noticed this while comparing assembly generated by GCC 5.3.0 and GCC
6.0.1.

Examples (diff -u 5.3.0 6.0.1)

  7 -   ff 50 18callq  *0x18(%rax)
  8 +   48 8b 40 18 mov0x18(%rax),%rax
  9 +   ff d0   callq  *%rax

 41 -   ff 50 08callq  *0x8(%rax)
 42 -   4c 8b 7b f8 mov-0x8(%rbx),%r15
 43 +   48 8b 40 08 mov0x8(%rax),%rax
 44 +   ff d0   callq  *%rax
 45 +   49 8b 5f f8 mov-0x8(%r15),%rbx

 49 -   ff 50 08callq  *0x8(%rax)
 50 +   48 8b 40 08 mov0x8(%rax),%rax
 51 +   ff d0   callq  *%rax

Seems that GCC 6.0.1 is no more combining mov + callq. I have not checked if it
was intentional change or not in GCC.

[Bug ipa/68331] [meta-bug] fipa-pta issues

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #10 from David Abdurachmanov  
---
I have been reg-testing GCC 6 for the last few weeks and I hit an issue with
compile code straggly segfaulting.

Compiler with GCC 5.3.0, ASan and valgrind shows no issues. Compiled with GCC
6.0.1, ASan and valgrind shows issues, program segfaults. If I go below -O2,
the execution at least does not segfault. Developers so far couldn't understand
whats happening. No issues if compiled with latest Clang or ICC.

I am trying to understand if this is a potential GCC bug and it's worth filling
another BZ ticket. I am trying to reg-test as much as I can before GCC 6.1.0 is
cut. What are your thoughts?

Bisect brought me to this commit as being the culprit:

7ae97ba6651703d99d9f0e20a4e48eb7743c103c is the first bad commit
commit 7ae97ba6651703d99d9f0e20a4e48eb7743c103c
Author: rguenth 
Date:   Thu Dec 10 09:41:08 2015 +

2015-12-10  Richard Biener  

PR ipa/68331
[..]

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231498
138bc75d-0d04-0410-961f-82ee72b054a4

What fails is:

421 std::unique_ptr node =
std::make_unique>(iLabel, value, isTracked);
422 ParameterDescriptionNode* pnode = addNode(std::move(node), isOptional,
writeToCfi);

addNode will segfault std::unique_ptr content is wrong. If one would do
node.get() you get 0x1 trying to access such memory will cause
segfault.

So, I took 7ae97ba6651703d99d9f0e20a4e48eb7743c103c (first bad commit) and
6c2acfc4892316b46df0fe4a6769fb6766ab1e0b (last good) and compared assembly for 
edmtest::ProducerWithPSetDesc::fillDescriptions(edm::ConfigurationDescriptions&).
I found no significant differences, all are offsets. I know that the second
call to edm::ParameterSetDescription::addNode fails.

[..]
  481f5f1:   e8 9a 7d ff ff  callq  17390
(char const (&) [6], int const&, bool, bool, bool)@plt>
  491f5f6:   48 8d 35 d3 f4 01 00lea0x1f4d3(%rip),%rsi#
3ead0 <_fini+0x2a10>
  501f5fd:   48 89 c7mov%rax,%rdi
  511f600:   e8 db 83 ff ff  callq  179e0

  521f605:   48 8d 85 50 fe ff fflea-0x1b0(%rbp),%rax
  531f60c:   48 8d bd 20 d7 ff fflea-0x28e0(%rbp),%rdi
  541f613:   48 8d 35 c9 cb 01 00lea0x1cbc9(%rip),%rsi#
3c1e3 <_fini+0x123>
  551f61a:   31 c9   xor%ecx,%ecx
  561f61c:   c7 85 50 fe ff ff 01movl   $0x8001,-0x1b0(%rbp)
  571f623:   00 00 80
  581f626:   48 89 c2mov%rax,%rdx
  591f629:   48 89 85 98 d0 ff ffmov%rax,-0x2f68(%rbp)
  601f630:   e8 7b 91 ff ff  callq  187b0
 >::__single_object
std::make_unique, char const (&) [16], int
const&, bool&>(char const (&) [16], int const&, bool&) [clone .isra.142] >
  611f635:   48 8b 85 20 d7 ff ffmov-0x28e0(%rbp),%rax
  621f63c:   b9 01 00 00 00  mov$0x1,%ecx
  631f641:   31 d2   xor%edx,%edx
  641f643:   4c 89 f6mov%r14,%rsi
  651f646:   4c 89 ffmov%r15,%rdi
  661f649:   48 89 85 10 ff ff ffmov%rax,-0xf0(%rbp)
  671f650:   e8 9b 77 ff ff  callq  16df0
 >, bool, bool)@plt>
  681f655:   48 8b bd 10 ff ff ffmov-0xf0(%rbp),%rdi
[..]

Before that it calls the cloned function. Pointer becomes wrong after line 66
[%rax,-0xf0(%rbp)]. Then I looked into cloned function between two commits.

This showed some differences:

  3 @@ -19,7 +19,6 @@
  4 48 89 dfmov%rbx,%rdi
  5 e8 75 e8 ff ff  callq  17060 
  7 -   49 89 1c 24 mov%rbx,(%r12)
  8 48 83 c0 10 add$0x10,%rax
  9 48 89 03mov%rax,(%rbx)
 10 41 8b 45 00 mov0x0(%r13),%eax
 11 @@ -34,9 +33,10 @@
 12 48 89 c5mov%rax,%rbp
 13 48 89 dfmov%rbx,%rdi
 14 be 28 00 00 00  mov$0x28,%esi
 15 -   e8 50 e4 ff ff  callq  16c70 
 16 +   e8 54 e4 ff ff  callq  16c70 
 17 48 89 efmov%rbp,%rdi
 18 -   e8 48 ef ff ff  callq  17770 <_Unwind_Resume@plt>
 19 -   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
 20 -   00
 21 +   e8 4c ef ff ff  callq  17770 <_Unwind_Resume@plt>
 22 +   66 90   xchg   %ax,%ax
 23 +   66 2e 0f 1f 84 00 00nopw   %cs
 24 +   00 00 00

# ASAN REPORT #

ASAN:DEADLYSIGNAL

[Bug ipa/68331] [meta-bug] fipa-pta issues

[david.abdurachmanov at gmail dot com]

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

--- Comment #11 from David Abdurachmanov  
---
"Good" code, annotated by me. Now notice from my previous message that the fix
for this PR, caused

49 89 1c 24 mov%rbx,(%r12)

to be removed. We lost one instruction which stored the address of allocated
objected via "pointer".

000187b0 
>::__single_object std::make_unique, char const
(&) [16], int const&, bool&>(char const (&) [16], int const&, bool&) [clone
.isra.142]>:
   187b0:   41 56   push   %r14
   187b2:   41 55   push   %r13
   187b4:   49 89 f6mov%rsi,%r14
   187b7:   41 54   push   %r12
   187b9:   55  push   %rbp
   187ba:   49 89 fcmov%rdi,%r12
   187bd:   53  push   %rbx

// Allocate 40 bytes on the heap

   187be:   bf 28 00 00 00  mov$0x28,%edi
   187c3:   49 89 d5mov%rdx,%r13
   187c6:   0f b6 e9movzbl %cl,%ebp
   187c9:   e8 62 e5 ff ff  callq  16d30 

// Store returned pointer in RBX

   187ce:   48 89 c3mov%rax,%rbx
   187d1:   e8 da f8 ff ff  callq  180b0 ()@plt>
   187d6:   41 b8 01 00 00 00   mov$0x1,%r8d
   187dc:   89 e9   mov%ebp,%ecx
   187de:   89 c2   mov%eax,%edx
   187e0:   4c 89 f6mov%r14,%rsi

// Call the ctor, pass pointer (this) from RBX

   187e3:   48 89 dfmov%rbx,%rdi
   187e6:   e8 75 e8 ff ff  callq  17060

   187eb:   48 8b 05 a6 36 03 00mov0x336a6(%rip),%rax#
4be98 <_DYNAMIC+0x430>

// Store RBX to memory pointed by R12

   187f2:   49 89 1c 24 mov%rbx,(%r12)
   187f6:   48 83 c0 10 add$0x10,%rax
   187fa:   48 89 03mov%rax,(%rbx)
   187fd:   41 8b 45 00 mov0x0(%r13),%eax
   18801:   89 43 20mov%eax,0x20(%rbx)

// Put address in R12 into return register

   18804:   4c 89 e0mov%r12,%rax
   18807:   5b  pop%rbx
   18808:   5d  pop%rbp
   18809:   41 5c   pop%r12
   1880b:   41 5d   pop%r13
   1880d:   41 5e   pop%r14
   1880f:   c3  retq
   18810:   48 89 c5mov%rax,%rbp
   18813:   48 89 dfmov%rbx,%rdi
   18816:   be 28 00 00 00  mov$0x28,%esi
   1881b:   e8 50 e4 ff ff  callq  16c70 
   18820:   48 89 efmov%rbp,%rdi
   18823:   e8 48 ef ff ff  callq  17770 <_Unwind_Resume@plt>
   18828:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
   1882f:   00

[Bug ipa/70760] New: [6 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

Bug ID: 70760
   Summary: [6 regression] wrong generated code for
std::make_unique with -fipa-pta
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

Created attachment 38325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38325&action=edit
untouched preprocessed file

Hopefully this is truly the last issues I see with GCC 6 on x86_64 and our
software.

Compiler with GCC 5.3.0, ASan and valgrind shows no issues. Compiled with GCC
6.0.1, ASan and valgrind shows issues, program segfaults. If we disable
-fipa-pta the program compiles and runs successfully. Developers so far
couldn't understand whats happening, at least at C++ level from their point of
view everything is fine. No issues if compiled with latest Clang or ICC.

TL;DR doing .get() on std::unique_ptr in a bizarre 0x1 pointer. Of
course accessing later such address causes segfaults.

GIT bisect tracked down the issue to a fix for PR ipa/68331
(https://gcc.gnu.org/viewcvs?rev=231498&root=gcc&view=rev)

In git,
first bad: 7ae97ba6651703d99d9f0e20a4e48eb7743c103c
last good: 6c2acfc4892316b46df0fe4a6769fb6766ab1e0b

The following code is failing on C++ level:

421 std::unique_ptr node =
std::make_unique>(iLabel, value, isTracked);
422 ParameterDescriptionNode* pnode = addNode(std::move(node), isOptional,
writeToCfi);

addNode function segfauls once it tries access through 0x1 address
which is from std::unique_ptr.

I looked at addNode assembly and fully expected that it should segfault.
Nothing wrong found with it. I went one frame up to
edmtest::ProducerWithPSetDesc::fillDescriptions(edm::ConfigurationDescriptions&)
symbol, but found no significant differences in generated assembly between
those two commits. All differences were in offsets which looked fine.

I knew that it's 2nd call to addNode inside
edmtest::ProducerWithPSetDesc::fillDescriptions which caused the failure.
Before 2nd addNode call is done it called to
std::_MakeUniq >::__single_object
std::make_unique, char const (&) [16], int
const&, bool&>(char const (&) [16], int const&, bool&) [clone .isra.142] symbol
and after it the second argument (to be passed to addNode) was damaged with
bizarre 0x1 pointer at run-time.

"Good code" annotated by me is below for this std::make_unique function. Due to
-fipa-pta we loose one instruction which is related to return value from
std::make_unique:

  3 @@ -19,7 +19,6 @@
  4 48 89 dfmov%rbx,%rdi
  5 e8 75 e8 ff ff  callq  17060 


  7 -   49 89 1c 24 mov%rbx,(%r12)



  8 48 83 c0 10 add$0x10,%rax
  9 48 89 03mov%rax,(%rbx)
 10 41 8b 45 00 mov0x0(%r13),%eax
 11 @@ -34,9 +33,10 @@
 12 48 89 c5mov%rax,%rbp
 13 48 89 dfmov%rbx,%rdi
 14 be 28 00 00 00  mov$0x28,%esi
 15 -   e8 50 e4 ff ff  callq  16c70 
 16 +   e8 54 e4 ff ff  callq  16c70 
 17 48 89 efmov%rbp,%rdi
 18 -   e8 48 ef ff ff  callq  17770 <_Unwind_Resume@plt>
 19 -   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
 20 -   00
 21 +   e8 4c ef ff ff  callq  17770 <_Unwind_Resume@plt>
 22 +   66 90   xchg   %ax,%ax
 23 +   66 2e 0f 1f 84 00 00nopw   %cs
 24 +   00 00 00

In a "good code" it used to return a pointer to a pointer to internally
allocated object. That missing instruction was storing address of allocation on
heap to some memory location. Later we used to return R12. Without that
instruction R12 contains RDI. Thus we are basically returning the first
argument of std::make_unique.

I have rushed a bit, thus hopefully didn't make too many mistakes. That's the
only meaningful difference I can in see in assembly code in 3 related symbols.

Attaching the preprocessed file (untouched).

We compile it with:

c++ -c -O2 -std=c++1z -ftree-vectorize -fvisibility-inlines-hidden
-fno-math-errno --param vect-max-version-for-alias-checks=50 -fipa-pta -msse3
-felide-constructors -fPIC ProducerWithPSetDesc.ii

Again, removing -fipa-pta seems to solve the issue (bring back the missing
instruction).

# GOOD ASM #

000187b0 
>::__single_object std::make_unique, char const
(&) [16], int const&, bool&>(char const (&) [16], int const&, bool&) [clone
.isra.142]>:
   187b0:   41 56   push   %r14
   187b2:   41 55   pu

[Bug ipa/68331] [meta-bug] fipa-pta issues

[david.abdurachmanov at gmail dot com]

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

--- Comment #13 from David Abdurachmanov  
---
Done,

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

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #4 from David Abdurachmanov  
---
I will test the second patch. Will take a few hours (it's millions of lines in
C++).

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #6 from David Abdurachmanov  
---
Will do, results will be late today or tomorrow.

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #8 from David Abdurachmanov  
---
Should I continue testing the 2nd patch, or dump whatever is currently built
and restart with the patch from your latest comment?

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #10 from David Abdurachmanov  
---
I did a quick test (still took several hours) with #1 and #3 patches and both
seem to solve the issue. Patches were tested on top of r235408.

Just in case I will run patch #3 (for now) again, but will force the whole
world to be recompiled starting GCC. That is a more extensive, but also
expensive test.

[Bug ipa/70760] [6/7 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov  
---
I have re-tested #3 patch by recompiling 316 RPMs (from GCC to our software --
top package). Have not seen those strange segfaults.

[Bug ipa/70760] [6 regression] wrong generated code for std::make_unique with -fipa-pta

[david.abdurachmanov at gmail dot com]

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

--- Comment #18 from David Abdurachmanov  
---
For now I will pull this change into my GCC 6.1.0 build.

Thanks!

[Bug c++/71388] New: [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

Bug ID: 71388
   Summary: [6/7 regression] wrong code, DSE removes memset in TBB
allocate_scheduler (causes run-time crashes)
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

Created attachment 38626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38626&action=edit
pre-processed file

We found this crashing one of our test cases in GCC 6.1.1 port of our software.
Looks like wrong code in Intel TBB.

TBB version: tbb44_20151115oss (also affects newer versions)
First bad commit: 8a36d0ec201ef1511b372523f72a763b836107b0 or r222135
Last good commit: 8b2942f7c961ee83bb0ff605129165ecdf6ac8f6 or r222134

Potentially wrongly compiled code is from src/tbb/custom_scheduler.h

111 public:
112 static generic_scheduler* allocate_scheduler( market& m ) {
113 void* p = NFS_Allocate(1, sizeof(scheduler_type), NULL);
114 std::memset(p, 0, sizeof(scheduler_type));
115 scheduler_type* s = new( p ) scheduler_type( m );
116 s->assert_task_pool_valid();
117 ITT_SYNC_CREATE(s, SyncType_Scheduler, SyncObj_TaskPoolSpinning);
118 return s;
119 }

>From our developer: What is happening is a class instance is being created with
placement new where the address is reused from a thread which has gone away.
However, (at least) one of the member data of the newly created object is non-0
and it is that non-0 value which ultimately leads to the crash.

Object size here is 408 bytes. A call to memset is not generated and don't seem
to be inlined also.

Can be cured if TTB is compiled with CXXFLAGS='-fno-builtin-memset' which will
force GCC to generate a call to memset.

Below you can find examples of
tbb::internal::custom_scheduler::allocate_scheduler(tbb::internal::market&)
symbol with good and bad GCC revision.

Note that in bad revision we lost: rep stos %rax,%es:(%rdi)

Attaching pre-processed scheduler.ii (not a minimal test case), compiled as:
g++ -o scheduler.o -c -g -O2 -m64 -mrtm -fPIC scheduler.ii

### GOOD ###

00023df0
::allocate_scheduler(tbb::internal::market&)>:
   23df0:   55  push   %rbp
   23df1:   53  push   %rbx
   23df2:   31 d2   xor%edx,%edx
   23df4:   48 89 fdmov%rdi,%rbp
   23df7:   be 98 01 00 00  mov$0x198,%esi
   23dfc:   bf 01 00 00 00  mov$0x1,%edi
   23e01:   48 83 ec 08 sub$0x8,%rsp
   23e05:   e8 96 9a fe ff  callq  d8a0

   23e0a:   48 8d 78 08 lea0x8(%rax),%rdi
   23e0e:   48 89 c1mov%rax,%rcx
   23e11:   48 89 c3mov%rax,%rbx
   23e14:   48 c7 00 00 00 00 00movq   $0x0,(%rax)
   23e1b:   48 c7 80 90 01 00 00movq   $0x0,0x190(%rax)
   23e22:   00 00 00 00
   23e26:   31 c0   xor%eax,%eax
   23e28:   48 83 e7 f8 and$0xfff8,%rdi
   23e2c:   48 89 eemov%rbp,%rsi
   23e2f:   48 29 f9sub%rdi,%rcx
   23e32:   81 c1 98 01 00 00   add$0x198,%ecx
   23e38:   c1 e9 03shr$0x3,%ecx
   23e3b:   f3 48 abrep stos %rax,%es:(%rdi)
   23e3e:   48 89 dfmov%rbx,%rdi
   23e41:   e8 5a e4 ff ff  callq  222a0

   23e46:   48 8d 05 13 1c 21 00lea0x211c13(%rip),%rax#
235a60 >
   23e4d:   48 83 c0 10 add$0x10,%rax
   23e51:   48 89 03mov%rax,(%rbx)
   23e54:   48 8d 05 35 2b 21 00lea0x212b35(%rip),%rax#
236990 <__itt_sync_create_ptr__3_0>
   23e5b:   48 8b 00mov(%rax),%rax
   23e5e:   48 85 c0test   %rax,%rax
   23e61:   74 1e   je 23e81
::allocate_scheduler(tbb::internal::market&)+0x91>
   23e63:   48 8d 15 fe 25 21 00lea0x2125fe(%rip),%rdx#
236468 
   23e6a:   48 8d 35 2f 26 21 00lea0x21262f(%rip),%rsi#
2364a0 
   23e71:   b9 02 00 00 00  mov$0x2,%ecx
   23e76:   48 89 dfmov%rbx,%rdi
   23e79:   48 8b 12mov(%rdx),%rdx
   23e7c:   48 8b 36mov(%rsi),%rsi
   23e7f:   ff d0   callq  *%rax
   23e81:   48 83 c4 08 add$0x8,%rsp
   23e85:   48 89 d8mov%rbx,%rax
   23e88:   5b  pop%rbx
   23e89:   5d  pop%rbp
   23e8a:   c3  retq
   

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

--- Comment #2 from David Abdurachmanov  
---
Doesn't std::memset apply here? They allocate storage, set it to 0x0 and then
place construct the object.

At first look I wouldn't expect GCC to remove std::memset.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

--- Comment #6 from David Abdurachmanov  
---
Agreed. As usual, thanks for verifying this. Will cook and send a patch to TBB.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

--- Comment #7 from David Abdurachmanov  
---
Just for reference (if someone reads this PR):
https://gcc.gnu.org/ml/gcc/2016-02/msg00205.html

It contains a reference to C++ standard.

[Bug c++/70822] [6 Regression] bogus "error: lvalue required as unary ‘&’ operand" with C++14 parenthesized SCOPE_REF

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #3 from David Abdurachmanov  
---
Are there plans to back port this to 6 branch?

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #7 from David Abdurachmanov  
---
This potentially caused errors while compiling Clang 3.9 in C++1z mode.

See Richard Smith comments on
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170522/193826.html

Quote:
"""
This is wrong. We have a "public:" on the previous line! But I think this
is just GCC's diagnostic being screwed up and what it's trying to say is
that it selected a deleted function.

But this function is the wrong overload resolution result; the operator
std::string from the base class should be selected.
"""

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[david.abdurachmanov at gmail dot com]

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

--- Comment #11 from David Abdurachmanov  
---
Created attachment 41461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41461&action=edit
Minimized file from LLVM

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov  
---
I have attached minimized file (PGOInstrumentation.cpp) from LLVM.

Compile line: g++ -c PGOInstrumentation.cpp

Result:
PGOInstrumentation.cpp: In constructor
'{anonymous}::PGOInstrumentationUseLegacyPass::PGOInstrumentationUseLegacyPass(std::__cxx11::string)':
PGOInstrumentation.cpp:105:25: error: 'llvm::cl::opt::opt(const llvm::cl::opt&)
[with DataType = std::__cxx11::basic_string; bool ExternalStorage =
false; ParserClass = llvm::cl::parser >]' is
private within this context
   ProfileFileName = PGOTestProfileFile;
 ^~
PGOInstrumentation.cpp:92:3: note: declared private here
   opt(const opt &) = delete;
   ^~~
PGOInstrumentation.cpp:105:25: error: use of deleted function
'llvm::cl::opt::opt(const
llvm::cl::opt&) [with DataType =
std::__cxx11::basic_string; bool ExternalStorage = false; ParserClass =
llvm::cl::parser >]'
   ProfileFileName = PGOTestProfileFile;
 ^~
PGOInstrumentation.cpp:92:3: note: declared here
   opt(const opt &) = delete;
   ^~~
PGOInstrumentation.cpp:72:2: note:   initializing argument 1 of
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_If_sv<_Tp,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&>
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_Tp) [with _Tp =
llvm::cl::opt >; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_If_sv<_Tp,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&> =
std::__cxx11::basic_string&]'
  operator=(_Tp __sv)
  ^~~~

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[david.abdurachmanov at gmail dot com]

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

--- Comment #13 from David Abdurachmanov  
---
Created attachment 41463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41463&action=edit
This is just minimized *.ii file

I am also adding PGOInstrumentation2.cpp.xz, which is just slightly minimized
original code. The previous one was minimized with C-Reduce.

[Bug c++/77493] New: [6 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

Bug ID: 77493
   Summary: [6 Regression] -fcrossjumping (-O2) on ppc64le causes
segfaults (jump to 0x0) (first bad r230091)
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

Created attachment 39568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39568&action=edit
pre-processed source code

Finally I moved our PPC64LE builds to GCC 6.2.0 from 5.3.0 and quickly found
that majority of workflows are segfaulting in a similar strange manner.

Quickly noticed that this starts happening with -O2, works fine with -O1.
Started bisection of GCC -O2 flags and it -fcrossjumping is the causing it.
Found that most issues are caused by MuonTrajectoryUpdator.o. Then started
hunting for the function causing regression. Found that it was
boost/smart_ptr/intrusive_ptr.hpp (from 1.57.0 version).

Doing the following resolves the issue:

165 #pragma GCC push_options
166 #pragma GCC optimize ("no-crossjumping")
167
168 T & operator*() const
169 {
170 BOOST_ASSERT( px != 0 );
171 return *px;
172 }
173
174 #pragma GCC pop_options

Started GCC bisection and did it twice with the same result.

First bad commit r230091 or b873d7f7eba25120074b3d74add21224e860df43
Last good commit r230090 or 79a77fee9f8eebf5bdd2b4868a0ba18b3ad3b74d

Does not happen on x86_64 and I still didn't move AArch64 to GCC 6.2.0.

This is quick look into GDB:

Dump of assembler code for function
Chi2MeasurementEstimator::estimate(TrajectoryStateOnSurface const&,
TrackingRecHit const&) const:
   0x3fff985a7e40 <+0>: addis   r2,r12,4
   0x3fff985a7e44 <+4>: addir2,r2,-320
=> 0x3fff985a7e48 <+8>: mflrr0
   0x3fff985a7e4c <+12>:std r27,-40(r1)
   0x3fff985a7e50 <+16>:std r28,-32(r1)
   0x3fff985a7e54 <+20>:mr  r28,r4
   0x3fff985a7e58 <+24>:std r30,-16(r1)
   0x3fff985a7e5c <+28>:std r31,-8(r1)
   0x3fff985a7e60 <+32>:mr  r27,r3
   0x3fff985a7e64 <+36>:mr  r3,r5
   0x3fff985a7e68 <+40>:std r29,-24(r1)
   0x3fff985a7e6c <+44>:mr  r31,r5
   0x3fff985a7e70 <+48>:std r0,16(r1)
   0x3fff985a7e74 <+52>:stdur1,-288(r1)
   0x3fff985a7e78 <+56>:ld  r9,0(r5) // beginning of TrackingRecHit
   0x3fff985a7e7c <+60>:ld  r4,88(r9) // we load 0x0 (loading
function address from vtable?)
   0x3fff985a7e80 <+64>:std r2,24(r1)
   0x3fff985a7e84 <+68>:mtctr   r4 // we load CTR with 0x0
   0x3fff985a7e88 <+72>:mr  r12,r4
   0x3fff985a7e8c <+76>:bctrl  // ucondition branch to CTR
with is 0x0
   0x3fff985a7e90 <+80>:ld  r2,24(r1)
   0x3fff985a7e94 <+84>:li  r5,21
   0x3fff985a7e98 <+88>:mr  r30,r3

Code looks like:

34 std::pair
 35 Chi2MeasurementEstimator::estimate(const TrajectoryStateOnSurface& tsos,
 36const TrackingRecHit& aRecHit) const {
 37 switch (aRecHit.dimension()) {
 38 case 1: return returnIt(lestimate<1>(tsos,aRecHit));
 39 case 2: return returnIt(lestimate<2>(tsos,aRecHit));
 40 case 3: return returnIt(lestimate<3>(tsos,aRecHit));
 41 case 4: return returnIt(lestimate<4>(tsos,aRecHit));
 42 case 5: return returnIt(lestimate<5>(tsos,aRecHit));
 43 }
 44 throw cms::Exception("RecHit of invalid size (not 1,2,3,4,5)");
 45 }

We are failing trying to make this call: aRecHit.dimension() [line 37].

[Bug c++/77493] [6 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #1 from David Abdurachmanov  
---
Created attachment 39569
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39569&action=edit
generated assembly with last good commit

[Bug c++/77493] [6 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #2 from David Abdurachmanov  
---
Created attachment 39570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39570&action=edit
generated assembly with the first bad commit

[Bug c++/77493] [6 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #3 from David Abdurachmanov  
---
Created attachment 39571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39571&action=edit
generated assembly with the first bad commit + pragma no-crossjumping

[Bug target/77493] [6 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #5 from David Abdurachmanov  
---
I tried running valgrind on both x86_64 and ppc64le. It was running for 2 days
and didn't report any invalid reads / writes to the memory. My first guess was
that we are corrupting memory.

I added -g -fsanitize=undefined -fno-omit-frame-pointer [-static-libubsan] on
involved pieces and it did produce some errors. None of that seems to touch
troublesome part of code, but with these flags code works again.

So far I am running builds with -fno-crossjumping and that seems to solve all
issues.

Also, trying to bring back ASan builds, but that will take time thus I will
keep looking into this.

[Bug target/77493] [6 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #7 from David Abdurachmanov  
---
I did try -fno-devirtualize and -fno-delete-null-pointer-checks without
success, but will re-try again now.

[Bug target/77493] [6 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #8 from David Abdurachmanov  
---
Can confirm that '-fno-delete-null-pointer-checks -fwrapv -fno-devirtualize'
don't change the outcode, fails the same.

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #10 from David Abdurachmanov  
---
We have been bitten by DSE with TBB already on GCC 6.2.0.

I decided to try -fno-lifetime-dse on the first bad commit and got some
surprising results. Now it fails with:

pure virtual method called
terminate called without an active exception

In this case we have a standard library container with 7 elements,
std::shared_ptr, where TrackingRecHit is abstract class, which
has:

  virtual int dimension() const = 0;

If I dump the actual type: typeid(*(x.get())).name() the actual object is of
MuonTransientTrackingRecHit type.

Then the code does std::stable_sort on the collection and now in some cases
MuonTransientTrackingRecHit changes to TrackingRecHit (abstract class). Thus we
are really calling pure virtual method.

This does not happen on x86_64.

I guess, this could be caused by actual MuonTransientTrackingRecHit being
destroyed if the last std::shared_ptr point to it goes away.

DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit
DUMP_BEFORE: std::shared_ptr
DUMP_BEFORE_TYPE: MuonTransientTrackingRecHit

// after std::stable_sort

DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: MuonTransientTrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit
DUMP: std::shared_ptr
DUMP_TYPE: TrackingRecHit

SIZE: 7

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov  
---
Looks to be std::vector> (aka
ConstRecHitContainer).

Here is the class and typedef for the containers:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/DataFormats/TrackingRecHit/interface/TrackingRecHit.h#L35

Here we call sort which is a member function (at the end of the file):
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/src/MuonTrajectoryUpdator.cc#L119

That member function calls stable_sort.

stable_sort is called here:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/src/MuonTrajectoryUpdator.cc#L260

This is the comparison function used:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/interface/MuonTrajectoryUpdator.h#L98

Will try to check where dtor is happening.

[Bug c++/60675] New: [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675

Bug ID: 60675
   Summary: [4.9 regression][aarch64] internal compiler error:
Max. number of generated reload insns per insn is
achieved (90)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

$ rpm --eval "%{_build}"
aarch64-redhat-linux-gnu

Compiles fine with system GCC (gcc version 4.8.1 20130920 (Red Hat 4.8.1-10)
(GCC)).

Fails with pre-4.9.0 (tested 208693 and trunk [208843]).

Compiles fine with trunk on x86_64.

Compiles fine on aarch64 is `-fPIC` is removed from compilation line.

Attaching minimized pre-processed file.

## COMPILE ##

g++ -std=c++11 -O2 -fPIC -o G4ErrorFreeTrajState.cc.o -c
G4ErrorFreeTrajState2.ii

## ICE ##

G4ErrorFreeTrajState2.ii: In member function 'virtual G4int
G4ErrorFreeTrajState::PropagateError(const G4Track*)':
G4ErrorFreeTrajState2.ii:35892:1: internal compiler error: Max. number of
generated reload insns per insn is achieved (90)

 }
 ^

[Bug c++/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675

--- Comment #1 from David Abdurachmanov  
---
Seems the testcase is too large. Trimming it more usually causes it not to ICE,
but will try to trim more.

[Bug c++/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675

--- Comment #3 from David Abdurachmanov  
---
With `-mno-lra` compiles fine.

[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675

--- Comment #5 from David Abdurachmanov  
---
Created attachment 32460
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32460&action=edit
Minimized pre-processed file

[Bug libstdc++/60789] New: [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f)

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789

Bug ID: 60789
   Summary: [4.9 Regression] Missing -lm while checking for math
functions (e.g., atan2f)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

Math functions tests are failing with GCC 4.9.0 (trunk, r209221), while working
fine at least up to 4.8.1.

Tested on x86_64 (Scientific Linux 6.5) and aarch64 (Fedora 19).

Looking at compile time, seems that `-lm` was lost.

This caused a number of _GLIBCXX_HAVE_* not being defined for math functions in
`c++config.h`, thus causes functions like `atan2f` to call `(float)atan2(x,
y)`.

# Fragment from ./x86_64-unknown-linux-gnu/libstdc++-v3/config.log, GCC
4.8.1, checking for `atan2f`.

configure:22347: checking for atan2f declaration
configure:22372: 
/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/xgcc
-shared-libgcc
-B/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc
-nostdinc++
-L/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src
-L/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src/.libs
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/bin/
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/lib/
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/include
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/sys-include
   -c -fno-builtin -D_GNU_SOURCE  conftest.cpp >&5
configure:22372: $? = 0
configure:22388: result: yes
configure:22394: checking for atan2f
configure:22394:
/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/xgcc
-B/build1/davidlt/gcc421diff/a/BUILD/slc6_amd64_gcc481/external/gcc/4.8.1-cms/gcc-gcc-4_8-branch-199526/obj/./gcc/
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/bin/
-B/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/lib/
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/include
-isystem
/build1/davidlt/gcc421diff/a/tmp/BUILDROOT/abdabd72f629a2521d29cea96ef20750/opt/cmssw/slc6_amd64_gcc481/external/gcc/4.8.1-cms/x86_64-redhat-linux-gnu/sys-include
   -o conftest -g -O2   conftest.c  -lm >&5
conftest.c:161:6: warning: conflicting types for built-in function 'atan2f'
[enabled by default]
 char atan2f ();
  ^
configure:22394: $? = 0
configure:22394: result: yes

# Same from GCC 4.9.0

configure:22559: checking for atan2f declaration
configure:22584:
/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/./gcc/xgcc
-shared-libgcc
-B/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/./gcc
-nostdinc++
-L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src
-L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/src/.libs
-L/build1/davidlt/gcc421diff/490/a/BUILD/slc6_amd64_gcc490/external/gcc/4.9.0-cms/gcc-trunk-209221/obj/x86_64-redhat-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/bin/
-B/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/lib/
-isystem
/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/include
-isystem
/build1/davidlt/gcc421diff/490/a/tmp/BUILDROOT/b60735266dcb81302bac5b296e8c0965/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/x86_64-redhat-linux-gnu/sys-in

[Bug libstdc++/60789] [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f)

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789

--- Comment #1 from David Abdurachmanov  
---
Found the culprit. I had CFLAGS/CXXFLAGS/LDFLAGS for gcc ./configure. Thus
probably setting CFLAGS causes `-lm` to vanish in libstdc++v3 math conftests.

[Bug libstdc++/60789] [4.9 Regression] Missing -lm while checking for math functions (e.g., atan2f)

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60789

David Abdurachmanov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from David Abdurachmanov  
---
I am marking it as RESOLVED INVALID.

After looking more closely, I found a typo in CXXFLAGS. It caused the following
test to fail in the first place:

>From libstdc++-v3/linkage.m4 in GLIBCXX_CHECK_MATH_SUPPORT:

361   dnl Check libm
362   AC_CHECK_LIB(m, sin, libm="-lm")
363   ac_save_LIBS="$LIBS"
364   LIBS="$LIBS $libm"

Thus `-lm` was not added for the rest of the tests.

[Bug c/65486] New: ICE: in type_natural_mode, at config/i386/i386.c:6646

[david.abdurachmanov at gmail dot com]

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

Bug ID: 65486
   Summary: ICE: in type_natural_mode, at config/i386/i386.c:6646
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

Tested in F21 with gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) and in
F22 with gcc version 5.0.0 20150226 (Red Hat 5.0.0-0.17) (GCC)

Testcase:

typedef long double a __attribute__((vector_size (32)));

a sum(a first, a second) {
  return first + second;
}

Changing vector size:

16 OK
32 ICE
64 ICE
128 OK
256 OK
512 OK
1024 OK
2048 OK

Does not allow storing 2 and 4 long doubles in a vector, but every other size
is okay.

a.cpp: In function ‘a sum(a, a)’:
a.cpp:3:24: internal compiler error: in type_natural_mode, at
config/i386/i386.c:6646
 a sum(a first, a second) {
^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/65486] ICE: in type_natural_mode, at config/i386/i386.c:6646

[david.abdurachmanov at gmail dot com]

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

--- Comment #3 from David Abdurachmanov  
---
Forgot this is on x86_64. Also tested with Clang 3.5, which worked fine.

It seems to that it's also ICE'ing on AArch64, but in expr.c if a single long
double is in a vector. I will file another bug report, once tested with GCC 5.
Currently used 4.9.2 on AArch64.

@Jakub,
Agreed, but I found it being used in some cases.

[Bug target/65491] New: [aarch64] ICE: in emit_move_insn, at expr.c:3609

[david.abdurachmanov at gmail dot com]

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

Bug ID: 65491
   Summary: [aarch64] ICE: in emit_move_insn, at expr.c:3609
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

Storing a single long double in a vector will cause GCC 4.9.2 and GCC 5.0.0 to
ICE on AArch64:

typedef long double a __attribute__((vector_size (16)));

a sum(a first, a second) {
  return first + second;
}

a.c:3:3: internal compiler error: in emit_move_insn, at expr.c:3609
 a sum(a first, a second) {
   ^
Please submit a full bug report,
with preprocessed source if appropriate.

On GCC 5.0.0 (F22) it reports expr.c:3601

Any other argument for vector_size seems to work just fine. Tested up to 2048.

[Bug c++/60112] New: bogus error: array subscript is above array bounds

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60112

Bug ID: 60112
   Summary: bogus error: array subscript is above array bounds
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

GCC pre-4.9.0 (r206686), no issues on 4.6.2, 4.7.2, and 4.8.1. I found that if
I mark `get_size' as inline or constexpr errors are gone. If I keep `nFaces'
uninitialized it also complains, but if I set it explicitly to some number
(e.g., 0,..,) it's fine. Even commenting out such line (49) as

lp += VV(tanDistToFace[iFDest]);

removes the errors.

I tried removing more mass from the test case, but it also removes the errors.

Doesn't work with -O2, but works fine with -O0, -O1, -O3, -Os, and -Og.

### COMPILE ###

c++ -c -O2 -std=c++11 -Werror=array-bounds -fdiagnostics-show-option -fPIC
test2.cpp

### ERRORS ###

test2.cpp: In function 'void abc()':
test2.cpp:43:37: error: array subscript is above array bounds
[-Werror=array-bounds]
 iFDestSorted[nDestSorted - i - 1] = iFDestSorted[iMax];
 ^
test2.cpp:44:22: error: array subscript is above array bounds
[-Werror=array-bounds]
 iFDestSorted[iMax] = iTmp;
  ^
cc1plus: some warnings being treated as errors

### TEST CASE ###

struct GP {
  double mx, my, mz;
  GP (double x, double y, double z) : mx(x), my(y), mz(z) { };
};
typedef struct GP GP;

void do_something(const GP& n) { }

struct VV {
  double mx;
  VV (double x) : mx(x) { };
};
typedef struct VV VV;

struct PP {
  double mx;
  PP (double x) : mx(x) { };
  double x() { return mx; };
  PP& operator+=(const VV& rhs) { mx += rhs.mx; return *this; };
};
typedef struct PP PP;

int get_size() { return 0; };

void abc() {
  double tanDistToFace[6] = {0,0,0,0,0,0};
  unsigned int iFDestSorted[6] = {0,0,0,0,0,0};
  unsigned int nDestSorted = 0;

  unsigned int nFaces = get_size();
  for (unsigned int iFace = 0; iFace < nFaces; ++iFace) {
nDestSorted++;
  }

  for (unsigned int i = 0; i < nDestSorted; ++i) {
unsigned int iMax = nDestSorted - i - 1;
for (unsigned int j=0; j < nDestSorted-i; ++j) {
  if (tanDistToFace[iFDestSorted[j]] > tanDistToFace[iFDestSorted[iMax]]) {
iMax = j;
  }
}
unsigned int iTmp = iFDestSorted[nDestSorted - i - 1];
iFDestSorted[nDestSorted - i - 1] = iFDestSorted[iMax];
iFDestSorted[iMax] = iTmp;
  }

int iFDest = iFDestSorted[0];
PP lp(0);
lp += VV(tanDistToFace[iFDest]);
GP gp(lp.x(), lp.x(), lp.x());
do_something(gp);
}

[Bug c++/60112] bogus error: array subscript is above array bounds

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60112

--- Comment #2 from David Abdurachmanov  
---
Tested today on r207627, still the same result.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/build1/davidlt/ngcc490/a/slc6_amd64_gcc490/external/gcc/4.9.0-cms/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-redhat-linux-gnu
Configured with: ../configure
--prefix=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms
--disable-multilib
 --disable-nls --with-system-zlib --disable-dssi
--enable-languages=c,c++,fortran --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object --enable-plugin --w
ith-linker-hash-style=gnu --enable-linker-build-id --enable-gold=yes
--enable-ld=default --enable-lto
--with-gmp=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f
4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms
--with-mpfr=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc
/4.9.0-cms
--with-mpc=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms
--with-isl=/build1/davidlt/ngcc490/
a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms
--with-cloog=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f
4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms
--enable-checking=release --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --enable-libstdcxx-time=rt --enable-
shared CC='gcc -fPIC' CXX='c++ -fPIC' CPP=cpp CXXCPP='c++ -E'
CFLAGS=-I/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/
gcc/4.9.0-cms/tmp/sw/include
CXXFLAGS=/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/tmp/sw/include
LDFL
AGS=-L/build1/davidlt/ngcc490/a/tmp/BUILDROOT/b53b2e753eeacd456bcc5c81474f4404/opt/cmssw/slc6_amd64_gcc490/external/gcc/4.9.0-cms/tmp/sw/lib
Thread model: posix
gcc version 4.9.0 (GCC)

[Bug target/59794] [4.7/4.8 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #13 from David Abdurachmanov  
---
Could we get this under -Wno-abi/-Wabi?

We have 256-bit vectors [__vector(4) double], but no AVX available/enabled. We
understand the affect on ABI compatibility and would like to disable such
warnings.

[Bug target/67603] New: [aarch64] constant folded of floating-point expression at compile-time value does not match run-time value

[david.abdurachmanov at gmail dot com]

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

Bug ID: 67603
   Summary: [aarch64] constant folded of floating-point expression
at compile-time value does not match run-time value
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

Created attachment 36344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36344&action=edit
standalone testcase

This was noticed in Fedora 23 AArch64, HepMC package was failing test --
testSimpleVector

Simplified testSimpleVector version is attached.

Compile: g++ -ansi -pedantic -Wall -g -O2 -o testSimpleVector
testSimpleVector.cc

Seems to fail on GCC 4.9.3, 5.2.0, trunk (r227832).

According to documentation -frounding-math disables const folding for floating
expression and it does resolve the issue, i.e. test is no more failing.

 72   namas::FourVector vector;
 73   namas::FourVector v4(1.1,2.2,3.3,4.4);
 74
 75   vector = v4;
 76   double masssq1 = v4.m2();
 77   double eta1 = v4.eta();
 78   double masssq2 = vector.m2();

v4.m2() get const folded at compile-time, but vector.m2() is computed at
run-time. The test fails because compile-time and run-time values are
"significantly" different, i.e. the difference is above 1.e-15.

vector.m2():  2.4217
v4.m2(): 2.4253 (from literal pool)

Why is that compiler cannot achieve the same result as at run-time?

[Bug target/67603] [aarch64] constant folded of floating-point expression at compile-time value does not match run-time value

[david.abdurachmanov at gmail dot com]

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

--- Comment #1 from David Abdurachmanov  
---
Created attachment 36345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36345&action=edit
Annotated assembly

Shows that one value is computed at run-time, while another one is loaded from
literal pool.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #11 from David Abdurachmanov  
---
I believe, I hit this issue with OpenLoops package on AArch64, while it works
fine on x86_64.

It shows up on 3 of Fortran files:
scons: *** [process_obj/pplljjj/loop_pplljjj_eexddxggg_1_qp.os] Error 1
scons: *** [process_obj/pplljjj/loop_pplljjj_eexuuxggg_1_qp.os] Error 1
scons: *** [process_obj/pplljjj/loop_pplljjj_eexbbxggg_1_qp.os] Error 1

I get "Error: pc-relative load offset out of range" 864 times.

Tested with GCC 4.9.1 and binutils 2.24.

I also looked into f9edeb70961d404caac5a849b0783c53228ddf62 / 213078, with it
applied on top it gets worse, i.e. more files are affected. From 864 it
increases to 1392 errors.

This particular library (pplljjj) is 158MB on x86_64. Most of it (153MB)
belongs to .text section.

The code must be compiled with -O0 otherwise machines have hard time handling
it:

gfortran: internal compiler error: Killed (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

@Andrew,
I am happy to test your patches if necessary.

[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #8 from David Abdurachmanov  
---
*** Bug 64413 has been marked as a duplicate of this bug. ***

[Bug middle-end/64413] [AArch64/ARMv7] ICE in copy_to_mode_reg, at explow.c:654

[david.abdurachmanov at gmail dot com]

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

David Abdurachmanov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at redhat dot com
 Resolution|--- |DUPLICATE

--- Comment #1 from David Abdurachmanov  
---
Worked fine with trunk. Bisecting showed that
5d098163f7aad3bed4124abc929983a620de2a82 / 216765 fixed the issue. Thus it's a
duplicate of PR 63442 ([AArch64] ICE with ubsan/overflow-int128.c test).

Applying the patch on top of GCC 4.9.1 resolved the ICE on OpenLoops 1.0.1
package.

The patch is one liner and resolves an ICE on valid code. Could I suggest RM to
have it backported for 4.9.3 release?

*** This bug has been marked as a duplicate of bug 63442 ***

[Bug sanitizer/64435] New: [5.0.0 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[david.abdurachmanov at gmail dot com]

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

Bug ID: 64435
   Summary: [5.0.0 Regression] Bootstrap failure in libsanitizer
on AArch64 with Linux kernel <= 3.15
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov 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

I finally started testing GCC trunk (5.0.0) on AArch64 before release is made.

I quickly find out that I couldn't bootstrap GCC on APM Mustang board with APM
Linux images (F19 + 3.12 kernel), but it worked fine with QEMU + F21 + 3.17
kernel). Failure details are below.

The culprit is 34c65c43f1518bf85f93526ad373adc6a683b4c5 from Linux repository.
Commit details are provided below.

Simply put __sanitizer___kernel_{uid,gid}_t depends on kernel version. <=3.15
it's unsigned int and >=3.16 it's unsigned short.

# GCC trunk failure #

In file included from
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:176:0:
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__1006' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1285:3:
note: in expansion of macro 'COMPILER_CHECK'
   COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE))
   ^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1006:1:
note: in expansion of macro 'CHECK_TYPE_SIZE'
 CHECK_TYPE_SIZE(__kernel_old_uid_t);
 ^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72:
error: size of array 'assertion_failed__1007' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
../../../../libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1285:3:
note: in expansion of macro 'COMPILER_CHECK'
   COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE))
   ^
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1007:1:
note: in expansion of macro 'CHECK_TYPE_SIZE'
 CHECK_TYPE_SIZE(__kernel_old_gid_t);
 ^
make[4]: *** [sanitizer_platform_limits_posix.lo] Error 1
make[4]: *** Waiting for unfinished jobs

# Linux Commit #

commit 34c65c43f1518bf85f93526ad373adc6a683b4c5
Author: Will Deacon 
Date:   Mon Jun 2 11:47:29 2014 +0100

arm64: uid16: fix __kernel_old_{gid,uid}_t definitions

Whilst native arm64 applications don't have the 16-bit UID/GID syscalls
wired up, compat tasks can still access them. The 16-bit wrappers for
these syscalls use __kernel_old_uid_t and __kernel_old_gid_t, which must
be 16-bit data types to maintain compatibility with the 16-bit UIDs used
by compat applications.

This patch defines 16-bit __kernel_old_{gid,uid}_t types for arm64
instead of using the 32-bit types provided by asm-generic.

Signed-off-by: Will Deacon 
Acked-by: Arnd Bergmann 
Cc: 
Signed-off-by: Catalin Marinas 

diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 42c7eec..0b3fcf8 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -30,7 +30,6 @@ generic-y += msgbuf.h
 generic-y += mutex.h
 generic-y += pci.h
 generic-y += poll.h
-generic-y += posix_types.h
 generic-y += preempt.h
 generic-y += resource.h
 generic-y += rwsem.h
diff --git a/arch/arm64/include/uapi/asm/posix_types.h
b/arch/arm64/include/uapi/asm/posix_types.h
new file mode 100644
index 000..7985ff6
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/posix_types.h
@@ -0,0 +1,10 @@
+#ifndef __ASM_POSIX_TYPES_H
+#define __ASM_POSIX_TYPES_H
+
+typedef unsigned short __kernel_old_uid_t;
+typedef unsigned short __kernel_old_gid_t;
+#define __kernel_old_uid_t __kernel_old_uid_t
+
+#include 
+
+#endif /*  __ASM_POSIX_TYPES_H */

[Bug sanitizer/64435] [5.0.0 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[david.abdurachmanov at gmail dot com]

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

--- Comment #1 from David Abdurachmanov  
---
Created attachment 34356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34356&action=edit
RFC patch (tested)

Bootstrapped on aarch64-linux-gnu machine with F19 + 3.12 and on QEMU with F21
+ 3.17.

[Bug sanitizer/64435] [5.0.0 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[david.abdurachmanov at gmail dot com]

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

--- Comment #2 from David Abdurachmanov  
---
linux/version.h does not bring any additional kernel headers, its fully
standalone and seems fine to include.

There might be a problem is someone builds a distribution with GCC 5 and kernel
<=3.15 and then decides to update the kernel creating mismatch with
libsanitizer.

[Bug ipa/64481] New: [5 Regression] r219076 breaks bootstrap (x86_64-unknown-linux-gnu)

[david.abdurachmanov at gmail dot com]

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

Bug ID: 64481
   Summary: [5 Regression] r219076 breaks bootstrap
(x86_64-unknown-linux-gnu)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

While doing testing, I found that I couldn't bootstrap GCC anymore during
holidays.

Using git bisect, I found first breaking commit:
d326c10c2de4a884476d099dbeca4794e145d8c1 / r219076.

Last good commit: 09196675b74bd04b562fe3b264a9648eb0568a59 / r219075
Last tested bad: 27f6a8a0012f8df67c88b9d28ab47c3492319a07 / r219158

Tested on Fedora 21 OpenStack image (clean setup). Commands executed on a new
virtual machine:

yum makecache
yum update
yum -y groupinstall "Development Tools"
yum -y groupinstall "C Development Tools and Libraries"
yum -y install zlib-devel
mkdir -p /build
cd /build/
git clone git://gcc.gnu.org/git/gcc.git
git checkout d326c10c2de4a884476d099dbeca4794e145d8c1
./contrib/download_prerequisites
mkdir obj
cd obj
../configure --prefix=/tmp/gccbuild --enable-bootstrap --disable-checking
--enable-languages=c,c++ --disable-multilib --with-system-zlib --enable-shared
--disable-nls
make -j4 bootstrap

[snip]

make[2]: Entering directory '/build/gcc/obj'
make[3]: Entering directory '/build/gcc/obj'
rm -f stage_current
make[3]: Leaving directory '/build/gcc/obj'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/valtrack.o differs
gcc/rtlanal.o differs
gcc/tree-ssa-ccp.o differs
gcc/tree-nested.o differs
gcc/tree-vect-stmts.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/tree-sra.o differs
gcc/dwarf2out.o differs
gcc/lto/lto.o differs
gcc/c/c-typeck.o differs
gcc/c/c-array-notation.o differs
gcc/c/c-decl.o differs
gcc/c/c-parser.o differs
gcc/tree-ssa-uninit.o differs
gcc/i386.o differs
gcc/tree-ssa.o differs
gcc/expr.o differs
gcc/except.o differs
gcc/tree-ssa-reassoc.o differs
gcc/rtl-error.o differs
gcc/tree-ssa-tail-merge.o differs
gcc/omp-low.o differs
gcc/ipa-icf.o differs
gcc/dominance.o differs
gcc/toplev.o differs
gcc/tree-ssa-structalias.o differs
gcc/ipa-pure-const.o differs
gcc/ipa-profile.o differs
gcc/coverage.o differs
gcc/ifcvt.o differs
gcc/tree-ssa-threadedge.o differs
gcc/tree-inline.o differs
gcc/trans-mem.o differs
gcc/lto-streamer-out.o differs
gcc/loop-iv.o differs
gcc/ipa-polymorphic-call.o differs
gcc/ipa-reference.o differs
gcc/tree-ssa-math-opts.o differs
gcc/graphite-sese-to-poly.o differs
gcc/cgraph.o differs
gcc/sese.o differs
gcc/ipa-split.o differs
gcc/tree-ssa-sccvn.o differs
gcc/tree-into-ssa.o differs
gcc/alias.o differs
gcc/attribs.o differs
gcc/c-family/c-pretty-print.o differs
gcc/c-family/array-notation-common.o differs
gcc/c-family/c-common.o differs
gcc/ipa-inline-analysis.o differs
gcc/vtable-verify.o differs
gcc/ipa-chkp.o differs
gcc/cfgrtl.o differs
gcc/ipa-inline-transform.o differs
gcc/tree-ssa-loop-im.o differs
gcc/dwarf2cfi.o differs
gcc/tree-ssa-dom.o differs
gcc/tree-eh.o differs
gcc/gcov.o differs
gcc/loop-invariant.o differs
gcc/tree-vrp.o differs
gcc/opts.o differs
gcc/combine-stack-adj.o differs
gcc/gimplify.o differs
gcc/varasm.o differs
gcc/tree-ssa-pre.o differs
gcc/ipa-cp.o differs 
gcc/tree-cfg.o differs
gcc/ipa-prop.o differs
gcc/cfgloop.o differs
gcc/tree-chkp.o differs
gcc/ipa-comdats.o differs
gcc/tree-vectorizer.o differs
gcc/postreload.o differs
gcc/lto-streamer-in.o differs
gcc/build/genmatch.o differs
gcc/ipa-icf-gimple.o differs
gcc/cfg.o differs
gcc/optabs.o differs
gcc/tsan.o differs
gcc/var-tracking.o differs
gcc/loop-unroll.o differs
gcc/cp/pt.o differs
gcc/cp/parser.o differs
gcc/cp/typeck2.o differs
gcc/cp/decl.o differs
gcc/cp/rtti.o differs
gcc/cp/call.o differs
gcc/cp/init.o differs
gcc/cp/cp-array-notation.o differs
gcc/cp/name-lookup.o differs
gcc/cp/constexpr.o differs
gcc/cp/semantics.o differs
gcc/tree-ssa-loop-niter.o differs
isl/isl_arg.o differs
isl/isl_ilp.o differs
isl/isl_tab_pip.o differs
isl/isl_space.o differs
isl/isl_transitive_closure.o differs
isl/isl_stream.o differs
isl/isl_output.o differs
libiberty/d-demangle.o differs
libiberty/pic/d-demangle.o differs
mpfr/lngamma.o differs
mpfr/gamma.o differs
Makefile:22563: recipe for target 'compare' failed
make[2]: *** [compare] Error 1
make[2]: Leaving directory '/build/gcc/obj'
Makefile:22542: recipe for target 'stage3-bubble' failed
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory '/build/gcc/obj'
Makefile:22605: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov  
---
I decided to re-enable -Os for OpenLoops. Then use powerful hardware with
32-physical-cores (x86_64) and 0.5TB of RAM to see if I could get lucky. Fired
up QEMU user mode with Fedora for AArch64 chroot for compiling.

It did resolve some of failures, but not everything. I have seen processes
going as far as 25+GB of RSS and taking hours to finish. This is the reason
package is compiled with -O0.

[Bug sanitizer/64435] [5.0.0 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[david.abdurachmanov at gmail dot com]

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

--- Comment #3 from David Abdurachmanov  
---
The patch has been submitted to LLVM/compiler-rt and approved. Not yet
committed, pending testing with Clang.

http://reviews.llvm.org/D6854

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

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

--- Comment #13 from David Abdurachmanov  
---
Created attachment 34416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34416&action=edit
31-lines, minimal testcase

I am adding 31-lines minimal testcase. Should be good enough for GCC testsuite.

$ gcc -O0 -c pr63304-testcase.c
/tmp/ccKdBqsL.s: Assembler messages:
/tmp/ccKdBqsL.s:58: Error: pc-relative load offset out of range
/tmp/ccKdBqsL.s:62: Error: pc-relative load offset out of range

Yesterday I looked into RTL output and assembly of some failures for OpenLoops.
The function was 400+K lines in assembly. On x86_64 it was something 180+K
lines of assembly and ~1.3MB for function body size.

I can confirm that offset is above 1MB mark and it was trying to load
__float128/long double to q1 from constant pool for passing to `addtf3`.

[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15

[david.abdurachmanov at gmail dot com]

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

--- Comment #8 from David Abdurachmanov  
---
I will finish testing my patch for upstream next week. I was busy with other
tasks.

AArch64 is young, this kind of things are bound to happen :/

[Bug middle-end/64413] New: [AArch64/ARMv7] ICE in copy_to_mode_reg, at explow.c:654

[david.abdurachmanov at gmail dot com]

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

Bug ID: 64413
   Summary: [AArch64/ARMv7] ICE in copy_to_mode_reg, at
explow.c:654
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

Created attachment 34338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34338&action=edit
testcase (AArch64, Fortran)

OpenLoops 1.0.1 package is failing to compile on AArch64 with GCC 4.9.{1,2}
there gfortran ICE'd:

test.f90: In function 'vert_aq_s':
test.f90:38:0: internal compiler error: in copy_to_mode_reg, at explow.c:654
 Jout_S%j(1) = 0
 ^

I managed to extract a minimal testcase (testcase.f90). It should be compiled
like this:

gfortran -o testcase.os -c -ffixed-line-length-0 -ffree-line-length-0 -O0 -O0
-fPIC testcase.f90

A similar ICE was recently posted (Oct 20) with GCC 4.9.1, ARMv7, C++ on
stackoverflow:
http://stackoverflow.com/questions/26474507/compiler-crash-with-arm-neon-datatypes

I.e., the ICE point to the same "copy_to_mode_reg, at explow.c:654". Might be
related.

Have not tested with GCC 5.0 (trunk).

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

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

--- Comment #14 from David Abdurachmanov  
---
I hit another two cases of this.

1. g2root tool, which converts GEANT geometry to ROOT geometry. It create a
single function, which contains lots of descriptions of material, shapes, etc.
all describing some 3D objects and physical properties. These can be very huge.

Also could think of MILL computing as possible example. They use C++ as they
assembler (at least for simulation). Thus you have something like:

void somefunc(void) {
  add(b0, b1);
  add(b2, b3);
  ...
}

IIRC, by compiling it they generate a simulator to run this program on specific
CPU.

2. mcfm 6.3 package, to be precise: mcfm-6.3/src/WW/triangle11new.f

triangle11new.s: Assembler messages:
triangle11new.s:587: Error: pc-relative load offset out of range
triangle11new.s:592: Error: pc-relative load offset out of range

..
   587 ldr x0, .LC2
   588 fmovd0, x2
   589 fmovd1, x0
   590 fdivd0, d0, d1
   591 fmovx2, d0
   592 ldr x0, .LC2
..

346645 .LC2:
346646 .word   0
346647 .word   1073741824
346648 .align  3
..

Distance between ldr instruction and .LC2 is 346058 assembly lines.

Here is the source file:
https://github.com/cms-externals/MCFM/blob/master/src/WW/triangle11new.f (just
1355 sloc).

It's those huge computations, which are killing it. Similar issue as in
OpenLoops package.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

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

--- Comment #21 from David Abdurachmanov  
---
I am on vacations now, but I already marked this on my TODO list. Once I find a
free time slot I will give it a spin. I will try to report in a few days.

BTW, I will also show up at GNU Tools Cauldron 2015.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[david.abdurachmanov at gmail dot com]

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

--- Comment #23 from David Abdurachmanov  
---
GCC trunk
  r226676
  or 15af172f2a0ea281969e3105da9f9bb100097c7d from
git://gcc.gnu.org/git/gcc.git
  Date:   Thu Aug 6 14:26:18 2015 +)

Rebased and applied:

  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02074.html
  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02258.html

binutils trunk
  f0ce0d3a331129309a46a6a9ac85fce35acae72b from
git://sourceware.org/git/binutils-gdb.git
  Date:   Thu Jul 23 16:01:01 2015 +0100)

Rebases and applied:
  https://sourceware.org/ml/binutils/2015-07/msg00137.html

$ gcc -dumpversion
6.0.0
$ ld --version
GNU ld (GNU Binutils) 2.25.51.20150806

I __successfully__ compiled OpenLoops 1.1.1 and MCFM 6.3 packages.