[Bug middle-end/86864] New: [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795

2018-08-05 Thread belyshev at depni dot sinp.msu.ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864

Bug ID: 86864
   Summary: [9 Regression] ICE in commit_one_edge_insertion, at
cfgrtl.c:2025 since r261795
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: belyshev at depni dot sinp.msu.ru
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r261795 caused the following ICE, reduced from i386.c:

long a;
void f ();
void g (int b, int c, int d)
{
  switch (b)
{
case 42:
case 29:
case 48:
case 40:
case 32:
  c = 2;
  break;
case 0:
  c = 1;
  break;
default:
  __builtin_unreachable ();
}
  if (d || a)
f ();
  if (c == 1)
f ();
}

during RTL pass: expand
bug.c: In function 'g':
bug.c:24:1: internal compiler error: in commit_one_edge_insertion, at
cfgrtl.c:2025

[Bug middle-end/86840] __attribute__((optimize("exceptions"))) is silently ignored

2018-08-05 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86840

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
There are a number of bugs with __attribute__((optimize)); I can't quite recall
which of them exactly I was thinking this is a duplicate of, though...

[Bug middle-end/79016] missing -Wstringop-overflow= overflowing allocated buffers

2018-08-05 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79016

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> This is also affects overflowing buffers allocated by a user-defined
> function declared with attribute alloc_size.

Confirmed for this part too.

[Bug fortran/86863] New: [OOP][F2008] type-bound module procedure name not recognized

2018-08-05 Thread damian at sourceryinstitute dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863

Bug ID: 86863
   Summary: [OOP][F2008] type-bound module procedure name not
recognized
   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 8.2.0 fails to recognize the public type-bound procedure below. The
error message goes away when "module procedure" is replaced with "subroutine"
and the dummy arguments are declared in the definition of the "set" subroutine.
 With gfortran 7.3.0 and 6.4.0, the code below causes an ICE.


$ cat module-procedure.f90 
module foo
  implicit none
  type bar
  contains
procedure, nopass :: foobar
  end type
contains
  subroutine foobar
  end subroutine
end module

module foobartoo
  implicit none
  interface
module subroutine set(object)
  use foo
  implicit none
  type(bar) object
end subroutine
  end interface
contains
  module procedure set
use foo, only : bar
call object%foobar
  end procedure
end module
rouson@sourcery-VirtualBox:~/Desktop/Builds/frapcon4.1/src/reproducer$ gfortran
-c module-procedure.f90 
module-procedure.f90:24:22:

 call object%foobar
  1
Error: ‘foobar’ at (1) should be a SUBROUTINE
rouson@sourcery-VirtualBox:~/Desktop/Builds/frapcon4.1/src/reproducer$ gfortran
--version
GNU Fortran (GCC) 8.2.0

[Bug target/86856] Format warnings building all-gcc

2018-08-05 Thread nightstrike at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856

nightstrike  changed:

   What|Removed |Added

Summary|Warning: unknown conversion |Format warnings building
   |type for|all-gcc
   |ASM_OUTPUT_REG_PUSH and |
   |ASM_OUTPUT_REG_POP  |

--- Comment #9 from nightstrike  ---
Ok, using gcc 8.1, the ASM warnings are gone, so I'll remove that from the
title.  The rest of the warnings are greatly reduced and slightly different, so
I'll repost here and try to improve the title. Feel free to change it better.


../../../gccsvn/gcc/gimple-fold.c: In function 'bool
gimple_fold_builtin_strncpy(gimple_stmt_iterator*, tree, tree, tree)':
../../../gccsvn/gcc/gimple-fold.c:1666:4: warning: format '%G' expects argument
of type 'gcall*', but argument 4 has type 'gimple*' [-Wformat=]
"%G%qD destination unchanged after copying no bytes "
^
"from a string of length %E",

stmt, fndecl, slen);

../../../gccsvn/gcc/gimple-fold.c:1671:4: warning: format '%G' expects argument
of type 'gcall*', but argument 4 has type 'gimple*' [-Wformat=]
"%G%qD destination unchanged after copying no bytes",
^~~~
stmt, fndecl);

../../../gccsvn/gcc/gimple-fold.c: In function 'bool
gimple_fold_builtin_strncat(gimple_stmt_iterator*)':
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: format '%G' expects
argument of type 'gcall*', but argument 4 has type 'gimple*' [-Wformat=]
   stmt, fndecl, len, dstsize);
     ^
../../../gccsvn/gcc/gimple-fold.c:2043:37: warning: format '%G' expects
argument of type 'gcall*', but argument 4 has type 'gimple*' [-Wformat=]
../../../gccsvn/gcc/gimple-fold.c:2059:9: warning: format '%G' expects argument
of type 'gcall*', but argument 4 has type 'gimple*' [-Wformat=]
 "%G%qD specified bound %E equals source length",
 ^~~
 stmt, fndecl, len))
 
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c: In function 'bool
{anonymous}::maybe_diag_overlap(location_t, gimple*,
{anonymous}::builtin_access&)':
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%G'
expects argument of type 'gcall*', but argument 4 has type 'gimple*'
[-Wformat=]
call, func, sizrange[0],

offstr[0], offstr[1], ovlsiz[0], offstr[2]);
  ^
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%G'
expects argument of type 'gcall*', but argument 4 has type 'gimple*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%G'
expects argument of type 'gcall*', but argument 4 has type 'gimple*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1403:46: warning: format '%G'
expects argument of type 'gcall*', but argument 4 has type 'gimple*'
[-Wformat=]
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1409:10: warning: format '%G'
expects argument of type 'gcall*', but argument 6 has type 'gimple*'
[-Wformat=]
  "%G%qD accessing %wu bytes at offsets %s "
  ^~
  "and %s overlaps between %wu and %wu bytes "
  
  "at offset %s",
  ~~
  call, func, sizrange[0], offstr[0], offstr[1],
  
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1406:10: warning: format '%G'
expects argument of type 'gcall*', but argument 6 has type 'gimple*'
[-Wformat=]
  "%G%qD accessing %wu byte at offsets %s "
  ^
  "and %s overlaps between %wu and %wu bytes "
  
  "at offset %s",
  ~~
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1412:10:
  call, func, sizrange[0], offstr[0], offstr[1],
  
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1418:10: warning: format '%G'
expects argument of type 'gcall*', but argument 6 has type 'gimple*'
[-Wformat=]
  "%G%qD accessing %wu bytes at offsets %s and "
  ^~
  "%s overlaps %wu or more bytes at offset %s",
  
  call, func, sizrange[0],
  
../../../gccsvn/gcc/gimple-ssa-warn-restrict.c:1416:10: warning: format '%G'
expects argument of type 'gcall*', but argument 6 has type 'gimple*'
[-Wformat=]
  "%G%qD accessing %wu byte at offsets %s and "
  ^
  "%s overlaps %wu or more bytes at offset %s",
  

[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP

2018-08-05 Thread nightstrike at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856

--- Comment #8 from nightstrike  ---
Ok, I'm trying again with a stock 8.1.

[Bug middle-end/86631] [9 Regression] missing -Walloc-size-larger-than on ILP32 hosts

2018-08-05 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86631

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #5 from John David Anglin  ---
Also seen on hppa-linux.

[Bug c++/86862] New: Segfault using extern template on class deriving from streambuf

2018-08-05 Thread jessemaurais at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86862

Bug ID: 86862
   Summary: Segfault using extern template on class deriving from
streambuf
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jessemaurais at gmail dot com
  Target Milestone: ---

Created attachment 44505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44505&action=edit
Source code with system info and command line using -v -save-temps added as
comments

Using GCC 8.2.0-1 in Debian testing the code

template  class Traits>
class base : public std::basic_streambuf>
{};
template  class Traits = std::char_traits>
class derived : public base
{};
extern template class derived;

segfaults apparently on parsing the base class for the extern template. No
special command line arguments are given. See the attachment for the full info
given by -v -save-temps

[Bug libstdc++/86861] New: 18_support/new_aligned.cc FAILs

2018-08-05 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861

Bug ID: 86861
   Summary: 18_support/new_aligned.cc FAILs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.10
Target: *-*-solaris2.10
 Build: *-*-solaris2.10

Thew new 18_support/new_aligned.cc test FAILs on Solaris 10 (sparc and x86),
which lacks aligned_alloc in libc:

+FAIL: 18_support/new_aligned.cc execution test

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
[New Thread 1 (LWP 1)]

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec5c9b5 in _lwp_kill () from /lib/libc.so.1
(gdb) where
#0  0xfec5c9b5 in _lwp_kill () from /lib/libc.so.1
#1  0xfec5782c in thr_kill () from /lib/libc.so.1
#2  0xfec037db in raise () from /lib/libc.so.1
#3  0xfebe29f5 in abort () from /lib/libc.so.1
#4  0xfeedddad in __gnu_cxx::__verbose_terminate_handler ()
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/vterminate.cc:95
#5  0xfeeda727 in __cxxabiv1::__terminate(void (*)()) ()
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_terminate.cc:47
#6  0xfeeda7a0 in std::terminate ()
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_terminate.cc:57
#7  0xfeedaaa8 in __cxxabiv1::__cxa_throw (obj=0x8066ab8, 
tinfo=0xfef763ac , 
dest=0xfeed8380 )
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:95
#8  0xfeedc257 in operator new (sz=1, al=(unknown: 1))
at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/new_opa.cc:113
#9  0x0805104d in Test::Test (this=0x8047494, size=1, a=1)
at
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/18_support/new_aligned.cc:29
#10 0x080511ad in test01 ()
at
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/18_support/new_aligned.cc:64
#11 0x080519fe in main ()
at
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/18_support/new_aligned.cc:118

[Bug libstdc++/86861] 18_support/new_aligned.cc FAILs

2018-08-05 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86861

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/86386] [8/9 Regression] unaligned load from stack with -Os -fno-tree-dce -mstringop-strategy=vector_loop -mavx512bw

2018-08-05 Thread hjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86386

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sun Aug  5 12:46:13 2018
New Revision: 263317

URL: https://gcc.gnu.org/viewcvs?rev=263317&root=gcc&view=rev
Log:
i386: Set cfun->machine->max_used_stack_alignment if needed

cfun->machine->max_used_stack_alignment is used to decide how stack frame
should be aligned.  This is independent of any psABIs nor 32-bit vs 64-bit.
It is always safe to compute max_used_stack_alignment.  We compute it only
if 128-bit aligned load/store may be generated on misaligned stack slot
which will lead to segfault.

gcc/

PR target/86386
* config/i386/i386.c (ix86_finalize_stack_frame_flags): Set
cfun->machine->max_used_stack_alignment if needed.

gcc/testsuite/

PR target/86386
* gcc.target/i386/pr86386.c: New file.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr86386.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP

2018-08-05 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856

--- Comment #7 from Andreas Schwab  ---
%z has been added in gcc 8.

[Bug libstdc++/86860] New: Reject valid overloads of subclass ostream operator<

2018-08-05 Thread mickey.veksler at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86860

Bug ID: 86860
   Summary: Reject valid overloads of subclass ostream operator<<
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mickey.veksler at gmail dot com
  Target Milestone: ---

The following is rejected by gcc (not by other compilers):
#include 
#include 

struct St : std::ostringstream {
template St& operator<<( const Tp& value ) { return *this; }
operator std::string() const { return str(); }
friend std::ostream& operator<<( std::ostream& s, const St& ss ) { return 
s << ss.str(); }
};
struct Memory_type {
std::string to_string() const { return St() << "s=" << s; }
const char* s;
};

Because of an ambiguity between user defined:
template St& operator<<( const Tp& value ) { return *this; }

and GCC function defined (in ostream header):
  template
  inline
  typename enable_if<__and_<__not_>,
   __is_convertible_to_basic_ostream<_Ostream>,
   __is_insertable<
   __rvalue_ostream_type<_Ostream>,
   const _Tp&>>::value,
   __rvalue_ostream_type<_Ostream>>::type
   operator<<(_Ostream&& __os, const _Tp& __x)
  {  }


The above function does not seem to be part of the standard, and it seems that
the other compilers can work without it.


This is described in
https://stackoverflow.com/questions/51637953/what-enable-if-or-other-hint-is-need-for-the-following-overloaded-to-compile/51692662#51692662

[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP

2018-08-05 Thread nightstrike at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856

--- Comment #6 from nightstrike  ---
7.3 is too old of a host compiler?

[Bug target/86856] Warning: unknown conversion type for ASM_OUTPUT_REG_PUSH and ASM_OUTPUT_REG_POP

2018-08-05 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86856

--- Comment #5 from Uroš Bizjak  ---
(In reply to nightstrike from comment #4)
> Itwhen building the "all-gcc" target, but I'm building a cross compiler (I
> just updated the Host field in the PR to reflect this).  When building a
> cross, I'm guessing it uses the host compiler for the whole thing, which in
> my case was gcc 7.3.

Warnings involving "%z" in ASM_OUTPUT_REG_{POP,PUSH} are harmless warnings,
(older) host compiler doesn't know about these specifiers.

I don't know about others, perhaps mingw was left behind and should update some
of its #defines.

OTOH, these warnings will break bootstrapped build.