[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||m.ostapenko at samsung dot com

--- Comment #1 from Maxim Ostapenko  ---
Eh, mine.

typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange, it
seems that it's an Objective-C declaration, right?

Could you check:

1) Libc version on your system.
2) Contents of /usr/include/os/trace.h. Is that a valid C header?

[Bug bootstrap/77676] powerpc64 and powerpc64le stage2 bootstrap fail

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
Patch to re-enable -fprintf-return-value:
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00785.html

[Bug middle-end/78149] missing warning on strncpy buffer overflow due to an excessive bound

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02308.html

[Bug sanitizer/78267] New: [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977

[dominiq at lps dot ens.fr]

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

Bug ID: 78267
   Summary: [7 Regression] libsanitizer breaks bootstrap on
x86_64-apple-darwin16 at r241977
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: chefmax at gcc dot gnu.org, dodji at gcc dot gnu.org,
dvyukov at gcc dot gnu.org, howarth.at.gcc at gmail dot com,
iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin16
Target: x86_64-apple-darwin16
 Build: x86_64-apple-darwin16

Bootstrap on x86_64-apple-darwin16 is broken at r241977 when building
libsanitizer:

libtool: compile:  /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/bin/
-B/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/lib/ -isystem
/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/include -isystem
/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../work/libsanitizer/sanitizer_common -I.. -I
../../../../work/libsanitizer/include -isystem
../../../../work/libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin16.1.0
-I../../../../work/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2
-MT sanitizer_mac.lo -MD -MP -MF .deps/sanitizer_mac.Tpo -c
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc  -fno-common
-DPIC -o .libs/sanitizer_mac.o
In file included from
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:39:0:
/usr/include/os/trace.h:204:15: error: expected unqualified-id before '^' token
 typedef void (^os_trace_payload_t)(xpc_object_t xdict);
   ^
/usr/include/os/trace.h:204:15: error: expected ')' before '^' token
In file included from /usr/include/Availability.h:180:0,
 from /usr/include/stdio.h:65,
 from
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:21:
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
 ^
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
 ^
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
 ^
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
 ^
/usr/include/os/trace.h:328:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.10), ios(8.0), watchos(2.0), tvos(8.0))
 ^
/usr/include/os/trace.h:328:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.10), ios(8.0), watchos(2.0), tvos(8.0))
 ^
/usr/include/os/trace.h:328:1: error: 'introduced' was not declared in this
scope
 __API_AVAILABLE(macosx(10.10), ios(8.0), watchos(2.0), tvos(8.0))
 ^
+ hundreds of similar errors.

[Bug tree-optimization/78121] [7 Regression] ice in set_value_range

[kugan at gcc dot gnu.org]

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

--- Comment #7 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Wed Nov  9 01:41:26 2016
New Revision: 241989

URL: https://gcc.gnu.org/viewcvs?rev=241989=gcc=rev
Log:
Fix ice in set_value_range
gcc/ChangeLog:

2016-11-09  Kugan Vivekanandarajah  

PR ipa/78121
* ipa-cp.c (propagate_vr_accross_jump_function): Pass param type.
Also fold constant passed as argument while computing value range.
(propagate_constants_accross_call): Pass param type.
* ipa-prop.c: export ipa_get_callee_param_type.
* ipa-prop.h: export ipa_get_callee_param_type.

gcc/testsuite/ChangeLog:

2016-11-09  Kugan Vivekanandarajah  

PR ipa/78121
* gcc.dg/ipa/pr78121.c: New test.



Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr78121.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Also 17.6.5.4 [global.functions] p4.

[Bug middle-end/78245] missing -Wformat-length on an overflow of a dynamically allocated buffer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00779.html

[Bug fortran/78260] ICE in gimplify_expr, at gimplify.c:11939

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-08
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed for revisions supporting -fopenacc.

[Bug fortran/78259] [7 Regression] ICE in gfc_trans_subcomponent_assign, at fortran/trans-expr.c:7330

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-08
 CC||foreese at gcc dot gnu.org
Summary|ICE in  |[7 Regression] ICE in
   |gfc_trans_subcomponent_assi |gfc_trans_subcomponent_assi
   |gn, at  |gn, at
   |fortran/trans-expr.c:7330   |fortran/trans-expr.c:7330
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE appeared between revisions r241509 (2016-10-25, compiles) and r241635
(2016-10-27, ICE), likely r241626.

[Bug fortran/78258] ICE in compare_values_warnv, at tree-vrp.c:1218

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-08
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed for recent gcc-7 configured with --enable-checking=yes. As for
pr78238 I don't see any ICE with r240271.

[Bug fortran/69861] [OOP] ICE on declaring class parameter array

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #3 from janus at gcc dot gnu.org ---
With r241979, both comment 0 and comment 1 are rejected correctly and the ICE
is gone.

[Bug middle-end/78266] New: broken openacc loop partitioning on nvptx offloading targets

[cesar at gcc dot gnu.org]

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

Bug ID: 78266
   Summary: broken openacc loop partitioning on nvptx offloading
targets
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux-gnu, nvptx-none

Created attachment 3
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3=edit
vprop.c

The attached test case demonstrates a situation where an acc 'gang worker'
partitioned loop encloses an acc vector partitioned loop fails to generate
correct code. I'm not sure if there is a problem in the nvptx backend
worker-state propagator, or if oaccdevlow is generating bad code.

This test case works fine if the outer loop is either gang or worker
partitioned, but not both.

[Bug c++/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
From the GCC User's Manual (https://gcc.gnu.org/onlinedocs/gcc.pdf):

By default, GCC also provides some additional extensions to the C++ language
that on rare occasions conflict with the C++ standard. See Section 3.5 [C++
Dialect Options], page 40. Use of the ‘-std’ options listed above disables
these extensions where they they conflict with the C++ standard version
selected. You may also select an extended version of the C++ language
explicitly with ‘-std=gnu++98’ (for C++98 with GNU extensions), or
‘-std=gnu++11’ (for C++11 with GNU extensions), or ‘-std=gnu++14’ (for C++14
with GNU extensions), or ‘-std=gnu++1z’ (for C++1z with GNU extensions).

[Bug fortran/68440] [OOP] ICE on declaring class variable with wrong attribute

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #7 from janus at gcc dot gnu.org ---
Fixed with r241979. Closing.

[Bug c++/78263] Compile failure with AltiVec library on PPC64le and -std=c++11 flag

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
You simply need to use -std=gnu++11 instead of -std=c++11.

[Bug debug/78265] New: Excess emission of debug info for ODR used global variables

[dblaikie at gmail dot com]

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

Bug ID: 78265
   Summary: Excess emission of debug info for ODR used global
variables
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dblaikie at gmail dot com
  Target Milestone: ---

ODR used global (& static class member) variables that are ODR used but never
actually referenced by live code still produce debug info. eg:

extern int i;
inline int f() {
  return i;
}

Even though f is never called, 'i' still gets a debug info description.

If that's insufficiently compelling, consider this case (this turns up in
something like protobuf code repeatedly, as does the above example (look at how
protobufs emit default instances for the above example, the below example comes
up in some similar code I don't think I have a good public example of))

template 
struct foo {
  static const int i = -1;
  int f() { return i; /* replace this with "return -1;" */ }
};
template
const int foo::i;

struct bar {
  foo f;
  int b() {
return f.f();
  }
};

If you make the suggested substitution, no debug info is produced for this code
at all. As-is, it produces 110 byte CU (this is, of course, actually unbounded
& worse than 110 bytes in the real world case - because once you pull in the
variable, you pull in its type and then any types they need, etc).

[Bug c++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/78264] New: [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[ro at gcc dot gnu.org]

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

Bug ID: 78264
   Summary: [7 regression] ICE in build_noexcept_spec, at
cp/except.c:1196
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.12, sparc-sun-solaris2.12
Target: [7 regression] ICE in build_noexcept_spec, at
cp/except.c:1196
 Build: [7 regression] ICE in build_noexcept_spec, at
cp/except.c:1196

Between 20161107 (r241917) and 2008 (r241972), many C++ testcases started
to FAIL with
an ICE:

+FAIL: g++.dg/concepts/expression.C   (internal compiler error)
+FAIL: g++.dg/concepts/expression.C   (test for excess errors)
+WARNING: g++.dg/concepts/expression.C   compilation failed to produce
executabl
e

Excess errors:
/vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/new:200:45: error: expected
'>' before numeric constant
/vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/new:201:37: internal
compiler error: in build_noexcept_spec, at cp/except.c:1196
0x5ee127 build_noexcept_spec(tree_node*, int)
/vol/gcc/src/hg/trunk/local/gcc/cp/except.c:1196
0x5a4863 cp_parser_noexcept_specification_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:23479
0x5a90bf cp_parser_exception_specification_opt
0x5a90bf cp_parser_exception_specification_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:23507
0x595d57 cp_parser_direct_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19358
0x595d57 cp_parser_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19204
0x5a6e23 cp_parser_parameter_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:20891
0x5a7727 cp_parser_parameter_declaration_list
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:20646
0x5a7c6f cp_parser_parameter_declaration_clause
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:20567
0x59630b cp_parser_direct_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19326
0x59630b cp_parser_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:19204
0x5ad763 cp_parser_init_declarator
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:18738
0x5afc8b cp_parser_single_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:26324
0x5afe97 cp_parser_template_declaration_after_parameters
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:25928
0x5b09ab cp_parser_explicit_template_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:26164
0x5b09ab cp_parser_template_declaration_after_export
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:26182
0x5b1133 cp_parser_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12370
0x5b14ab cp_parser_declaration_seq_opt
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12297
0x5b1d1b cp_parser_namespace_body
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:17971
0x5b1d1b cp_parser_namespace_definition
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:17947
0x5b0faf cp_parser_declaration
/vol/gcc/src/hg/trunk/local/gcc/cp/parser.c:12401

+FAIL: g++.dg/cpp1z/eval-order2.C   (internal compiler error)
+FAIL: g++.dg/cpp1z/eval-order2.C   (test for excess errors)
+WARNING: g++.dg/cpp1z/eval-order2.C   compilation failed to produce executable

+FAIL: g++.dg/cpp1z/init-statement6.C   (internal compiler error)
+FAIL: g++.dg/cpp1z/init-statement6.C   (test for excess errors)
+WARNING: g++.dg/cpp1z/noexcept-type9.C   compilation failed to produce
executab
le

+FAIL: 19_diagnostics/error_code/is_error_code_v.cc (test for excess errors)
+FAIL: 21_strings/basic_string/cons/char/7.cc (test for excess errors)
+WARNING: 21_strings/basic_string/cons/char/7.cc compilation failed to produce
e
xecutable

  and many more in libstdc++

  32 and 64-bit, sparc and x86

  Rainer

[Bug fortran/68440] [OOP] ICE on declaring class variable with wrong attribute

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Nov  8 22:07:21 2016
New Revision: 241979

URL: https://gcc.gnu.org/viewcvs?rev=241979=gcc=rev
Log:
2016-11-08  Janus Weil  

PR fortran/68440
* expr.c (check_alloc_comp_init): Loosen an assert.
* resolve.c (resolve_fl_parameter): Reject class parameters.

2016-11-08  Janus Weil  

PR fortran/68440
* gfortran.dg/class_58.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/class_58.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu

[chefmax at gcc dot gnu.org]

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

--- Comment #15 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Tue Nov  8 22:06:02 2016
New Revision: 241978

URL: https://gcc.gnu.org/viewcvs?rev=241978=gcc=rev
Log:
PR sanitizer/63958
Reapply:
2014-10-14  David S. Miller  

* sanitizer_common/sanitizer_platform_limits_linux.cc (time_t):
Define at __kernel_time_t, as needed for sparc.
(struct __old_kernel_stat): Don't check if __sparc__ is defined.
* libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
(__sanitizer): Define struct___old_kernel_stat_sz,
struct_kernel_stat_sz, and struct_kernel_stat64_sz for sparc.
(__sanitizer_ipc_perm): Adjust for sparc targets.
(__sanitizer_shmid_ds): Likewsie.
(__sanitizer_sigaction): Likewise.
(IOC_SIZE): Likewsie.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h

[Bug c++/78263] New: Compile failure with AltiVec library on PPC64le and -std=c++11 flag

[khill at us dot ibm.com]

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

Bug ID: 78263
   Summary: Compile failure with AltiVec library on PPC64le and
-std=c++11 flag
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: khill at us dot ibm.com
  Target Milestone: ---

Created attachment 39998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39998=edit
Preprocessed source source for main.cpp

GCC is unable to compile C++ code which includes the AltiVec library with
-std=c++11 flag on PPC64le target.

The following code snippet will reproduce the error: 

#include 

int main(int argc, char *argv[])
{
  bool test = false;
  return 0;
}

GCC and AltiVec both define __bool causing the code to become invalid.

One solution found is to undef the following:

#undef vector 
#undef pixel 
#undef bool 

This solution is not always straightforward for larger code bases and requires
users of our tools to edit the source files of any project/example that
includes the AltiVec library (e.g CL/opencl.h).

Test Case on Ubuntu 16.04 w/ kernel 4.4.0-45-generic:

gcc -v -save-temps -std=c++11 -c main.cpp
Using built-in specs.
COLLECT_GCC=gcc
Target: powerpc64le-linux-gnu

...

Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.2) 

...

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-c' '-mcpu=power8'
 /usr/lib/gcc/powerpc64le-linux-gnu/5/cc1plus -fpreprocessed main.ii
-msecure-plt -quiet -dumpbase main.cpp -mcpu=power8 -auxbase main -std=c++11
-version -fstack-protector-strong -Wformat -Wformat-security -o main.s
GNU C++11 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609
(powerpc64le-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.2) version 5.4.0 20160609
(powerpc64le-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler executable checksum: 840114473bcf0205e182c11cebcb2c2e
main.cpp: In function ‘int main(int, char**)’:
main.cpp:5:52: error: cannot convert ‘bool’ to ‘__vector(4) __bool int’ in
initialization

[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[helloqirun at gmail dot com]

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

Qirun Zhang  changed:

   What|Removed |Added

 CC||helloqirun at gmail dot com

--- Comment #5 from Qirun Zhang  ---
My r241966 build also miscompiles.

[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[fdumont at gcc dot gnu.org]

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

--- Comment #8 from François Dumont  ---
Ok, at least it confirms what I thought about builtins. So the problem is
rather a buggy target.

Even if so I'll try to find an alternative approach to avoid snprintf usage.

[Bug fortran/50069] FORALL fails on a character array

[louis.krupp at zoho dot com]

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

--- Comment #11 from louis.krupp at zoho dot com ---
You're right.  I wasn't paying attention to the third ("function reverse ...")
in the bug report.

I believe that's fixed with the attached patch to trans-expr.c along with my
other patch.  I no longer see the ICE, and "make check-fortran" turns up no
surprises.

I haven't tried this second patch (to trans-expr.c) by itself.

The force-forall-temp flag in the first patch isn't intended to fix anything; 
its sole purpose is to get code with obscure bugs to fail sooner, in testing,
instead of later when forall really needs to create and use a temporary under
circumstances that no one had anticipated.

Louis


  On Tue, 08 Nov 2016 07:03:59 -0800 dominiq at lps dot ens.fr
 wrote  
 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 
 >  
 > --- Comment #10 from Dominique d'Humieres  --- 
 > > The attached patch adds a slight variation of Tobias Burnus's patch 
 > > for 50069 to my patch for 55086, and it seems to fix the two tests in
50069. 
 >  
 > I have applied the patch without the last hunk. It fixes the first test by 
 > supplying the needed temporary. However compiling the test (variant of the
test 
 > in comment 6) 
 >  
 > function  reverse(string) ! bind(c, name='reverse') 
 > implicit none 
 > character(len=*), intent(in) :: string 
 > character(len=:),allocatable :: reverse 
 > integer :: i 
 > reverse = string 
 > forall (i=1:len(reverse)) reverse(i:i) = 
 > reverse(len(reverse)-i+1:len(reverse)-i+1) 
 > end function reverse 
 >  
 > still gives an ICE 
 >  
 >  forall (i=1:len(reverse)) reverse(i:i) = 
 > reverse(len(reverse)-i+1:len(reverse)-i+1) 
 >  
 > internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:2550 
 >  
 > The patch also fixes the ICE for the test reduced test from pr55086 
 >  
 >   implicit none 
 >   character(len=5), pointer :: c, d 
 >   allocate (c, d) 
 >  
 >   d = '12345' 
 >   c = "abcde" 
 >  
 >   call test2p (d, c) 
 >   print *, d 
 >   if (d /= '1cb15') stop 'WRONG' 
 >  
 > contains 
 >  subroutine test2p(o, i) 
 >   character(len=*), pointer :: o, i 
 >   integer :: nl1, nu1 
 >   integer :: i1 
 >   nl1 = 2 
 >   nu1 = 4 
 >   forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)   !  ICE 
 >   forall (i1 = nl1:nu1) o(i1:i1) = o(nu1+1-i1:nu1+1-i1) 
 >  end subroutine test2p 
 > end 
 >  
 > but at the expense of an unneeded temporary: 
 >  
 >   { 
 > integer(kind=4) i1.0; 
 > integer(kind=4) D.3446; 
 > integer(kind=8) count1.1; 
 > integer(kind=8) num.2; 
 > character(kind=1)[0:][1:1] * temp.4; 
 > void * restrict D.3452; 
 >  
 > D.3446 = nu1; 
 > count1.1 = 0; 
 > num.2 = 0; 
 > { 
 >   integer(kind=4) count.3; 
 >  
 >   i1.0 = nl1; 
 >   count.3 = (1 - nl1) + nu1; 
 >   while (1) 
 > { 
 >   if (count.3 <= 0) goto L.1; 
 >   num.2 = num.2 + 1; 
 >   i1.0 = i1.0 + 1; 
 >   count.3 = count.3 + -1; 
 > } 
 >   L.1:; 
 > } 
 > D.3452 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long) 
 > num.2, 1>); 
 > temp.4 = (character(kind=1)[0:][1:1] *) D.3452; 
 > { 
 >   integer(kind=4) count.5; 
 >  
 >   i1.0 = nl1; 
 >   count.5 = (1 - nl1) + nu1; 
 >   while (1) 
 > { 
 >   if (count.5 <= 0) goto L.2; 
 >   (*temp.4)[count1.1][1]{lb: 1 sz: 1} = (**i)[i1.0]{lb: 1 sz: 1}; 
 >   count1.1 = count1.1 + 1; 
 >   i1.0 = i1.0 + 1; 
 >   count.5 = count.5 + -1; 
 > } 
 >   L.2:; 
 > } 
 > count1.1 = 0; 
 > { 
 >   integer(kind=4) count.6; 
 >  
 >   i1.0 = nl1; 
 >   count.6 = (1 - nl1) + nu1; 
 >   while (1) 
 > { 
 >   if (count.6 <= 0) goto L.3; 
 >   (**o)[i1.0]{lb: 1 sz: 1} = (*temp.4)[count1.1][1]{lb: 1 sz: 1}; 
 >   count1.1 = count1.1 + 1; 
 >   i1.0 = i1.0 + 1; 
 >   count.6 = count.6 + -1; 
 > } 
 >   L.3:; 
 > } 
 > __builtin_free ((void *) temp.4); 
 >   } 
 >  
 > --  
 > You are receiving this mail because: 
 > You are on the CC list for the bug.

[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #4 from Zhendong Su  ---
Richard and Martin, my build of r241970 still miscompiles the test: 

$ gcc-trunk -v  
Using built-in specs.
COLLECT_GCC=gcc-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 20161108 (experimental) [trunk revision 241970] (GCC) 
$ 
$ gcc-trunk -Os small.c
$ ./a.out
Segmentation fault (core dumped)
$

[Bug target/78262] New: [7 Regression] wrong code with -fschedule-insns

[zsojka at seznam dot cz]

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

Bug ID: 78262
   Summary: [7 Regression] wrong code with -fschedule-insns
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 39996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39996=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O -fschedule-insns testcase.c
$ ./a.out
Aborted

At the assembly level, the problem seems to be:
# testcase.c:12:   u128_0 = u128_0 << 127 | u128_0 >> 1;
mov rax, rcx# tmp99, _2
shrdrcx, rbx, 1 # _2, _2,
shrdrbx, rax, 1 # _2, tmp99,
# testcase.c:13:   u128_0 >>= (u8)u128_0;
shrdrcx, rbx, cl# _5, _5, _2
shr rbx, cl # _5, _2

^^^ the last shrd modifies rcx (and thus cl), which is used in the last shr
instruction - but it should use the original, unmodified value.

This might be a duplicate of some other bug that I cannot find now.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-241953-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-241953-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161108 (experimental) (GCC)

[Bug middle-end/78261] New: vect pass only vectorizes half of the array in gcc.c-torture/execute/pr68532.c

[acsawdey at gcc dot gnu.org]

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

Bug ID: 78261
   Summary: vect pass only vectorizes half of the array in
gcc.c-torture/execute/pr68532.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-*

Created attachment 39995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39995=edit
asm output

In this test case the loop in test() is vectorized but for some reason we only
end up generating vector code to do half of the array and a small loop to do
the other half.

Compile options:

xgcc gcc/testsuite/gcc.c-torture/execute/pr68532.c -mcpu=power8
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -O2 -ftree-vectorize
-fno-vect-cost-model -lm -fdump-tree-all-all -S -o pr68532_p8.s

The vect pass appears to know what is going on from this output:

vectorization_factor = 8, niters = 16

However it only ends up generating 8 iterations with of vector code and then a
serial loop that runs for 8 iterations to finish up the computation:

li 9,8
addi 4,4,128
mtctr 9
[...]
.L2:
lhz 9,0(4)
addi 4,4,16
mullw 9,9,5
add 3,9,3
rlwinm 3,3,0,0x
bdnz .L2
blr

[Bug target/70799] STV pass does not convert DImode shifts

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-08
Summary|STV pass does not convert   |STV pass does not convert
   |DImode shifts and rotates   |DImode shifts
 Ever confirmed|0   |1

--- Comment #5 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #0)
> These should all be converted to DImode vector shifts for SSE2/AVX2 32bit
> target (and similar for rotates):

There are no corresponding SSE insns for rotates.

[Bug target/70799] STV pass does not convert DImode shifts and rotates

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Nov  8 19:06:54 2016
New Revision: 241974

URL: https://gcc.gnu.org/viewcvs?rev=241974=gcc=rev
Log:
PR target/70799
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p):
Handle ASHIFT and LSHIFTRT.
(dimode_scalar_chain::compute_convert_gain): Ditto.
(dimode_scalar_chain::convert_insn): Ditto.

testsuite/ChangeLog:

PR target/70799
* gcc.target/i386/pr70799-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr70799-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Eric Niebler from comment #6)
> Jonathan, the wording for std::reverse mentions iter_swap and doesn't seem
> to say whether it is called qualified or unqualified.

17.6.1.1 [contents] means it calls it qualified as ::std::iter_swap, unless
otherwise specified. AFAICS it isn't otherwise specified.

> AFAIK, it is the only
> algorithm that is required to use iter_swap. It seems to be a hold-over from
> a time before time. The requires clause says that *value must be swappable,

Which does mean an unqualified call to swap happens, as per 17.6.3.2
[swappable.requirements].

> but it doesn't *exactly* say that the call to iter_swap must resolve to the
> version in namespace std that does swap(*a,*b). Please forgive me if I'm
> misreading the standard.

The standard library always assumes qualified calls to avoid ADL, unless
otherwise specified (as done for swap in [swappable.requirements]).

[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> At r241973, I see these failures on x86_64-linux-gnu:

... but only if I configure using --with-arch=haswell.

(the CPU on that machine is Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz)

[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
At r241973, I see these failures on x86_64-linux-gnu:

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/fast-math-mgrid-resid.f   -O   scan-tree-dump-times pcom
"Predictive commoning failed: no suitable chains" 0
FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f   -O   scan-tree-dump-times pcom
"Loop iterates only 1 time, nothing to do" 1

[Bug fortran/78260] ICE in gimplify_expr, at gimplify.c:11939

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

Another name clash :


$ cat z2.f90
module m
   integer :: n = 0
contains
   subroutine s
!$acc declare present(s)
  n = n + 1
   end
end


$ gfortran-7-20161106 -fopenacc -c z2.f90
z2.f90:1:0:

 module m

internal compiler error: in get, at cgraph.h:2479
0xf39b15 varpool_node::get(tree_node const*)
../../gcc/cgraph.h:2479
0xf39b15 varpool_node::get_create(tree_node*)
../../gcc/varpool.c:144
0xb20d77 scan_sharing_clauses
../../gcc/omp-low.c:2068
0xb2e7f8 scan_omp_target
../../gcc/omp-low.c:3193
0xb2e7f8 scan_omp_1_stmt
../../gcc/omp-low.c:3984
0x9ba87a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9baa98 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9ba952 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9baa98 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xb037e9 scan_omp
../../gcc/omp-low.c:4027
0xb388aa execute_lower_omp
../../gcc/omp-low.c:17902
0xb388aa execute
../../gcc/omp-low.c:17949

[Bug fortran/78260] New: ICE in gimplify_expr, at gimplify.c:11939

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78260
   Summary: ICE in gimplify_expr, at gimplify.c:11939
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code and option -fopenacc, affects version 6 and 7 :


$ cat z1.f90
module m
   integer :: n = 0
contains
   subroutine s
!$acc declare present(m)
  n = n + 1
   end
end


$ gfortran-7-20161106 -fopenacc -c z1.f90
z1.f90:1:0:

 module m

internal compiler error: in gimplify_expr, at gimplify.c:11939
0x9d8d8b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11939
0x9e4647 gimplify_addr_expr
../../gcc/gimplify.c:5665
0x9d6fdf gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11050
0x9e30af gimplify_modify_expr
../../gcc/gimplify.c:5262
0x9d60ed gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11004
0x9d9966 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6259
0x9db5a1 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:428
0x9db5a1 gimplify_assign(tree_node*, tree_node*, gimple**)
../../gcc/gimplify.c:12518
0xb364ac lower_omp_target
../../gcc/omp-low.c:16193
0xb364ac lower_omp_1
../../gcc/omp-low.c:17084
0xb364ac lower_omp
../../gcc/omp-low.c:17177
0xb3200c lower_omp_1
../../gcc/omp-low.c:17025
0xb3200c lower_omp
../../gcc/omp-low.c:17177
0xb391ef execute_lower_omp
../../gcc/omp-low.c:17912
0xb391ef execute
../../gcc/omp-low.c:17949

[Bug fortran/78259] New: ICE in gfc_trans_subcomponent_assign, at fortran/trans-expr.c:7330

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78259
   Summary: ICE in gfc_trans_subcomponent_assign, at
fortran/trans-expr.c:7330
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Test version 7 (--enable-checking=yes) with option -fdec :


$ cat z1.f90
subroutine sub
  structure /s/
union
  map
integer n(2)
  end map
  map
integer(8) m /2/
  end map
end union
  end structure
  record /s/ r
  r.n(1) = 1
end


$ gfortran-7-20161106 -fdec -c z1.f90
z1.f90:14:0:

 end

internal compiler error: Segmentation fault
0xc3a64f crash_signal
../../gcc/toplev.c:338
0x76e8d1 gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.c:7330
0x76db12 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:7482
0x76fd52 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7548
0x76852c gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7715
0x771b99 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:9730
0x74cbb0 gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool)
../../gcc/fortran/trans-decl.c:3924
0x756a9d gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4530
0x758e53 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6363
0x6e1d90 translate_all_program_units
../../gcc/fortran/parse.c:5944
0x6e1d90 gfc_parse_file()
../../gcc/fortran/parse.c:6144
0x725822 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/78258] New: ICE in compare_values_warnv, at tree-vrp.c:1218

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78258
   Summary: ICE in compare_values_warnv, at tree-vrp.c:1218
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Version 7 (configured with --enable-checking=yes) ICEs at -Os,-O2,-O3.


$ cat z1.f90
program p
   implicit none
   call sub (1, 'abcd')
   call sub (2, x4=4, x3='1234567')
contains
   subroutine sub (x1, x2, x3, x4)
  integer, intent(in) :: x1
  character(4), optional :: x2
  character(8), optional :: x3
  integer, optional :: x4
  if ( x1 == 1 ) then
 if ( x2 /= 'abcd' ) call abort
  else
 if ( x3 /= '1234567' ) call abort
 if ( x4 /= 4 ) call abort
  end if
   end
end


$ gfortran-7-20161106 -O2 z1.f90
z1.f90:4:25:

call sub (2, x4=4, x3='1234567')
 1
Warning: Character length of actual argument shorter than of dummy argument
'x3' (7/8) at (1) [-Wargument-mismatch]
z1.f90:4:0:

call sub (2, x4=4, x3='1234567')

internal compiler error: in compare_values_warnv, at tree-vrp.c:1218
0xeb46fa compare_values_warnv
../../gcc/tree-vrp.c:1217
0xeb481c compare_values
../../gcc/tree-vrp.c:1361
0xeb4f37 set_value_range
../../gcc/tree-vrp.c:366
0xeb817b vrp_meet_1
../../gcc/tree-vrp.c:8722
0xeb817b vrp_meet(value_range*, value_range const*)
../../gcc/tree-vrp.c:8745
0x1326d45 ipcp_vr_lattice::meet_with_1(value_range const*)
../../gcc/ipa-cp.c:909
0x1329e40 ipcp_vr_lattice::meet_with(value_range const*)
../../gcc/ipa-cp.c:891
0x1329e40 propagate_vr_accross_jump_function
../../gcc/ipa-cp.c:1872
0x1329e40 propagate_constants_accross_call
../../gcc/ipa-cp.c:2232
0x132d6dc propagate_constants_topo
../../gcc/ipa-cp.c:3127
0x132d6dc ipcp_propagate_stage
../../gcc/ipa-cp.c:3237
0x132fffd ipcp_driver
../../gcc/ipa-cp.c:4967
0x132fffd execute
../../gcc/ipa-cp.c:5061

[Bug fortran/78258] ICE in compare_values_warnv, at tree-vrp.c:1218

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
For completeness, two correct and working variants :


$ cat y1.f90
program p
   implicit none
   call sub (1, 'abcd')
   call sub (2, x4=4, x3='1234567')
contains
   subroutine sub (x1, x2, x3, x4)
  integer, intent(in) :: x1
  character(4), optional :: x2
  character(7), optional :: x3
  integer, optional :: x4
  if ( x1 == 1 ) then
 if ( x2 /= 'abcd' ) call abort
  else
 if ( x3 /= '1234567' ) call abort
 if ( x4 /= 4 ) call abort
  end if
   end
end


$ cat y2.f90
program p
   implicit none
   call sub (1, 'abcd')
   call sub (2, x4=4, x3='1234567')
contains
   subroutine sub (x1, x2, x3, x4)
  integer, intent(in) :: x1
  character(4), optional :: x2
  character(*), optional :: x3
  integer, optional :: x4
  if ( x1 == 1 ) then
 if ( x2 /= 'abcd' ) call abort
  else
 if ( x3 /= '1234567' ) call abort
 if ( x4 /= 4 ) call abort
  end if
   end
end

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #3 from Gerhard Steinmetz  
---
Adding an explicit declaration of "n" to snippet from comment 0 :


$ cat zz1.f90
subroutine s(n)
   integer :: n
   character(n) :: c
   c = 'c'
   print *, len(c), ' >>' // c // '<<'
end
program p
   call s(2)
end


$ gfortran-7-20161106 zz1.f90
$ a.out
   2  >>c <<

$ gfortran-7-20161106 -fimplicit-none zz1.f90
$ a.out
   2  >>c <<

---


$ cat zz2.f90
subroutine s(n)
   ! integer :: n
   character(n) :: c
   c = 'c'
   print *, len(c), ' >>' // c // '<<'
end
program p
   call s(2)
end


$ gfortran-7-20161106 zz1.f90
$ a.out
   2  >>c <<

[Bug fortran/78238] [7 Regression] ICE: verify_gimple failed, with -fdefault-integer-8

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #5 from Gerhard Steinmetz  
---
> Also, what happens if you use -freal-4-real-8?
   -freal-4-real-8  : works
   -freal-4-real-10 : works
   -freal-4-real-16 : works
   -fdefault-real-8 : works

   -finteger-4-integer-8 : fails
   -fdefault-integer-8   : fails

[Bug tree-optimization/78257] New: missing memcmp optimization with constant arrays

[msebor at gcc dot gnu.org]

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

Bug ID: 78257
   Summary: missing memcmp optimization with constant arrays
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC folds some calls to memcmp involving constants but not others even though
it's able to fold equivalent expressions not involving the function.  The test
case below shows two such examples.  Using memcmp to compare constant string
arrays is folded unless the comparison includes the terminating nul.  Using
memcmp to compare arrays of integers is not folded even though comparing the
array elements (even recursively) is.

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout t.c
const char a[] = "1234";
const char b[] = "1234";

const int i[] = { 1234 };
const int j[] = { 1234 };

int f0 (void)
{
  return __builtin_memcmp (a, b, sizeof a);
}

int f1 (void)
{
  return __builtin_memcmp (a, b, sizeof a - 1);
}

int f2 (void)
{
  return __builtin_memcmp (i, j, sizeof i);
}

int f3 (void)
{
  return *i == *j;
}

int f4 (void)
{
  return __builtin_strcmp (a, b);
}

;; Function f0 (f0, funcdef_no=0, decl_uid=1799, cgraph_uid=0, symbol_order=4)

f0 ()
{
  int _2;

  :
  _2 = __builtin_memcmp (, , 5); [tail call]
  return _2;

}



;; Function f1 (f1, funcdef_no=6, decl_uid=1802, cgraph_uid=1, symbol_order=5)

f1 ()
{
  :
  return 0;

}



;; Function f2 (f2, funcdef_no=2, decl_uid=1805, cgraph_uid=2, symbol_order=6)

f2 ()
{
  int _2;

  :
  _2 = __builtin_memcmp (, , 4); [tail call]
  return _2;

}



;; Function f3 (f3, funcdef_no=3, decl_uid=1808, cgraph_uid=3, symbol_order=7)

f3 ()
{
  :
  return 1;

}



;; Function f4 (f4, funcdef_no=4, decl_uid=1811, cgraph_uid=4, symbol_order=8)

f4 ()
{
  :
  return 0;

}

[Bug fortran/68440] [OOP] ICE on declaring class variable with wrong attribute

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from janus at gcc dot gnu.org ---
Actually, since all of the attributes DUMMY, POINTER and ALLOCATABLE conflict
with the PARAMETER attribute, I guess the combination of CLASS and PARAMETER
can be forbidden completely.

Thus the second part of the patch becomes a bit simpler:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (Revision 241972)
+++ gcc/fortran/resolve.c   (Arbeitskopie)
@@ -14001,6 +14001,15 @@ resolve_fl_parameter (gfc_symbol *sym)
 >value->where);
   return false;
 }
+
+  /* F03:C509,C514.  */
+  if (sym->ts.type == BT_CLASS)
+{
+  gfc_error ("CLASS variable %qs at %L cannot have the PARAMETER
attribute",
+sym->name, >declared_at);
+  return false;
+}
+
   return true;
 }

[Bug libstdc++/78231] Should std::sort use unqualifed iter_swap?

[eric.niebler at gmail dot com]

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

Eric Niebler  changed:

   What|Removed |Added

 CC||eric.niebler at gmail dot com

--- Comment #6 from Eric Niebler  ---
Jonathan, the wording for std::reverse mentions iter_swap and doesn't seem to
say whether it is called qualified or unqualified. AFAIK, it is the only
algorithm that is required to use iter_swap. It seems to be a hold-over from a
time before time. The requires clause says that *value must be swappable, but
it doesn't *exactly* say that the call to iter_swap must resolve to the version
in namespace std that does swap(*a,*b). Please forgive me if I'm misreading the
standard.

[Bug fortran/68440] [OOP] ICE on declaring class variable with wrong attribute

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from janus at gcc dot gnu.org ---
Draft patch:


Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (Revision 241972)
+++ gcc/fortran/expr.c  (Arbeitskopie)
@@ -2206,7 +2206,7 @@ check_alloc_comp_init (gfc_expr *e)
   gfc_constructor *ctor;

   gcc_assert (e->expr_type == EXPR_STRUCTURE);
-  gcc_assert (e->ts.type == BT_DERIVED);
+  gcc_assert (e->ts.type == BT_DERIVED || e->ts.type == BT_CLASS);

   for (comp = e->ts.u.derived->components,
ctor = gfc_constructor_first (e->value.constructor);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (Revision 241972)
+++ gcc/fortran/resolve.c   (Arbeitskopie)
@@ -14001,6 +14001,19 @@ resolve_fl_parameter (gfc_symbol *sym)
 >value->where);
   return false;
 }
+
+  /* F03:C509.  */
+  /* Assume that use associated symbols were checked in the module ns.
+ Class variables that are associate-names are also something special
+ and excepted from the test.  */
+  if (sym->ts.type == BT_CLASS && !sym->attr.class_ok
+  && !sym->attr.use_assoc && !sym->assoc)
+{
+  gfc_error ("CLASS variable %qs at %L must be dummy, allocatable "
+"or pointer", sym->name, >declared_at);
+  return false;
+}
+
   return true;
 }

[Bug middle-end/78256] New: test case gcc.dg/pr35691-1.c fails starting with its introduction in r241915

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78256
   Summary: test case gcc.dg/pr35691-1.c fails starting with its
introduction in r241915
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/pr35691-1.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2
-fdump-tree-forwprop-details -S   -o pr35691-1.s(timeout = 300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/pr35691-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-fdump-tree-forwprop-details -S -o pr35691-1.s
PASS: gcc.dg/pr35691-1.c (test for excess errors)
FAIL: gcc.dg/pr35691-1.c scan-tree-dump forwprop1 "gimple_simplified to _[0-9]*
= \\(int\\) z1_[0-9]*\\(D\\);"

This fails on power on both BE and LE.

[Bug fortran/77596] [F03] procedure pointer component with implicit interface can point to a function

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from janus at gcc dot gnu.org ---
Fixed with r241972. Closing. Thanks for the report!

[Bug fortran/77596] [F03] procedure pointer component with implicit interface can point to a function

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Nov  8 16:10:56 2016
New Revision: 241972

URL: https://gcc.gnu.org/viewcvs?rev=241972=gcc=rev
Log:
2016-11-08  Janus Weil  

PR fortran/77596
* expr.c (gfc_check_pointer_assign): Add special check for procedure-
pointer component with absent interface.

2016-11-08  Janus Weil  

PR fortran/77596
* gfortran.dg/proc_ptr_comp_46.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_46.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78255] New: [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM

[avieira at gcc dot gnu.org]

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

Bug ID: 78255
   Summary: [5/6/7 regression] Indirect sibling call causing wrong
code generation for ARM
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avieira at gcc dot gnu.org
  Target Milestone: ---

As first reported by Andrew on
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1616992

To reproduce on trunk:
$ cat test.c
#include 
struct table_s
{
void (*fun0)
( void );
void (*fun1)
( void );
void (*fun2)
( void );
void (*fun3)
( void );
void (*fun4)
( void );
void (*fun5)
( void );
void (*fun6)
( void );
void (*fun7)
( void );
} table;

void callback0(){__asm("mov r0, r0 \n\t");}
void callback1(){__asm("mov r0, r0 \n\t");}
void callback2(){__asm("mov r0, r0 \n\t");}
void callback3(){__asm("mov r0, r0 \n\t");}
void callback4(){__asm("mov r0, r0 \n\t");}

void test(void) {
memset(, 0, sizeof table);

asm volatile ("" : : : "r3");

table.fun0 = callback0;
table.fun1 = callback1;
table.fun2 = callback2;
table.fun3 = callback3;
table.fun4 = callback4;
table.fun0();
}

$ arm-none-eabi-gcc -S -O2 -mthumb -mcpu=cortex-m3 test.c
$ cat test.s
...
ldr r5, .L8+4
ldr r3, .L8+8
ldr r0, .L8+12
ldr r1, .L8+16
ldr r2, .L8+20
str r5, [r4]
str r0, [r4, #4]
str r1, [r4, #8]
str r2, [r4, #12]
str r3, [r4, #16]
pop {r3, r4, r5, lr}
bx  r3  @ indirect register sibling call
...

As reported, we see that r3 is "restored" before being used to do the sibling
call. So it will no longer contain the address of the call.

I believe this is because 'arm_get_frame_offsets' is called to determine
whether we can safely use 'r3' to align the stack using the function
'any_sibcall_could_use_r3'. This is done before the address of the sibcall is
assigned a hard register, so 'any_sibcall_could_use_r3' returns 'false' and we
push and pop 'r3' in the pro- and epilogue.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[sarnila at adit dot fi]

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

--- Comment #39 from Pekka  ---
Well this change did now hit me.

We have a code base of thousands of modules for a set of industrial systems.
Every now and then we must recompile for new platforms with new versions of
things like gcc. And now is one such time.

The code base has been developed over 20 odd years and continues. Nearly every
time some backward compatibility is broken it is a big headache for me. Some
modules must be updated. Usually gcc warnings are very helpful in this. But now
I get thousand of them. I our environment it is absolutely necessary to have
version strings in every singe module to be stamped inside the created binary.
Every module has it own versions. Modules are normally developed independently
(a bit like kernel drivers).

Years ago when 'unused warning' appeared we had this tedious project to add
'const' to every version stamp in every module (there are different version
string names for different purposes). I must now figure out what is the best
solution.

There must be millions of C-modules out there that are still in current use and
have versions or something similar stamped in they binaries.

I see the need for progress but I must say I'm quite annoyed on how lightly in
the open source world backward compatibility is broken.

[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #3 from Zhendong Su  ---
Interesting. I just doubled checked, and my r241911 build does miscompile both
the original test that I have and the reported reduced test above. 

Let me also build the TOT and check. 

Thank you both for investigating!

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #40 from Jerry DeLisle  ---
(In reply to Joost VandeVondele from comment #37)
> (In reply to Joost VandeVondele from comment #36)
> > #pragma GCC optimize ( "-Ofast -fvariable-expansion-in-unroller
> > -funroll-loops" )
>
Using: (I found it necessary to split into separate lines)
#pragma GCC optimize ( "-Ofast" )
#pragma GCC optimize ( "-funroll-loops" )
#pragma GCC optimize ( "-fvariable-expansion-in-unroller" )

$ gfc -static -Ofast -finline-matmul-limit=0 compare.f90 
[jerry@quasar pr51119]$ ./a.out 
 =
 MEASURED GIGAFLOPS  =
 =
 Matmul   Matmul
 fixed Matmul variable
 Size  Loops explicit   refMatmul  assumedexplicit
 =
2  2000  0.055  0.048  0.042  0.055
4  2000  0.366  0.236  0.299  0.368
8  2000  0.628  0.673  1.610  1.833
   16  2000  2.876  2.765  2.821  2.930
   32  2000  4.681  3.382  4.812  4.763
   64  2000  6.742  2.817  6.760  6.764
  128  2000  8.532  3.194  7.852  8.539
  256   477  9.420  3.319  9.053  9.420
  51259  8.435  2.358  8.319  8.390
 1024 7  8.493  1.368  8.379  8.444
 2048 1  8.499  1.666  8.385  8.448

[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[vogt at linux dot vnet.ibm.com]

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

--- Comment #26 from Dominik Vogt  ---
Patch for s390[x], gcc-6:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00745.html

[Bug target/78253] [ARM] call weak function instead of strong when called through pointer

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-11-08
 Ever confirmed|0   |1

--- Comment #4 from Christophe Lyon  ---
With gcc 4.9, the generated code looks like:
save_weak_func_pointer:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
add fp, sp, #0
ldr r3, .L7
.LPIC1:
add r3, pc, r3
ldr r2, .L7+4
ldr r2, [r3, r2]
ldr r1, .L7+8
ldr r3, [r3, r1]
str r3, [r2]
sub sp, fp, #0
@ sp needed
ldr fp, [sp], #4
bx  lr
.L8:
.align  2
.L7:
.word   _GLOBAL_OFFSET_TABLE_-(.LPIC1+8)
.word   __weak_func_ptr(GOT)
.word   some_weak_func(GOT)

With gcc 5.3:
save_weak_func_pointer:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
add fp, sp, #0
ldr r2, .L7
.LPIC1: 
add r2, pc, r2
ldr r3, .L7+4
ldr r3, [r2, r3]
ldr r2, .L7+8
.LPIC2:
add r2, pc, r2
str r2, [r3]
nop
sub sp, fp, #0
@ sp needed
ldr fp, [sp], #4
bx  lr
.L8:
.align  2
.L7:
.word   _GLOBAL_OFFSET_TABLE_-(.LPIC1+8)
.word   __weak_func_ptr(GOT)
.word   some_weak_func-(.LPIC2+8)

That is, some_weak_func is not referenced through the got anymore.

I've noticed that r220674 introduced a new param to default_binds_local_p:
weak_dominates, which is true when called via default_binds_local_p_2.

I am not sure what "weak_dominates", and I couldn't find a description in the
gcc-patches thread where r220674 and more recent updates were discussed.

I am wondering whether have weak_dominates=false on arm is the right fix, as it
does not explain why the sample code works on x86_64 and aarch64.

[Bug fortran/60777] [F03] RECURSIVE function rejected in specification expression

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Steve, do you wanna go ahead with the patch in comment 1, or is there
> something wrong with it?

To be honest, I don't remember this bug nor why I did not
finish the patch (i.e., convert example to testcase).  If
you feel that the patch in comment #3 is correct, you are
more than welcomed to commit it.

[Bug fortran/50069] FORALL fails on a character array

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> The attached patch adds a slight variation of Tobias Burnus's patch
> for 50069 to my patch for 55086, and it seems to fix the two tests in 50069.

I have applied the patch without the last hunk. It fixes the first test by
supplying the needed temporary. However compiling the test (variant of the test
in comment 6)

function  reverse(string) ! bind(c, name='reverse')
implicit none
character(len=*), intent(in) :: string
character(len=:),allocatable :: reverse
integer :: i
reverse = string
forall (i=1:len(reverse)) reverse(i:i) =
reverse(len(reverse)-i+1:len(reverse)-i+1)
end function reverse

still gives an ICE

 forall (i=1:len(reverse)) reverse(i:i) =
reverse(len(reverse)-i+1:len(reverse)-i+1)

internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:2550

The patch also fixes the ICE for the test reduced test from pr55086

  implicit none
  character(len=5), pointer :: c, d
  allocate (c, d)

  d = '12345'
  c = "abcde"

  call test2p (d, c)
  print *, d
  if (d /= '1cb15') stop 'WRONG'

contains
 subroutine test2p(o, i)
  character(len=*), pointer :: o, i
  integer :: nl1, nu1
  integer :: i1
  nl1 = 2
  nu1 = 4
  forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)   !  ICE
  forall (i1 = nl1:nu1) o(i1:i1) = o(nu1+1-i1:nu1+1-i1)
 end subroutine test2p
end

but at the expense of an unneeded temporary:

  {
integer(kind=4) i1.0;
integer(kind=4) D.3446;
integer(kind=8) count1.1;
integer(kind=8) num.2;
character(kind=1)[0:][1:1] * temp.4;
void * restrict D.3452;

D.3446 = nu1;
count1.1 = 0;
num.2 = 0;
{
  integer(kind=4) count.3;

  i1.0 = nl1;
  count.3 = (1 - nl1) + nu1;
  while (1)
{
  if (count.3 <= 0) goto L.1;
  num.2 = num.2 + 1;
  i1.0 = i1.0 + 1;
  count.3 = count.3 + -1;
}
  L.1:;
}
D.3452 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
num.2, 1>);
temp.4 = (character(kind=1)[0:][1:1] *) D.3452;
{
  integer(kind=4) count.5;

  i1.0 = nl1;
  count.5 = (1 - nl1) + nu1;
  while (1)
{
  if (count.5 <= 0) goto L.2;
  (*temp.4)[count1.1][1]{lb: 1 sz: 1} = (**i)[i1.0]{lb: 1 sz: 1};
  count1.1 = count1.1 + 1;
  i1.0 = i1.0 + 1;
  count.5 = count.5 + -1;
}
  L.2:;
}
count1.1 = 0;
{
  integer(kind=4) count.6;

  i1.0 = nl1;
  count.6 = (1 - nl1) + nu1;
  while (1)
{
  if (count.6 <= 0) goto L.3;
  (**o)[i1.0]{lb: 1 sz: 1} = (*temp.4)[count1.1][1]{lb: 1 sz: 1};
  count1.1 = count1.1 + 1;
  i1.0 = i1.0 + 1;
  count.6 = count.6 + -1;
}
  L.3:;
}
__builtin_free ((void *) temp.4);
  }

[Bug target/78253] New: [ARM] call weak function instead of strong when called through pointer

[clyon at gcc dot gnu.org]

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

Bug ID: 78253
   Summary: [ARM] call weak function instead of strong when called
through pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

This is a forward/summary of https://bugs.linaro.org/show_bug.cgi?id=2562

Since GCC 5, on ARM a code fragment like:
some_module.c:
int __attribute__((weak)) some_weak_func(void)
{
return 10;
}
void save_weak_func_pointer(void)
{
__weak_func_ptr = some_weak_func;
}

saves the address of the weak implementation in __weak_func_ptr even though the
function can be overridden by a strong implementation in another object file.

so even if main.c has:
int some_weak_func(void)
{
return 11;
}

when calling through __weak_func_ptr(), we end up calling the weak
implementation.

[Bug libfortran/51119] MATMUL slow for large matrices

[jvdelisle at gcc dot gnu.org]

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

--- Comment #39 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #38)
> 
> Jerry, what Netlib code were you basing your code on?

http://www.netlib.org/blas/index.html#_level_3_blas_tuned_for_single_processors_with_caches

Used the dgemm version from the download zip to start, stripped it of unneeded
code, converted to C with f2c, and further edits to clean it up.

[Bug target/78253] [ARM] call weak function instead of strong when called through pointer

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---
Compile the attached code with:
CFLAGS="-marm -fpie"
arm-linux-gnueabi-gcc $CFLAGS -c main.c -o main.o
arm-linux-gnueabi-gcc $CFLAGS -c some_module.c -o some_module.o

Link with
arm-linux-gnueabi-gcc -pie -o test_weak main.o some_module.o

Correct execution should show:
  Entering test_weak_funcion_call
  This line is to avoid optimization in further call_weak_by_pointer
res_pointer_call = 11
res_direct_call = 11
  All Ok

But instead we have:
  Entering test_weak_funcion_call
  This line is to avoid optimization in further call_weak_by_pointer
res_pointer_call = 10
res_direct_call = 11
  ERROR: Results from direct call and from call via pointer differs


The behaviour changed with r220674.

[Bug target/78253] [ARM] call weak function instead of strong when called through pointer

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Created attachment 39994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39994=edit
some_module.c

[Bug target/78254] New: FAIL: g++.dg/torture/pr77822.C -O3 -g (internal compiler error)

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

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

Bug ID: 78254
   Summary: FAIL: g++.dg/torture/pr77822.C   -O3 -g  (internal
compiler error)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: m68k-*-*

Combine is generating

(insn 47 46 48 (set (cc0)
(compare (zero_extract:SI (reg:SI 1 %d1 [orig:33 b.0_3 ] [33])
(const_int 1 [0x1])
(const_int -33 [0xffdf]))
(const_int 0 [0])))
"../../../gcc/gcc/testsuite/g++.dg/torture/pr77822.C":27 31 {*m68k.md:763}
 (expr_list:REG_DEAD (reg:SI 1 %d1 [orig:33 b.0_3 ] [33])
(nil)))

but output_btst cannot cope with out-of-range bit pos for a register operand.

[Bug target/78253] [ARM] call weak function instead of strong when called through pointer

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 39993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39993=edit
main.c

[Bug fortran/60777] [F03] RECURSIVE function rejected in specification expression

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||janus at gcc dot gnu.org
Summary|Fortran 2003: RECURSIVE |[F03] RECURSIVE function
   |function rejected in|rejected in specification
   |specification expression|expression

--- Comment #3 from janus at gcc dot gnu.org ---
Steve, do you wanna go ahead with the patch in comment 1, or is there something
wrong with it?

[Bug target/78243] incorrect byte offset in vextractuh with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Created attachment 39992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39992=edit
complete asm output

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[howarth.at.gcc at gmail dot com]

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

--- Comment #2 from Jack Howarth  ---
It appears that config/iconv.m4 needs to be reworked for its tests to succeed.
Removing  INCICONV from CPPFLAGS on darwin causes the headers from /usr/include
to be accidentally used against the libs from /opt/local/lib...

configure:10761: /usr/bin/clang++ -arch x86_64 -std=gnu++98 -o conftest -g
-Wl,-no_pie  conftest.cpp  -L/opt/local/lib -liconv >&5

fails because -I/opt/local/include was dropped. This should be available to
configure already from...

--with-libiconv-prefix[=DIR]

without resorting to CPPFLAGS to pass it around to the Makefile.

[Bug fortran/60500] [5/6/7 Regression] Spurious warning on derived type initialization

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
BTW does it make sense to back port r241885?

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[davmac at davmac dot org]

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

Davin McCall  changed:

   What|Removed |Added

 CC||davmac at davmac dot org

--- Comment #27 from Davin McCall  ---
> Another option is to decide which to throw based on an environment variable, 
> so > applications can choose whether they want the types thrown by the 
> library to be > catchable by new code or old code.

Please don't do this. It will mean programs that require wrapper scripts just
to work properly, or problems with old-abi programs launching new-abi programs
and vice-versa, and will undoubtedly cause confusion when programs seem to work
correctly some of the time and not otherwise.

> But we might end up just throwing the new type, and saying old code needs to 
> be > recompiled, or just to catch it as std::exception not 
> std::ios_base::failure.

If you are going to mandate that old code needs to be recompiled (including if
you say that it should catch std::exception, since that requires altering the
code and therefore implies recompilation), I would suggest that you also bump
the soname; this is definitely an ABI break. At that point you can remove the
dual ABI anyway, since you only need to support the new one.

If you do not plan on bumping the soname, but will change the thrown exception
type to the new type, I would suggest that this change be made as soon as is
practically possible to avoid the production of further software being compiled
against the old ABI - which will then need to be recompiled when this change is
made. The less that needs to be recompiled the better, especially since that
was IIUC the reason for the creation of the dual ABI in the first place.

[Bug fortran/60500] [5/6/7 Regression] Spurious warning on derived type initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|vehre at gcc dot gnu.org   |dominiq at lps dot 
ens.fr

--- Comment #10 from Dominique d'Humieres  ---
Let see if I can come with a test for it.

[Bug libgcc/78252] New: C++ demangler crashes with infinite recursion

[P at draigBrady dot com]

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

Bug ID: 78252
   Summary: C++ demangler crashes with infinite recursion
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: P at draigBrady dot com
  Target Milestone: ---

Created attachment 39991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39991=edit
problematic symbol

There is an infinite recursion in d_print_comp() in gcc-5 to gcc-6.2 at least.
Simple reproducer attached

[Bug other/78250] Gcc 6 bootstrap failure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fine.

[Bug other/78250] Gcc 6 bootstrap failure

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
After throwing away the build dir I cannot reproduce the failure anymore.

[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from vehre at gcc dot gnu.org ---
No regressions so far. Closing.

[Bug fortran/39627] [meta-bug] Fortran 2008 support

[vehre at gcc dot gnu.org]

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

Bug 43366 Summary: [OOP][F08] Intrinsic assign to polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43366

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/43366] [OOP][F08] Intrinsic assign to polymorphic variable

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from vehre at gcc dot gnu.org ---
No regressions reported so far. Closing.

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenther at suse dot de]

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

--- Comment #28 from rguenther at suse dot de  ---
On Tue, 8 Nov 2016, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
> 
> --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #26 from Richard Biener  ---
> > I believe that https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00686.html will
> > fix this (currently in testing).
> 
> While it fixes the failures on sparc, it introduces a couple of ICEs on
> previously working testcases, both i386-pc-solaris2.12 and
> sparc-sun-solaris2.12, 32 and 64-bit, e.g.
> 
> FAIL: gcc.dg/vect/bb-slp-24.c (test for excess errors)
> Excess errors:
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/bb-slp-24.c:11:6:
> internal compiler error: tree check: expected class 'expression', have
> 'exceptional' (ssa_name) in tree_operand_check, at tree.h:3543
> 0xcad8f3 tree_class_check_failed(tree_node const*, tree_code_class, char
> const*, int, char const*)
> /vol/gcc/src/hg/trunk/local/gcc/tree.c:9814
> 0x104122b expr_check(tree_node*, char const*, int, char const*)
> /vol/gcc/src/hg/trunk/local/gcc/tree.h:3214
> 0x104122b tree_operand_check(tree_node*, int, char const*, int, char const*)
> 0x104122b tree_operand_check(tree_node*, int, char const*, int, char const*)
> /vol/gcc/src/hg/trunk/local/gcc/tree.h:3543
> 0x104122b vect_compute_data_ref_alignment(data_reference*)
> /vol/gcc/src/hg/trunk/local/gcc/tree-vect-data-refs.c:816
> 0x10423e3 vect_slp_analyze_and_verify_node_alignment
> /vol/gcc/src/hg/trunk/local/gcc/tree-vect-data-refs.c:2148
> 0x1042537 vect_slp_analyze_and_verify_instance_alignment(_slp_instance*)
> /vol/gcc/src/hg/trunk/local/gcc/tree-vect-data-refs.c:2180
> 0xc805d3 vect_slp_analyze_bb_1
> /vol/gcc/src/hg/trunk/local/gcc/tree-vect-slp.c:2677
> 0xc805d3 vect_slp_bb(basic_block_def*)
> /vol/gcc/src/hg/trunk/local/gcc/tree-vect-slp.c:2790
> 0xc82cfb execute
> /vol/gcc/src/hg/trunk/local/gcc/tree-vectorizer.c:794

Yes, I've fixed that one in the version in testing right now.

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #26 from Richard Biener  ---
> I believe that https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00686.html will
> fix this (currently in testing).

While it fixes the failures on sparc, it introduces a couple of ICEs on
previously working testcases, both i386-pc-solaris2.12 and
sparc-sun-solaris2.12, 32 and 64-bit, e.g.

FAIL: gcc.dg/vect/bb-slp-24.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/bb-slp-24.c:11:6:
internal compiler error: tree check: expected class 'expression', have
'exceptional' (ssa_name) in tree_operand_check, at tree.h:3543
0xcad8f3 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/vol/gcc/src/hg/trunk/local/gcc/tree.c:9814
0x104122b expr_check(tree_node*, char const*, int, char const*)
/vol/gcc/src/hg/trunk/local/gcc/tree.h:3214
0x104122b tree_operand_check(tree_node*, int, char const*, int, char const*)
0x104122b tree_operand_check(tree_node*, int, char const*, int, char const*)
/vol/gcc/src/hg/trunk/local/gcc/tree.h:3543
0x104122b vect_compute_data_ref_alignment(data_reference*)
/vol/gcc/src/hg/trunk/local/gcc/tree-vect-data-refs.c:816
0x10423e3 vect_slp_analyze_and_verify_node_alignment
/vol/gcc/src/hg/trunk/local/gcc/tree-vect-data-refs.c:2148
0x1042537 vect_slp_analyze_and_verify_instance_alignment(_slp_instance*)
/vol/gcc/src/hg/trunk/local/gcc/tree-vect-data-refs.c:2180
0xc805d3 vect_slp_analyze_bb_1
/vol/gcc/src/hg/trunk/local/gcc/tree-vect-slp.c:2677
0xc805d3 vect_slp_bb(basic_block_def*)
/vol/gcc/src/hg/trunk/local/gcc/tree-vect-slp.c:2790
0xc82cfb execute
/vol/gcc/src/hg/trunk/local/gcc/tree-vectorizer.c:794

Rainer

[Bug fortran/60500] [5/6/7 Regression] Spurious warning on derived type initialization

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #9 from vehre at gcc dot gnu.org ---
Fixed by r241885. Thanks Mikael for pointing this out.

Waiting one week for regressions to be reported before closing.

[Bug tree-optimization/78234] [7 Regression] LLVM reports dynamic-stack-buffer-overflow in gimple-ssa-store-merging.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to ktkachov from comment #3)
> Marcus, could you please try r241962 ?

Works fine now. Thanks for the fix.

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[howarth.at.gcc at gmail dot com]

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

--- Comment #1 from Jack Howarth  ---
FYI, the only reason we never see the same breakage on fink as MacPorts is that
we don't happen to have a libunwinder package in our package set to expose us
to 

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

We do however end up with the same contamination of CPPFLAGS late in the build
(in our case with contamination by -I/sw/include). 

Also, in the case of 

  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib

this process results in DIR being placed on CPPFLAGS instead of being keep on
the INCLUDES lines of individual Makefile.in instead. My initial attempts to
detangle this have been along the lines of...

--- gcc/Makefile.in.orig2016-11-08 03:29:02.0 -0500
+++ gcc/Makefile.in 2016-11-08 03:29:56.0 -0500
@@ -1063,7 +1063,7 @@
 # currently being compiled, in both source trees, to be examined as well.
 # libintl.h will be found in ../intl if we are using the included libintl.
 INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
-  -I$(srcdir)/../include @INCINTL@ \
+  -I$(srcdir)/../include @INCINTL@ ${INCICONV} \
   $(CPPINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \
   $(ISLINC)

--- libstdc++-v3/src/Makefile.in.orig   2016-11-08 02:14:37.0 -0500
+++ libstdc++-v3/src/Makefile.in2016-11-08 02:15:15.0 -0500
@@ -126,7 +126,7 @@
 @VTV_CYGMIN_TRUE@am_libvtv_la_OBJECTS = vtv_stubs.lo
 libvtv_la_OBJECTS = $(am_libvtv_la_OBJECTS)
 @VTV_CYGMIN_TRUE@am_libvtv_la_rpath = -rpath $(toolexeclibdir)
-DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
+DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir) -I${INCICONV}
 depcomp =
 am__depfiles_maybe =
 CXXCOMPILE = $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
--- libstdc++-v3/configure.orig 2016-11-08 02:00:42.0 -0500
+++ libstdc++-v3/configure  2016-11-08 02:10:25.0 -0500
@@ -28529,7 +28529,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
@@ -40804,7 +40803,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
@@ -46928,7 +46926,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
@@ -59755,7 +59752,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 am_cv_lib_iconv=no
 am_save_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS="$CPPFLAGS $INCICONV"
 if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
 fi
--- libstdc++-v3/configure.orig 2016-11-08 02:33:18.0 -0500
+++ libstdc++-v3/configure  2016-11-08 02:34:41.0 -0500
@@ -28596,7 +28596,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
@@ -40870,7 +40870,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
@@ -46993,7 +46993,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
@@ -59819,7 +59819,7 @@
 if test "$am_cv_func_iconv" != yes; then
   am_save_CPPFLAGS="$CPPFLAGS"
   am_save_LIBS="$LIBS"
-  CPPFLAGS="$LIBS $INCICONV"
+  CPPFLAGS="$LIBS"
   LIBS="$LIBS $LIBICONV"
   if test x$gcc_no_link = xyes; then
   as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO"
5
--- gcc/configure.orig  2016-11-08 02:53:20.0 -0500
+++ gcc/configure   2016-11-08 02:56:53.0 -0500
@@ -10681,7 +10681,6 @@
 am_cv_func_iconv="no, consider installing GNU libiconv"
 

[Bug testsuite/78242] Error in testsuite/gcc.dg/asan/use-after-scope-8.c since its introduction

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug tree-optimization/78234] [7 Regression] LLVM reports dynamic-stack-buffer-overflow in gimple-ssa-store-merging.c

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Marcus, could you please try r241962 ?

[Bug bootstrap/78251] New: config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[howarth.at.gcc at gmail dot com]

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

Bug ID: 78251
   Summary: config/gettext.m4 and config/iconv.m4 contaminate
CPPFLAGS
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
  Target Milestone: ---

While debugging the MacPorts build approach for FSF gcc and comparing it to our
own in the fink project, I ran across a surprising result. The MacPorts project
builds fail when their libunwinder-headers package is installed in their
${prefix} which is /opt/local. I expected to be able to solve this by building,
like fink, with CPPFLAGS and LDFLAGS unset (i.e. no -I/opt/local/include on
CPPFLAGS and -L/opt/local/lib on LDFLAGS) but instead to rely on the individual
--with-*= configure options to sort the paths out. 

Weirdly the build starts out fine and the initially generated Makefiles always
retain...

CPPFLAGS=

but once the build hits any configure which used config/gettext.m4 or
config/iconv.m4, CPPFLAGS gets contaminated with INCICONV or LIBICONV_INCLUDE.

Why can't config/gettext.m4 and config/iconv.m4 be restructured to perform its
tests without contaminating the previous contents of CPPFLAGS in the process?

[Bug tree-optimization/78234] [7 Regression] LLVM reports dynamic-stack-buffer-overflow in gimple-ssa-store-merging.c

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Nov  8 12:31:31 2016
New Revision: 241962

URL: https://gcc.gnu.org/viewcvs?rev=241962=gcc=rev
Log:
[1/2] Fix off-by-one error in clear_bit_region in store merging (PR
tree-optimization/78234 ?)

PR tree-optimization/78234
* gimple-ssa-store-merging.c (clear_bit_region): Fix off-by-one error
in start != 0 case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c

[Bug testsuite/78242] Error in testsuite/gcc.dg/asan/use-after-scope-8.c since its introduction

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Tue Nov  8 12:28:33 2016
New Revision: 241961

URL: https://gcc.gnu.org/viewcvs?rev=241961=gcc=rev
Log:
use-after-scope fallout

PR testsuite/78242
* g++.dg/asan/use-after-scope-4.C: New test.
* g++.dg/asan/use-after-scope-types-4.C: Update scanned pattern.
* gcc.dg/asan/use-after-scope-8.c: Remove.
PR testsuite/78242
* dbgcnt.def: Add new debug counter asan_use_after_scope.
* gimplify.c (gimplify_decl_expr): Do not sanitize vars
with a value expr.  Do not add artificial variables to
live_switch_vars.  Use the debug counter.
(gimplify_target_expr): Use the debug counter.
* internal-fn.def: Remove ECF_TM_PURE from ASAN_MARK builtin.
* sanitizer.def: Set ATTR_NOTHROW_LEAF_LIST to
BUILT_IN_ASAN_CLOBBER_N and BUILT_IN_ASAN_UNCLOBBER_N.

Added:
trunk/gcc/testsuite/g++.dg/asan/use-after-scope-4.C
Removed:
trunk/gcc/testsuite/gcc.dg/asan/use-after-scope-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dbgcnt.def
trunk/gcc/gimplify.c
trunk/gcc/internal-fn.def
trunk/gcc/sanitizer.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/asan/use-after-scope-types-4.C

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener  ---
I believe that https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00686.html will
fix this (currently in testing).

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Richard Biener  ---
if-combine is combining parts of

if( (red_cost < 0 && arc->ident == 1)
|| (red_cost > 0 && arc->ident == 2) )
{

to

  if (red_cost_86 < 0)
goto ;
  else
goto ;

  :
  if (_23 == 1)
goto ;
  else
goto ;

  :
  _340 = _23 == 2;
  _341 = red_cost_86 > 0;
  _338 = _340 & _341;
  if (_338 != 0)
goto ;
  else
goto ;

the guard could be written as

  red_cost != 0 && arc->ident == 1 + (red_cost > 0)

before if-combine we see

  red_cost_86 = _27 + _29;
  if (red_cost_86 < 0)
goto ;
  else
goto ;

  :
  if (_23 == 1)
goto ;
  else
goto ;

  :
  if (red_cost_86 > 0)
goto ;
  else
goto ;

  :
  if (_23 == 2)
goto ;
  else
goto ;

[Bug c++/78249] In consistent results for 0.0 * inf when optimizer is enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
libstdc++ uses __builtin_huge_val().  On trunk I see some changes but CCP still
folds __builtin_huge_val () * 0.0 to -NaN.

[Bug c++/78249] In consistent results for 0.0 * inf when optimizer is enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-08
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
#include 

double x = 0.0 * std::numeric_limits::infinity();

get's me

x:
.long   0
.long   2146959360

independent of optimization level.  But I can confirm the findings for

#include 
#include 
double y = 0.0 * std::numeric_limits::infinity();
int main() {
double x = 0.0 * std::numeric_limits::infinity();
std::cout << "CPP runtime: " << x << std::endl;
std::cout << "CPP compile-time: " << y << std::endl;
}

which evaluates 0.0 * std::numeric_limits::infinity() at runtime via

  4008fe:   e8 9f 00 00 00  callq  4009a2
<_ZNSt14numeric_limitsIdE8
infinityEv>
  400903:   66 0f 28 c8 movapd %xmm0,%xmm1
  400907:   66 0f ef c0 pxor   %xmm0,%xmm0
  40090b:   f2 0f 59 c1 mulsd  %xmm1,%xmm0

where with optimization we simplify it to +NaN (at compile-time).

[Bug rtl-optimization/78200] [7 Regression] 429.mcf of cpu2006 regresses in GCC trunk for avx2 target.

[venkataramanan.kumar at amd dot com]

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

--- Comment #7 from Venkataramanan  ---
Bisecting shows non canonical gimple generation at r238370.

--snip--
commit f3dce1cdd016e16cf9dc051d127bdf6eb58430fc
Author: rguenth 
Date:   Fri Jul 15 10:53:29 2016 +

2016-07-15  Richard Biener  

* tree-ssa-pre.c (get_representative_for): Make sure to return
the value number of SSA names.
(phi_translate_1): get_representative_for cannot return NULL.
(do_pre_regular_insertion): Remove redundant call to
fully_constant_expression.
(do_pre_partial_partial_insertion): Likewise.


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

r238370 test.c.148t.ifcvt
;;   basic block 30, loop depth 1, count 0, freq 407, maybe hot
;;prev block 29, next block 31, flags: (NEW, REACHABLE)
;;pred:   28 [64.0%]  (FALSE_VALUE,EXECUTABLE)
  _71 = _109 == 2;
  _15 = if_conversion_var_108 > 0;
  _70 = _71 & _15;
  if (_70 != 0)
goto ;
  else
goto ;


r238369 test.c.148t.ifcvt

  ;;   basic block 30, loop depth 1, count 0, freq 407, maybe hot
;;prev block 29, next block 31, flags: (NEW, REACHABLE)
;;pred:   28 [64.0%]  (FALSE_VALUE,EXECUTABLE)
  _26 = _73 == 2;
  _38 = if_conversion_var_72 > 0;
  _86 = _26 & _38;
  if (_86 != 0)
goto ;
  else
goto ;
;;succ:   31 [34.0%]  (TRUE_VALUE,EXECUTABLE)
;;32 [66.0%]  (FALSE_VALUE,EXECUTABLE)

[Bug c++/78193] [7 regression] g++.dg/concepts/inherit-ctor3.C etc. FAIL at r241765

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-08
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
This looks related to the ABI and was introduced by:

r241765 | jason | 2016-11-02 02:50:29 +0100 (Wed, 02 Nov 2016) | 53 lines

Implement P0136R1, Rewording inheriting constructors.

[Bug other/78250] Gcc 6 bootstrap failure

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Yep, usually this happens when a configure test ICEs

[Bug target/78007] Important loop from 482.sphinx3 is not vectorized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

[Bug target/78007] Important loop from 482.sphinx3 is not vectorized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #39827|0   |1
is obsolete||

--- Comment #5 from Richard Biener  ---
Created attachment 39990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39990=edit
patch I am testing

[Bug fortran/65173] ICE while compiling wrong code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
> All of these ICEs are now gone with r238822.

On darwin, I still get an ICE for the test in comment 0. For the other tests I
get non-deterministic ICEs: for the test in comment 2 I get

pr65173_1.f90:3:55:

  character(1), dimension(256), allocatable :: names
   1
Error: Allocatable component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault: 11

or

pr65173_1.f90:3:55:

  character(1), dimension(256), allocatable :: names
   1
Error: Allocatable component of structure at (1) must have a deferred shape
pr65173_1.f90:3:55:

  character(1), dimension(256), allocatable :: names
   1
Error: Character length of component 'names' needs to be a constant
specification expression at (1)

I have traced the problem to

   13476 if (c->ts.u.cl->length == NULL
   13477 || (!resolve_charlen(c->ts.u.cl))
-> 13478 || !gfc_is_constant_expr (c->ts.u.cl->length))

in resolve.c. The ICEs occur when c->ts.u.cl->length != NULL, the ICE occurs in
gfc_is_constant_expr in expr.c at

-> 899switch (e->expr_type)

It seems that c->ts.u.cl->length is not properly set to NULL.

[Bug other/78250] Gcc 6 bootstrap failure

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

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

--- Comment #1 from Andreas Schwab  ---
You should have "#define HAVE_DECL_BASENAME 1" in gcc/auto-host.h.

[Bug libfortran/51119] MATMUL slow for large matrices

[tkoenig at gcc dot gnu.org]

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

--- Comment #38 from Thomas Koenig  ---
(In reply to Joost VandeVondele from comment #37)
> (In reply to Joost VandeVondele from comment #36)
> > #pragma GCC optimize ( "-Ofast -fvariable-expansion-in-unroller
> > -funroll-loops" )
> 
> and really beneficial for larger matrices would be 
> 
> -floop-nest-optimize
> 
> in particular the blocking (it would be an additional motivation for PR14741
> and work on graphite in general), don't know if one can give the parameter
> for the blocking. In principle the loop-nest-optimization, together with the
> -Ofast (and ideally -march=native, which we can't have in libgfortran, I
> assume) would yield near peak performance.

The algorithm that Jerry implemented already has a very nice unrolling/
blocking algorithm.  I doubt that the gcc algorithms can add to that.

Regarding -march=native, that could really be an improvement,
especially with -mavx.  I wonder if it is possible to have
architecture-specific versions of library functions?  We could
select the right routine depending on the -march flag.  Worth
a question on the gcc list, probably (but definitely _not_ a
prerequisite for this going into gcc 7).

Of course, we _could_ also try to bring blocking to the inline
version (PR 66189), risking insanity for the implementer :-)

Jerry, what Netlib code were you basing your code on?

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #25 from Rainer Orth  ---
Created attachment 39989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39989=edit
sparc bb-slp-1.c.160t.slp1

It seems your latest patch has caused a couple of regressions on SPARC: on
sparc-sun-solaris2.12 I see

+FAIL: gcc.dg/vect/bb-slp-1.c -flto -ffat-lto-objects  scan-tree-dump-times
slp1
 "basic block vectorized" 1
+FAIL: gcc.dg/vect/bb-slp-1.c scan-tree-dump-times slp1 "basic block
vectorized"
 1
+FAIL: gcc.dg/vect/bb-slp-16.c -flto -ffat-lto-objects  scan-tree-dump-times
slp
1 "basic block vectorized" 1
+FAIL: gcc.dg/vect/bb-slp-16.c scan-tree-dump-times slp1 "basic block
vectorized
" 1
+FAIL: gcc.dg/vect/bb-slp-2.c -flto -ffat-lto-objects  scan-tree-dump-times
slp1
 "basic block vectorized" 1
+FAIL: gcc.dg/vect/bb-slp-2.c scan-tree-dump-times slp1 "basic block
vectorized"
 1

for both 32 and 64-bit.

  Rainer

[Bug other/78250] New: Gcc 6 bootstrap failure

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 78250
   Summary: Gcc 6 bootstrap failure
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: s390
Target: s390
 Build: s390

Gcc-6 (rev 241836) does not bootstrap on s390 (31-bit system) because of many
warnings/errors generated by differing prototypes from header files.  One
example:

--
In file included from ~/src/gcc/gcc/system.h:685:0,
 from ~/src/gcc/gcc/genenums.c:21:
~/src/gcc/gcc/../include/libiberty.h:112:14: error: ambiguating new declaration
of 'char* basename(const char*)'
 extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL
ATTRIBUTE_NONNULL(1);
  ^~~~
In file included from
~/src/gcc/build-regtest-dc-gcc6-fix-extzv-1_0-1478598183-s390-default/prev-s390-ibm-linux-gnu/libstdc++-v3/include/cstring:42:0,
 from ~/src/gcc/gcc/system.h:235,
 from ~/src/gcc/gcc/genenums.c:21:
/usr/include/string.h:597:26: note: old declaration 'const char* basename(const
char*)'
 extern "C++" const char *basename (const char *__filename)
  ^~~~
--

[Bug libfortran/51119] MATMUL slow for large matrices

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #37 from Joost VandeVondele  
---
(In reply to Joost VandeVondele from comment #36)
> #pragma GCC optimize ( "-Ofast -fvariable-expansion-in-unroller
> -funroll-loops" )

and really beneficial for larger matrices would be 

-floop-nest-optimize

in particular the blocking (it would be an additional motivation for PR14741
and work on graphite in general), don't know if one can give the parameter for
the blocking. In principle the loop-nest-optimization, together with the -Ofast
(and ideally -march=native, which we can't have in libgfortran, I assume) would
yield near peak performance.

[Bug c++/78249] In consistent results for 0.0 * inf when optimizer is enabled

[joshua.england at worldprogramming dot com]

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

--- Comment #1 from Joshua England  
---
[je@josh-fedora tmp]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.1.1 20160621 (Red Hat 6.1.1-3) (GCC)

[Bug c++/78249] New: In consistent results for 0.0 * inf when optimizer is enabled

[joshua.england at worldprogramming dot com]

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

Bug ID: 78249
   Summary: In consistent results for 0.0 * inf when optimizer is
enabled
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joshua.england at worldprogramming dot com
  Target Milestone: ---

Created attachment 39988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39988=edit
Code and make file to show the bug

The following code gives -NAN when not optimized and NAN when optimized (note
the change in sign).

double x = 0.0 * std::numeric_limits::infinity();

The attachment contains FORTRAN code as the project I am working on requires
linking to FORTRAN code. I discovered the problem because of inconsistent
results between the output from GFORTRAN and G++ give similar code.

[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Same for me, I also tested the same revision.