[Bug fortran/86907] [9.0 regression] bogus warning "No location in expression near"

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
As remark, the renaming of types t2 => t1 is needed to produce the bug, as well
as the components of t1 being allocatable. The used revision of gfortran was
262687.

[Bug fortran/86907] New: [9.0 regression] bogus warning "No location in expression near"

[juergen.reuter at desy dot de]

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

Bug ID: 86907
   Summary: [9.0 regression] bogus warning "No location in
expression near"
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Created attachment 44522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44522=edit
Minimal reproducer for the warning.

In the following example, gfortran from version 9 on (I think 8 was ok) is
issuing a bogus warning: 
gfortran  -c reproducer.f90
reproducer.f90:30:49:

 type(t2), dimension(cmd%n_pass) :: adapt_code
 1
Warning: No location in expression near (1)

This is the code:
module m_1
  type, public :: t1
 private
 character(LEN=1), dimension(:), allocatable :: chars
  end type t1

end module m_1

!

module m_2
  use m_1, t2 => t1

  type :: t3
 private
 integer :: n_pass = 0
   contains
 procedure :: execute => t3_execute
  end type t3

contains

  function eval_string () result (sval)
type(t2) :: sval
  end function eval_string

  subroutine t3_execute (cmd)
class(t3), intent(inout) :: cmd
!!! Creates a bogus version in gfortran 9.0.0
type(t2), dimension(cmd%n_pass) :: adapt_code
integer :: i
do i = 1, cmd%n_pass
   adapt_code(i) = eval_string ()
end do
  end subroutine t3_execute

end module m_2

[Bug tree-optimization/86889] s390x gcc build fails when configured with --disable-checking

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-09
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
Thank you.  With the small test case I can confirm the warning even on
x86_64-linux.  I've reduced it a tiny bit more.  Here's the smaller test case
and the VRP output:

$ cat f.c && gcc -S -O2 -Wall -fdump-tree-vrp=/dev/stdout f.c
struct a { long b[2]; };

int d (struct a *p)
{
  int g = 1;

  for (; g >= 0; g--)
if (p->b[g])
  return g;

  __builtin_unreachable ();
}

;; Function d (d, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5
;; 2 succs { 5 3 }
;; 3 succs { 5 4 }
;; 4 succs { 5 }
;; 5 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_9 -> { p_4(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 3 ( 50%)



Value ranges after VRP:

_1: VARYING
p_4(D): VARYING
g_5: [0, 1]
_8: VARYING
p_9: ~[0B, 0B]  EQUIVALENCES: { p_4(D) } (1 elements)
_11: VARYING


f.c: In function ‘d’:
f.c:8:13: warning: array subscript -1 is below array bounds of ‘long int[2]’
[-Warray-bounds]
8 | if (p->b[g])
  | ^~~
d (struct a * p)
{
  int g;
  long int _1;
  long int _8;
  long int _11;

   [local count: 357878152]:
  _8 = p_4(D)->b[1];
  if (_8 != 0)
goto ; [33.33%]
  else
goto ; [66.67%]

   [local count: 238597364]:
  _11 = p_4(D)->b[0];
  if (_11 != 0)
goto ; [33.33%]
  else
goto ; [66.67%]

   [local count: 159072864]:
  _1 = p_4(D)->b[-1];

   [local count: 357878150]:
  # g_5 = PHI <-1(4), 1(2), 0(3)>
  return g_5;

}



;; Function d (d, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 4 3 }
;; 3 succs { 4 }
;; 4 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_2 -> { p_4(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 5
Number of blocks to update: 2 ( 40%)



Value ranges after VRP:

_1: [0, +INF]
p_2: ~[0B, 0B]  EQUIVALENCES: { p_4(D) } (1 elements)
p_4(D): VARYING
g_5: [0, 1]
_8: VARYING
_9: [0, 1]
_11: VARYING
_12: [-1, 0]


d (struct a * p)
{
  int g;
  _Bool _1;
  long int _8;
  int _9;
  long int _11;
  int _12;

   [local count: 357878152]:
  _8 = p_4(D)->b[1];
  if (_8 != 0)
goto ; [33.33%]
  else
goto ; [66.67%]

   [local count: 238597364]:
  _11 = p_4(D)->b[0];
  _1 = _11 == 0;
  _9 = (int) _1;
  _12 = -_9;

   [local count: 357878150]:
  # g_5 = PHI <_12(3), 1(2)>
  return g_5;

}

[Bug fortran/86906] New: erroneous name clash with renaming in use statement

[damian at sourceryinstitute dot org]

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

Bug ID: 86906
   Summary: erroneous name clash with renaming in use statement
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

gfortran 6.4, 7.3, and 8.2 all produce the error message below when attempting
to use a renamed type while in the same scope as the variable that motivated
the renaming:

$ cat foo.f90 
module foo
  type config
  end type
end module
  use foo, only: foo_config => config
contains
  subroutine cap
integer config
type(foo_config) extra
  end subroutine
end

$ gfortran foo.f90 
foo.f90:9:26:

 integer config
  2
 type(foo_config) extra
  1
Error: The type ‘config’ cannot be host associated at (1) because it is blocked
by an incompatible object of the same name declared at (2)

$ gfortran --version
GNU Fortran (GCC) 8.2.0

[Bug middle-end/86903] ICE in init_target_to_host_charmap

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Duplicate of pr82700.

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

[Bug tree-optimization/82700] ICE in printf-return-value with -fexec-charset=EBCDIC-US: converting to execution character set: Invalid or incomplete multibyte or wide character

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #3 from Martin Sebor  ---
*** Bug 86903 has been marked as a duplicate of this bug. ***

[Bug c++/86905] New: g++ ICE on valid code: verify_cgraph_node failed

[helloqirun at gmail dot com]

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

Bug ID: 86905
   Summary: g++ ICE on valid code: verify_cgraph_node failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

It appears to be a recent regression. g++-8.1 compiles.

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180809 (experimental) [trunk revision 263445] (GCC)

$ g++-trunk abc.C
abc.C: In function ‘int pthread_equal()’:
abc.C:1:42: warning: no return statement in function returning non-void
[-Wreturn-type]
 extern "C" __inline int pthread_equal() {}
  ^
abc.C: At global scope:
abc.C:3:17: error: comdat-local function called by void b() outside its comdat
 void b() { a(); }
 ^
_ZL1av/1 (int a()) @0x7f1523464420
  Type: function definition analyzed alias transparent_alias weakref
  Visibility: weak comdat_group:pthread_equal
  Same comdat group as: pthread_equal/0
  References: pthread_equal/0 (alias)
  Referring:
  First run: 0
  Function flags:
  Called by: void b()/2 (can throw external)
  Calls:
abc.C:3:17: internal compiler error: verify_cgraph_node failed
0xaf69ec cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:3433
0xaeae8c symtab_node::verify()
../../gcc/gcc/symtab.c:1218
0xaeaf57 symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1238
0xafe434 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:625
0xafe434 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2520
0xb00399 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2517
0xb00399 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2698
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.




$ cat abc.C
extern "C" __inline int pthread_equal() {}
static __typeof(pthread_equal) a __attribute__((__weakref__("pthread_equal")));
void b() { a(); }

[Bug other/86904] New: Column numbers ignore tab characters

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 86904
   Summary: Column numbers ignore tab characters
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As noted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c21 :

/* Both gcc and emacs number source *lines* starting at 1, but
   they have differing conventions for *columns*.

   GCC uses a 1-based convention for source columns,
   whereas Emacs's M-x column-number-mode uses a 0-based convention.

   For example, an error in the initial, left-hand
   column of source line 3 is reported by GCC as:

  some-file.c:3:1: error: ...etc...

   On navigating to the location of that error in Emacs
   (e.g. via "next-error"),
   the locus is reported in the Mode Line
   (assuming M-x column-number-mode) as:

 some-file.c   10%   (3, 0)

   i.e. "3:1:" in GCC corresponds to "(3, 0)" in Emacs.  */

In terms of 0 vs 1, GCC complies with the GNU standards here:
https://www.gnu.org/prep/standards/html_node/Errors.html

However our "column numbers" are also simply a 1-based byte-count, so a tab
character is treated by us as simply an increment of 1 right now.

(see also PR 49973, which covers the case of multibyte characters).

It turns out that we convert tab characters to *single* space characters when
printing source code.

This behavior has been present since Manu first implemented
-fdiagnostics-show-caret in r186305 (aka
5a9830842f69ebb059061e26f8b0699cbd85121e, PR 24985), where it was this logic
(there in diagnostic.c's diagnostic_show_locus):
  char c = *line == '\t' ? ' ' : *line;
  pp_character (context->printer, c);

(that logic is now in diagnostic-show-locus.c in layout::print_source_line)

This is arguably a bug, but it's intimately linked to the way in which we track
"column numbers".

Our "column numbers" are currently simply a 1-based byte-count, I believe, so a
tab character is treated by us as simply an increment of 1 right now.

There are similar issues with encodings that aren't 1 byte per character (e.g.
non-ASCII unicode characters), which are being tracked in PR 49973.

Presumably, when we print source lines containing tab characters, we should
emit a number of spaces to reach a tab stop.

Consider a diagnostic with a multiline range covering the
following source (and beyond):

  indent: 6 (tabs: 0, spaces: 6)
   indent: 7 (tabs: 0, spaces: 7)
indent: 8 (tabs: 1, spaces: 0)
 indent: 9 (tabs: 1, spaces: 1)

i.e.:

  "  indent: 6 (tabs: 0, spaces: 6)\n"
  "   indent: 7 (tabs: 0, spaces: 7)\n"
  "\tindent: 8 (tabs: 1, spaces: 0)\n"
  "\t indent: 9 (tabs: 1, spaces: 1)\n"

Currently diagnostic_show_locus prints:

   indent: 6 (tabs: 0, spaces: 6)
   ~~
indent: 7 (tabs: 0, spaces: 7)
~~
  indent: 8 (tabs: 1, spaces: 0)
  ~~
   indent: 9 (tabs: 1, spaces: 1)
   ~~

i.e:
  "   indent: 6 (tabs: 0, spaces: 6)\n"
  "   ~~\n"
  "indent: 7 (tabs: 0, spaces: 7)\n"
  "~~\n"
  "  indent: 8 (tabs: 1, spaces: 0)\n"
  "  ~~\n"
  "   indent: 9 (tabs: 1, spaces: 1)\n"
  "   ~~\n"

which misrepresents the indentation of the user's code.

It should respect tabstops, and print:

   indent: 6 (tabs: 0, spaces: 6)
   ~~
indent: 7 (tabs: 0, spaces: 7)
~~
 indent: 8 (tabs: 1, spaces: 0)
 ~~
  indent: 9 (tabs: 1, spaces: 1)
  ~~

i.e.:

  "   indent: 6 (tabs: 0, spaces: 6)\n"
  "   ~~\n"
  "indent: 7 (tabs: 0, spaces: 7)\n"
  "~~\n"
  " indent: 8 (tabs: 1, spaces: 0)\n"
  " ~~\n"
  "  indent: 9 (tabs: 1, spaces: 1)\n"
  "  ~~\n"

We should also handle erroneous leading spaces before a tab, so that e.g.

  "  \tfoo"

should be printed as if it were:

 "\tfoo"

(given that that's what the user's editor is probably printing it as).

Similarly, we should presumably print "8" for the column number for the 'f' of
"foo".  However, IDEs are expecting GCC's existing behavior, so we should
probably add a command-line option for controlling this.

Adding a left margin with line numbers (as of r263450) doesn't change this bug,
but makes fixing it slightly more complicated.

Maybe:
  -fdiagnostics-x-coord=bytes : count of bytes
  

[Bug middle-end/86903] New: ICE in init_target_to_host_charmap

[bernd.edlinger at hotmail dot de]

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

Bug ID: 86903
   Summary: ICE in init_target_to_host_charmap
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

$ cat w.cc
int main()
{
  __builtin_printf("%ld\n", 0);
  return 0;
}
$ gcc -S -fexec-charset=DE w.cc
w.cc: In function 'int main()':
w.cc:1:5: internal compiler error: converting to execution character set:
Invalid or incomplete multibyte or wide character
 int main()
 ^~~~
0xa6ced9 c_cpp_error(cpp_reader*, int, int, rich_location*, char const*,
__va_list_tag (*) [1])
../../gcc-trunk/gcc/c-family/c-common.c:6141
0x17d74c0 cpp_diagnostic
../../gcc-trunk/libcpp/errors.c:74
0x17d7646 cpp_error(cpp_reader*, int, char const*, ...)
../../gcc-trunk/libcpp/errors.c:87
0x17d0033 cpp_host_to_exec_charset(cpp_reader*, unsigned int)
../../gcc-trunk/libcpp/charset.c:798
0xa6cff3 c_common_to_target_charset(long)
../../gcc-trunk/gcc/c-family/c-common.c:6159
0x169d2a1 init_target_to_host_charmap
../../gcc-trunk/gcc/gimple-ssa-sprintf.c:334
0x169d2a1 execute
../../gcc-trunk/gcc/gimple-ssa-sprintf.c:4086
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2018-07-26 00:00:00 |2018-08-09
 Ever confirmed|0   |1

--- Comment #5 from Segher Boessenkool  ---
I cannot reproduce this, not on gcc14 either.  I notice you use ppc64le-linux,
while the canonical name is powerpc64le-linux; maybe that matters?

[Bug c/86894] error for a zero-length array initialized with empty braced list

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-09
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug middle-end/86897] [9 regression] gcc.dg/uninit-suppress_2.c FAILs

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug middle-end/86897] [9 regression] gcc.dg/uninit-suppress_2.c FAILs

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Thu Aug  9 17:11:45 2018
New Revision: 263454

URL: https://gcc.gnu.org/viewcvs?rev=263454=gcc=rev
Log:
PR middle-end/86897
* gcc.dg/uninit-suppress_2.c: Disable DOM.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/uninit-suppress_2.c

[Bug target/86799] nios2 port needs updating for CVE-2017-5753

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
Fixed on trunk.

[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753

[rearnsha at gcc dot gnu.org]

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

Bug 86799 Summary: nios2 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86799

   What|Removed |Added

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

[Bug target/86799] nios2 port needs updating for CVE-2017-5753

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw  ---
I nearly missed this patch for my accumulated back-porting list since it
didn't have the PR number in it.

Just adding it so that I can track things properly.  The original commit
landed as r263301.

[Bug target/86902] New: [9 Regression] ICE: in as_a, at machmode.h:356 at -O

[zsojka at seznam dot cz]

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

Bug ID: 86902
   Summary: [9 Regression] ICE: in as_a, at machmode.h:356 at -O
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O testcase.c
during RTL pass: combine
testcase.c: In function 'c':
testcase.c:10:1: internal compiler error: in as_a, at machmode.h:356
 }
 ^
0xc2ec89 scalar_int_mode as_a(machine_mode)
/repo/gcc-trunk/gcc/machmode.h:356
0xc2ec89 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:1838
0xc28b60 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:873
0xc2cf50 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:372
0x141f679 if_then_else_cond
/repo/gcc-trunk/gcc/combine.c:9249
0x141f468 if_then_else_cond
/repo/gcc-trunk/gcc/combine.c:9267
0x143e378 combine_simplify_rtx
/repo/gcc-trunk/gcc/combine.c:5764
0x1446529 subst
/repo/gcc-trunk/gcc/combine.c:5646
0x144613c subst
/repo/gcc-trunk/gcc/combine.c:5580
0x144ae7f try_combine
/repo/gcc-trunk/gcc/combine.c:3385
0x1456d10 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1302
0x1456d10 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:14945
0x1456d10 execute
/repo/gcc-trunk/gcc/combine.c:14990
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

Tested revisions:
r263450 - FAIL
r263387 - FAIL

[Bug middle-end/86901] New: [AArch64] Suboptimal register allocation for int/float reinterpret

[wilco at gcc dot gnu.org]

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

Bug ID: 86901
   Summary: [AArch64] Suboptimal register allocation for int/float
reinterpret
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

This example (narrowed down from GLIBC) shows inefficient register allocation:

typedef unsigned int uint32_t;

float g (float);

static inline uint32_t
top12 (float x)
{
  union
  {
float f;
uint32_t i;
  } u = {x};
  return (u.i >> 20) & 0x7ff;
}

void
f1 (float y, float *p)
{
  if (__builtin_expect (top12 (y) < top12 (1.0), 1))
*p = y * y;
  else
g (y + y);
}

void
f2 (float y, float *p)
{
  if (__builtin_expect (top12 (y) < top12 (1.0), 1))
*p = y * y;
  else
g (y);
}

On AArch64 this generates with -O2:

f1:
fmovx1, d0
ubfxx1, x1, 20, 11
cmp w1, 1015
bhi .L2
fmuls0, s0, s0
str s0, [x0]
ret
.L2:
fadds0, s0, s0
b   g

f2:
.cfi_startproc
fmovs1, s0   // eh?
fmovx1, d1   // why not fmov w1, s0???
ubfxx1, x1, 20, 11
cmp w1, 1015
bhi .L7
fmuls1, s0, s0
str s1, [x0]
ret
.L7:
b   g

Also the move is done as 64 bits rather than 32.

[Bug c++/86871] [8/9 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Aug  9 16:03:25 2018
New Revision: 263451

URL: https://gcc.gnu.org/viewcvs?rev=263451=gcc=rev
Log:
Allow inner-loop reductions with variable-length vectors

While working on PR 86871, I noticed we were being overly restrictive
when handling variable-length vectors.  For:

  for (i : ...)
{
  res = ...;
  for (j : ...)
res op= ...;
  a[i] = res;
}

we don't need a reduction operation (although we do for double
reductions like:

  res = ...;
  for (i : ...)
for (j : ...)
  res op= ...;
  a[i] = res;

which must still be rejected).

2018-08-08  Richard Sandiford  

gcc/
* tree-vect-loop.c (vectorizable_reduction): Allow inner-loop
reductions for variable-length vectors.

gcc/testsuite/
* gcc.target/aarch64/sve/reduc_8.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/sve/reduc_8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #10 from David Malcolm  ---
Author: dmalcolm
Date: Thu Aug  9 15:32:13 2018
New Revision: 263450

URL: https://gcc.gnu.org/viewcvs?rev=263450=gcc=rev
Log:
diagnostics: add line numbers to source (PR other/84889)

This patch adds a left margin to the lines of source (and annotations)
printed by diagnostic_show_locus, so that e.g. rather than:

test.c: In function 'test':
test.c:12:15: error: 'struct foo' has no member named 'm_bar'; did you mean
'bar'?
   return ptr->m_bar;
   ^
   bar

we print:

test.c: In function 'test':
test.c:12:15: error: 'struct foo' has no member named 'm_bar'; did you mean
'bar'?
12 |   return ptr->m_bar;
   |   ^
   |   bar

Similarly, for a multiline case (in C++ this time), this:

bad-binary-ops.C: In function 'int test_2()':
bad-binary-ops.C:26:4: error: no match for 'operator+' (operand types are 's'
and 't')
   return (some_function ()
   
+ some_other_function ());
^~~~

becomes:

bad-binary-ops.C: In function 'int test_2()':
bad-binary-ops.C:26:4: error: no match for 'operator+' (operand types are 's'
and 't')
25 |   return (some_function ()
   |   
26 |+ some_other_function ());
   |^~~~

I believe this slightly improves the readability of the output, in that it:
- distinguishes between the user's source code vs the annotation lines
  that we're adding (the underlinings and fix-it hints here)
- shows the line numbers in another place (potentially helpful for
  multiline diagnostics, where the user can see the line numbers directly,
  rather than have to figure them out relative to the caret: in the 2nd
  example, note how the diagnostic is reported at line 26, but the first
  line printed is actually line 25)

I'm not sure that this is the precise format we want to go with [1], but
I think it's an improvement over the status quo, and we're in stage 1
of gcc 9, so there's plenty of time to shake out issues.

I've turned it on by default; it can be disabled via
-fno-diagnostics-show-line-numbers (it's also turned off in the testsuite, to
avoid breaking numerous existing test cases).

[1] Some possible variants:
  - maybe just "LL|" rather than "LL | "
  - maybe ':' rather than '|'
  - maybe we should have some leading indentation, to better split up
the diagnostics visually via the left-hand column
  - etc

gcc/ChangeLog:
PR other/84889
* common.opt (fdiagnostics-show-line-numbers): New option.
* diagnostic-show-locus.c (class layout): Add fields
"m_show_line_numbers_p" and "m_linenum_width";
(num_digits): New function.
(test_num_digits): New function.
(layout::layout): Initialize new fields.  Update m_x_offset
logic to handle any left margin.
(layout::print_source_line): Print line number when requested.
(layout::start_annotation_line): New member function.
(layout::print_annotation_line): Call it.
(layout::print_leading_fixits): Likewise.
(layout::print_trailing_fixits): Likewise.  Update calls to
move_to_column for new parameter.
(layout::get_x_bound_for_row): Add "add_left_margin" param and use
it to potentially call start_annotation_line.
(layout::show_ruler): Call start_annotation_line.
(selftest::test_line_numbers_multiline_range): New selftest.
(selftest::diagnostic_show_locus_c_tests): Call test_num_digits
and selftest::test_line_numbers_multiline_range.
* diagnostic.c (diagnostic_initialize): Initialize
show_line_numbers_p.
* diagnostic.h (struct diagnostic_context): Add field
"show_line_numbers_p".
* doc/invoke.texi (Diagnostic Message Formatting Options): Add
-fno-diagnostics-show-line-numbers.
* dwarf2out.c (gen_producer_string): Add
OPT_fdiagnostics_show_line_numbers to the ignored options.
* lto-wrapper.c (merge_and_complain): Likewise to the "pick
one setting" options.
(append_compiler_options): Likewise to the dropped options.
(append_diag_options): Likewise to the passed-on options.
* opts.c (common_handle_option): Handle the new option.
* toplev.c (general_init): Set up global_dc->show_line_numbers_p.

gcc/testsuite/ChangeLog:
PR other/84889
* gcc.dg/plugin/diagnostic-test-show-locus-bw-line-numbers.c: New
test.
* gcc.dg/plugin/diagnostic-test-show-locus-color-line-numbers.c:
New test.
* gcc.dg/plugin/plugin.exp (plugin_test_list): Add the new tests.
* lib/prune.exp: Add -fno-diagnostics-show-line-numbers to
TEST_ALWAYS_FLAGS.


Added:
   
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-bw-line-numbers.c
   
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-color-line-numbers.c

[Bug tree-optimization/86858] [9 Regression] GCC ICE at -O3 in as_a, at is-a.h:197

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Aug  9 14:45:02 2018
New Revision: 263448

URL: https://gcc.gnu.org/viewcvs?rev=263448=gcc=rev
Log:
Restore flow_bb_inside_loop_p tests (PR 86858)

The series to remove vinfo_for_stmt also removed tests of
flow_bb_inside_loop_p if the call was simply testing whether the
statement was in the vectorisation region.  I'd tried to keep calls
that were testing whether the statement was in a particular loop
(inner or outer), but messed up in vect_is_simple_reduction and
removed calls that were actually needed.  This patch restores them.

I double-checked the other removed calls and I think these are
the only ones affected.

2018-08-08  Richard Sandiford  

gcc/
PR tree-optimization/86858
* tree-vect-loop.c (vect_is_simple_reduction): Restore
flow_bb_inside_loop_p calls.

gcc/testsuite/
PR tree-optimization/86858
* gcc.dg/vect/pr86858.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr86858.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug c++/86871] [8/9 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_call(trunc_mod_expr) in gimple_assign_lhs, at gimple.h:2462

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Aug  9 14:37:24 2018
New Revision: 263447

URL: https://gcc.gnu.org/viewcvs?rev=263447=gcc=rev
Log:
Fix invalid assumption in vect_transform_stmt (PR 86871)

The handling of outer-loop uses of inner-loop definitions assumed
that anything that wasn't a PHI would be a gassign.  It's also
possible for it to be a gcall.

2018-08-08  Richard Sandiford  

gcc/
PR tree-optimization/86871
* tree-vect-stmts.c (vect_transform_stmt): Use gimple_get_lhs
instead of gimple_assign_lhs.

gcc/testsuite/
PR tree-optimization/86871
* gcc.dg/vect/pr86871.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr86871.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug c++/86900] New: -gdwarf-5 -O2 -ffunction-sections = assembler error

[jan.kratochvil at redhat dot com]

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

Bug ID: 86900
   Summary: -gdwarf-5 -O2 -ffunction-sections = assembler error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---

g++ -gdwarf-5 -O2 -ffunction-sections -c 1.cc -o 1.o

/tmp/ccnCmT6w.s: Assembler messages:
/tmp/ccnCmT6w.s:61840: Error: invalid operands
(.text.unlikely._ZN4base27HistogramDeltaSerialization11RecordDeltaERKNS_13HistogramBaseERKNS_16HistogramSamplesE
and
.text._ZN4base27HistogramDeltaSerialization11RecordDeltaERKNS_13HistogramBaseERKNS_16HistogramSamplesE
sections) for `-'
...

FAIL: gcc-8.2.1-1dwarf64.fc28.x86_64
FAIL: gcc-8.1.1-5.fc28.x86_64

[Bug target/86887] [9 Regression] aarch64: adcs accepts only register arguments

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Earnshaw  ---
Fixed.

[Bug target/86887] [9 Regression] aarch64: adcs accepts only register arguments

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Thu Aug  9 13:39:17 2018
New Revision: 263446

URL: https://gcc.gnu.org/viewcvs?rev=263446=gcc=rev
Log:
aarch64 - PR target/86887 Fix missing register constraints in carryin patterns

Some of the carryin insn patterns are missing a register constraint.
That means that the register allocator can pick practically anything
to hold that value, including memory locations, or registers of the
wrong class.

PR target/86887
* config/aarch64/aarch64.md (add3_carryinC_zero): Add missing
register constraint to operand 0.
(add3_carryinC): Likewise.
(add3_carryinV_zero, add3_carryinV): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md

[Bug middle-end/86897] [9 regression] gcc.dg/uninit-suppress_2.c FAILs

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
Yea, the fix for this was in my tree when I was testing.  The DOM changes
compromise the test.  I'll push my fix to the trunk in a couple hours when I'm
back online.

[Bug sanitizer/86899] [8/9 regression] TSAN incorrect warning: control reaches end of non-void function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-09
  Known to work||7.3.0
   Target Milestone|--- |8.3
Summary|[7? regression] TSAN|[8/9 regression] TSAN
   |incorrect warning: control  |incorrect warning: control
   |reaches end of non-void |reaches end of non-void
   |function|function
 Ever confirmed|0   |1
  Known to fail||8.2.0, 9.0

--- Comment #1 from Martin Liška  ---
Started with Jakub's r255403.

[Bug sanitizer/86899] New: [7? regression] TSAN incorrect warning: control reaches end of non-void function

[dimhen at gmail dot com]

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

Bug ID: 86899
   Summary: [7? regression] TSAN incorrect warning: control
reaches end of non-void function
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

r255400 PASS
r255622 FAIL
r263351 FAIL

$ cat a.cpp 
int foo()
{
return 0;
if(0) {
return 0;
}
}

$ g++ -Wall  -c a.cpp

$ g++ -Wall -fsanitize=thread -c a.cpp 
a.cpp: In function ‘int foo()’:
a.cpp:7:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=native
Thread model: posix
gcc version 9.0.0 20180807 (experimental) [trunk revision 263351] (GCC)

[Bug target/86896] invalid vmovdqa64 instruction for KNL emitted

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Fixed on trunk in r260969 which is a front-end change. Thus I'm going to
isolate a smaller test-case first.

[Bug target/86896] invalid vmovdqa64 instruction for KNL emitted

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Fixed in 8.2.0, seen in 8.1.0. I'm bisecting right now.

[Bug c++/86898] [9 regression] g++.old-deja/g++.mike/p784.C FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/86898] New: [9 regression] g++.old-deja/g++.mike/p784.C FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 86898
   Summary: [9 regression] g++.old-deja/g++.mike/p784.C FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

Between 20180807 (r263360) and 20180808 (r263409), g++.old-deja/g++.mike/p784.C
started to FAIL

+FAIL: g++.old-deja/g++.mike/p784.C  -std=gnu++11 (test for excess errors)
+FAIL: g++.old-deja/g++.mike/p784.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.old-deja/g++.mike/p784.C  -std=gnu++98 (test for excess errors)

I'm seeing it on 32-bit Solaris/SPARC and x86 only, but gcc-testresults lists
many others.

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.mike/p784.C:1185:21:
error: friend declaration of 'String common_prefix(const String&, const
String&, int)' specifies default arguments and isn't a definition
[-fpermissive]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.mike/p784.C:1187:21:
error: friend declaration of 'String common_suffix(const String&, const
String&, int)' specifies default arguments and isn't a definition
[-fpermissive]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.old-deja/g++.mike/p784.C:1226:21:
error: friend declaration of 'int readline(istream&, String&, char, int)'
specifies default arguments and isn't a definition [-fpermissive]

[Bug middle-end/86897] [9 regression] gcc.dg/uninit-suppress_2.c FAILs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-09
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r263342.

[Bug c/86895] Wrong description of -fvect-cost-model in common.opt

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug middle-end/86897] [9 regression] gcc.dg/uninit-suppress_2.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug middle-end/86897] New: [9 regression] gcc.dg/uninit-suppress_2.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 86897
   Summary: [9 regression] gcc.dg/uninit-suppress_2.c FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

Between 20180806 (r263336) and 20180807 (r263360), gcc.dg/uninit-suppress_2.c
started to FAIL:

+FAIL: gcc.dg/uninit-suppress_2.c should not be promoted to error (test for
warnings, line 16)

I'm seeing it on 32 and 64-bit Solaris/SPARC and x86, according to
gcc-testresults this seems to happen everywhere.

[Bug c/86895] Wrong description of -fvect-cost-model in common.opt

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Aug  9 10:37:02 2018
New Revision: 263444

URL: https://gcc.gnu.org/viewcvs?rev=263444=gcc=rev
Log:
Remove extra line in common.opt (PR c/86895).

2018-08-09  Martin Liska  

PR c/86895
* common.opt: Remove extra line.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt

[Bug c/86895] Wrong description of -fvect-cost-model in common.opt

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-09
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Yes, it's error that I done in r245788, let me fix that.

[Bug target/86896] New: invalid vmovdqa64 instruction for KNL emitted

[kretz at kde dot org]

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

Bug ID: 86896
   Summary: invalid vmovdqa64 instruction for KNL emitted
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (unreduced) at
https://web-docs.gsi.de/~mkretz/invalid_knl_instruction.cpp

Compile the test case with `g++ -std=c++17 -O1 -march=knl
invalid_knl_instruction.cpp`

Output when testing with Intel SDE `-knl`:
TID 0 SDE-ERROR: Executed instruction not valid for specified chip (KNL):
0x41eb28: vmovdqa64 xmm4, xmm16
Image: a.out+0x1eb28 (in multi-region image, region# 0)
Function:
_ZN5Tests10operators_IN2Vc2v24simdIyNS2_8simd_abi11__fixed_abiILi31EE3runEv
Instruction bytes are: 62 b1 fd 08 6f e0

[Bug c/86895] New: Wrong description of -fvect-cost-model in common.opt

[niva at niisi dot msk.ru]

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

Bug ID: 86895
   Summary: Wrong description of -fvect-cost-model in common.opt
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niva at niisi dot msk.ru
  Target Milestone: ---

gcc --help -v prints the following:

  Specifies the cost model for vectorization.
-fvect-cost-model=[unlimited|dynamic|cheap] Specifies
  the cost model for vectorization.

I think that this results from the defect in gcc/common.opt:

fvect-cost-model=
Common Joined RejectNegative Enum(vect_cost_model) Var(flag_vect_cost_model)
Init(VECT_COST_MODEL_DEFAULT) Optimization
Specifies the cost model for vectorization.
-fvect-cost-model=[unlimited|dynamic|cheap] Specifies the cost model for
vectorization.

[Bug c++/86503] Segmentation fault signal terminated

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-09
 Ever confirmed|0   |1

[Bug tree-optimization/86889] s390x gcc build fails when configured with --disable-checking

[iii at linux dot ibm.com]

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

--- Comment #2 from Ilya Leoshkevich  ---
C-Reduced version:

struct a {
  long b[128 / (8 * 8)];
};
int c;
void d() {
  a *e;
  long f;
  int g = 1;
  for (; g >= 0; g--) {
f = e->b[g];
if (f)
  goto h;
  }
  __builtin_unreachable();
h:
  c = g;
}

Repro:

$ PATH=build/prev-gcc:$PATH xg++ -c -O2 -Warray-bounds bitmap.E.c
bitmap.E.c: In function ‘void d()’:
bitmap.E.c:10:15: warning: array subscript -1 is below array bounds of ‘long
int [2]’ [-Warray-bounds]
 f = e->b[g];
 ~~^

[Bug target/84332] ICE in insn_default_length, at config/s390/s390.md:9697 for -fstack-clash-protection

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #4 from Andreas Krebbel  ---
Fixed with commit from comment 3

[Bug target/84332] ICE in insn_default_length, at config/s390/s390.md:9697 for -fstack-clash-protection

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Aug  9 07:06:23 2018
New Revision: 263441

URL: https://gcc.gnu.org/viewcvs?rev=263441=gcc=rev
Log:
S/390: Fix PR84332 ICE with stack clash protection

Our implementation of the stack probe requires the probe interval to
be used as displacement in an address operand.  The maximum probe
interval currently is 64k.  This would exceed short displacements.
Trim that value down to 4k if that happens.  This might result in too
many probes being generated only on the oldest supported machine level
z900.

gcc/ChangeLog:

2018-08-09  Andreas Krebbel  

PR target/84332
* config/s390/s390.c (s390_option_override_internal): Reduce the
stack-clash-protection-probe-interval param if it would be too big
for z900.

gcc/testsuite/ChangeLog:

2018-08-09  Andreas Krebbel  

PR target/84332
* gcc.target/s390/pr84332.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr84332.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #5)
> So what is wrong about that?  CONST_INTs are sign-extended always, so
> 0xff00 is just fine?

As said in Comment #2, it is not wrong, just suspicious.

(insn 10 9 11 3 (set (reg:SI 94 [  ])
(zero_extend:SI (reg:QI 92 [  ]))) "pr86882.c":10 140
{*zero_extendqisi2}
 (nil))
(insn 11 10 13 3 (parallel [
(set (reg:SI 95 [ jd ])
(xor:SI (reg:SI 94 [  ])
(const_int 257 [0x101])))
(clobber (reg:CC 17 flags))
]) "pr86882.c":10 461 {*xorsi_1}
 (expr_list:REG_DEAD (reg:SI 94 [  ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 13 11 14 3 (parallel [
(set (reg:HI 97)
(xor:HI (subreg:HI (reg:SI 95 [ jd ]) 0)
(subreg:HI (reg:QI 92 [  ]) 0)))
(clobber (reg:CC 17 flags))
]) "pr86882.c":11 459 {*xorhi_1}
 (expr_list:REG_DEAD (reg:SI 95 [ jd ])
(expr_list:REG_DEAD (reg:QI 92 [  ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

gets combined to:

Trying 10, 11 -> 13:

Successfully matched this instruction:
(set (reg:HI 95 [ jd ])
(and:HI (subreg:HI (reg:QI 92 [  ]) 0)
(const_int -256 [0xff00])))
Successfully matched this instruction:
(set (reg:HI 97)
(xor:HI (reg:HI 95 [ jd ])
(const_int 257 [0x101])))

The first one operates on paradoxical HImode subreg of QImode input operand
(valid bitmask 0xff), which is masked with 0xff00. The result is a value, which
has only highpart unmasked and lowpart = 0x00. Later, a couple instructions
operate in HImode, but finally we get to:

(insn 14 13 15 3 (set (reg:QI 92 [  ])
(subreg:QI (reg:HI 97) 0)) "pr86882.c":11 88 {*movqi_internal}
 (nil))

which discards paradoxical highpart from the Himode operations. So, I guess the
above is OK (but I didn't check the validity of XOR and AND simplifications in
different modes).

It looks to me that the invalid RTX from comment #1 should read:

(set (reg:QI 97)
(const_int 1 [0x1]))