[Bug debug/69073] internal compiler error: in maybe_record_trace_start

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
Can this PR be a duplicate of PR67778? I don't have a compiler for rx-elf
target so cannot check it myself.

[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|WAITING |NEW
  Known to work||4.9.3
   Target Milestone|--- |5.4
  Known to fail||5.3.0, 6.0

--- Comment #49 from Dominique d'Humieres  ---
> Fairly trivial to fix once one finds
>
> F2003, p. 126.
>
> A variable in a specification expression shall have its type and
> type parameters, if any, specified by a previous declaration in
> the same scoping unit, by the implicit typing rules in effect for
> the scoping unit, or by host or use association.
>
> Note, the fix requires adjusting 2 testcases for new error
> conditions and fixing 1 testcase that actually has invalid
> code.

Thanks for the pointer. I am indeed aware that the original code and the
reduced versions posted in comments 41 and 47 are invalid and easy to fix.
Nevertheless gfortran used to give an error up to revision r229286 and is now
giving an ICE since revision r229287 for trunk (6.0) and r229553 for the 5
branch. The path to the original error should be restored.

[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka  ---
A variant of this seems to hit current Firefox:

 0:35.53
/aux/hubicka/firefox9/js/src/jit/x86-shared/AtomicOperations-x86-shared.h:361:104:
internal compiler error: unexpected expression �(void*)(& zero)� of kind
implicit_conv_expr
 0:35.53  while (!__atomic_compare_exchange(, , , false,
__ATOMIC_ACQUIRE, __ATOMIC_ACQUIRE)) {

[Bug tree-optimization/69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
This goes wrong in fre3, which does not consider that *e might alias d.

[Bug fortran/69090] Allocatable arrays mishandled in 'omp declare target'

[iverbin at gcc dot gnu.org]

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

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||iverbin at gcc dot gnu.org

--- Comment #4 from iverbin at gcc dot gnu.org ---
(In reply to Alexander Monakov from comment #0)
> Compiling and running the following testcase with non-shared-memory
> accelerator segfaults in the target region, because only pointed-to data of
> the allocatable array is copied, but not the array structure (.data, .offset
> fields) itself.  From my reading of the OpenMP spec, allocatable arrays are
> not explicitely allowed in the 'declare target' directive, so the code is
> ill-formed. However, no diagnostic is issued, and generally I don't know
> what GCC intends to do here.

Do you mean *global* allocatable arrays, or locals fail too?
We discussed it a bit here: https://gcc.gnu.org/ml/gcc/2015-03/msg00238.html
There is also a discussion in OpenMP ML about clarifying the spec; and as per
my understanding global allocatable arrays are not allowed by OpenMP 4.5, so it
would be nice to have a diagnostic instead of segfault.

[Bug fortran/69090] Allocatable arrays mishandled in 'omp declare target'

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
Ilya, 'omp declare target' is not applicable to arrays with automatic storage,
is it? The array needs to be either global, or have the SAVE attribute (similar
to 'static' keyword for local vars in C) — either way it would be statically
allocated (the array describing structure, not the variably allocatable data).
In fact, my example does use a local, SAVE'd array.

Thanks for the reference! I didn't recall that thread when filing this bug. Odd
that it "works" without the 'declare target'.

[Bug tree-optimization/69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
Summary|wrong code at -O1   |[6 Regression] wrong code
   |-fstrict-aliasing   |at -O1 -fstrict-aliasing

--- Comment #2 from Jakub Jelinek  ---
Started with r223883.

[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Perhaps something like this?
Index: constexpr.c
===
--- constexpr.c (revision 232023)
+++ constexpr.c (working copy)
@@ -3560,6 +3560,7 @@ cxx_eval_constant_expression (const cons
   break;

 case CONVERT_EXPR:
+case IMPLICIT_CONV_EXPR:
 case VIEW_CONVERT_EXPR:
 case NOP_EXPR:
 case UNARY_PLUS_EXPR:

[Bug debug/69073] internal compiler error: in maybe_record_trace_start

[ysato at users dot sourceforge.jp]

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

--- Comment #2 from Yoshinori Sato  ---
It looks different problem.
I tried x86_64 cross compile.
Using built-in specs.
COLLECT_GCC=rx-elf-gcc
COLLECT_LTO_WRAPPER=/home/ysato/rxelf/libexec/gcc/rx-elf/6.0.0/lto-wrapper
Target: rx-elf
Configured with: ../configure --target=rx-elf --prefix=/home/ysato/rxelf
--enable-languages=c --disable-libssp --disable-ssp --disable-mpc --disable-gmp
--disable-mpfr --disable-threads --disable-shared --disable-libmudflap
--disable-libgomp --disable-zlib --disable-libquadmath --without-libc
--disable-libatomic
Thread model: single
gcc version 6.0.0 20151222 (experimental) (GCC)

PR67778 example is not happened ICE.

[Bug fortran/67779] Strange ordering with strings in extended object

[tkoenig at gcc dot gnu.org]

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

--- Comment #23 from Thomas Koenig  ---
(In reply to Paul Thomas from comment #21)

> the right patch this time

Works well, looks obvious.

Pre-approved if you don't think it is, in fact, obvious :-)

[Bug target/55144] opening glibc-c.o: No such file or directory

[vapier at gcc dot gnu.org]

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

Mike Frysinger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Mike Frysinger  ---
previous commit should address this

[Bug target/47093] [meta-bug]: broken configurations

[vapier at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47093
Bug 47093 depends on bug 55144, which changed state.

Bug 55144 Summary: opening glibc-c.o: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55144

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug target/55144] opening glibc-c.o: No such file or directory

[vapier at gcc dot gnu.org]

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

Mike Frysinger  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/68810] [6 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|FAIL:   |[6 regression] FAIL:
   |g++.dg/cpp0x/constexpr-rein |g++.dg/cpp0x/constexpr-rein
   |terpret1.C  -- test for |terpret1.C  -- test for
   |errors -- -m32  |errors -- -m32

[Bug target/69118] New: Wrong condition in avx512f_maskcmp3

[hjl.tools at gmail dot com]

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

Bug ID: 69118
   Summary: Wrong condition in avx512f_maskcmp3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com
  Target Milestone: ---

(define_insn "avx512f_maskcmp3"
  [(set (match_operand: 0 "register_operand" "=Yk")
(match_operator: 3 "sse_comparison_operator"
  [(match_operand:VF 1 "register_operand" "v")
   (match_operand:VF 2 "nonimmediate_operand" "vm")]))]
  "TARGET_SSE"
  ^^^ Shouldn't it be TARGET_AVX512F?

  "vcmp%D3\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "type" "ssecmp")
   (set_attr "length_immediate" "1")
   (set_attr "prefix" "evex")
   (set_attr "mode" "")])

[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to kargl from comment #3)
> To use IEEE_SELECTED_REAL_KIND in an initialization expression
> with arbitrary integer kind type parameter requires a rewrite
> of simplify_ieee_selected_real_kind in simplify.c.  This isn't
> too terribly hard.
> 
> The fix for the use of IEEE_SELECTED_REAL_KIND as a generic
> intrinsic subprogram in a non-initialization expression appears
> to be much more difficult.  It probably means that 125 explicit
> interfaces need to be added to the IEEE_ARITHMETIC module.  I
> won't pursue this avenue.

I was looking at this yesterday.  It is implemented in ieee_arithmetic.F90 and
I think can be done with generic type bound procedures.  According to the
comment in the code, the ieee_arithmetic.F90 file is generated, but it is not
clear to me where the generation of the .F90 is specified.

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to vries from comment #4)
> Created attachment 37210 [details]
> minimal version, v2

needs -fno-tree-loop-im as well:
...
$ gcc doloop-2.c -O1 -ftree-parallelize-loops=2 -Wl,-rpath=$(pwd
-P)/install/lib64 -fno-tree-loop-im
...

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37207=edit
minimal version

[Bug c/69088] type conversion to int

[ka_bena at yahoo dot fr]

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

--- Comment #2 from BENAÏSSA  ---
/*
thank you for your answer.
 A.Benaïssa
Comment:
  Please consider this case: 
*/

#include  
int main()
{ 
  float A = 0.F  ;
  _Bool  B1  = 1.F / A ;
  signed char    B2  = 1.F / A ;
  unsigned char  B3  = 1.F / A ;
  signed short   B4  = 1.F / A ;
  unsigned short B5  = 1.F / A ;
  signed int B6  = 1.F / A ;
  unsigned int   B7  = 1.F / A ;
  signed long    B8  = 1.F / A ;
  unsigned long  B9  = 1.F / A ;
  signed long long   B10 = 1.F / A ;
  unsigned long long B11 = 1.F / A ;

  double C = 0.  ;
  _Bool  D1  = 1. / C ;
  signed char    D2  = 1. / C ;
  unsigned char  D3  = 1. / C ;
  signed short   D4  = 1. / C ;
  unsigned short D5  = 1. / C ;
  signed int D6  = 1. / C ;
  unsigned int   D7  = 1. / C ;
  signed long    D8  = 1. / C ;
  unsigned long  D9  = 1. / C ;
  signed long long   D10 = 1. / C ;
  unsigned long long D11 = 1. / C ;

  long double E = 0.L  ;
  _Bool  F1  = 1.L / E ;
  signed char    F2  = 1.L / E ;
  unsigned char  F3  = 1.L / E ;
  signed short   F4  = 1.L / E ;
  unsigned short F5  = 1.L / E ;
  signed int F6  = 1.L / E ;
  unsigned int   F7  = 1.L / E ;
  signed long    F8  = 1.L / E ;
  unsigned long  F9  = 1.L / E ;
  signed long long   F10 = 1.L / E ;
  unsigned long long F11 = 1.L / E ;

  __float128 G = 0.Q  ;
  _Bool  H1  = 1.Q / G ;
  signed char    H2  = 1.Q / G ;
  unsigned char  H3  = 1.Q / G ;
  signed short   H4  = 1.Q / G ;
  unsigned short H5  = 1.Q / G ;
  signed int H6  = 1.Q / G ;
  unsigned int   H7  = 1.Q / G ;
  signed long    H8  = 1.Q / G ;
  unsigned long  H9  = 1.Q / G ;
  signed long long   H10 = 1.Q / G ;
  unsigned long long H11 = 1.Q / G ;

  printf("_Bool\n") ;
  printf("  B1 = %d \n" , B1) ;
  printf("  D1 = %d \n" , D1) ;
  printf("  F1 = %d \n" , F1) ;
  printf("  H1 = %d \n" , H1) ;
  printf("char signed\n") ;
  printf("  B2 = %d \n" , (int)B2) ;
  printf("  D2 = %d \n" , (int)D2) ;
  printf("  F2 = %d \n" , (int)F2) ;
  printf("  H2 = %d \n" , (int)H2) ;
  printf("char unsigned\n") ;
  printf("  B3 = %u \n" , (int unsigned)B3) ;
  printf("  D3 = %u \n" , (int unsigned)D3) ;
  printf("  F3 = %u \n" , (int unsigned)F3) ;
  printf("  H3 = %u \n" , (int unsigned)H3) ;
  printf("short signed\n") ;
  printf("  B4 = %hd \n" , B4) ;
  printf("  D4 = %hd \n" , D4) ;
  printf("  F4 = %hd \n" , F4) ;
  printf("  H4 = %hd \n" , H4) ;
  printf("short unsigned\n") ;
  printf("  B5 = %hu \n" , B5) ;
  printf("  D5 = %hu \n" , D5) ;
  printf("  F5 = %hu \n" , F5) ;
  printf("  H5 = %hu \n" , H5) ;
  printf("int signed\n") ;
  printf("  B6 = %d \n" , B6) ;
  printf("  D6 = %d \n" , D6) ;
  printf("  F6 = %d \n" , F6) ;
  printf("  H6 = %d \n" , H6) ;
  printf("int unsigned\n") ;
  printf("  B7 = %u \n" , B7) ;
  printf("  D7 = %u \n" , D7) ;
  printf("  F7 = %u \n" , F7) ;
  printf("  H7 = %u \n" , H7) ;
  printf("long\n") ;
  printf("  B8 = %d \n" , B8) ;
  printf("  D8 = %d \n" , D8) ;
  printf("  F8 = %d \n" , F8) ;
  printf("  H8 = %d \n" , H8) ;
  printf("long unsigned \n") ;
  printf("  B9 = %lu \n" , B9) ;
  printf("  D9 = %lu \n" , D9) ;
  printf("  F9 = %lu \n" , F9) ;
  printf("  H9 = %lu \n" , H9) ;
  printf("long long \n") ;
  printf("  B10 = %lld \n" , B10) ;
  printf("  D10 = %lld \n" , D10) ;
  printf("  F10 = %lld \n" , F10) ;
  printf("  H10 = %lld \n" , H10) ;
  printf("long long unsigned\n") ;
  printf("  B11 = %llu \n" , B11) ;
  printf("  D11 = %llu \n" , D11) ;
  printf("  F11 = %llu \n" , F11) ;
  printf("  H11 = %llu \n" , H11) ;

return 0;
}
/*
RESULTS::

_Bool
  B1 = 1 
  D1 = 1 
  F1 = 1 
  H1 = 1 
char signed
  B2 = 0 
  D2 = 0 
  F2 = 0 
  H2 = -1 
char unsigned
  B3 = 0 
  D3 = 0 
  F3 = 0 
  H3 = 0 
short signed
  B4 = -32768 
  D4 = -32768 
  F4 = -32768 
  H4 = -1 
short unsigned
  B5 = 0 
  D5 = 0 
  F5 = 0 
  H5 = 0 
int signed
  B6 = -2147483648 
  D6 = -2147483648 
  F6 = -2147483648 
  H6 = 2147483647 
int unsigned
  B7 = 0 
  D7 = 0 
  F7 = 0 
  H7 = 0 
long
  B8 = -2147483648 
  D8 = -2147483648 
  F8 = -2147483648 
  H8 = 2147483647 
long unsigned 
  B9 = 0 
  D9 = 0 
  F9 = 0 
  H9 = 0 
long long 
  B10 = -9223372036854775808 
  D10 = -9223372036854775808 
  F10 = -9223372036854775808 
  H10 = 9223372036854775807 
long long unsigned
  B11 = 0 
  D11 = 0 
  F11 = 0 
  H11 = 0 

it is clear that there is no real infinite value for any floating 
point representation but instead there is a symbolic representation
of infinites values by a finite sequence of bits.
This finite sequence of bits allows us to create a simple algebra 
on infinite's.
The type conversion from valid floating values to integer values is 
always possible in C.
This not means that for "infinites floating point values" , the result
of type 

[Bug fortran/69064] [5/6 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #50 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #49)
> > Fairly trivial to fix once one finds
> >
> > F2003, p. 126.
> >
> > A variable in a specification expression shall have its type and
> > type parameters, if any, specified by a previous declaration in
> > the same scoping unit, by the implicit typing rules in effect for
> > the scoping unit, or by host or use association.
> >
> > Note, the fix requires adjusting 2 testcases for new error
> > conditions and fixing 1 testcase that actually has invalid
> > code.
> 
> Thanks for the pointer. I am indeed aware that the original code and the
> reduced versions posted in comments 41 and 47 are invalid and easy to fix.

That's not what I was writing about.  Once one understands F2003
and fixes gfortran, then the Note below applies.  That is, you need
to fix
M   testsuite/gfortran.dg/array_constructor_26.f03
M   testsuite/gfortran.dg/array_constructor_27.f03
M   testsuite/gfortran.dg/bounds_check_strlen_2.f90

> Nevertheless gfortran used to give an error up to revision r229286 and is
> now giving an ICE since revision r229287 for trunk (6.0) and r229553 for the
> 5 branch. The path to the original error should be restored.

That isn't the fix that is needed as the original path can't be restored.

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #37208|0   |1
is obsolete||

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 37211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37211=edit
doloop-2.c.141t.ivcanon, v2

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #37207|0   |1
is obsolete||

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 37210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37210=edit
minimal version, v2

[Bug target/68917] test suite failure for builtin-bitops-1.c

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Bernd Edlinger  ---
fixed.

[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Francois-Xavier Coudert from comment #5)
> (In reply to Jerry DeLisle from comment #4)
> > I was looking at this yesterday.  It is implemented in ieee_arithmetic.F90
> > and I think can be done with generic type bound procedures.
> 
> There's also a simplifier for the compile-time version.

See comment 3.  The simplifier is fairly easy to rewrite;
although it does take some time to work out the semantics
of keyword usage.

> > According to
> > the comment in the code, the ieee_arithmetic.F90 file is generated, but it
> > is not clear to me where the generation of the .F90 is specified.
> 
> It is not automatically generated.

I believe that one should force type conversion in 
external_spec_function.  All valid values fit in
a REAL(4).  The only problem might be integer
wrap-around semantics.

[Bug lto/69119] New: More fun with LTO on arm

[tulipawn at gmail dot com]

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

Bug ID: 69119
   Summary: More fun with LTO on arm
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

I've found a couple of `-flto -ffat-lto-objects` problems that happen on armv7
but not on x86 using the same gcc version. Not using -flto on arm makes the
issues go away.

**1**. https://github.com/jemalloc/jemalloc/issues/313

All tests pass on x86 with lto enabled. Should I open a new gcc issue?



**2**. Trying to link the rust compiler's stdlib with -flto and -fPIC among
CFLAGS ends like this:

rustc:
arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libstd

In function ‘memset’,
inlined from ‘je_malloc’ at
/tmp/rustc-nightly/src/jemalloc/include/jemalloc/internal/tcache.h:345:6:
/usr/include/arm-linux-gnueabihf/bits/string3.h:81:7: warning: call to
‘__warn_memset_zero_len’ declared with attribute warning: memset used with
constant zero length parameter; this could be due to transposed parameters
   __warn_memset_zero_len ();
   ^
/usr/bin/ld.bfd.real: error: /tmp/cczYIjMC.ltrans0.ltrans.o: requires
unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC

error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-L"
"/tmp/rustc-nightly/arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib"
"arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/std-ca1c970e.0.o"
"-o"
"arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libstd-ca1c970e.so"
"arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/std-ca1c970e.metadata.o"
"-Wl,-O1" "-nodefaultlibs" "-L" "arm-unknown-linux-gnueabihf/rt" "-L"
"/usr/lib/llvm-3.6/lib" "-L"
"/tmp/rustc-nightly/arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib"
"-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "backtrace" "-Wl,--no-whole-archive"
"-Wl,-Bdynamic" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/libcollections-ca1c970e.rlib" "-Wl,--no-whole-archive"
"-Wl,--whole-archive" "/tmp/rustc.K1iwqkGsmEEU/liballoc-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/librustc_unicode-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/liballoc_jemalloc-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/liblibc-ca1c970e.rlib" "-Wl,--no-whole-archive"
"-Wl,--whole-archive" "/tmp/rustc.K1iwqkGsmEEU/librand-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/libcore-ca1c970e.rlib" "-Wl,--no-whole-archive" "-l"
"pthread" "-l" "c" "-l" "m" "-l" "rt" "-shared" "-l" "compiler-rt"


Again, the same lto build succeeds on x86 whereas a non-lto one finishes on
arm.

[Bug lto/69119] More fun with LTO on arm

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 Target||armv7
   Host||armv7
   Severity|normal  |major

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 37209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37209=edit
doloop-2.c.142t.parloops

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 37208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37208=edit
doloop-2.c.141t.ivcanon

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
With -floop-parallelize-all --param graphite-min-loops-per-function=1 we have
in graphite:
...
Creating dr for i
analyze_innermost: success.
base_address: 
offset from base address: 0
constant offset from base address: 0
step: 0
aligned to: 128
base_object: i
[scop-detection-fail] Graphite cannot handle data-refs in stmt:
# VUSE <.MEM_11>
i.1_4 = i;
...

and in parloops:
...
loop is not parallel according to graphite
...

[Bug tree-optimization/69110] [Regression 4.9/5/6] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|execution failure in|[Regression 4.9/5/6]
   |gcc.c-torture/execute/doloo |execution failure in
   |p-2.c with  |gcc.c-torture/execute/doloo
   |-ftree-parallelize-loops=2  |p-2.c with
   ||-ftree-parallelize-loops=2

--- Comment #10 from vries at gcc dot gnu.org ---
Hmm, self-dependence code was added in PR36228 and removed in PR49960. 

Test passes with ubuntu gcc 4.6 and fails with ubuntu gcc 4.8.

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #37209|0   |1
is obsolete||

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 37212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37212=edit
doloop-2.c.142t.parloops, v2

[Bug fortran/69121] New: IEEE_SCALB is not generic

[kargl at gcc dot gnu.org]

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

Bug ID: 69121
   Summary: IEEE_SCALB is not generic
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

% cat cc.f90
program foo
   use ieee_arithmetic
   implicit none
   real x
   integer(2) n
   x = 2.
   n = 2
   print *, ieee_scalb(x,n)
end program foo

% gfc -fdump-tree-original cc.f90
cc.f90:8:11:

print *, ieee_scalb(x,n)
   1

Error: There is no specific function for the generic 'ieee_scalb' at (1)

[Bug tree-optimization/69110] [Regression 4.9/5/6] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic

[fxcoudert at gcc dot gnu.org]

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

--- Comment #5 from Francois-Xavier Coudert  ---
(In reply to Jerry DeLisle from comment #4)
> I was looking at this yesterday.  It is implemented in ieee_arithmetic.F90
> and I think can be done with generic type bound procedures.

There's also a simplifier for the compile-time version.

> According to
> the comment in the code, the ieee_arithmetic.F90 file is generated, but it
> is not clear to me where the generation of the .F90 is specified.

It is not automatically generated.

[Bug c++/69098] Member function pointer template flagged with 'is not a function template'

[hir...@trash-mail.com]

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

--- Comment #1 from hir...@trash-mail.com ---
The error message I got, copied from Wandbox:

prog.cc: In instantiation of 'static void
Specializer::InnerClassTempl< >::InnerMemberFn() [with unsigned int
 = 0u]':
prog.cc:16:24:   required from here
prog.cc:33:36: error: 'template constexpr void (Specializer::* const
SpecPerType::SpecMbrFnPtr)()< >' is not a function
template
  typename Spec::FnType ErrorSite = Spec::template SpecMbrFnPtr;
^~~~

prog.cc:33:36: error: 'SpecMbrFnPtr' is not a member of 'Spec {aka
SpecPerType}'

[Bug target/68191] s390x Linux Split Stacks support

[koriakin at 0x04 dot net]

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

Marcin Kościelnicki  changed:

   What|Removed |Added

 CC||koriakin at 0x04 dot net

--- Comment #2 from Marcin Kościelnicki  ---
I have submitted patches for this issue:

- gcc: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00034.html
- gold: https://sourceware.org/ml/binutils/2016-01/msg2.html
- gold (older thread, I forgot --in-reply-to):
https://sourceware.org/ml/binutils/2015-12/msg00141.html
- glibc: https://sourceware.org/ml/libc-alpha/2016-01/msg8.html

[Bug tree-optimization/69110] execution failure in gcc.c-torture/execute/doloop-2.c with -ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #8 from vries at gcc dot gnu.org ---
loop before parloops, at ivcanon:
...
  # z_10 = PHI 
  # .MEM_11 = PHI <.MEM_6(4), .MEM_3(D)(2)>
  # ivtmp_12 = PHI 

  # VUSE <.MEM_11>
  i.1_4 = iD.1855;

  _5 = i.1_4 + 1;

  # .MEM_6 = VDEF <.MEM_11>
  iD.1855 = _5;

  z_7 = z_10 + 1;

  ivtmp_2 = ivtmp_12 - 1;

  if (ivtmp_2 != 0)
goto ;
  else
goto ;
...

The loop cannot be parallelized because the store to iD.1855 in every loop
iteration aliases with the load from and store to iD.1855 in every other loop
iteration.

However, parloops concludes that parallelization is possible:
...
;; Function foo (foo, funcdef_no=0, decl_uid=1857, cgraph_uid=0,
symbol_order=1) (executed once)


Pass statistics of "parloops": 

Trying loop 1 as candidate
loop 1 is innermost
Analyzing # of iterations of loop 1
  exit condition [999, + , 4294967295] != 0
  bounds on difference of bases: -999 ... -999
  result:
# of iterations 999, bounded by 999
Analyzing # of iterations of loop 1
  exit condition [999, + , 4294967295] != 0
  bounds on difference of bases: -999 ... -999
  result:
# of iterations 999, bounded by 999
doloop-2.c:6:1: note: === vect_analyze_loop_form ===
doloop-2.c:6:1: note: === get_loop_niters ===
Considering loop 1
loop is innermost
Creating dr for i
analyze_innermost: success.
base_address: 
offset from base address: 0
constant offset from base address: 0
step: 0
aligned to: 128
base_object: i
Creating dr for i
analyze_innermost: success.
base_address: 
offset from base address: 0
constant offset from base address: 0
step: 0
aligned to: 128
base_object: i
(compute_affine_dependence
  stmt_a: i.1_4 = i;
  stmt_b: i = _5;
)
(compute_affine_dependence
  stmt_a: i.1_4 = i;
  stmt_b: i.1_4 = i;
)
(compute_affine_dependence
  stmt_a: i = _5;
  stmt_b: i = _5;
)
Dependence tester statistics:
Number of dependence tests: 3
Number of dependence tests classified dependent: 3
Number of dependence tests classified independent: 0
Number of undetermined dependence tests: 0
Number of subscript tests: 0
Number of undetermined subscript tests: 0
Number of same subscript function: 0
Number of ziv tests: 0
Number of ziv tests returning dependent: 0
Number of ziv tests returning independent: 0
Number of ziv tests unimplemented: 0
Number of siv tests: 0
Number of siv tests returning dependent: 0
Number of siv tests returning independent: 0
Number of siv tests unimplemented: 0
Number of miv tests: 0
Number of miv tests returning dependent: 0
Number of miv tests returning independent: 0
Number of miv tests unimplemented: 0
(Data Dep: 
#(Data Ref: 
#  bb: 3 
#  stmt: i.1_4 = i;
#  ref: i
#  base_object: i;
#)
#(Data Ref: 
#  bb: 3 
#  stmt: i = _5;
#  ref: i
#  base_object: i;
#)
  inner loop index: 0
  loop nest: (1 )
  distance_vector:   0 
  direction_vector: =
)
(Data Dep: 
#(Data Ref: 
#  bb: 3 
#  stmt: i.1_4 = i;
#  ref: i
#  base_object: i;
#)
#(Data Ref: 
#  bb: 3 
#  stmt: i.1_4 = i;
#  ref: i
#  base_object: i;
#)
  inner loop index: 0
  loop nest: (1 )
  distance_vector:   0 
  direction_vector: =
)
(Data Dep: 
#(Data Ref: 
#  bb: 3 
#  stmt: i = _5;
#  ref: i
#  base_object: i;
#)
#(Data Ref: 
#  bb: 3 
#  stmt: i = _5;
#  ref: i
#  base_object: i;
#)
  inner loop index: 0
  loop nest: (1 )
  distance_vector:   0 
  direction_vector: =
)
  SUCCESS: may be parallelized
...

[Bug target/69120] New: sse2_shufpd_v2df_mask has wrong name

[hjl.tools at gmail dot com]

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

Bug ID: 69120
   Summary: sse2_shufpd_v2df_mask has wrong name
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com
  Target Milestone: ---

(define_insn "sse2_shufpd_v2df_mask"
  ^ Shouldn't it be avx512vl?
  [(set (match_operand:V2DF 0 "register_operand" "=v")
(vec_merge:V2DF
  (vec_select:V2DF
(vec_concat:V4DF
  (match_operand:V2DF 1 "register_operand" "v")
  (match_operand:V2DF 2 "nonimmediate_operand" "vm"))
(parallel [(match_operand 3 "const_0_to_1_operand")
   (match_operand 4 "const_2_to_3_operand")]))
  (match_operand:V2DF 5 "vector_move_operand" "0C")
  (match_operand:QI 6 "register_operand" "Yk")))]
  "TARGET_AVX512VL"
{
  int mask; 
  mask = INTVAL (operands[3]);
  mask |= (INTVAL (operands[4]) - 2) << 1;
  operands[3] = GEN_INT (mask);

  return "vshufpd\t{%3, %2, %1, %0%{%6%}%N5|%0%{6%}%N5, %1, %2, %3}";
}

[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---

> I believe that one should force type conversion in 
> external_spec_function.  All valid values fit in
> a REAL(4).  The only problem might be integer
> wrap-around semantics.

Bummer that doesn't work. :(

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
141d7d6e93a44d509f0be246231b46939e728c97 is the first bad commit
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231674
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug fortran/69101] IEEE_SELECTED_REAL_KIND is not generic

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> > I believe that one should force type conversion in 
> > external_spec_function.  All valid values fit in
> > a REAL(4).  The only problem might be integer
> > wrap-around semantics.
> 
> Bummer that doesn't work. :(

Big bummer.  It is not possible to brute force a fix by
adding ~1700 lines to ieee/ieee_arithmetic.c.

[Bug fortran/69121] IEEE_SCALB is not generic

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
This is easy to fix by adding the appropriate code to
libgfortran/ieee/ieee_arithmetic.F90.

% svn diff ieee_arithmetic.F90 | wc -l
  225

[Bug testsuite/68886] [6 regression] FAIL: gcc.c-torture/execute/stkalign.c execution test

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|hppa-unknown-linux-gnu  |hppa-*-*, powerpc*-*-*
 CC||jbeulich at novell dot com
   Host|hppa-unknown-linux-gnu  |
Summary|FAIL:   |[6 regression] FAIL:
   |gcc.c-torture/execute/stkal |gcc.c-torture/execute/stkal
   |ign.c execution test|ign.c execution test
  Build|hppa-unknown-linux-gnu  |

--- Comment #1 from Andreas Schwab  ---
Also fails on powerpc.  I don't see how this test does anything useful.  It
will always fail if the compiler happens to allocate locals on a 64 or more
byte boundary.

[Bug c++/69065] [C++11] multiple alignas specifiers

[kukyakya at gmail dot com]

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

kukyakya at gmail dot com changed:

   What|Removed |Added

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

--- Comment #1 from kukyakya at gmail dot com ---
'alignas' specifier is not meant to be used in type declaration.
(http://stackoverflow.com/a/34006668/1030861)

Was not a bug.

Works as expected if used properly.
---
#include 

struct test1 {
alignas(int) alignas(double) char _; 
};

struct test2 {
alignas(double) alignas(int) char _; 
};

int main()
{
  std::cout << "alignof(int) is " << alignof(int) << std::endl;
  std::cout << "alignof(double) is " << alignof(double) << std::endl;
  std::cout << "alignof(test1) is " << alignof(test1) << std::endl;
  std::cout << "alignof(test2) is " << alignof(test2) << std::endl;
}
---
alignof(int) is 4
alignof(double) is 8
alignof(test1) is 8
alignof(test2) is 8
---

[Bug c++/69065] [C++11] multiple alignas specifiers

[kukyakya at gmail dot com]

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

kukyakya at gmail dot com changed:

   What|Removed |Added

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

--- Comment #2 from kukyakya at gmail dot com ---
Reopening the bug. It still does not accept 'alignas(pack...)' form.

---
#include 

struct test {
alignas(int, double) char _;
};

int main()
{
  std::cout << "alignof(int) is " << alignof(int) << std::endl;
  std::cout << "alignof(double) is " << alignof(double) << std::endl;
  std::cout << "alignof(test) is " << alignof(test) << std::endl;
}
---
$ g++ -Wall -Wextra -std=c++14 -pedantic -O2 a.cpp
a.cpp:4:13: error: expected ‘)’ before ‘,’ token
  alignas(int, double) char _;
 ^
a.cpp:4:13: error: expected ‘)’ before ‘,’ token
a.cpp:4:13: error: expected unqualified-id before ‘,’ token
---