[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #5 from Alexandre Oliva  ---
The problem is that, in the presence of a template-dependent USING_DECL,
overloaded functions are dropped from the bindings and from lookup results: we
get only the USING_DECL in the value binding, and from the absence of template
functions in an overload set, we decide the looked up name cannot be a template
function in cp_parser_template_name.

[Bug c++/87539] [8/9 Regression] internal compiler error when compiling project with Os optimization flag

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 29 07:42:52 2018
New Revision: 266611

URL: https://gcc.gnu.org/viewcvs?rev=266611&root=gcc&view=rev
Log:
PR c++/87539
* g++.dg/cpp0x/pr87539.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr87539.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/88256] New: [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn)

[asolokha at gmx dot com]

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

Bug ID: 88256
   Summary: [7/8/9 Regression] ICE: Segmentation fault (in
make_ssa_name_fn)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-9.0.0-alpha20181125 snapshot (r266441), 8.2, 7.3 ICE when compiling
gcc/testsuite/gcc.c-torture/compile/pr84305.c at any optimization level w/
-fipa-cp:

% g++-9.0.0-alpha20181125 -O1 -fipa-cp -c
gcc/testsuite/gcc.c-torture/compile/pr84305.c
during IPA pass: materialize-all-clones
gcc/testsuite/gcc.c-torture/compile/pr84305.c: In function 'void f2(int)':
gcc/testsuite/gcc.c-torture/compile/pr84305.c:4:26: internal compiler error:
Segmentation fault
4 | void f1 (void) { f2 (a); }
  |  ^
0xf07ebf crash_signal
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/toplev.c:326
0x11136c9 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-ssanames.c:268
0xf82a04 make_ssa_name
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-ssanames.h:114
0xf82a04 remap_ssa_name
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:245
0xf87d97 copy_tree_body_r(tree_node**, int*, void*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:1118
0x11b5782 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree.c:11892
0x11b5ead walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree.c:12214
0x11b5ead walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree.c:12214
0xf820e5 remap_type_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:578
0xf81021 remap_type(tree_node*, copy_body_data*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:607
0xf8914b remap_gimple_op_r
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:999
0x11b5782 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree.c:11892
0x11b5ead walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree.c:12214
0x11b5ead walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree.c:12214
0xc8ca3d walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/gimple-walk.c:202
0xf83541 remap_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:1778
0xf84536 copy_bb
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:1828
0xf85ddd copy_cfg_body
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:2720
0xf85ddd copy_body
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:2962
0xf8e3ea tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-inline.c:5994

[Bug c++/88258] New: [9 Regression] Infinite loop emitting diagnostics in the C++ front-end

[asolokha at gmx dot com]

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

Bug ID: 88258
   Summary: [9 Regression] Infinite loop emitting diagnostics in
the C++ front-end
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20181125 snapshot (r266441) enters infinite loop when compiling
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c w/ -fopenmp:

% timeout 0.0072 g++-9.0.0-alpha20181125 -fopenmp -c
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c: In function 'void f1()':
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:8:3: error: '_Atomic' was not declared in
this scope
8 |   _Atomic int i = 0, k[4];
  |   ^~~
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:10:3: error: 'k' was not declared in this
scope
   10 |   k[0] = 0;
  |   ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:14:37: error: 'i' has not been declared
   14 |   #pragma omp parallel reduction (+:i)  /* { dg-error "'_Atomic' 'i' in
'reduction' clause" } */
  | ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:15:5: error: 'i' was not declared in this
scope
   15 | i++;
  | ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:16:39: error: '_Atomic' does not name a
type
   16 |   #pragma omp declare reduction (foo: _Atomic int: omp_out += omp_in)
initializer (omp_priv = omp_orig * 0) /* { dg-error "'_Atomic' qualified type
in '#pragma omp declare reduction'" } */
  |   ^~~
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:16:46: error: expected ':' before 'int'
   16 |   #pragma omp declare reduction (foo: _Atomic int: omp_out += omp_in)
initializer (omp_priv = omp_orig * 0) /* { dg-error "'_Atomic' qualified type
in '#pragma omp declare reduction'" } */
  |  ^~~~
  |  :
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:20:39: error: 'i' has not been declared
   20 |   #pragma omp parallel reduction (bar:i) /* { dg-error "'_Atomic' 'i'
in 'reduction' clause" } */
  |   ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:21:5: error: 'i' was not declared in this
scope
   21 | i++;
  | ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c: At global scope:
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:29:18: error: expected ',' or '...'
before 'p'
   29 | f2 (int *_Atomic p)
  |  ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c: In function 'void f2(int*)':
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:31:29: error: 'p' has not been declared
   31 |   #pragma omp simd aligned (p : 16)  /* { dg-error "'_Atomic' 'p' in
'aligned' clause" } */
  | ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:33:5: error: 'p' was not declared in this
scope
   33 | p[i]++;
  | ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c: At global scope:
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:36:1: error: '_Atomic' does not name a
type
   36 | _Atomic int x;
  | ^~~
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:39:13: error: variable or field 'f3'
declared void
   39 | f3 (_Atomic int *p)
  | ^~~
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:39:5: error: '_Atomic' was not declared
in this scope
   39 | f3 (_Atomic int *p)
  | ^~~
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:42:27: error: expected unqualified-id
before end of line
   42 |   #pragma omp atomic write
  |   ^
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:42:27: error: expected unqualified-id
before end of line
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:42:27: error: expected unqualified-id
before end of line
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:42:27: error: expected unqualified-id
before end of line
gcc/testsuite/gcc.dg/gomp/_Atomic-3.c:42:27: error: expected unqualified-id
before end of line

<…>

Program received signal SIGINT, Interrupt.
0x77ada988 in write () from /lib64/libc.so.6
(gdb) where
#0  0x77ada988 in write () from /lib64/libc.so.6
#1  0x77a70d0d in _IO_file_write () from /lib64/libc.so.6
#2  0x77a6ff83 in new_do_write () from /lib64/libc.so.6
#3  0x77a7154e in _IO_file_xsputn () from /lib64/libc.so.6
#4  0x77a63c15 in fputs () from /lib64/libc.so.6
#5  0x0183d0e4 in pp_write_text_to_stream (pp=pp@entry=0x247dbc0)
at
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/pretty-print.c:840
#6  0x0183d169 in pp_flush (pp=0x247dbc0)
at
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/pretty-print.c:1467
#7  pp_flush (pp=0x247dbc0) at
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/pretty-print.c:1462
#8  0x01829e8a in diagnostic_report_diagnostic (context

[Bug preprocessor/88257] New: [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842

[asolokha at gmx dot com]

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

Bug ID: 88257
   Summary: [9 Regression] ICE in
linemap_position_for_line_and_column, at
libcpp/line-map.c:842
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20181125 snapshot (r266441) ICEs when compiling
gcc/testsuite/gcc.dg/format/pr78304.c w/ -Wformat:

% g++-9.0.0-alpha20181125 -Wformat -c gcc/testsuite/gcc.dg/format/pr78304.c 
gcc/testsuite/gcc.dg/format/pr78304.c: In function 'void test(const char*)':
gcc/testsuite/gcc.dg/format/pr78304.c:9:37: internal compiler error: in
linemap_position_for_line_and_column, at libcpp/line-map.c:842
9 |   printf ("size: %" PRIu32 "\n", msg); /* { dg-warning "expects
argument of type" } */
  | ^
0x18631a5 linemap_position_for_line_and_column(line_maps*, line_map_ordinary
const*, unsigned int, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/libcpp/line-map.c:842
0x18631a5 linemap_position_for_line_and_column(line_maps*, line_map_ordinary
const*, unsigned int, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/libcpp/line-map.c:837
0x1844d06 get_substring_ranges_for_loc
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/input.c:1437
0x18455fb get_location_within_string(cpp_reader*, string_concat_db*, unsigned
int, cpp_ttype, int, int, int, unsigned int*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/input.c:1490
0xa17d26 c_get_substring_location(substring_loc const&, unsigned int*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-common.c:879
0xa4e2c5 get_corrected_substring
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:3503
0xa4e2c5 format_type_warning
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:3718
0xa4f855 check_format_types
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:3262
0xa4f855 argument_parser::check_argument_type(format_char_info const*,
length_modifier const&, tree_node*&, char const*&, bool, unsigned long&,
tree_node*&, int, char const*, char const*, unsigned int, char)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:2776
0xa52f70 argument_parser::check_argument_type(format_char_info const*,
length_modifier const&, tree_node*&, char const*&, bool, unsigned long&,
tree_node*&, int, char const*, char const*, unsigned int, char)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:2671
0xa52f70 check_format_info_main
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:2988
0xa52f70 check_format_arg
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:1740
0xa503ff check_format_info
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:1463
0xa503ff check_function_format(tree_node const*, tree_node*, int, tree_node**,
vec*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-format.c:1120
0xa41be1 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/c-family/c-common.c:5675
0x823f64 build_over_call
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cp/call.c:8263
0x8314ac build_new_function_call(tree_node*, vec**, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cp/call.c:4407
0x9be30d finish_call_expr(tree_node*, vec**, bool,
bool, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cp/semantics.c:2560
0x93a578 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cp/parser.c:7300
0x948609 cp_parser_unary_expression
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cp/parser.c:8382

[Bug target/88255] New: Thumb-1: GCC too aggressive on mul->lsl/sub/add optimization

[husseydevin at gmail dot com]

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

Bug ID: 88255
   Summary: Thumb-1: GCC too aggressive on mul->lsl/sub/add
optimization
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: husseydevin at gmail dot com
  Target Milestone: ---

I might be wrong, but it appears that GCC is too aggressive in its conversion
from multiplication to shift+add when targeting Thumb-1

It is true that, for example, the Cortex-M0 can have the small multiplier and a
16 cycle shift sequence would be faster. However, I was targeting arm7tdmi
(-march=armv4t -mthumb -O3 -mtune=arm7tdmi) which, if I am not mistaken, uses
one cycle for every 8 bits.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0234b/i102180.html

However, looking in the source code, I notice that the loop is dividing by 4. I
think it might be a bug that is causing the otherwise 7 (I think) cycle
sequence in the code below to be considered as having a weight of 18 cycles.

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/arm/arm.c#L8959

I could be wrong, but one of the things I noticed is that very old versions of
GCC (2.95) will not perform this many shifts, and that Clang, when given the 
transpiled output in C and targeted for the same platform, will actually
convert it back into a ldr/mul.

However, when targeting cortex-m0plus.small-multiply, it will still turn it
into multiplication.

Code example: 

  unsigned MultiplyByPrime(unsigned val)
  {
  return val * 2246822519U;
  }

  MultiplyByPrime:
 lslsr3, r0, #7 @ unsigned ret = val << 7;
 subsr3, r3, r0 @ ret -= val;
 lslsr3, r3, #5 @ ret <<= 5;
 subsr3, r3, r0 @ ret -= val;
 lslsr3, r3, #2 @ ret <<= 2;
 addsr3, r3, r0 @ ret += val;
 lslsr2, r3, #3 @ unsigned tmp = ret << 3;
 addsr3, r3, r2 @ ret += tmp;
 lslsr3, r3, #1 @ ret <<= 1;
 addsr3, r3, r0 @ ret += val;
 lslsr3, r3, #6 @ ret <<= 6;
 addsr3, r3, r0 @ ret += val;
 lslsr2, r3, #4 @ tmp = ret << 4;
 subsr3, r2, r3 @ ret = tmp - ret;
 lslsr3, r3, #3 @ ret <<= 3;
 subsr0, r3, r0 @ ret -= val;
 bx  lr @ return ret;

[Bug rtl-optimization/85899] ICE in find_fallthru_edge_from, at haifa-sched.c:8059

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
gcc/testsuite/gcc.dg/vect/vect-cond-4.c does not need autopar:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181125 -O1 -fschedule-insns
-fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
-fselective-scheduling -funroll-all-loops -fno-section-anchors -fno-tree-ch
-fno-tree-dominator-opts --param max-completely-peeled-insns=52 --param
max-unrolled-insns=29 -c gcc/testsuite/gcc.dg/vect/vect-cond-4.c
during RTL pass: sched1
gcc/testsuite/gcc.dg/vect/vect-cond-4.c: In function 'foo':
gcc/testsuite/gcc.dg/vect/vect-cond-4.c:37:1: internal compiler error: in
find_fallthru_edge_from, at haifa-sched.c:8085
   37 | }
  | ^
0x7462ba find_fallthru_edge_from(basic_block_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/haifa-sched.c:8085
0xcde34f in_fallthru_bb_p
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sel-sched.c:608
0xcde34f extract_new_fences_from
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sel-sched.c:680
0xcde34f calculate_new_fences
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sel-sched.c:7429
0xcde34f sel_sched_region_2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sel-sched.c:7505
0xcde892 sel_sched_region_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sel-sched.c:7546
0xcdf17e sel_sched_region(int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sel-sched.c:7647
0xce01b9 run_selective_scheduling()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sel-sched.c:7733
0xcbeef4 rest_of_handle_sched
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sched-rgn.c:3718
0xcbeef4 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/sched-rgn.c:3828

[Bug fortran/88254] New: Support construct name for CHANGE TEAM & END TEAM

[weeks at iastate dot edu]

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

Bug ID: 88254
   Summary: Support construct name for CHANGE TEAM & END TEAM
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weeks at iastate dot edu
  Target Milestone: ---

The Fortran 2018 CHANGE TEAM and END TEAM statements should support a construct
name. Support is current lacking in gfortran 8.2.0; see the example below (and
also example C.6.8 from the N2146 draft of the Fortran 2018 standard).

===
$ cat team_construct_name.f90
program test_team_construct_name
   use, intrinsic :: iso_fortran_env, only: team_type
   implicit none

   type(team_type) :: team

   form team (1, team)

   team_construct_name: change team(team)
  if (.true.) exit team_construct_name
  error stop 'fail'
   end team team_construct_name

   write(*,*) 'pass'
end program
$ gfortran-mp-8 team_construct_name.f90
team_construct_name.f90:9:3:

team_construct_name: change team(team)
   1
Error: Unclassifiable statement at (1)
team_construct_name.f90:10:42:

   if (.true.) exit team_construct_name
  1
Error: Name 'team_construct_name' in EXIT statement at (1) is unknown
team_construct_name.f90:12:12:

end team team_construct_name
1
Error: Unclassifiable statement at (1)
$ gfortran-mp-8 -v 
Using built-in specs.
COLLECT_GCC=gfortran-mp-8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin17/8.2.0/lto-wrapper
Target: x86_64-apple-darwin17
Configured with:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc8/gcc8/work/gcc-8.2.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin17
--enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc8
--includedir=/opt/local/include/gcc8 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-8
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-8 --with-gxx-include-dir=/opt/local/include/gcc8/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--disable-tls --with-pkgversion='MacPorts gcc8 8.2.0_3'
Thread model: posix
gcc version 8.2.0 (MacPorts gcc8 8.2.0_3)
===

[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu Nov 29 00:39:37 2018
New Revision: 266598

URL: https://gcc.gnu.org/viewcvs?rev=266598&root=gcc&view=rev
Log:
PR libstdc++/86910 fix filesystem::create_directories

Implement the proposed semantics from P1164R0, which reverts the changes
of LWG 2935. This means that failure to create a directory because a
non-directory already exists with that name will be reported as an
error.

While rewriting the function, also fix PR 87846, which is a result of
the C++17 changes to how a trailing slash on a path affects the last
component of a path.

PR libstdc++/86910
PR libstdc++/87846
* src/filesystem/ops.cc (experimental::create_directories): Report
an error when the path resolves to an existing non-directory (P1164).
* src/filesystem/std-ops.cc (create_directories): Likewise. Handle
empty filenames due to trailing slashes.
* testsuite/27_io/filesystem/operations/create_directories.cc: Test
when some component of the path exists and is not a directory. Test
trailing slashes.
* testsuite/experimental/filesystem/operations/create_directories.cc:
Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/ops.cc
trunk/libstdc++-v3/src/filesystem/std-ops.cc
   
trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/create_directories.cc
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/operations/create_directories.cc

[Bug libstdc++/87846] std::filesystem::create_directories with a path with a trailing slash does not create any directory

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Nov 29 00:39:37 2018
New Revision: 266598

URL: https://gcc.gnu.org/viewcvs?rev=266598&root=gcc&view=rev
Log:
PR libstdc++/86910 fix filesystem::create_directories

Implement the proposed semantics from P1164R0, which reverts the changes
of LWG 2935. This means that failure to create a directory because a
non-directory already exists with that name will be reported as an
error.

While rewriting the function, also fix PR 87846, which is a result of
the C++17 changes to how a trailing slash on a path affects the last
component of a path.

PR libstdc++/86910
PR libstdc++/87846
* src/filesystem/ops.cc (experimental::create_directories): Report
an error when the path resolves to an existing non-directory (P1164).
* src/filesystem/std-ops.cc (create_directories): Likewise. Handle
empty filenames due to trailing slashes.
* testsuite/27_io/filesystem/operations/create_directories.cc: Test
when some component of the path exists and is not a directory. Test
trailing slashes.
* testsuite/experimental/filesystem/operations/create_directories.cc:
Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/ops.cc
trunk/libstdc++-v3/src/filesystem/std-ops.cc
   
trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/create_directories.cc
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/operations/create_directories.cc

[Bug target/88096] wrong inline AVX512F optimization

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #1 from Andi Kleen  ---
Can you please attach a pre-processed test case of a file that shows the bug?

It's ok if it doesn't run, as long as the problem is clearly identified in the
assembler.

Then the test case could be likely minimized.

[Bug rtl-optimization/88253] New: Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc

[westfw at westfw dot info]

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

Bug ID: 88253
   Summary: Inlining of function incorrectly deletes volatile
register access when using XOR in avr-gcc
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: westfw at westfw dot info
  Target Milestone: ---

Created attachment 45116
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45116&action=edit
.i pre-processed file from --keep-temps

Using avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_495) 5.4.0
(bug also occurs in avr-gcc 4.9 and 8.1; does NOT occur in 4.8.1)

A rather trivial C program:

#include 
uint16_t aRead() {
uint8_t h;
uint8_t l;
l = ADCL;
h = ADCH;
return (h<<8) | l;
}

int main() {
volatile uint8_t x;
x = aRead()^42;
}

only reads ADCL when aRead() is inlined from main; the read of (volatile) ADCH
is apparently removed by an optimization step, which breaks things because that
read has side-effects at the hardware level.

 :
   0:   cf 93   pushr28
   2:   df 93   pushr29
   4:   1f 92   pushr1
   6:   cd b7   in  r28, 0x3d   ; 61
   8:   de b7   in  r29, 0x3e   ; 62
   a:   80 91 78 00 lds r24, 0x0078 ; 0x800078 <__SREG__+0x800039>
   e:   9a e2   ldi r25, 0x2A   ; 42
  10:   89 27   eor r24, r25
  12:   89 83   std Y+1, r24; 0x01

This seems to happen during or slightly before the .combine pass of
optimization; the ud_dce output dump shows both volatile accesses, and the
combine has only one.   Does not happen using inclusive-OR, or a plain store.
(yes, I know that the value of ADCH that is read is never actually used.  But
it's volatile, and has side effects, and should be read.)

General compiler command: "avr-gcc -O3 -g adctest.i"
Seems to occur regardless of the reason for inlining - happens with "-Os -fto"
or with -Os and the always_inline attribute specified.

Some discussion at
https://www.avrfreaks.net/forum/avr-gcc-optimization-xor-incorrectly-eliminates-volatile-access

[Bug c++/88103] [7/8/9 Regression] Wrong value category when conditional expression result is used as object expression

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Possibly unrelated, but PR 67795 is another example where ?: has the wrong
value category depending on where it is used (cast vs return).

>From my comment in https://gcc.gnu.org/ml/gcc-patches/2013-07/msg00234.html ,
we were still not implementing the full standard rules after my patch, I don't
know if that happened since. Still, I am surprised if my patch caused those
errors.

[Bug c/88065] [9 Regression] ICE in -Wsizeof-pointer-memaccess on an invalid strncpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r266594.

[Bug c/87297] [9 Regression] ICE on strncpy with an undeclared argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r266594.

[Bug c/87297] [9 Regression] ICE on strncpy with an undeclared argument

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Nov 28 23:04:09 2018
New Revision: 266594

URL: https://gcc.gnu.org/viewcvs?rev=266594&root=gcc&view=rev
Log:
PR c/88065 - ICE in -Wsizeof-pointer-memaccess on an invalid strncpy
PR c/87297 - ICE on strncpy with an undeclared argument

gcc/c-family/ChangeLog:

PR c/88065
PR c/87297
* c-warn.c (sizeof_pointer_memaccess_warning): Bail if source
or destination is an error.

gcc/testsuite/ChangeLog:

PR c/88065
PR c/87297
* c-c++-common/Wsizeof-pointer-memaccess4.c: New test.



Added:
trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess4.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/testsuite/ChangeLog

[Bug c/88065] [9 Regression] ICE in -Wsizeof-pointer-memaccess on an invalid strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Nov 28 23:04:09 2018
New Revision: 266594

URL: https://gcc.gnu.org/viewcvs?rev=266594&root=gcc&view=rev
Log:
PR c/88065 - ICE in -Wsizeof-pointer-memaccess on an invalid strncpy
PR c/87297 - ICE on strncpy with an undeclared argument

gcc/c-family/ChangeLog:

PR c/88065
PR c/87297
* c-warn.c (sizeof_pointer_memaccess_warning): Bail if source
or destination is an error.

gcc/testsuite/ChangeLog:

PR c/88065
PR c/87297
* c-c++-common/Wsizeof-pointer-memaccess4.c: New test.



Added:
trunk/gcc/testsuite/c-c++-common/Wsizeof-pointer-memaccess4.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87937] [8 Regression] LHS reallocation broken inside "select type" and "associate"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

  Known to work||8.2.0, 9.0
Summary|[8/9 Regression] LHS|[8 Regression] LHS
   |reallocation broken inside  |reallocation broken inside
   |"select type" and   |"select type" and
   |"associate" |"associate"
  Known to fail|8.2.0   |8.2.1

--- Comment #14 from Dominique d'Humieres  ---
> Backporting r264725 on top of the current gcc-8 branch fixes the issue for me.

I changed the summary that the problem is fixed on trunk.

[Bug d/87816] D runtime fails to build on aarch64

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Last library fixes were merged in r266572.

However it is still required to enable always building libphobos when
--enable-languages=d on aarch64-linux.

[Bug c++/87531] [8/9 Regression] assignment operator does nothing if performed as a call via operator=

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov 28 21:25:06 2018
New Revision: 266590

URL: https://gcc.gnu.org/viewcvs?rev=266590&root=gcc&view=rev
Log:
[PR c++/87531] operator= lookup in templates

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02301.html
PR c++/87531
* class.c (finish_struct): In a template, add artificial using
decl for operator=.

* g++.dg/lookup/pr87531.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr87531.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/87846] std::filesystem::create_directories with a path with a trailing slash does not create any directory

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The implementation of create_directories worked for the Filesystem TS but I
didn't update it to cope with the different C++17 semantics for a trailing
slash. The empty filename at the end of the path confused the function into
thinking it didn't need to create anything.

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

[trnka at scm dot com]

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

--- Comment #13 from Tomáš Trnka  ---
(In reply to Dominique d'Humieres from comment #12)
> I finally got it: the problem has been introduced in trunk by revision
> r264358 and fixed by r264725.

Good catch! (How could I have missed that?)

Backporting r264725 on top of the current gcc-8 branch fixes the issue for me.
Thanks!

[Bug middle-end/88251] -Wformat-truncation=2 false alarms when compiling gzip, Emacs

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The warning can also be avoided by using the snprintf return value and taking
some action based on it (just returning it from a function isn't enough).

[Bug target/88207] [9 regression] gcc.target/i386/pr22076.c etc. FAIL

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Nov 28 20:08:03 2018
New Revision: 266582

URL: https://gcc.gnu.org/viewcvs?rev=266582&root=gcc&view=rev
Log:
2018-11-28  Vladimir Makarov  

PR target/88207
* ira-costs.c (scan_one_insn): Process subregs when updating costs
for pseudos and allocnos from insn.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c

[Bug middle-end/88251] -Wformat-truncation=2 false alarms when compiling gzip, Emacs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
The warning in this case is by design.  The test makes it clear that the buffer
can be as small as 2 bytes but the output is at least 15.  With
-Wformat-truncation=2 the buffer needs to be big enough for the longest output,
or 25 + 1 bytes.  This suppresses the warning:

  int
  rpl_strerror_r (int errnum, char *buf, size_t buflen)
  {
if (buflen <= 25)
  return 34;
return snprintf (buf, buflen, "Unknown error %d", errnum);
  }

[Bug c++/88222] [9 Regression] ubsan error at cp/decl.c for broken code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/88222] [9 Regression] ubsan error at cp/decl.c for broken code

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Nov 28 20:03:06 2018
New Revision: 266581

URL: https://gcc.gnu.org/viewcvs?rev=266581&root=gcc&view=rev
Log:
PR c++/88222 - ICE with bit-field with invalid type.
* decl.c (grokdeclarator): Check if declarator is null.

* g++.dg/ext/flexary31.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/flexary31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
I finally got it: the problem has been introduced in trunk by revision r264358
and fixed by r264725.

On the GCC8 branch the problem has been introduced by r264404 and AFAICT the
fix has not been back ported. If it helps I can try to apply the path in trunk
to my gcc8 build.

Note that the problem is not present in 8.2.0.

[Bug c++/88252] New: Deduction guide assume the constructor parameter is a forwarding reference if constructor defined outside class

[okannen at gmail dot com]

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

Bug ID: 88252
   Summary: Deduction guide assume the constructor parameter is a
forwarding reference if constructor defined outside
class
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okannen at gmail dot com
  Target Milestone: ---

Constructor parameter that have the forms of a forwarding reference (T&&)
inside a constructor are not forwarding reference if T is a parameter of the
class template. But gcc assumes it is a forwarding reference if the constructor
is defined outside the class:


template
struct B1 {
B1(T&& x){}
};

template
struct B2 {
B2(T&& x) ;
};
template
B2::B2(T&& x){}

int i;
B1 a{i};//Expect: compilation error, class template argument deduction failed
B2 b{i};//Unexpected: no compilation error.

[Bug middle-end/88251] New: -Wformat-truncation=2 false alarms when compiling gzip, Emacs

[eggert at cs dot ucla.edu]

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

Bug ID: 88251
   Summary: -Wformat-truncation=2 false alarms when compiling
gzip, Emacs
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

-Wformat-truncation can falsely report a buffer overflow in code that is trying
to be careful and catch overflows before they happen. Although this bug report
seems related to Bug#83431, strlen is not involved so it seems to be simpler or
lower-level than Bug#83431.

I ran into this problem when trying to compile an experimental version of
Emacs, and Jim Meyering ran into a similar problem when trying to build GNU
gzip .

I observed the problem in GCC 8.2.1 20181105 (Red Hat 8.2.1-5).

To reproduce the problem, use the command:

gcc -O2 -S -Wformat-truncation=2 strerror_r.i

to compile this program:

typedef unsigned long size_t;
extern int snprintf (char *__restrict, size_t,
 const char *__restrict __format, ...)
  __attribute__ ((__nothrow__))
  __attribute__ ((__format__ (__printf__, 3, 4)));
int
rpl_strerror_r (int errnum, char *buf, size_t buflen)
{
  if (buflen <= 1)
return 34;
  return snprintf (buf, buflen, "Unknown error %d", errnum);
}

GCC incorrectly reports a diagnostic, as follows.

strerror_r.i: In function ‘rpl_strerror_r’:
strerror_r.i:11:36: warning: ‘Unknown error ’ directive output truncated
writing 14 bytes into a region of size 2 [-Wformat-truncation=]
   return snprintf (buf, buflen, "Unknown error %d", errnum);
  ~~^~~~
strerror_r.i:11:10: note: ‘snprintf’ output between 16 and 26 bytes into a
destination of size 2
   return snprintf (buf, buflen, "Unknown error %d", errnum);
  ^~

Somehow GCC gets confused into thinking that buflen == 2 in the last printf
call. However, the correct assumption is that buflen >= 2.

[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[patrickdepinguin at gmail dot com]

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

--- Comment #8 from Thomas De Schampheleire  
---
To clarify the situation with underflow / denormal exception I will debug the
issue again and inspect the corresponding registers.

I'm not familiar with 'NaNs': is it a specific value that I can see in the
union variable? During debugging, the union value was '3'.

[Bug driver/47785] GCC with -flto does not pass -Wa options to the assembler

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #12 from Andrew Pinski  ---
*** Bug 88250 has been marked as a duplicate of this bug. ***

[Bug lto/88250] -flto doesn't preserve -Wa options

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 47785.

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

[Bug c++/83342] extern marked variable template with later definition emits error

[okannen at gmail dot com]

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

Olivier Kannengieser  changed:

   What|Removed |Added

 CC||okannen at gmail dot com

--- Comment #2 from Olivier Kannengieser  ---
Whit gcc 8.2, there is no more bug for constant template variables. But
compilation produces undefined symbol error at linking phase if variables
templates are non const:

template
extern T value4;
template
T value4= 0;

auto test4 = value4; //linking phase error: undefined symbol value4

template
extern T value5;
template
inline T value5=0;

auto test5 = value5; //linking phase error: undefined symbol value5


There are no error with Clang.

[Bug lto/88250] New: -flto doesn't preserve -Wa options

[hjl.tools at gmail dot com]

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

Bug ID: 88250
   Summary: -flto doesn't preserve -Wa options
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

[hjl@gnu-cfl-1 pr23929]$ cat y.c
float
foo (float x, float y)
{
  return y;
}
[hjl@gnu-cfl-1 pr23929]$ gcc -c y.c -Wa,-msse2avx
[hjl@gnu-cfl-1 pr23929]$ gcc -shared y.o
[hjl@gnu-cfl-1 pr23929]$ objdump --disassemble=foo a.out 

a.out: file format elf64-x86-64


Disassembly of section .init:

Disassembly of section .plt:

Disassembly of section .plt.got:

Disassembly of section .text:

10f9 :
10f9:   55  push   %rbp
10fa:   48 89 e5mov%rsp,%rbp
10fd:   c5 fa 11 45 fc  vmovss %xmm0,-0x4(%rbp)
1102:   c5 fa 11 4d f8  vmovss %xmm1,-0x8(%rbp)
1107:   c5 fa 10 45 f8  vmovss -0x8(%rbp),%xmm0
110c:   5d  pop%rbp
110d:   c3  retq   

Disassembly of section .fini:
[hjl@gnu-cfl-1 pr23929]$ gcc -c y.c -Wa,-msse2avx -flto
[hjl@gnu-cfl-1 pr23929]$ gcc -shared y.o -Wa,-msse2avx
[hjl@gnu-cfl-1 pr23929]$ objdump --disassemble=foo a.out 

a.out: file format elf64-x86-64


Disassembly of section .init:

Disassembly of section .plt:

Disassembly of section .plt.got:

Disassembly of section .text:

10f9 :
10f9:   55  push   %rbp
10fa:   48 89 e5mov%rsp,%rbp
10fd:   f3 0f 11 45 fc  movss  %xmm0,-0x4(%rbp)
1102:   f3 0f 11 4d f8  movss  %xmm1,-0x8(%rbp)
1107:   f3 0f 10 45 f8  movss  -0x8(%rbp),%xmm0
110c:   5d  pop%rbp
110d:   c3  retq   

Disassembly of section .fini:
[hjl@gnu-cfl-1 pr23929]$ 

-msse2avx is never passed to assembler with -flto.

[Bug rtl-optimization/88179] [9 regression][MIPS] pr84941.c ICE in lra_eliminate_reg_if_possible at lra-eliminations.c:1393 start with r266385

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Thank you for reporting this.  I am working on the PR.  I think the solution
will be ready on this week.

[Bug fortran/88249] New: ICE in gfc_resolve_filepos, at fortran/io.c:2853

[gs...@t-online.de]

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

Bug ID: 88249
   Summary: ICE in gfc_resolve_filepos, at fortran/io.c:2853
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With a missing file-unit-number, down to at least gcc-5 :


$ cat z1.f90
program p
   backspace (err=1)
   endfile (err=1)
   flush (err=1)
   rewind (err=1)
end


$ gfortran-9-20181125 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb2bcff crash_signal
../../gcc/toplev.c:326
0x63f696 gfc_resolve_filepos(gfc_filepos*)
../../gcc/fortran/io.c:2853
0x6850ab gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11547
0x68702f resolve_codes
../../gcc/fortran/resolve.c:16704
0x6870fe gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16739
0x674e87 resolve_all_program_units
../../gcc/fortran/parse.c:6064
0x674e87 gfc_parse_file()
../../gcc/fortran/parse.c:6314
0x6bdaff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/88248] [F18] Bogus warning about obsolescent feature: Labeled DO statement

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

For completeness, similar with outdated return labels :


$ cat z3.f90
program p
   do
  call sub (*98, *99)
   end do
98 continue
99 continue
end


$ gfortran-9-20181125 -c z3.f90 -std=f2008
z3.f90:3:24:

3 |   call sub (*98, *99)
  |1
Warning: Obsolescent feature: Alternate-return argument at (1)


$ gfortran-9-20181125 -c z3.f90 -std=f2018
z3.f90:3:24:

3 |   call sub (*98, *99)
  |1
Warning: Obsolescent feature: Alternate-return argument at (1)
z3.f90:5:2:

5 | 98 continue
  |  1
Warning: Fortran 2018 obsolescent feature: Labeled DO statement at (1)
z3.f90:6:2:

6 | 99 continue
  |  1
Warning: Fortran 2018 obsolescent feature: Labeled DO statement at (1)

[Bug fortran/88248] New: [F18] Bogus warning about obsolescent feature: Labeled DO statement

[gs...@t-online.de]

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

Bug ID: 88248
   Summary: [F18] Bogus warning about obsolescent feature: Labeled
DO statement
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Branching out via END=, ERR= or EOR= specifier in combination with
CONTINUE is interpreted as a labeled DO loop. Option -std=f2018 
misleadingly flags this with a warning -- (low prio).


$ cat z1.f90
program p
   do
  rewind (1, err=99)
   end do
99 continue
end


$ cat z2.f90
program p
   character(3) :: c = 'abc'
   integer :: k
   do k = 1, 10
  open (k, err=99)
  close (k, err=99)
  backspace (k, err=99)
  endfile (k, err=99)
  rewind (k, err=99)
  flush (k, err=99)
  inquire (k, err=99)
  read (k, '(a)', end=97) c
  read (k, '(a)', eor=98, advance='no') c
  read (k, '(a)', err=99) c
  write (k, '(a)', err=99) c
  wait (k, end=97)
  wait (k, eor=98)
  wait (k, err=99)
   end do
97 continue
98 continue
99 continue
end


$ gfortran-9-20181125 -c z1.f90 -std=f2008
$
$ gfortran-9-20181125 -c z1.f90 -std=f2018
z1.f90:5:2:

5 | 99 continue
  |  1
Warning: Fortran 2018 obsolescent feature: Labeled DO statement at (1)

[Bug fortran/88247] [8/9 Regression] ICE in get_array_ctor_var_strlen, at fortran/trans-array.c:2068

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

This variant compiles and works :


$ cat z2.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t), allocatable :: x
   x = t('abc')
   associate (y => x%c(:))
  print *, y
   end associate
end


$ gfortran-9-20181125 z2.f90 -static-libgfortran
$ a.out
 abc
$

[Bug fortran/88247] New: [8/9 Regression] ICE in get_array_ctor_var_strlen, at fortran/trans-array.c:2068

[gs...@t-online.de]

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

Bug ID: 88247
   Summary: [8/9 Regression] ICE in get_array_ctor_var_strlen, at
fortran/trans-array.c:2068
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects version 8/9, but also struggles with older versions :


$ cat z1.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t), allocatable :: x
   x = t('abc')
   associate (y => [x%c(:)])
  print *, y
   end associate
end


$ gfortran-7 -c z1.f90
$
$ gfortran-9-20181125 -c z1.f90
z1.f90:8:0:

8 |   print *, y
  |
internal compiler error: Segmentation fault
0xb2bcff crash_signal
../../gcc/toplev.c:326
0x6d32fe get_array_ctor_var_strlen
../../gcc/fortran/trans-array.c:2068
0x6d32fe get_array_ctor_strlen(stmtblock_t*, splay_tree_s*, tree_node**)
../../gcc/fortran/trans-array.c:2136
0x6d0e67 trans_array_constructor
../../gcc/fortran/trans-array.c:2473
0x6d0e67 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2835
0x6d16e5 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5129
0x6d1a9d gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-array.c:7310
0x7283cf trans_associate_var
../../gcc/fortran/trans-stmt.c:1717
0x72ec31 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2073
0x6c11b7 trans_code
../../gcc/fortran/trans.c:1918
0x6e88d4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x675026 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x675026 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bdaff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #4 from Peter Bergner  ---
Ok, so the fix is to not allow -mabi=ieeelongdouble without -mvsx & -mpopcntd. 
I'll prepare a patch to do that.

[Bug fortran/85953] [7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370

[gs...@t-online.de]

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

--- Comment #4 from G. Steinmetz  ---

Changed in gcc-9 between 20180916 (ICE) and 20180923 (ok).

$ gfortran-9-20181125 z1.f90 -static-libgfortran
$ a.out
 abc
$

[Bug target/54700] Optimize away x<0 as mask argument of a blend.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-28
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Jakub Jelinek  ---
Created attachment 45115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45115&action=edit
gcc9-pr54700.patch

Untested fix.

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
We should not allow -mabi=ieeelongdouble if we do not have the full ISA 2.06
(power7) instruction set (i.e. both -mpopcntd and -mvsx should be set).  It was
probably an oversight that I only checked for -mvsx.

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
Here's a much smaller C test case.  It seems we try and convert the SFmode var
into a KFmode var before converting it to an integer?!?!

Mike, does this look familiar to you?  Should KFmode even be supported if we've
disabled popcntd?

bergner@pike:~/gcc/BUGS/PR87496$ cat pr87496.c 
unsigned long
foo (float f)
{
  return f;
}
bergner@pike:~/gcc/BUGS/PR87496$
/home/bergner/gcc/build/gcc-fsf-mainline-pr87496-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr87496-debug/gcc -O2 -S
-mabi=ieeelongdouble -mno-popcntd pr87496.c 
cc1: warning: Using IEEE extended precision long double [-Wpsabi]
during RTL pass: expand
pr87496.c: In function ‘foo’:
pr87496.c:4:10: internal compiler error: Segmentation fault
4 |   return f;
  |  ^
0x1110517b crash_signal
/home/bergner/gcc/gcc-fsf-mainline-pr87496/gcc/toplev.c:326
0x109e52f0 aggregate_value_p(tree_node const*, tree_node const*)
/home/bergner/gcc/gcc-fsf-mainline-pr87496/gcc/function.c:2091
0x10652fa3 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
/home/bergner/gcc/gcc-fsf-mainline-pr87496/gcc/calls.c:4747
0x108d894b emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, rtx_def*, machine_mode)
/home/bergner/gcc/gcc-fsf-mainline-pr87496/gcc/rtl.h:4201
0x117edc13 rs6000_expand_float128_convert(rtx_def*, rtx_def*, bool)
   
/home/bergner/gcc/gcc-fsf-mainline-pr87496/gcc/config/rs6000/rs6000.c:21918

[Bug tree-optimization/88223] [8 Regression] Wrong code for intrinsic memmove

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com  ---
On Wed, 28 Nov 2018, rguenth at gcc dot gnu.org wrote:

> Hmm, OTOH the C standard specifies that the store to u.b.b makes it the
> u.b the active member and it makes the old contents undefined.  That
> would mean when loading u.a.b after the store we cannot rely on the
> exact value we get but at least the bits touched by u.b.b should be
> up-to-date (which is enough to show breakage).  I thought about
> using

In my view, storing to u.b.b should be equivalent to loading u.b (a 
type-punning operation if u.a was previously the active member), storing 
the new value of u.b.b in a copy of the loaded value of u.b, and storing 
that result back in u.b (making u.b the active member of u).  (So if bits 
set in u.a are not padding in u.b, and not part of the space occupied by 
u.b.b, they should be preserved.)

[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
As discussed, the load instructions should never raise underflow 
exceptions, and having traps enabled for the nonstandard denormal operand 
exception is clearly outside the scope of what code generation should 
support.  So the underflow exception being raised by a load seems like 
some kind of issue with the instruction implementation (but you should 
test the instruction directly on hardware without qemu involved).

*But* the issue definitely exists with loads of signaling NaNs converting 
them to quiet NaNs and raising "invalid", so modifying data (if the result 
gets stored back) as well as raising spurious exceptions.  See bug 58416 
(which as discussed there, is an issue even with -fno-signaling-nans, 
because it's perfectly valid to have the sNaN patterns in a union with 
-fno-signaling-nans if you don't actually access them as float/double).

So I think any bug here is a combination of a duplicate of bug 58416, 
possibly with some kind of qemu bug resulting in "underflow" being raised 
when "denormal operand" should actually be raised instead.

[Bug libstdc++/87846] std::filesystem::create_directories with a path with a trailing slash does not create any directory

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-28
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.3
 Ever confirmed|0   |1

[Bug libstdc++/83511] Missing default argument for basic_string_view::substr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.3

[Bug libstdc++/83511] Missing default argument for basic_string_view::substr

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/83306] filesystem_error is not nothrow copyable

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 28 17:07:22 2018
New Revision: 266569

URL: https://gcc.gnu.org/viewcvs?rev=266569&root=gcc&view=rev
Log:
Fix undefined references in libstdc++fs.a

The recent patch for PR 83306 removed the fs_err_concat functions that
were used by the experimental::filesystem::filesystem_error class as
well. This fixes it by doing the string generation directly in
filesystem_error::_M_gen_what() instead of using the removed function.

PR libstdc++/83306
* src/filesystem/path.cc (filesystem_error::_M_gen_what()): Create
string directly, instead of calling fs_err_concat.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/path.cc

[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-28
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Mine.

[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[patrickdepinguin at gmail dot com]

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

--- Comment #6 from Thomas De Schampheleire  
---
(In reply to Florian Weimer from comment #5)
> (In reply to Thomas De Schampheleire from comment #4)
> > When analyzing this problem with gdb, we looked at the floating-point status
> > register before the fldl call, then after, and only the underflow bit was
> > new. But there were already other bits present, we probably should have set
> > the register to 0 first. Nevertheless, the underflow bit got set.
> 
> This is QEMU with TCG, right?  It could be an i387 emulation bug.

I don't think so. Isn't it so that KVM and TCG are mutually exclusive choices?
We see the problem if we pass --enable-kvm and don't see the problem if we
don't pass that flag. From my limited understanding of qemu, not paying the
flag means that the default TCG emulation is used. Am I wrong?

[Bug middle-end/82918] No aliasing is possible on non equal pointers

[antoshkka at gmail dot com]

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

--- Comment #4 from Antony Polukhin  ---
Still rereads the value2.data[0] value in this sample:

struct array {
int data[3];
};

void foo2(array& value, const array& value2) {
value.data[1] = value2.data[0];
value.data[0] = value2.data[0];
value.data[2] = value2.data[0]; // Rereads here
}

[Bug libstdc++/83511] Missing default argument for basic_string_view::substr

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 28 16:53:35 2018
New Revision: 266568

URL: https://gcc.gnu.org/viewcvs?rev=266568&root=gcc&view=rev
Log:
PR libstdc++/83511 add default argument to basic_string_view::substr

PR libstdc++/83511
* include/std/string_view (basic_string_view::substr): Add default
argument to first parameter.
* include/experimental/string_view (basic_string_view::substr):
Likewise.
* testsuite/21_strings/basic_string_view/operations/substr/char/
83511.cc: New test.
* testsuite/21_strings/basic_string_view/operations/substr/wchar_t/
83511.cc: New test.
* testsuite/experimental/string_view/operations/substr/char/83511.cc:
New test.
*
testsuite/experimental/string_view/operations/substr/wchar_t/83511.cc:
New test.

Added:
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/substr/char/83511.cc
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/substr/wchar_t/83511.cc
   
trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/char/83511.cc
   
trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/wchar_t/83511.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/experimental/string_view
trunk/libstdc++-v3/include/std/string_view

[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
We still have:
   /* When not generating debug info we can eliminate info on unused
  variables.  */
   else if (!flag_auto_profile && debug_info_level == DINFO_LEVEL_NONE  
&& !optinfo_wants_inlining_info_p ())   

can we do better here?

[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Target||s390x-redhat-linux
   Priority|P3  |P1
 CC||marxin at gcc dot gnu.org
   Host||s390x-redhat-linux
  Build||s390x-redhat-linux

[Bug middle-end/88246] New: Abort signal terminated program collect2 - munmap_chunk(): invalid pointer

[krebbel at gcc dot gnu.org]

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

Bug ID: 88246
   Summary: Abort signal terminated program collect2 -
munmap_chunk(): invalid pointer
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

GCC build fails on s390x since r266508 with:

/home/andreas/bisect/gcc-266508-build/./gcc/xgcc
-B/home/andreas/bisect/gcc-266508-build/./gcc/
-B/home/andreas/bisect/gcc-266508-install/s390x-ibm-linux-gnu/bin/
-B/home/andreas/bisect/gcc-266508-install/s390x-ibm-linux-gnu/lib/ -isystem
/home/andreas/bisect/gcc-266508-install/s390x-ibm-linux-gnu/include -isystem
/home/andreas/bisect/gcc-266508-install/s390x-ibm-linux-gnu/sys-include  
-fno-checking -O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
-Wl,--version-script=libgcc.map -o 32/libgcc_s.so.1.tmp -g -O2 -m31 -B./
_muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o
_ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o
_absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o
_mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o
_clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o
_mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixxfdi_s.o _fixunsxfdi_s.o
_floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o
_floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o
_divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o
_fixsfdi_s.o _fixdfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o
_fixunstfdi_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o
unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 32/libgcc_s.so &&
if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1
32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp
32/libgcc_s.so.1 && ln -s libgcc_s.so.1 32/libgcc_s.so
munmap_chunk(): invalid pointer
munmap_chunk(): invalid pointer
xgcc: internal compiler error: Aborted signal terminated program collect2
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [Makefile:992: libgcc_s.so] Error 4
make[5]: Leaving directory
'/home/andreas/bisect/gcc-266508-build/s390x-ibm-linux-gnu/32/libgcc'
make[4]: *** [Makefile:1210: multi-do] Error 1
make[4]: Leaving directory
'/home/andreas/bisect/gcc-266508-build/s390x-ibm-linux-gnu/libgcc'
make[3]: *** [Makefile:127: all-multi] Error 2
make[3]: *** Waiting for unfinished jobs
xgcc: internal compiler error: Aborted signal terminated program collect2
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [Makefile:992: libgcc_s.so] Error 4
make[3]: Leaving directory
'/home/andreas/bisect/gcc-266508-build/s390x-ibm-linux-gnu/libgcc'
make[2]: *** [Makefile:17482: all-stage2-target-libgcc] Error 2
make[2]: Leaving directory '/home/andreas/bisect/gcc-266508-build'
make[1]: *** [Makefile:21818: stage2-bubble] Error 2
make[1]: Leaving directory '/home/andreas/bisect/gcc-266508-build'
make: *** [Makefile:978: all] Error 2

[Bug target/88152] optimize SSE & AVX char compares with subsequent movmskb

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45114&action=edit
gcc9-pr88152.patch

Untested patch to do similar comparison transformations we do for comparisons
against INTEGER_CSTs also for comparisons against uniform_vector_p VECTOR_CSTs.

[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.3

--- Comment #8 from Jonathan Wakely  ---
The proposed new direction is:

In case mkdir() fails because p already exists, if p resolves to an existing
directory, no error is reported, otherwise an error is reported.

And consistently for create_directory and create_directories, of course.

[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #5 from Florian Weimer  ---
(In reply to Thomas De Schampheleire from comment #4)
> When analyzing this problem with gdb, we looked at the floating-point status
> register before the fldl call, then after, and only the underflow bit was
> new. But there were already other bits present, we probably should have set
> the register to 0 first. Nevertheless, the underflow bit got set.

This is QEMU with TCG, right?  It could be an i387 emulation bug.

[Bug libstdc++/86756] Don't define __cpp_lib_filesystem unless --enable-libstdcxx-filesystem-ts

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Thinking further about this, I think  should always be installed,
but it should only define the portable parts.

The enumeration types, filesystem::path, filesystem::filesystem_error and
filesystem::directory_entry are all supportable for any hosted implementation.

Directory iterators and filesystem operations require OS support, so should be
conditionally-supported.

The C++17 implementation needs to move from libstdc++fs.a into libstdc++.so
anyway, so that simplifies things a little.

(In reply to Jonathan Wakely from comment #1)
> Same for  and __cpp_lib_experimental_filesystem.

It looks like that is already dependent on ENABLE_FILESYSTEM_TS so nothing to
do there.

[Bug other/87695] Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||avr at gjlay dot de,
   ||chertykov at gmail dot com,
   ||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Donna Ory from comment #3)
> Sooo...what does that mean?
> Do I still have a 3D printer that won't print because the problem lies with
> the so called original program that I'm just trying to put back in it?

It means that there's still disagreement as to whose responsibility this bug is
exactly (Arduino's, Atmel's, MicrochipTech's, or someone else's). cc-ing AVR
maintainers to see if they know who in the AVR/Arduino community might be the
right person to talk to about this.

[Bug libstdc++/64132] [7/8/9 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #13 from Jonathan Wakely  ---
Thanks, Dave. That's what the test expects ... so I don't know why it then
fails.

[Bug libstdc++/83306] filesystem_error is not nothrow copyable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/83306] filesystem_error is not nothrow copyable

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 28 15:27:11 2018
New Revision: 266565

URL: https://gcc.gnu.org/viewcvs?rev=266565&root=gcc&view=rev
Log:
PR libstdc++/83306 make filesystem_error no-throw copyable

The class API provides no way to modify the members, so we can share
them between copies of the same object. Copying becomes a simple
reference count update, which doesn't throw.

Also adjust the what() string to allow distinguishing between an empty
path passed to the constructor, and no path.

PR libstdc++/83306
* include/bits/fs_path.h (filesystem_error): Move data members into
pimpl class owned by shared_ptr. Remove inline definitions of member
functions.
* src/filesystem/std-path.cc (filesystem_error::_Impl): Define.
(filesystem_error): Define member functions.
* testsuite/27_io/filesystem/filesystem_error/cons.cc: New test.
* testsuite/27_io/filesystem/filesystem_error/copy.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/27_io/filesystem/filesystem_error/
trunk/libstdc++-v3/testsuite/27_io/filesystem/filesystem_error/cons.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/filesystem_error/copy.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fs_path.h
trunk/libstdc++-v3/src/filesystem/std-path.cc

[Bug target/88152] optimize SSE & AVX char compares with subsequent movmskb

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Matthias Kretz from comment #2)
> I just realized, the movmsk(x<0) => movmsk(x) transformation also applies to
> float and double if -ffinite-math-only (i.e. no NaN, it's alright for inf)
> and -fno-signed-zeros are active.

See PR54700, I'm not really sure if you can do it for floating point at all,
-fno-signed-zeros isn't a guarantee the operand will not be -0.0 and having x <
0.0 behave differently based on whether x is -0.0 or 0.0 (with
-fno-signed-zeros quite randomly) is IMHO very bad.

[Bug c++/88245] New: Wrong location for "explicitly defaulted here"

[redi at gcc dot gnu.org]

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

Bug ID: 88245
   Summary: Wrong location for "explicitly defaulted here"
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct X
{
  ~X();
};

X::~X() = default;

X::~X() = default;


With all versions this says:

expl.cc:8:1: error: definition of explicitly-defaulted 'X::~X()'
8 | X::~X() = default;
  | ^
expl.cc:1:8: note: 'X::~X()' explicitly defaulted here
1 | struct X
  |^

This is very unhelpful. The location of the "explicitly defaulted here" note
doesn't tell you where the first definition was (it could be nowhere near the
second definition, maybe in some included header). It certainly wasn't where
the "here" says.

[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

[patrickdepinguin at gmail dot com]

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

--- Comment #4 from Thomas De Schampheleire  
---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Thomas De Schampheleire from comment #0)
> > gcc 7.3.0 optimizes below code in a way that may cause a floating-point
> > underflow (SIGFPE with underflow flag) on x86. The underflow occurs on an
> > 'fldl' instruction.
> 
> FLD will generate _denormal_ (#DE) exception for denormal single and double
> FP operand ([1], 8.5.2). This is a non-standard exception, and has to be
> distinguished from numeric underflow exception (#UE). Is there a reason for
> denormal exception to be unmasked? 
> 
> [1] http://home.agh.edu.pl/~amrozek/x87.pdf

I don't think we intentionally set any such flags from the application code.
How would the denormal exception be enabled? Is that with feenableexcept ?

When analyzing this problem with gdb, we looked at the floating-point status
register before the fldl call, then after, and only the underflow bit was new.
But there were already other bits present, we probably should have set the
register to 0 first. Nevertheless, the underflow bit got set.

[Bug ipa/87959] ICE in tree check: expected enumeral_type, have record_type in free_enum_values, at ipa-devirt.c:2265

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed in r266325.

[Bug lto/88220] LTO ICE with GNU inline and alias's

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
I'll take a look.

[Bug c/88237] __extension__ in function declaration argument list causes error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Andreas Schwab from comment #3)
> __extension__ can also be used for declarations and definitions that contain
> extensions, but it needs to occur at the start of them.

It'd be nice if the error message said this and offered a fix-it hint, instead
of printing the confusing "expected" wording.

[Bug testsuite/85368] [8/9 regression] phi-opt-11 test fails on IBM Z

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #8 from Christophe Lyon  ---
I see a regression:
FAIL: gcc.dg/tree-ssa/phi-opt-11.c scan-tree-dump-times optimized "if" 0
(used to have PASS: gcc.dg/tree-ssa/phi-opt-11.c scan-tree-dump-times optimized
"if" 2)

on arm-none-eabi --with-mode thumb --with-cpu cortex-m3

Jakub said:
> I've tested it on x86_64 as example of
> !logical_op_short_circuit && branch_cost
> target, Jeff/Andreas on s390x as example
> of logical_op_short_circuit &&
> branch_cost target and I've tested on
> powerpc64{,le} as example of
> logical_op_short_circuit && !branch_cost target.
> arm is a branch_cost target and cortex-m3 is
> logical_op_short_circuit, why
> doesn't the -mbranch-cost=2 option override
> the cortex-m3 defaults?

That's not clear. We have:
#define BRANCH_COST(speed_p, predictable_p) \
  ((arm_branch_cost != -1) ? arm_branch_cost :  \
   (current_tune->branch_cost (speed_p, predictable_p)))

static int
arm_cortex_m_branch_cost (bool speed_p, bool predictable_p)
{
  return (TARGET_32BIT && speed_p) ? 1
 : arm_default_branch_cost (speed_p, predictable_p);
}

But since arm_branch_cost=2, we should just use that.

[Bug libbacktrace/88244] New: [libbacktrace] Failure to open .gnu_debuglink is silent

[vries at gcc dot gnu.org]

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

Bug ID: 88244
   Summary: [libbacktrace] Failure to open .gnu_debuglink is
silent
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: ian at gcc dot gnu.org
  Target Milestone: ---

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

Attached test-case exercises libbacktrace with a broken .gnu_debuglink:
...
$ ./etest 
test1: [0]: missing file name or function name
FAIL: backtrace_full noinline
test2: [0]: missing file name or function name
FAIL: backtrace_full inline
test3: [0]: missing file name or function name
FAIL: backtrace_simple noinline
test4: [0]: missing file name or function name
FAIL: backtrace_simple inline
PASS: backtrace_syminfo variable
...

While the test-case is verbose about not finding specific debug info,
libbacktrace is silent about the underlying issue: failing to open
.gnu_debuglink.

[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
--- gcc/config/rs6000/rs6000.c.jj   2018-11-27 16:40:23.821758250 +0100
+++ gcc/config/rs6000/rs6000.c  2018-11-28 15:15:08.254736153 +0100
@@ -15328,6 +15328,7 @@ rs6000_gimple_fold_builtin (gimple_stmt_
   enum rs6000_builtins fn_code
 = (enum rs6000_builtins) DECL_FUNCTION_CODE (fndecl);
   tree arg0, arg1, lhs, temp;
+  enum tree_code bcode;
   gimple *g;

   size_t uns_fncode = (size_t) fn_code;
@@ -15366,10 +15367,32 @@ rs6000_gimple_fold_builtin (gimple_stmt_
 case P8V_BUILTIN_VADDUDM:
 case ALTIVEC_BUILTIN_VADDFP:
 case VSX_BUILTIN_XVADDDP:
+  bcode = PLUS_EXPR;
+do_binary:
   arg0 = gimple_call_arg (stmt, 0);
   arg1 = gimple_call_arg (stmt, 1);
   lhs = gimple_call_lhs (stmt);
-  g = gimple_build_assign (lhs, PLUS_EXPR, arg0, arg1);
+  if (INTEGRAL_TYPE_P (TREE_TYPE (TREE_TYPE (lhs)))
+ && !TYPE_OVERFLOW_WRAPS (TREE_TYPE (TREE_TYPE (lhs
+   {
+ /* Ensure the binary operation is performed in a type
+that wraps if it is integral type.  */
+ gimple_seq stmts = NULL;
+ tree type = unsigned_type_for (TREE_TYPE (lhs));
+ tree uarg0 = gimple_build (&stmts, VIEW_CONVERT_EXPR,
+type, arg0);
+ tree uarg1 = gimple_build (&stmts, VIEW_CONVERT_EXPR,
+type, arg1);
+ tree res = gimple_build (&stmts, gimple_location (stmt), bcode,
+  type, uarg0, uarg1);
+ gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
+ g = gimple_build_assign (lhs, VIEW_CONVERT_EXPR,
+  build1 (VIEW_CONVERT_EXPR,
+  TREE_TYPE (lhs), res));
+ gsi_replace (gsi, g, true);
+ return true;
+   }
+  g = gimple_build_assign (lhs, bcode, arg0, arg1);
   gimple_set_location (g, gimple_location (stmt));
   gsi_replace (gsi, g, true);
   return true;
@@ -15381,13 +15404,8 @@ rs6000_gimple_fold_builtin (gimple_stmt_
 case P8V_BUILTIN_VSUBUDM:
 case ALTIVEC_BUILTIN_VSUBFP:
 case VSX_BUILTIN_XVSUBDP:
-  arg0 = gimple_call_arg (stmt, 0);
-  arg1 = gimple_call_arg (stmt, 1);
-  lhs = gimple_call_lhs (stmt);
-  g = gimple_build_assign (lhs, MINUS_EXPR, arg0, arg1);
-  gimple_set_location (g, gimple_location (stmt));
-  gsi_replace (gsi, g, true);
-  return true;
+  bcode = MINUS_EXPR;
+  goto do_binary;
 case VSX_BUILTIN_XVMULSP:
 case VSX_BUILTIN_XVMULDP:
   arg0 = gimple_call_arg (stmt, 0);

handles this, but I'm not sure if it is correct for all the builtins that can
show up and if it isn't needed for some other builtins (e.g. some
multiplications too).

[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
#define vec_add(a,b) ((a)+(b))

IIRC that only fails for __vector bool, but I think the ppc people didn't like
this approach.

[Bug target/54700] Optimize away x<0 as mask argument of a blend.

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Marc Glisse from comment #4)
> > __v4su
> > f (__v4su a, __v4su b, __v4su c)
> > {
> >   return a > INT_MAX ? b : c;
> > }
> 
> We should be folding that to (__v4si) a < 0, don't we do that already?  At
> least for non-vectors we do AFAIK.

See PR 88152.

[Bug target/54700] Optimize away x<0 as mask argument of a blend.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Marc Glisse from comment #4)
> __v4su
> f (__v4su a, __v4su b, __v4su c)
> {
>   return a > INT_MAX ? b : c;
> }

We should be folding that to (__v4si) a < 0, don't we do that already?  At
least for non-vectors we do AFAIK.

[Bug tree-optimization/88223] [8/9 Regression] Wrong code for intrinsic memmove

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 28 13:51:42 2018
New Revision: 266560

URL: https://gcc.gnu.org/viewcvs?rev=266560&root=gcc&view=rev
Log:
2018-11-28  Richard Biener  

PR tree-optimization/88223
* tree-ssa-sccvn.c (vn_reference_lookup_3): When skipping
over a stored-same value may-alias store make sure to consider
partial overlaps which are valid when TBAA reasonings do not
apply and byte-granular overlaps are possible at all.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr88223.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug target/54700] Optimize away x<0 as mask argument of a blend.

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #2)
> I'm not really sure if we can optimize v<0 for floating point v even with
> -fno-signed-zeros, isn't that option about allowing to optimize away x+0.0
> and similar to x?  I guess one can't guarantee that -0.0 won't appear though
> and treating -0.0 < 0 as sometimes false and sometimes true could just break
> too much stuff.

Yeah, I'm not completely sure about the floating point case. I think it would
be safe for (most of?) my applications, but likely not for everyone. The int
case is definitely safer. We could have kept your PR as the main one since it
comes with a nice complete testcase and analysis. Related to another recent
report would be the unsigned version, but that probably should be handled
separately in a different place.

__v4su
f (__v4su a, __v4su b, __v4su c)
{
  return a > INT_MAX ? b : c;
}

[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The problem is that the builtin has __vector signed int arguments:
 
V4SI
size 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffefd54738 nunits:4>
SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffefd742a0
arg-types 
chain 
chain >>>
pointer_to_this >
readonly nothrow public external built-in decl_6 SI :0:0
align:32 warn_if_not_align:0 built-in: BUILT_IN_MD:48 context
 chain >

Guess most of the builtins have those, so the easiest fix to me seems to be to
cast it in the gimple_fold targhook.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[hjl.tools at gmail dot com]

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

Bug 87214 Summary: [9 Regression] SPEC CPU2017, CPU2006 520/620, 403 runfails 
after r263772 with march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

[Bug c/88243] ice in vect_create_epilog_for_reduction, at tree-vect-loop.c:4689

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
svn blame says

263128   rsandifo   gcc_assert (STMT_VINFO_RELATED_STMT (orig_stmt_info) ==
stmt_info);

[Bug tree-optimization/87214] [9 Regression] SPEC CPU2017, CPU2006 520/620, 403 runfails after r263772 with march=skylake-avx512

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from H.J. Lu  ---
I can't reproduce it with r266551.

[Bug c/88243] New: ice in vect_create_epilog_for_reduction, at tree-vect-loop.c:4689

[dcb314 at hotmail dot com]

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

Bug ID: 88243
   Summary: ice in vect_create_epilog_for_reduction, at
tree-vect-loop.c:4689
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int a, b, c;

void d() {
  int e, f;
  for (; a; a++) {
e = d;
b = 0;
for (; b < 2; b++) {
  f = e = e / 2;
  c = c + f;
}
  }
}

recent gcc trunk with compiler flag -O3 does this:

$ /home/dcb/gcc/results.266550/bin/gcc -c -w -O3 bug486.c
during GIMPLE pass: vect
bug486.c: In function ‘d’:
bug486.c:3:6: internal compiler error: in vect_create_epilog_for_reduction, at
tree-vect-loop.c:4689
3 | void d() {
  |  ^
0x6e53e7 vect_create_epilog_for_reduction
../../trunk/gcc/tree-vect-loop.c:4689
0xffd75e vectorizable_reduction(_stmt_vec_info*, gimple_stmt_iterator*,
_stmt_vec_info**, _slp_tree*, _slp_instance*, vec*)
../../trunk/gcc/tree-vect-loop.c:7129
0xfec95d vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../trunk/gcc/tree-vect-stmts.c:9685
0xfeef26 vect_transform_loop_stmt
../../trunk/gcc/tree-vect-loop.c:8180

The problem seems to start somewhere between revision 266450 and 266500.

[Bug target/88241] Optimize vector signed integral comparison against 0 followed by blend

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jakub Jelinek  ---
Dup.

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

[Bug target/54700] Optimize away x<0 as mask argument of a blend.

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
*** Bug 88241 has been marked as a duplicate of this bug. ***

[Bug target/54700] Optimize away x<0 as mask argument of a blend.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'm not really sure if we can optimize v<0 for floating point v even with
-fno-signed-zeros, isn't that option about allowing to optimize away x+0.0 and
similar to x?  I guess one can't guarantee that -0.0 won't appear though and
treating -0.0 < 0 as sometimes false and sometimes true could just break too
much stuff.

[Bug target/88241] Optimize vector signed integral comparison against 0 followed by blend

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
PR 54700?

[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-28
 Ever confirmed|0   |1

--- Comment #4 from Segher Boessenkool  ---
This is documented in the ELFv2 ABI, linked from
https://gcc.gnu.org/readings.html .

vec_add is overloaded, and defined as  X vec_add(X, X)  for pretty much every
vector type X.  So I would expect everything to be vector unsigned int here,
but something is going wrong.

Confirmed.

(The vec_vsx_st doesn't have to do with the problem btw.  Not that it is
good or anything ;-) )

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #15 from Eric Botcazou  ---
>> I only have:
[...]
>> as execution test failures, but I have a bunch of output pattern test
>> failures.
>
> Rainer, do you also have a slew of output pattern test failures on SPARC?

I do indeed: on S11.5 the full list is

  6 c-c++-common/asan/alloca_big_alignment.c
  6 c-c++-common/asan/alloca_detect_custom_size.c
  6 c-c++-common/asan/alloca_overflow_partial.c
  6 c-c++-common/asan/alloca_overflow_right.c
  6 c-c++-common/asan/alloca_underflow_left.c
 14 c-c++-common/asan/global-overflow-1.c
  6 c-c++-common/asan/heap-overflow-1.c
  2 c-c++-common/asan/misalign-1.c
  2 c-c++-common/asan/misalign-2.c
  7 c-c++-common/asan/pr62089.c
  6 c-c++-common/asan/stack-overflow-1.c
 10 c-c++-common/asan/strlen-overflow-1.c
  6 c-c++-common/asan/use-after-free-1.c
  7 g++.dg/asan/deep-tail-call-1.C
  3 g++.dg/asan/large-func-test-1.C

These are often just off-by-one errors in the line numbers; I believe I
have a patch around somewhere to fix at least some of those...

[Bug tree-optimization/88217] [8 Regression] Compile time and memory hog w/ -O2 -fstrict-enums -fno-tree-forwprop -fno-tree-fre

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] Compile|[8 Regression] Compile time
   |time and memory hog w/ -O2  |and memory hog w/ -O2
   |-fstrict-enums  |-fstrict-enums
   |-fno-tree-forwprop  |-fno-tree-forwprop
   |-fno-tree-fre   |-fno-tree-fre
  Known to fail|9.0 |

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

[Bug tree-optimization/88217] [8 Regression] Compile time and memory hog w/ -O2 -fstrict-enums -fno-tree-forwprop -fno-tree-fre

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 28 13:04:27 2018
New Revision: 266557

URL: https://gcc.gnu.org/viewcvs?rev=266557&root=gcc&view=rev
Log:
2018-11-28  Richard Biener  

PR tree-optimization/88217
* vr-values.c (vr_values::extract_range_from_phi_node): Make
sure to handle results > +INF and < -INF correctly when
trying to drop down to +INF - 1 or -INF + 1.

* g++.dg/pr88217.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/pr88217.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vr-values.c

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #14 from Eric Botcazou  ---
>> The only asan execution failures I see on Solaris 11/SPARC are
[...]
> I only have:
>
> c-c++-common/asan/pointer-compare-1.c
> c-c++-common/asan/pointer-compare-2.c
> c-c++-common/asan/pointer-subtract-1.c
> c-c++-common/asan/pointer-subtract-2.c
> g++.dg/asan/function-argument-3.C
>
> as execution test failures, but I have a bunch of output pattern test 
> failures.

I've checked current results and find the same on S11.3, while on
S11.[45] there's the added g++.dg/asan/default-options-1.C.

[Bug tree-optimization/79351] [7/8/9 Regression] Invalid tree PRE optimization around compound literal

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 28 12:57:58 2018
New Revision: 266556

URL: https://gcc.gnu.org/viewcvs?rev=266556&root=gcc&view=rev
Log:
2018-11-28  Richard Biener  

PR tree-optimization/79351
* tree-ssa-sccvn.c (vn_reference_lookup_3): For assignments from
empty CONSTRUCTORs ensure the store is at a constant position.

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

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr79351.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/79351] [7/8/9 Regression] Invalid tree PRE optimization around compound literal

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1, 8.2.1, 9.0
 Resolution|--- |FIXED
  Known to fail||7.3.0, 8.2.0

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug c/88237] __extension__ in function declaration argument list causes error

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

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

--- Comment #3 from Andreas Schwab  ---
__extension__ can also be used for declarations and definitions that contain
extensions, but it needs to occur at the start of them.  See the glibc sources
for examples.

[Bug libstdc++/88199] [7/8 Regression] memory leak on unordered container move assignment

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 7.4 and 8.3, thanks François.

[Bug target/88236] [avr] Invalid code generated for __memx char pointer deference for avr5 arch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||avr
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-28
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.