[Bug c++/69481] ICE with C++11 alias using with templates

[wen...@mitsuba-renderer.org]

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

--- Comment #4 from Wenzel Jakob  ---
I'm pretty sure this is a recent regression -- GCC was able to compile the code
on Bug 77629 a month ago.

[Bug c++/69481] ICE with C++11 alias using with templates

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Wenzel Jakob from comment #4)
> I'm pretty sure this is a recent regression -- GCC was able to compile the
> code on Bug 77629 a month ago.

Did you use a compiler from a release branch? If so --enable-checking=release
is the default there while on the trunk it is always =yes.

[Bug c++/69481] ICE with C++11 alias using with templates

[wen...@mitsuba-renderer.org]

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

--- Comment #6 from Wenzel Jakob  ---
No -- I am experimenting with the AVX512F backend and thus need to use the
development branch.

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[lkrupp at gcc dot gnu.org]

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

lkrupp at gcc dot gnu.org changed:

   What|Removed |Added

 CC||lkrupp at gcc dot gnu.org

--- Comment #6 from lkrupp at gcc dot gnu.org ---
I started looking at this until I read all of the comments and realized that
someone had already come up with a patch, and one that is probably better and
certainly simpler than whatever I would have done.

It might be worth noting that the problem seems to come up when an array is
passed to an intrinsic function that returns a scalar when its argument is a
scalar and that returns an array when it's passed an array.  In the sample
program in the description, the intrinsic function is integer to real
conversion.  The following sample program reproduces that problem with a simple
array instead of an implied do loop, and also with the square root function. 
Compiling this with -fbounds-check makes the program fail on the assignment
statement:

program assign_allocatable
implicit none

  call s_int_real_cvt
  call s_sqrt

contains

  subroutine s_int_real_cvt
  implicit none
  integer, parameter :: r(3) = [101, 102, 103]
  real, allocatable :: k(:)

  k = r

  if (any(k /= r)) call abort

  return
  end subroutine

  subroutine s_sqrt
  implicit none
  real, parameter :: r(5) = [1, 4, 9, 16, 25]
  real, allocatable :: a(:)

  a = sqrt(r)

  if (any(a /= [1, 2, 3, 4, 5])) call abort

  return
  end subroutine

end program

Array-value intrinsics like TRANSFER and PACK don't seem to trigger this
problem.

[Bug sanitizer/77631] New: no symbols in backtrace shown by ASan when debug info is split

[gcc-bugs at muelli dot cryptobitch.de]

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

Bug ID: 77631
   Summary: no symbols in backtrace shown by ASan when debug info
is split
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at muelli dot cryptobitch.de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

I'm using GCC 6.2 with Address Sanitizer.
When stripping debug info to separate files, gdb is able to load those nicely.
When ASan prints a stacktrace, however, no symbols are shown.

bash-4.3$ gdb gnome-calculator 
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gnome-calculator...Reading symbols from
/usr/lib/debug//app/bin/gnome-calculator.debug...done.
done.
(gdb) start
Temporary breakpoint 1 at 0x4129b9: file gnome-calculator.c, line 1162.
Starting program: /app/bin/gnome-calculator 
warning: Error disabling address space randomization: Operation not
permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7ffc23a33f78)
at gnome-calculator.c:1162
1162return calculator_main (argv, argc);
(gdb) l
1157
1158int main (int argc, char ** argv) {
1159#if !GLIB_CHECK_VERSION (2,35,0)
1160g_type_init ();
1161#endif
1162return calculator_main (argv, argc);
1163}
1164
1165
1166static void calculator_class_init (CalculatorClass * klass)
{
(gdb) n

(gnome-calculator:5): Gtk-WARNING **: Locale not supported by C
library.
Using the fallback 'C' locale.
=
==3==ERROR: AddressSanitizer: global-buffer-overflow on address
0x006c7eb0 at pc 0x0041491e bp 0x7fff8ef07f50 sp 0x7fff8ef07f48
READ of size 8 at 0x006c7eb0 thread T0
#0 0x41491d  (/app/bin/gnome-calculator+0x41491d)
#1 0x413f36  (/app/bin/gnome-calculator+0x413f36)
#2 0x4213da  (/app/bin/gnome-calculator+0x4213da)
#3 0x4243ec  (/app/bin/gnome-calculator+0x4243ec)
#4 0x42c59a in math_buttons_set_mode (/app/bin/gnome-
calculator+0x42c59a)
#5 0x40de41  (/app/bin/gnome-calculator+0x40de41)
#6 0x7f7d81e65783  (/lib/libgobject-2.0.so.0+0xf783)
#7 0x7f7d81e7f5e7 in g_signal_emit_valist (/lib/libgobject-



I expected to see a nice stacktrace just like gdb would print it.

[Bug fortran/77632] New: Pointer initialisation does not quite work

[arjen.markus895 at gmail dot com]

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

Bug ID: 77632
   Summary: Pointer initialisation does not quite work
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arjen.markus895 at gmail dot com
  Target Milestone: ---

The Fortran 2008 standard allows pointer variables to be initialised as:

real, dimension(100), target :: array
real, dimension(:), pointer :: parray => array

While the syntax is accepted, the result is not as expected. The following
program demonstrates this:

! test_pointer_init.f90 --
! It seems pointer initialisation is not working correctly?
!
program test_pointer_init
implicit none

real, dimension(100), target  :: array
real, dimension(:), pointer   :: alternative => array

! This prints "F" whereas I expect "T"

write( *, '(a,l)'  ) 'Associated: ', associated(alternative,array)

end program test_pointer_init

[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature

[wen...@mitsuba-renderer.org]

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

--- Comment #3 from Wenzel Jakob  ---
Any updates here? Should this be closed?

[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature

[wen...@mitsuba-renderer.org]

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

--- Comment #4 from Wenzel Jakob  ---
Hmm, it looks like this is still an issue. Recompiling my codebase with the
latest trunk version of gcc still produces many errors caused by this, e.g.


include/simdarray/array_avx512.h:1059:53: error: invalid conversion from
‘simd::ArrayOperations >::Scalar* {aka
unsigned int*}’ to ‘const int*’ [-fpermissive]
 __m512i values = _mm512_mask_i32gather_epi32(
  ~~~^
 _mm512_undefined_epi32(), mask.k, index.m, f, sizeof(Scalar));
 ~
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include/immintrin.h:45:0,
 from include/simdarray/array.h:33,
 from tests/histogram.cpp:2:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include/avx512fintrin.h:9316:1:
note:   initializing argument 4 of ‘__m512i
_mm512_mask_i32gather_epi32(__m512i, __mmask16, __m512i, const int*, int)’
 _mm512_mask_i32gather_epi32 (__m512i __v1_old, __mmask16 __mask,
 ^~~
In file included from include/simdarray/array.h:73:0,
 from tests/histogram.cpp:2:
include/simdarray/array_avx512.h:1068:22: error: use of ‘main(int,
char**):: [with auto:1 = simd::Array]’ before deduction of ‘auto’
 values = func(Derived(values)).m;

etc...

[Bug tree-optimization/72824] [5/6 Regression] Signed floating point zero semantics broken at optimization level -O3 (tree-loop-distribute-patterns)

[wen...@mitsuba-renderer.org]

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

--- Comment #13 from Wenzel Jakob  ---
The fix was merged, so I assume this bug should be closed as RESOLVED?

[Bug c++/69481] ICE with C++11 alias using with templates

[wen...@mitsuba-renderer.org]

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

--- Comment #7 from Wenzel Jakob  ---
Correction: this ICE indeed goes away when building with
--enable-checking=release (though that doesn't seem like a nice solution). I
assume I used this check level in my trunk builds before and forgot it this
time.

[Bug fortran/77632] Pointer initialisation does not quite work

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0). This Fortran 2008 is not implemented in
4.7.3.

[Bug middle-end/71682] [7 Regression] Several libjava failures on x86_64-apple-darwin15 with -m32 after r237556

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Related to/duplicate of pr77262. IMO it would be nice to investigate the
problem before java is removed from gcc.

[Bug target/77633] New: AVX512: shuffle intrinsic has incorrect signature when optimizations are enabled

[wen...@mitsuba-renderer.org]

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

Bug ID: 77633
   Summary: AVX512: shuffle intrinsic has incorrect signature when
optimizations are enabled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wen...@mitsuba-renderer.org
  Target Milestone: ---

The AVX512 shuffle intrinsic switches to a different implementation (&
different signature) when optimizations are turned on. This leads to the
following strange error message when compiling a snippet that passes the type
checker at -O0.

///


$ g++-7 test.c -march=knl -O3
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include/immintrin.h:29:0,
 from test.c:1:
test.c: In function ‘void test()’:
test.c:8:50: error: invalid conversion from ‘int’ to ‘_MM_PERM_ENUM’
[-fpermissive]
 _mm512_shuffle_epi32(_mm512_setzero_epi32(), _MM_SHUFFLE(0, 3, 0, 1));
  ^
In file included from
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include/immintrin.h:45:0,
 from test.c:1:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include/avx512fintrin.h:3848:1:
note:   initializing argument 2 of ‘__m512i _mm512_shuffle_epi32(__m512i,
_MM_PERM_ENUM)’
 _mm512_shuffle_epi32 (__m512i __A, _MM_PERM_ENUM __mask)
 ^~~~


///


#include 

void test() {
/* SSE shuffle: works */
_mm_shuffle_epi32(_mm_setzero_si128(), _MM_SHUFFLE(0, 3, 0, 1));

/* AVX512 shuffle: type checker error when optimizations are turned on! */
_mm512_shuffle_epi32(_mm512_setzero_epi32(), _MM_SHUFFLE(0, 3, 0, 1));
}

[Bug c++/69481] ICE with C++11 alias using with templates

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
(In reply to Wenzel Jakob from comment #7)
> Correction: this ICE indeed goes away when building with
> --enable-checking=release (though that doesn't seem like a nice solution). I
> assume I used this check level in my trunk builds before and forgot it this
> time.

No. I guess you were right. You can switch checking on/off with -fchecking in
gcc6/7.
And indeed the testcase from PR77629 only hits the assert on trunk.
Will try to bisect later.

[Bug testsuite/77634] New: some vectorized testcases fail with -mcpu=thunderx

[pinskia at gcc dot gnu.org]

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

Bug ID: 77634
   Summary: some vectorized testcases fail with -mcpu=thunderx
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

I noticed the aarch64 testsuite does not use -fno-vect-cost-model when it
should be and if I configure gcc --with-cpu=thunderx, I get the following
failures due to this:
-FAIL: gcc.target/aarch64/fmaxmin.c scan-assembler-times fmaxnm\\tv[0-9]+.2d,
v[0-9]+.2d, v[0-9]+.2d 1
-FAIL: gcc.target/aarch64/fmaxmin.c scan-assembler-times fminnm\\tv[0-9]+.2d,
v[0-9]+.2d, v[0-9]+.2d 1
-FAIL: gcc.target/aarch64/fmul_fcvt_2.c scan-assembler-times
fcvtzs\\tv[0-9].4s, v[0-9].4s*.*#2 1
-FAIL: gcc.target/aarch64/fmul_fcvt_2.c scan-assembler-times
fcvtzs\\tv[0-9].4s, v[0-9].4s*.*#3 1
-FAIL: gcc.target/aarch64/fmul_fcvt_2.c scan-assembler-times
fcvtzs\\tv[0-9].4s, v[0-9].4s*.*#4 1
-FAIL: gcc.target/aarch64/vect-abs-compile.c scan-assembler abstv[0-9]+.2d
-FAIL: gcc.target/aarch64/vect-clz.c scan-assembler clz\\tv[0-9]+.4s
-FAIL: gcc.target/aarch64/vect-fcm-eq-d.c scan-assembler fcmeqtv[0-9]+.2d,
v[0-9]+.2d, 0
-FAIL: gcc.target/aarch64/vect-fcm-eq-d.c scan-assembler fcmeqtv[0-9]+.2d,
v[0-9]+.2d, v[0-9]+.2d
-FAIL: gcc.target/aarch64/vect-fcm-eq-d.c scan-tree-dump-times vect "vectorized
1 loops" 8
-FAIL: gcc.target/aarch64/vect-fcm-ge-d.c scan-assembler fcmgetv[0-9]+.2d,
v[0-9]+.2d, 0
-FAIL: gcc.target/aarch64/vect-fcm-ge-d.c scan-assembler fcmgetv[0-9]+.2d,
v[0-9]+.2d, v[0-9]+.2d
-FAIL: gcc.target/aarch64/vect-fcm-ge-d.c scan-assembler fcmlttv[0-9]+.2d,
v[0-9]+.2d, 0
-FAIL: gcc.target/aarch64/vect-fcm-ge-d.c scan-tree-dump-times vect "vectorized
1 loops" 8
-FAIL: gcc.target/aarch64/vect-fcm-gt-d.c scan-assembler fcmgttv[0-9]+.2d,
v[0-9]+.2d, 0
-FAIL: gcc.target/aarch64/vect-fcm-gt-d.c scan-assembler fcmgttv[0-9]+.2d,
v[0-9]+.2d, v[0-9]+.2d
-FAIL: gcc.target/aarch64/vect-fcm-gt-d.c scan-assembler fcmletv[0-9]+.2d,
v[0-9]+.2d, 0
-FAIL: gcc.target/aarch64/vect-fcm-gt-d.c scan-tree-dump-times vect "vectorized
1 loops" 8
-FAIL: gcc.target/aarch64/vect-fmovd-zero.c scan-assembler
movitv[0-9]+.2d, 0
-FAIL: gcc.target/aarch64/vect-fmovd-zero.c scan-tree-dump-times vect
"vectorized 1 loops" 1
-FAIL: gcc.target/aarch64/vect-fmovd.c scan-assembler fmovtv[0-9]+.2d,
4.25
-FAIL: gcc.target/aarch64/vect-fmovd.c scan-tree-dump-times vect "vectorized 1
loops" 1
-FAIL: gcc.target/aarch64/vect-fmovf-zero.c scan-assembler
movitv[0-9]+.[24]s, 0
-FAIL: gcc.target/aarch64/vect-fmovf-zero.c scan-tree-dump-times vect
"vectorized 1 loops" 1
-FAIL: gcc.target/aarch64/vect-fmovf.c scan-assembler
fmovtv[0-9]+.[24]s, 4.25
-FAIL: gcc.target/aarch64/vect-fmovf.c scan-tree-dump-times vect "vectorized 1
loops" 1
-FAIL: gcc.target/aarch64/vect_ctz_1.c scan-assembler clz\\tv[0-9]+.2s
-FAIL: gcc.target/aarch64/vect_ctz_1.c scan-assembler clz\\tv[0-9]+.4s


-FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times
pcom "Executing predictive commoning without unrolling" 1
-FAIL: gfortran.dg/vect/pr62283.f   -O   scan-tree-dump-times vect "vectorized
1 loops" 2



-FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++11  scan-tree-dump-times slp1 "basic
block vectorized" 1
-FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++14  scan-tree-dump-times slp1 "basic
block vectorized" 1
-FAIL: g++.dg/vect/slp-pr56812.cc  -std=c++98  scan-tree-dump-times slp1 "basic
block vectorized" 1

[Bug testsuite/77635] New: load/store pair testcases need to use -mcpu=generic

[pinskia at gcc dot gnu.org]

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

Bug ID: 77635
   Summary: load/store pair testcases need to use -mcpu=generic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

When I added load/store pair word unaligned to the backend, I forgot to update
the testsuite to use -mcpu=generic so the following testcases fail currently
when gcc is configured --with-cpu=thunderx:
-FAIL: gcc.target/aarch64/ldp_stp_1.c scan-assembler-times stp\\tw[0-9]+,
w[0-9] 7
-FAIL: gcc.target/aarch64/store-pair-1.c scan-assembler stp\\tw([0-9]+)|(zr),
w[0-9]+

[Bug c++/77629] internal compiler error: same canonical type node for different types

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2016-09-18
 CC||jason at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
Started with r238696:

commit 44d0a5f893a449013cf4d64127dcac7b51c0a8e8
Author: jason 
Date:   Sun Jul 24 23:40:05 2016 +

PR c++/71515 - typename in partial specialization

* pt.c (resolve_typename_type): Try to avoid calling
currently_open_class.

Testcase:

template  struct A;
template  using enable_if_t = typename A<_Cond>::type;
template  struct B;
template  struct C;
template  struct D;
template 
struct B::peel>> {
  using Base = D;
//  typedef  D  Base; // OK
  using typename Base::Scalar;
  Scalar a;
};

See: PR69481 for a similar issue.

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I suspect libbacktrace does not implement this.

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[tprince at computer dot org]

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

--- Comment #8 from tprince at computer dot org ---
I show my configure parameters in my test results posts.  At some time in the
past, each of them has been important.  I don't know if the parameters quoted
by cygwin release pertain to cross compiling.  As the parameters I use have
been successful again last week on win8.1 I don't see how they might pertain to
the f951 bootstrap failure on win10.  When I get back to the win10 box I will
compare with disable bootstrap.

[Bug tree-optimization/72824] [5 Regression] Signed floating point zero semantics broken at optimization level -O3 (tree-loop-distribute-patterns)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||6.2.1
Summary|[5/6 Regression] Signed |[5 Regression] Signed
   |floating point zero |floating point zero
   |semantics broken at |semantics broken at
   |optimization level -O3  |optimization level -O3
   |(tree-loop-distribute-patte |(tree-loop-distribute-patte
   |rns)|rns)

--- Comment #14 from Jakub Jelinek  ---
Only on the 6.x branch so far, not in 5.x.

[Bug libstdc++/77619] uninitialized_meow_construct and friends not exception safe

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01131.html

[Bug target/77628] avx512: unnecessary GR extending after kmovw

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Uroš Bizjak  ---
This is fixed for current trunk (gcc-7).

[Bug target/77621] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Uroš Bizjak  ---
It compiles OK with vanilla gcc-6.

However, you are using RedHat provided compiler, please report the failure to
RedHat bugzilla, as the compiler instructed you when it crashed.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

--- Comment #16 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #14)
> Created attachment 39638 [details]
> exhaustive results for libstdc++ with Xcode 8 + patch
> 
> Silenced with
> 
> +# Ignore harmless warnings from Xcode 8.0.
> +regsub -all "(^|\n)ld: warning: direct access in function\[^\n\]* means
> the weak symbol cannot be overridden\[^\n\]*" $text "" text
> 
> in libstdc++-v3/testsuite/lib/prune.exp.

Unfortunately, these are not really harmless - since they flag that ld64 is
getting confused by GCC's output (another atom problem).

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe  ---

So.. we need a patch that implements what Dominique was trying (but in a way
that doesn't involve discarding the original section defs. since they are
needed for "older linker" - for some def. of "older").

1. a patch that changes the section usage depending on the capability of ld64.

 ... I have a patch under test for this.

2. configury to detect if we have a ld64 that doesn't cope (and we need to find
one that doesn't to test that).  My initial tests suggest that even 85.2.1 can
do the week symbol coalescing without the sections, so we might have to poke at
a 10.4 system to find this.

 ... TODO

3. The fallout that Dominique sees with his patch is caused by two latent
issues:

 .data
weak symbol
  ...
L_xxx$non_lazy_ptr

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #18 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #17)
oops hit send at the wrong moment:

> So.. we need a patch that implements what Dominique was trying (but in a way
> that doesn't involve discarding the original section defs. since they are
> needed for "older linker" - for some def. of "older").
> 
1. a patch that changes the section usage depending on the capability of
 ld64.

  ... I have a patch under test for this.

 2. configury to detect if we have a ld64 that doesn't cope (and we need to
 find one that doesn't to test that).  My initial tests suggest that even
 85.2.1 can do the week symbol coalescing without the sections, so we might
 have to poke at a 10.4 system to find this.

  ... TODO

 3. The fallout that Dominique sees with his patch is caused by two latent
 issues:

  .data
 weak symbol
   ...
 L_xxx$non_lazy_ptr
  .y _symbol

now - ld64 can't split L_xxx$non_lazy_ptr from the weak symbol (since it's
L_xxx) and it means that the atom containing the indirection is now marked weak
- and we are accessing it directly.  This is what ld64's warming is about.

  I have a patch that sorts this one out (and squashes most of the
libstdc++ fallout)

... but there's a similar problem with weak constants followed by non-weak ones
(which are local and legitimately directly referenced in the tu).

 ... TODO.

I'll attach a WIP in patch here, when 1 && 3 are solved (it's testable without
2).

[Bug fortran/77636] New: OpenMP SIMD rejects an array in ALIGNED clause list

[venovako at venovako dot eu]

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

Bug ID: 77636
   Summary: OpenMP SIMD rejects an array in ALIGNED clause list
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: venovako at venovako dot eu
  Target Milestone: ---

Created attachment 39641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39641&action=edit
The source file to reproduce the problem.

I use GNU Fortran (GCC) 7.0.0 20160918 (experimental), bootstrapped from SVN
rev. 240220, but the problem appears with some earlier builds, also.

I've observed the following on x86_64 (Darwin), and power8le (Linux).

The command line that fails to build an executable:
gfortran -fopenmp simderr.f90

The output:
simderr.f90:24:23:

 !$OMP SIMD ALIGNED(A:16)
   1
Error: ‘a’ in ALIGNED clause must be POINTER, ALLOCATABLE, Cray pointer or
C_PTR at (1)
simderr.f90:12:21:

   !$OMP SIMD ALIGNED(A:16)
 1
Error: ‘a’ in ALIGNED clause must be POINTER, ALLOCATABLE, Cray pointer or
C_PTR at (1)

So, when an array variable or a dummy argument (here, 'A') is referenced in
ALIGNED clause of a SIMD directive, it is rejected with an explanation quoted
above.

If you refer to OpenMP standard, version 4.5 (November 2015), page 76, lines 3
to 8, the only constraints mentioned are in the conditional form (IF a list
item ... has the ALLOCATABLE/POINTER attribute... THEN something must hold).
I fail to see any statement that precludes having an "ordinary" array
referenced in the list.
Besides being a reasonable and the most simple use case conceivable of the
ALIGNED clause, the same program as attached here is compiled correctly and
without any errors/warnings with, e.g., Intel Fortran 17.0.0.102 Build 20160720
on Darwin; `ifort -qopenmp simderr.f90` would do.

The restrictions that the error output mentions echo those in the same OpenMP
standard, page 80, lines 19 to 20, pertaining to DECLARE SIMD (but not to SIMD)
directive.

Do I get it right that such restrictions should not apply in this case, and the
code should be accepted as valid and compiled?

[Bug jit/66627] [meta-bug] Tracker bug for jit bugs affecting ravi

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||meta-bug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-18
Summary|Tracker bug for jit bugs|[meta-bug] Tracker bug for
   |affecting ravi  |jit bugs affecting ravi
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
.

[Bug c++/72822] libiberty/ demangler crash

[jan.kratochvil at redhat dot com]

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

--- Comment #3 from Jan Kratochvil  ---
Without a fix I do not know if it is the same problem or not:

_ZSt7forwardIRZZN6WebKit29NetworkConnectionToWebProcess26writeBlobsToTemporaryFilesERKN3WTF6VectorINS2_6StringELm0ENS2_15CrashOnOverflowELm16EEEmENUlRT_E_clIS7_EEDaSA_EUlvE_EOS9_RNSt16remove_referenceIS9_E4typeE

https://bugzilla.redhat.com/show_bug.cgi?id=1367131

[Bug c++/72822] libiberty/ demangler crash

[jan.kratochvil at redhat dot com]

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

--- Comment #4 from Jan Kratochvil  ---
Comment 3 is for: https://bugzilla.redhat.com/show_bug.cgi?id=1377020

[Bug c++/77637] New: ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[chengniansun at gmail dot com]

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

Bug ID: 77637
   Summary: ICE on x86_64-linux-gnu (Segmentation fault,
tree_check, cp_parser_std_attribute_list...)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160918 (experimental) [trunk revision 240220] (GCC)
$
$ g++-trunk small.C
small.C:1:6: internal compiler error: Segmentation fault
 int[[...]] a;
  ^~~
0xdc7baf crash_signal
../../gcc-source-trunk/gcc/toplev.c:336
0x78a1cb tree_check
../../gcc-source-trunk/gcc/tree.h:3025
0x78a1cb cp_parser_std_attribute_list
../../gcc-source-trunk/gcc/cp/parser.c:24223
0x78a1cb cp_parser_std_attribute_spec
../../gcc-source-trunk/gcc/cp/parser.c:24289
0x78a1cb cp_parser_std_attribute_spec_seq
../../gcc-source-trunk/gcc/cp/parser.c:24377
0x78d94f cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12694
0x79a9c1 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12416
0x79ae66 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12363
0x7a3d14 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12260
0x7a28af cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12139
0x7a2bf8 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4356
0x7a2bf8 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37714
0x917b92 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1073
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
int[[...]] a;
$

[Bug c++/77638] New: ICE on x86_64-linux-gnu (internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in cp_parser_template_declaration_after_parame

[chengniansun at gmail dot com]

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

Bug ID: 77638
   Summary: ICE on x86_64-linux-gnu (internal compiler error: tree
check: expected tree that contains ‘decl common’
structure, have ‘error_mark’ in
cp_parser_template_declaration_after_parameters, at
cp/parser.c:25722)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160918 (experimental) [trunk revision 240220] (GCC)
$
$ g++-trunk small.C
small.C:2:11: error: ‘CharT’ has not been declared
 template 
   ^
small.C:2:18: error: ‘CharT’ has not been declared
 template 
  ^
small.C:3:30: error: ‘String’ has not been declared
 typename enable_if::type operator"" _script();
  ^~
small.C:3:47: error: template argument 1 is invalid
 typename enable_if::type operator"" _script();
   ^
small.C:3:75: internal compiler error: tree check: expected tree that contains
‘decl common’ structure, have ‘error_mark’ in
cp_parser_template_declaration_after_parameters, at cp/parser.c:25722
 typename enable_if::type operator"" _script();
   ^
0x10790d4 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9914
0x79c2a8 contains_struct_check
../../gcc-source-trunk/gcc/tree.h:3140
0x79c2a8 cp_parser_template_declaration_after_parameters
../../gcc-source-trunk/gcc/cp/parser.c:25722
0x79c7a1 cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:25902
0x79c7a1 cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:25920
0x7a3e59 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12209
0x7a28af cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12139
0x7a2bf8 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4356
0x7a2bf8 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37714
0x917b92 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1073
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
template  struct enable_if;
template 
typename enable_if::type operator"" _script();

[Bug c++/77639] New: ICE on x86_64-linux-gnu (internal compiler error: tree check: accessed elt 1 of tree_vec with 0 elts in unify, at cp/pt.c:19674)

[chengniansun at gmail dot com]

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

Bug ID: 77639
   Summary: ICE on x86_64-linux-gnu (internal compiler error: tree
check: accessed elt 1 of tree_vec with 0 elts in
unify, at cp/pt.c:19674)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160918 (experimental) [trunk revision 240220] (GCC)
$
$ g++-trunk small.C
small.C:2:35: error: an explicit specialization must be preceded by ‘template
<>’
 template  {};
   ^~~~
   template <>
small.C:2:42: error: enclosing class templates are not explicitly specialized
 template  {};
  ^
small.C:2:56: error: types may not be defined in parameter types
 template  {};
^
small.C:2:56: error: definition of ‘struct B’ inside template
parameter list
small.C:2:57: error: two or more data types in declaration of ‘parameter’
 template  {};
 ^
small.C:2:58: error: expected ‘>’ before ‘;’ token
 template  {};
  ^
small.C:2:58: error: expected unqualified-id before ‘;’ token
small.C:3:20: internal compiler error: tree check: accessed elt 1 of tree_vec
with 0 elts in unify, at cp/pt.c:19674
 B i;
^
0x107f2b5 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9939
0x6f2572 tree_vec_elt_check
../../gcc-source-trunk/gcc/tree.h:3247
0x6f2572 unify
../../gcc-source-trunk/gcc/cp/pt.c:19674
0x6f1915 unify
../../gcc-source-trunk/gcc/cp/pt.c:20081
0x6f4156 get_partial_spec_bindings
../../gcc-source-trunk/gcc/cp/pt.c:20851
0x6eb961 most_specialized_partial_spec
../../gcc-source-trunk/gcc/cp/pt.c:21107
0x707005 instantiate_class_template_1
../../gcc-source-trunk/gcc/cp/pt.c:9848
0x707005 instantiate_class_template(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:10416
0x7adbcb complete_type(tree_node*)
../../gcc-source-trunk/gcc/cp/typeck.c:133
0x66b315 start_decl_1(tree_node*, bool)
../../gcc-source-trunk/gcc/cp/decl.c:5168
0x6944bf start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc-source-trunk/gcc/cp/decl.c:5131
0x79a089 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18701
0x79aae7 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12495
0x79ae66 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12363
0x7a3d14 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12260
0x7a28af cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12139
0x7a2bf8 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4356
0x7a2bf8 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37714
0x917b92 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1073
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
$ cat small.C
template  struct B {};
template  {};
B i;
$

[Bug plugins/62252] a callback to event PLUGIN_FINISH_TYPE segfaults

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #1 from Kazumoto Kojima  ---
(In reply to Rich Felker from comment #0)

Do you have any idea for reasonable size?  Or do you prefer some options
like -mno-prefer-expand-block-move / -mexpand-block-move-threshold= ?

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker  ---
Unless you expect the inline memcpy to be a size savings (and it does not seem
to be), the size threshold can just be chosen such that function call time is
negligible compared to copying time. I suspect that's already true around 256
bytes or so. I'm testing a patch where I used 256 as the limit and it made the
Linux kernel very slightly faster (~1-2%) and does not seem to hurt anywhere.

Major differences are unlikely to be seen unless the library memcpy does
something fancy like DMA (or just avoiding aliasing in direct-mapped caches).

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to frankhb1989 from comment #7)
> This is definitely a leak from the view of libc. Why is the status INVALID
> instead of WONTFIX?

It is still reachable.  Since it is reachable, a pointer at deconstructor time
could use it.  This pool is used to low memory situations.  And can be used
even near exit.  There is no leak; a leak means it is no longer reachable.
Most programs will not free some of their memory at the end of their program
anyways; they would just call exit.

[Bug tree-optimization/77514] [6 Regression] ICE in VN_INFO_GET, at tree-ssa-sccvn.c:406 w/ -O2 (and above)

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 19 06:54:10 2016
New Revision: 240226

URL: https://gcc.gnu.org/viewcvs?rev=240226&root=gcc&view=rev
Log:
2016-09-19  Richard Biener  

PR tree-optimization/77514
* tree-ssa-pre.c (create_expression_by_pieces): Optimize
search for folded stmt.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/77605] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] wrong|[5/6 Regression] wrong code
   |code at -O3 on  |at -O3 on x86_64-linux-gnu
   |x86_64-linux-gnu|

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/77605] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 19 06:55:17 2016
New Revision: 240227

URL: https://gcc.gnu.org/viewcvs?rev=240227&root=gcc&view=rev
Log:
2016-09-19  Richard Biener  

PR middle-end/77605
* tree-data-ref.c (analyze_subscript_affine_affine): Use the
proper niter to bound the loops.

* gcc.dg/torture/pr77605.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77605.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[michael at mijobe dot org]

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

michael at mijobe dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #4 from michael at mijobe dot org ---
Have now had the time to recompile. Running now into an internal compiler
error:

$HOME/gcc-6.2.0-build/./prev-gcc/xg++ -B$HOME/gcc-6.2.0-build/./prev-gcc/
-B$HOME/gcc-6.2.0-bin/sparc-sun-solaris2.10/bin/ -nostdinc++
-B$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-B$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs

-I$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10
 -I$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/include 
-I$HOME/gcc-6.2.0/libstdc++-v3/libsupc++
-L$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-L$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I../../gcc-6.2.0/gcc -I../../gcc-6.2.0/gcc/.
-I../../gcc-6.2.0/gcc/../include -I./../intl
-I../../gcc-6.2.0/gcc/../libcpp/include -I$HOME/gcc-6.2.0-build/./gmp
-I$HOME/gcc-6.2.0/gmp -I$HOME/gcc-6.2.0-build/./mpfr -I$HOME/gcc-6.2.0/mpfr
-I$HOME/gcc-6.2.0/mpc/src  -I../../gcc-6.2.0/gcc/../libdecnumber
-I../../gcc-6.2.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-6.2.0/gcc/../libbacktrace -I$HOME/gcc-6.2.0-build/./isl/include
-I$HOME/gcc-6.2.0/isl/include  -o gtype-desc.o -MT gtype-desc.o -MMD -MP -MF
./.deps/gtype-desc.TPo gtype-desc.c
$HOME/gcc-6.2.0-build/./prev-gcc/xg++ -B$HOME/gcc-6.2.0-build/./prev-gcc/
-B$HOME/gcc-6.2.0-bin/sparc-sun-solaris2.10/bin/ -nostdinc++
-B$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-B$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs

-I$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10
 -I$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/include 
-I$HOME/gcc-6.2.0/libstdc++-v3/libsupc++
-L$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-L$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I../../gcc-6.2.0/gcc -I../../gcc-6.2.0/gcc/.
-I../../gcc-6.2.0/gcc/../include -I./../intl
-I../../gcc-6.2.0/gcc/../libcpp/include -I$HOME/gcc-6.2.0-build/./gmp
-I$HOME/gcc-6.2.0/gmp -I$HOME/gcc-6.2.0-build/./mpfr -I$HOME/gcc-6.2.0/mpfr
-I$HOME/gcc-6.2.0/mpc/src  -I../../gcc-6.2.0/gcc/../libdecnumber
-I../../gcc-6.2.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-6.2.0/gcc/../libbacktrace -I$HOME/gcc-6.2.0-build/./isl/include
-I$HOME/gcc-6.2.0/isl/include  -o haifa-sched.o -MT haifa-sched.o -MMD -MP -MF
./.deps/haifa-sched.TPo ../../gcc-6.2.0/gcc/haifa-sched.c
In file included from ../../gcc-6.2.0/gcc/haifa-sched.c:141:0:
../../gcc-6.2.0/gcc/haifa-sched.c: In function 'int dep_cost_1(dep_t, dw_t)':
../../gcc-6.2.0/gcc/sched-int.h:252:31: internal compiler error: Arithmetische
Ausnahme
 #define DEP_COST(D) ((D)->cost)
   ^
../../gcc-6.2.0/gcc/haifa-sched.c:1438:12: note: in expansion of macro
'DEP_COST'
 return DEP_COST (link);
^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [Makefile:1085: haifa-sched.o] Error 1
make[3]: Leaving directory '$HOME/gcc-6.2.0-build/gcc'
make[2]: *** [Makefile:4433: all-stage2-gcc] Error 2
make[2]: Leaving directory '$HOME/gcc-6.2.0-build'
make[1]: *** [Makefile:22325: stage2-bubble] Error 2
make[1]: Leaving directory '$HOME/gcc-6.2.0-build'
make: *** [Makefile:917: all] Error 2