[Bug target/87285] New: [9 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3235) with -O2 -std=gnu++11

[zsojka at seznam dot cz]

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

Bug ID: 87285
   Summary: [9 Regression] ICE: SIGSEGV in tree_class_check
(tree.h:3235) with -O2 -std=gnu++11
   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: mipsel-unknown-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 44680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44680=edit
reduced testcase (from compatibility-c++0x.cc)

Compiler output:
$ cc1plus -O2 -std=gnu++11 testcase.C 
 virtual a b::c() const constexpr b::b(b&&) constexpr b::b(b&&) constexpr
b::b(b&&)
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   during
GIMPLE pass: fnsplit

testcase.C: In function 'virtual a b::c() const':
testcase.C:13:1: internal compiler error: Segmentation fault
13 | }
   | ^
0xe0747f crash_signal
/repo/gcc-trunk/gcc/toplev.c:325
0x10c9acc tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/repo/gcc-trunk/gcc/tree.h:3235
0x10c9acc decl_function_context(tree_node const*)
/repo/gcc-trunk/gcc/tree.c:8994
0x116d247 mips_get_compress_mode
/repo/gcc-trunk/gcc/config/mips/mips.c:1355
0x116e388 mips_set_current_function
/repo/gcc-trunk/gcc/config/mips/mips.c:19636
0xa9939b invoke_set_current_function_hook
/repo/gcc-trunk/gcc/function.c:4616
0xaa392b invoke_set_current_function_hook
/repo/gcc-trunk/gcc/function.c:4600
0xaa392b allocate_struct_function(tree_node*, bool)
/repo/gcc-trunk/gcc/function.c:4729
0xe9c6af initialize_cfun
/repo/gcc-trunk/gcc/tree-inline.c:2452
0xe9c6af tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*)
/repo/gcc-trunk/gcc/tree-inline.c:5832
0x937b3a cgraph_node::create_version_clone_with_body(vec, vec*, bitmap_head*, bool,
bitmap_head*, basic_block_def*, char const*)
/repo/gcc-trunk/gcc/cgraphclones.c:983
0x1598d0d split_function
/repo/gcc-trunk/gcc/ipa-split.c:1327
0x159cea8 execute_split_functions
/repo/gcc-trunk/gcc/ipa-split.c:1825
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I am failing to finish build due to this ICE.

$ xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-trunk-264226-checking-yes-rtl-df-extra-mipsel/gcc/xgcc
Target: mipsel-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/mipsel-unknown-linux-gnu
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=mipsel-unknown-linux-gnu
--with-ld=/usr/bin/mipsel-unknown-linux-gnu-ld
--with-as=/usr/bin/mipsel-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-264226-checking-yes-rtl-df-extra-mipsel
Thread model: posix
gcc version 9.0.0 20180912 (experimental) (GCC)

[Bug c++/87282] Invalid use of 'void', in unevaluated context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug middle-end/87276] Buggy tree-ssa optimization introduced in revision 263875

[vincent-gcc at vinc17 dot net]

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

--- Comment #3 from Vincent Lefèvre  ---
Note: This may yield security issues since basically, this makes integer
overflow detection fail. In the testcase, after

  unsigned long uc;
  uc = (unsigned long) sum + (unsigned long) ps->e;

uc > 9223372036854775807, i.e. uc > LONG_MAX, is regarded as false instead of
true.

[Bug middle-end/87276] Buggy tree-ssa optimization introduced in revision 263875

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

Summary|Buggy code with -O2 in  |Buggy tree-ssa optimization
   |trunk revision 264170: MPFR |introduced in revision
   |test tstrtofr fails |263875

--- Comment #2 from Vincent Lefèvre  ---
The bug was introduced in r263875.

[Bug middle-end/87237] __atomic_load on 4-byte-sized, 1-byte-aligned struct is not atomic

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #4 from Richard Smith  ---
(In reply to Alexander Monakov from comment #3)
> With GCC size/align are 3/1 while with Clang it's 4/4 as you said

Oh sorry, you're right, I'd forgotten about this ABI discrepancy. We really
need to get the psABI fixed to say one way or the other! :)

[Bug c++/86946] ice: canonical types differ for identical types

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Still going wrong nearly a month later on revision 264210.

[Bug middle-end/87237] __atomic_load on 4-byte-sized, 1-byte-aligned struct is not atomic

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
(In reply to Richard Smith from comment #2)
> I think that's only true for objects whose size corresponds to that of a
> fundamental type. Consider:
> 
> struct B { char c[3]; };
> 
> Here, an atomic object of type B (eg, _Atomic(B) or std::atomic) would
> have size=4, align=4, and yet GCC treats B as having an alignment of 1 for
> the purpose of atomic accesses.

No, this does not appear to be true. With GCC size/align are 3/1 while with
Clang it's 4/4 as you said:

struct B { char c[3];};

_Atomic struct B b;

int a = _Alignof b;
int s = sizeof b;

s:
.long   3
[...]
a:
.long   1
.comm   b,3,1

[Bug middle-end/87237] __atomic_load on 4-byte-sized, 1-byte-aligned struct is not atomic

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #2 from Richard Smith  ---
(In reply to Alexander Monakov from comment #1)
> GCC assumes the access is sufficiently aligned for an atomic object of
> corresponding type

I think that's only true for objects whose size corresponds to that of a
fundamental type. Consider:

struct B { char c[3]; };

Here, an atomic object of type B (eg, _Atomic(B) or std::atomic) would have
size=4, align=4, and yet GCC treats B as having an alignment of 1 for the
purpose of atomic accesses.

Rather, GCC appears (from its external behavior) to consider only the object
size and not the alignment for atomic accesses, and assumes power-of-2-sized
objects to be aligned to their size (or to the maximum alignment of a
fundamental type, whichever is lower).

There exists code that assumes that GCC behaves as documented in this regard.
For example, libc++'s std::atomic makes this assumption, and as a result,
std::atomic is not atomic when using gcc with libc++. For that reason,
changing GCC to avoid the unwarranted alignment assumption seems superior to me
to updating the documentation to match the behavior. (For what it's worth, I
recently fixed Clang to behave per the GCC documentation in this regard; Clang
used to fall back to a libcall for the underaligned case, but would mistakenly
call the "optimized" library routines that assume the object is sufficiently
aligned.)

[Bug middle-end/87237] __atomic_load on 4-byte-sized, 1-byte-aligned struct is not atomic

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
GCC assumes the access is sufficiently aligned for an atomic object of
corresponding type, so either the documentation needs to mention that, or gcc
should stop "upgrading" alignment.

typedef int i1 __attribute__((aligned(1)));

int f(i1 *p)
{
  return __atomic_load_n(p, __ATOMIC_RELAXED);
}


We expand the load to (note A32)

(insn 6 3 7 2 (set (reg:SI 87 [ _4 ])
(mem/v:SI (reg/v/f:DI 89 [ p ]) [-1  S4 A32])) ttt.c:5 -1
 (nil))

[Bug fortran/87284] New: [7/8/9 Regression] Allocation of class arrays with mold results in "conditional jump or move depends on uninitialised value"

[pault at gcc dot gnu.org]

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

Bug ID: 87284
   Summary: [7/8/9 Regression] Allocation of class arrays with
mold results in "conditional jump or move depends on
uninitialised value"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: pault at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Reported by Andrew Baldwin on clf:

  MODULE INTS_TYPE_MODULE
TYPE, ABSTRACT :: BASE_TYPE
END TYPE BASE_TYPE

TYPE, EXTENDS (BASE_TYPE) :: INTS_TYPE
  INTEGER, ALLOCATABLE :: INTS(:)
END TYPE INTS_TYPE
  CONTAINS
SUBROUTINE MOLD_ALLOCATE (IT_OBJS, MOLD_OBJ)
  CLASS (BASE_TYPE), ALLOCATABLE, INTENT (OUT) :: IT_OBJS(:)
  CLASS (BASE_TYPE), INTENT (IN) :: MOLD_OBJ

  ALLOCATE (IT_OBJS(2), mold = MOLD_OBJ)

  RETURN
END SUBROUTINE MOLD_ALLOCATE
  END MODULE INTS_TYPE_MODULE

  PROGRAM MFE
USE INTS_TYPE_MODULE
IMPLICIT NONE

CLASS (BASE_TYPE), ALLOCATABLE :: IT_OBJS(:)
INTEGER :: I
TYPE (INTS_TYPE) :: MOLD_OBJ

ALLOCATE (INTS_TYPE :: IT_OBJS(2))

SELECT TYPE (IT_OBJS)
TYPE IS (INTS_TYPE)
  ALLOCATE (IT_OBJS(1)%INTS(10))

  ALLOCATE (IT_OBJS(2)%INTS(10))
END SELECT


DEALLOCATE (IT_OBJS)

CALL MOLD_ALLOCATE (IT_OBJS, MOLD_OBJ)

IF (ALLOCATED(IT_OBJS)) THEN
  IF (SIZE(IT_OBJS) .GE. 2) THEN
SELECT TYPE (IT_OBJS)
TYPE IS (INTS_TYPE)
  ALLOCATE (IT_OBJS(1)%INTS(10))

  ALLOCATE (IT_OBJS(2)%INTS(10))
END SELECT
  END IF
END IF
  END PROGRAM MFE

It produces the following code for the initialization after the allocation in
'mold_allocate':

{
  struct base_type[0:] * restrict D.3905;
  integer(kind=8) D.3906;
  integer(kind=8) D.3907;
  integer(kind=8) D.3908;
  struct base_type * D.3909;

  D.3905 = (struct base_type[0:] * restrict) it_objs->_data.data;
  D.3906 = it_objs->_data.offset;
  D.3907 = it_objs->_data.dim[0].lbound;
  D.3908 = it_objs->_data.dim[0].ubound;

/* This is OK - init expr for the dynamic type.  */

  D.3909 = it_objs->_vptr->_def_init;
  {
integer(kind=8) S.7;

S.7 = D.3907;
while (1)
  {
if (S.7 > D.3908) goto L.11;

/* Copied to elements of the base type  */

it_objs->_vptr->_copy (D.3909, &(*D.3905)[S.7 + D.3906]);
S.7 = S.7 + 1;
  }
L.11:;
  }
}

A trivial fix regtests OK:
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 264209)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_trans_class_init_assign (gfc_code *c
*** 1505,1511 
gfc_start_block ();

lhs = gfc_copy_expr (code->expr1);
-   gfc_add_data_component (lhs);

rhs = gfc_copy_expr (code->expr1);
gfc_add_vptr_component (rhs);
--- 1505,1510 
*** gfc_trans_class_init_assign (gfc_code *c
*** 1528,1533 
--- 1527,1533 
  }
else
  {
+   gfc_add_data_component (lhs);
sz = gfc_copy_expr (code->expr1);
gfc_add_vptr_component (sz);
gfc_add_size_component (sz);

It will be committed as 'obvious' when I have a moment.

Paul

[Bug fortran/87172] [9 Regression] Spurious "Derived type 'c_funptr' at (1) has not been declared" error after r263782

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Sep 11 17:44:04 2018
New Revision: 264214

URL: https://gcc.gnu.org/viewcvs?rev=264214=gcc=rev
Log:
fix PR 87172

2018-09-11  Janus Weil  

PR fortran/87172
* resolve.c (resolve_fl_derived): If a type has the 'use_assoc'
attribute, then it was declared in another module, so there should be
no error that it has not been declared.

2018-09-11  Janus Weil  

PR fortran/87172
* gfortran.dg/iso_c_binding_only_2.f90: New test case.

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

[Bug c++/87274] -std=c++11 breaks quadmath macros

[lopresti at gmail dot com]

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

--- Comment #3 from Patrick J. LoPresti  ---
Yes,  is an extension. But it would be nice, IMO, if it were a
standard-compatible extension.

So this is, as you say, a feature request somehow to enable quad-precision
literals in standard compilation modes. And I admit this was my real motivation
for the bug report in the first place.

Thanks.

[Bug fortran/87277] [8/9 regression] Segfault on using array component of class scalar pointer as an actual argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
Fixed on trunk and 8-branch.

Paul

[Bug lto/87283] [9 Regression] internal compiler error: in remove, at alloc-pool.h:433

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 44679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44679=edit
A testcase

./lto1 -quiet -dumpdir ./ -dumpbase gromacs.ltrans2 -mtune=generic
-march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
gromacs.ltrans2.ltrans.o -O2 -O2 -version -fno-openmp -fno-openacc -fno-pie
-ffast-math -fwhole-program -fuse-linker-plugin -fltrans /tmp/gromacs.ltrans2.o
-o gromacs.ltrans2.s

GNU GIMPLE (GCC) version 9.0.0 20180911 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20180726 (Red Hat 8.2.1-1), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 9.0.0 20180911 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20180726 (Red Hat 8.2.1-1), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
during GIMPLE pass: recip
sim_util.c: In function ‘do_force.constprop’:
sim_util.c:189:6: internal compiler error: in remove, at alloc-pool.h:433
0x9858fb base_pool_allocator::remove(void*)
/export/gnu/import/git/sources/gcc/gcc/alloc-pool.h:433
0x120cc1e object_allocator::remove(occurrence*)
/export/gnu/import/git/sources/gcc/gcc/alloc-pool.h:521
0x1201b97 free_bb
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-math-opts.c:523
0x1202ae9 execute_cse_reciprocals_1
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-math-opts.c:840
0x1202e1d execute
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-math-opts.c:923
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.

[Bug lto/87283] [9 Regression] internal compiler error: in remove, at alloc-pool.h:433

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
The patch I'm testing for PR 87259 fixes this as well. Though it may not be an
exact duplicate.

[Bug fortran/87277] [8/9 regression] Segfault on using array component of class scalar pointer as an actual argument

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Tue Sep 11 17:18:13 2018
New Revision: 264213

URL: https://gcc.gnu.org/viewcvs?rev=264213=gcc=rev
Log:
2018-09-11  Paul Thomas  

PR fortran/87277
* expr.c (is_subref_array): Add the check of dimensionality for
class, dummy, pointer arrays.

2018-09-11  Paul Thomas  

PR fortran/87277
* gfortran.dg/select_type_43.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_43.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug lto/87283] [9 Regression] internal compiler error: in remove, at alloc-pool.h:433

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Breakpoint 1, fancy_abort (
file=0x1fafb28 "/export/gnu/import/git/sources/gcc/gcc/alloc-pool.h", 
line=433, 
function=0x1fafb88
::remove(void*)::__FUNCTION__> "remove")
at /export/gnu/import/git/sources/gcc/gcc/diagnostic.c:1560
1560  internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
Missing separate debuginfos, use: dnf debuginfo-install
gmp-6.1.2-7.0.fc28.x86_64 isl-0.16.1-6.0.fc28.x86_64
libmpc-1.0.2-9.0.fc28.x86_64 mpfr-3.1.6-1.fc28.x86_64
zlib-1.2.11-8.1.fc28.x86_64
(gdb) bt
#0  fancy_abort (
file=0x1fafb28 "/export/gnu/import/git/sources/gcc/gcc/alloc-pool.h", 
line=433, 
function=0x1fafb88
::remove(void*)::__FUNCTION__> "remove")
at /export/gnu/import/git/sources/gcc/gcc/diagnostic.c:1560
#1  0x009858fc in base_pool_allocator::remove (
this=0x2fad900, object=0x2fe88e0)
at /export/gnu/import/git/sources/gcc/gcc/alloc-pool.h:433
#2  0x0120cc1f in object_allocator::remove (
this=0x2fad900, object=0x2fe88e0)
at /export/gnu/import/git/sources/gcc/gcc/alloc-pool.h:521
#3  0x01201b98 in free_bb (occ=0x2fe88e0)
at /export/gnu/import/git/sources/gcc/gcc/tree-ssa-math-opts.c:523
#4  0x01202aea in execute_cse_reciprocals_1 (def_gsi=0x0, def=
)
at /export/gnu/import/git/sources/gcc/gcc/tree-ssa-math-opts.c:840
#5  0x01202e1e in (anonymous namespace)::pass_cse_reciprocals::execute
(this=0x2bddb10, fun=0x7fffeace02c0)
at /export/gnu/import/git/sources/gcc/gcc/tree-ssa-math-opts.c:923
#6  0x00e64ea5 in execute_one_pass (
pass=)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2446
---Type  to continue, or q  to quit---
#7  0x00e651f6 in execute_pass_list_1 (
pass=)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2535
#8  0x00e65227 in execute_pass_list_1 (
pass=)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2536
#9  0x00e6527f in execute_pass_list (fn=0x7fffeace02c0, pass=
)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2546
#10 0x0096afd2 in cgraph_node::expand (
this=)
at /export/gnu/import/git/sources/gcc/gcc/cgraphunit.c:2121
#11 0x0096b603 in expand_all_functions ()
at /export/gnu/import/git/sources/gcc/gcc/cgraphunit.c:2259
#12 0x0096c166 in symbol_table::compile (this=0x7fffeadab100)
at /export/gnu/import/git/sources/gcc/gcc/cgraphunit.c:2610
#13 0x0086768b in lto_main ()
at /export/gnu/import/git/sources/gcc/gcc/lto/lto.c:3429
#14 0x00fc63d7 in compile_file ()
at /export/gnu/import/git/sources/gcc/gcc/toplev.c:455
#15 0x00fc8e9b in do_compile ()
at /export/gnu/import/git/sources/gcc/gcc/toplev.c:2170
#16 0x00fc9188 in toplev::main (this=0x7fffd45e, argc=25, 
---Type  to continue, or q  to quit---
argv=0x2ba9b00) at /export/gnu/import/git/sources/gcc/gcc/toplev.c:2305
#17 0x01e29162 in main (argc=25, argv=0x7fffd558)
at /export/gnu/import/git/sources/gcc/gcc/main.c:39
(gdb) f 1
#1  0x009858fc in base_pool_allocator::remove (
this=0x2fad900, object=0x2fe88e0)
at /export/gnu/import/git/sources/gcc/gcc/alloc-pool.h:433
433   gcc_assert (m_initialized);
(gdb) f 1
#1  0x009858fc in base_pool_allocator::remove (
this=0x2fad900, object=0x2fe88e0)
at /export/gnu/import/git/sources/gcc/gcc/alloc-pool.h:433
433   gcc_assert (m_initialized);
(gdb) p m_initialized
$1 = false
(gdb)

[Bug c++/86623] constexpr evaluation fails to give an error for modifying a const object

[jorrit at jorrit dot de]

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

Jö  changed:

   What|Removed |Added

 CC||jorrit at jorrit dot de

--- Comment #1 from Jö  ---
This looks like a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85125

[Bug lto/87283] New: [9 Regression] internal compiler error: in remove, at alloc-pool.h:433

[hjl.tools at gmail dot com]

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

Bug ID: 87283
   Summary: [9 Regression] internal compiler error: in remove, at
alloc-pool.h:433
   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: ktkachov at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r264126 caused LTO failure when building 435.gromacs in SPEC
CPU 2006:

gfortran  -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin 
-DSPEC_CPU_LP64flincs.o fsettle.fppized.o fshake.o innerf.o flincsd.o
fsettled.fppized.o fshaked.o 3dview.o atomprop.o binio.o block_tx.o bondfree.o
buffer.o calcgrid.o calch.o calcmu.o calcvir.o clincs.o comlib.o confio.o
constr.o copyrite.o coupling.o csettle.o disre.o do_fit.o do_gct.o dummies.o
ebin.o edsam.o enxio.o ewald.o ewald_util.o f77_wrappers.o fatal.o ffscanf.o
fftgrid.o filenm.o fnbf.o force.o futil.o gbutil.o gctio.o genalg.o ghat.o
glaasje.o gmx_system_xdr.o gmxfio.o ifunc.o index.o init.o init_sh.o innerc.o
invblock.o ionize.o libxdrf.o macros.o main.o maths.o matio.o md.o mdatom.o
mdebin.o mdrun.o memdump.o minimize.o mshift.o mvdata.o mvxvf.o names.o
network.o nrama.o nrjac.o nrnb.o ns.o nsb.o nsgrid.o orires.o pargs.o pbc.o
pdbio.o pme.o poisson.o pppm.o princ.o psgather.o pssolve.o psspread.o pull.o
pullinit.o pullio.o pullutil.o rando.o random.o rbin.o rdgroup.o readinp.o
relax_sh.o replace.o rmpbc.o shakef.o shift_util.o sim_util.o smalloc.o
sortwater.o splittop.o stat.o statutil.o strdb.o string2.o symtab.o synclib.o
tables.o tgroup.o tpxio.o trnio.o trxio.o txtdump.o typedefs.o update.o vcm.o
vec.o viewit.o wgms.o wman.o wnblist.o writeps.o xdrd.o xtcio.o xutils.o xvgr.o
-lm-o gromacs
...
during GIMPLE pass: recip
sim_util.c: In function 'do_force.constprop':
sim_util.c:189:6: internal compiler error: in remove, at alloc-pool.h:433
189 | void do_force(FILE *log,t_commrec *cr,t_commrec *mcr,
|  ^
0x6776a1 base_pool_allocator::remove(void*)
../../src-trunk/gcc/alloc-pool.h:433
0x6776a1 object_allocator::remove(occurrence*)
../../src-trunk/gcc/alloc-pool.h:521
0x6776a1 free_bb
../../src-trunk/gcc/tree-ssa-math-opts.c:523
0xd265cf execute_cse_reciprocals_1
../../src-trunk/gcc/tree-ssa-math-opts.c:840
0xd2945d execute
../../src-trunk/gcc/tree-ssa-math-opts.c:923
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccVGmyGV.mk:8: /tmp/gromacs.HLEgaE.ltrans2.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [gromacs] Error 1

[Bug c++/87282] New: Invalid use of 'void', in unevaluated context

[delrieutheo at gmail dot com]

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

Bug ID: 87282
   Summary: Invalid use of 'void', in unevaluated context
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: delrieutheo at gmail dot com
  Target Milestone: ---

Created attachment 44678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44678=edit
void pointers substraction bug

Hello,

I've been playing around with the detected idiom lately, and I stumbled across
a bug in GCC 8.2.0, when substracting two void* in an unevaluated context.

Adding those two void* works as expected (as shown in the attachment).

The attachment compiles with Clang 5.0.2.

[Bug fortran/87277] [8/9 regression] Segfault on using array component of class scalar pointer as an actual argument

[pault at gcc dot gnu.org]

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

--- Comment #1 from Paul Thomas  ---
Author: pault
Date: Tue Sep 11 15:59:07 2018
New Revision: 264210

URL: https://gcc.gnu.org/viewcvs?rev=264210=gcc=rev
Log:
2018-09-11  Paul Thomas  

PR fortran/87277
* expr.c (is_subref_array): Add the check of dimensionality for
class, dummy, pointer arrays.

2018-09-11  Paul Thomas  

PR fortran/87277
* gfortran.dg/select_type_43.f90: New test.


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

[Bug c/66658] missing -Wunused-value negating a function result in a comma expression

[ethouris at gmail dot com]

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

Michal Malecki  changed:

   What|Removed |Added

 CC||ethouris at gmail dot com

--- Comment #3 from Michal Malecki  ---
Just caught this one, too, something like:

if (x(a, b), c)
{ ... }

Where x is declared as

int x(int a, int b, int c = -1);

There should be at least a warning that "suggested parentheses around the
expression", not necessarily with every case where the "comma operator" is
used.

[Bug c/87242] optimize -O2 incorrect output

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-09-11
 CC||amonakov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Alexander Monakov  ---
Please either attach a compressed file as indicated by Andrew, or if you want
to minimize the testcase yourself, take a look at tools such as c-reduce or
multidelta.

Also make sure to explain what the problem is, the title of the bug is not
enough.

Note that gcc-5 is no longer supported.

[Bug middle-end/87276] Buggy code with -O2 in trunk revision 264170: MPFR test tstrtofr fails

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
I could simplify the code:

#include 
#include 

struct s { long e; };

static void f (struct s *ps)
{
  volatile long m = 9223372036854775807;
  const char *str = "11E";
  int r;
  long sum;

  ps->e = 0;

  for (;;)
{
  if (*str++ != '1')
break;
  ps->e ++;
}

  r = 1;
  sum = m;
  printf ("%ld\n", sum);

  if (sum >= 0 && ps->e >= 0)
{
  unsigned long uc;
  uc = (unsigned long) sum + (unsigned long) ps->e;
  if (uc > 9223372036854775807)
r = 2;
  else
sum = 17;
}
  else
sum = sum + ps->e;

  printf ("%ld\n", sum);
  printf ("%d\n", r);
  if (r != 2)
exit (1);
  ps->e = sum;
}

int main (void)
{
  struct s s;
  f ();
  return 0;
}

$ gcc-snapshot -O2 tst.c -o tst
$ ./tst
9223372036854775807
17
1
zsh: exit 1 ./tst

instead of

9223372036854775807
9223372036854775807
2

[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from Jonathan Wakely  ---
> Jay, is the original problem on SunOS still happening?
>
> Rainer, any insight into that build failure? Are some Solaris patches needed?

I don't think so: both in Solaris 10 FCS and in current Solaris 11.4,
 declares strsignal alike:

extern char *strsignal(int);

And for me, both HAVE_STRSIGNAL and HAVE_DECL_STRSIGNAL are defined as 1
in gcc/auto-host.h.

Jay needs to look at gcc/config.log in more detail to find why the
corresponding autoconf tests fail for him while they work here.

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

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

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

--- Comment #1 from Andreas Schwab  ---
Probably a dup of the various scheduler related qsort ICEs.

[Bug c++/87279] gcc violates §17.1.10

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/87278] [8/9 Regression] GCC 8 fails to compile make_shared()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 8.3

[Bug libstdc++/87278] [8/9 Regression] GCC 8 fails to compile make_shared()

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 11 11:51:10 2018
New Revision: 264208

URL: https://gcc.gnu.org/viewcvs?rev=264208=gcc=rev
Log:
PR libstdc++/87278 restore support for std::make_shared()

PR libstdc++/87278
* include/bits/shared_ptr.h (make_shared): Use remove_cv instead of
remove_const.
* testsuite/20_util/shared_ptr/creation/87278.cc: New test.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/shared_ptr/creation/87278.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/shared_ptr.h

[Bug libstdc++/87278] [8/9 Regression] GCC 8 fails to compile make_shared()

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 11 11:50:39 2018
New Revision: 264207

URL: https://gcc.gnu.org/viewcvs?rev=264207=gcc=rev
Log:
PR libstdc++/87278 restore support for std::make_shared()

PR libstdc++/87278
* include/bits/shared_ptr.h (make_shared): Use remove_cv instead of
remove_const.
* testsuite/20_util/shared_ptr/creation/87278.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/creation/87278.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr.h

[Bug target/87281] New: qsort checking ICE in ia64_reorg building libgo

[jsm28 at gcc dot gnu.org]

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

Bug ID: 87281
   Summary: qsort checking ICE in ia64_reorg building libgo
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: wilson at tuliptree dot org
  Target Milestone: ---
Target: ia64-*-*

Building an all-languages cross compiler for ia64-linux-gnu, trunk r264193, I
see the following ICE building libgo (I don't know how to produce any
equivalent of preprocessed source as a self-contained testcase for Go code, and
I don't know whether this is a regression):

/scratch/jmyers/glibc/many9/src/gcc/libgo/go/bytes/bytes.go: In function
'bytes.genSplit':
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/bytes/bytes.go:211:1: error: qsort
comparator non-negative on sorted output: 2
211 | func genSplit(s, sep []byte, sepSave, n int) [][]byte {
| ^
during RTL pass: mach
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/bytes/bytes.go:211:1: internal
compiler error: qsort checking failed
0x7388f2 qsort_chk_error
/scratch/jmyers/glibc/many9/src/gcc/gcc/vec.c:201
0x7389fc qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/scratch/jmyers/glibc/many9/src/gcc/gcc/vec.c:244
0x12dbde0 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/scratch/jmyers/glibc/many9/src/gcc/gcc/sort.cc:238
0x11d1b40 ready_sort_real
/scratch/jmyers/glibc/many9/src/gcc/gcc/haifa-sched.c:3089
0x11d95ca schedule_block(basic_block_def**, void*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/haifa-sched.c:6677
0x1256575 schedule_ebb(rtx_insn*, rtx_insn*, bool)
/scratch/jmyers/glibc/many9/src/gcc/gcc/sched-ebb.c:537
0x1256bf4 schedule_ebbs()
/scratch/jmyers/glibc/many9/src/gcc/gcc/sched-ebb.c:657
0xf40cfc ia64_reorg
/scratch/jmyers/glibc/many9/src/gcc/gcc/config/ia64/ia64.c:9859
0xbe42c9 execute
/scratch/jmyers/glibc/many9/src/gcc/gcc/reorg.c:3984
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:2941: recipe for target 'bytes.lo' failed
make[5]: *** [bytes.lo] Error 1

[Bug tree-optimization/87280] New: [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3647

[asolokha at gmx dot com]

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

Bug ID: 87280
   Summary: [9 Regression] ICE in set_ssa_val_to, at
tree-ssa-sccvn.c:3647
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 44677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44677=edit
Testcase

gcc-9.0.0-alpha20180909 snapshot (r264185) ICEs when compiling the attached
snippet w/ -O2 (-Os, -O3, -Ofast) --param rpo-vn-max-loop-depth=5:

% gcc-9.0.0-alpha20180909 -O2 --param rpo-vn-max-loop-depth=5 -w -c rilo1emt.c 
during GIMPLE pass: fre
rilo1emt.c: In function 'j8':
rilo1emt.c:58:1: internal compiler error: in set_ssa_val_to, at
tree-ssa-sccvn.c:3647
58 | }
   | ^
0x699fa5 set_ssa_val_to
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/tree-ssa-sccvn.c:3647
0xe63d78 visit_phi
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/tree-ssa-sccvn.c:4261
0xe6435f visit_stmt
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/tree-ssa-sccvn.c:4304
0xe65e89 process_bb
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/tree-ssa-sccvn.c:5923
0xe671a8 do_rpo_vn
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/tree-ssa-sccvn.c:6454
0xe67f8c execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180909/work/gcc-9-20180909/gcc/tree-ssa-sccvn.c:6646

[Bug libstdc++/87278] [8/9 Regression] GCC 8 fails to compile make_shared()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-09-11
  Known to work||7.3.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |8.3
Summary|GCC 8 fails to compile  |[8/9 Regression] GCC 8
   |make_shared() |fails to compile
   ||make_shared()
 Ever confirmed|0   |1
  Known to fail||8.2.0, 9.0

--- Comment #2 from Jonathan Wakely  ---
In general the standard committee's library working group is moving further and
further towards a position of "using volatile with the standard library is not
supported".

I'll fix this case though.

[Bug rtl-optimization/82982] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[segher at gcc dot gnu.org]

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

--- Comment #14 from Segher Boessenkool  ---
Erm, not Will.  Everyone :-)

[Bug middle-end/82407] [meta-bug] qsort_chk fallout tracking

[segher at gcc dot gnu.org]

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

Bug 82982 Summary: [8/9 Regression] ICE: qsort checking failed (error: qsort 
comparator non-negative on sorted output: 5) in ready_sort_real in haifa 
scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug rtl-optimization/82982] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #13 from Segher Boessenkool  ---
Will, So I'll close this PR now.  Please reopen if you can reproduce it again.
Thanks everyone!

[Bug c++/87279] New: gcc violates §17.1.10

[sp2danny at gmail dot com]

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

Bug ID: 87279
   Summary: gcc violates §17.1.10
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sp2danny at gmail dot com
  Target Milestone: ---

All versions of gcc (tested with godbolt) fails to compile the following:

# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.cpp"

template void f();
template void f() {}
int main() { f(); }

===

Tested (on godbolt) with -std=c++11 , -std=c++14 , -std=c++17 , fails equally
on all.
Tested (on godbolt) with all versions from 4.1 to 8.2 , fails equally on all.

The -save-temps output (above) was generated with gcc 4.9.2
The output of gcc -v is:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10+deb8u1'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10+deb8u1)

===

Commandline used:
g++ -std=c++11 test.cpp

(not that it matters, it fails regardless of parameters)
The exact error is:

test.cpp: In function ‘int main()’:
test.cpp:4:16: error: no matching function for call to ‘f()’
 int main() { f(); }
^
test.cpp:4:16: note: candidate is:
test.cpp:3:28: note: template void f()
 template void f() {}
^
test.cpp:3:28: note:   template argument deduction/substitution failed:
test.cpp:4:16: note:   couldn't deduce template parameter ‘T’
 int main() { f(); }

===

It may be noted that neither clang, MSVC nor icc have a problem with the above
code.
According to §17.1.10 the above code should be well defined.

[Bug tree-optimization/87042] UBSAN: poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
I'll fix that later in this stage1.

[Bug libstdc++/87278] GCC 8 fails to compile make_shared()

[okannen at gmail dot com]

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

Olivier Kannengieser  changed:

   What|Removed |Added

 CC||okannen at gmail dot com

--- Comment #1 from Olivier Kannengieser  ---
This bug appeared after commit 7086d631 "PR libstdc++/48101 improve errors for
invalid container specializations" which invalidated use of standard allocator
of cv qualified type.

[Bug libstdc++/87278] New: GCC 8 fails to compile make_shared()

[jzwinck at gmail dot com]

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

Bug ID: 87278
   Summary: GCC 8 fails to compile make_shared()
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jzwinck at gmail dot com
  Target Milestone: ---

This code compiled in GCC prior to 8.0, but fails to compile in GCC 8.1 and
8.2:

std::make_shared(0)

The error is:

bits/shared_ptr.h: In instantiation of 'std::shared_ptr<_Tp>
std::make_shared(_Args&& ...) [with _Tp = volatile int; _Args = {int}]':

bits/shared_ptr.h:718:45: error: no matching function for call to
'std::allocator::allocator()'

Demo: https://godbolt.org/z/rKy3od

Prior discussion:
https://stackoverflow.com/questions/52268878/gcc-8-fails-to-compile-make-sharedvolatile-int

[Bug tree-optimization/87259] [9 Regression] ICE: error: definition in block 3 does not dominate use in block 2

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. The transformation from r264126 isn't triggered here, but it looks
like the fact that execute_cse_reciprocals_1 didn't get to run on some of the
statements gives the ICE.
Testing a patch

[Bug c++/87274] -std=c++11 breaks quadmath macros

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Patrick J. LoPresti from comment #0)
> Note that my code does not use any quad-precision literals; just the
> documented `FLT128_MAX` macro.

Which is a quad-precision literal, of course.

> I realize quadmath is more a C thing than a C++ thing... But it would still
> be nice if this worked, IMO.

It does work if you use the right options to allow the necessary extensions.

> On a possibly related note, writing "__extension__" before a quad-precision
> literal does not silence this error. Perhaps it should (?)

Yes, maybe. Confirming for that feature request.

[Bug c++/87274] -std=c++11 breaks quadmath macros

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is not a bug. If you want to use the non-standard extensions in
 then either use -std=gnu++11 instead of -std=c++11, or use
-fext-numeric-literals to enable the non-standard suffixes, as suggested.

Using -std=c++11 says you want to disable GNU extensions that conflict with ISO
C++11.

[Bug c++/87275] unsequenced writes not diagnosed in constant expression

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Clang and EDG also compile it without error.

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
So it got way past stage 2 then:

(In reply to matthew.hambley from comment #1)
> It looks like it gets to stage 2 of the bootstrapping process, then it fails
> in
> the MPFR self-test in the way described.

Because it completed the bootstrap successfully, and only failed during
checking.

You should use -k when running make check, so it continues past errors like
this.

[Bug bootstrap/86615] gcc build failure: auto-host.h error: declaration does not declare anything [-fpermissive]

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Botcazou  ---
Then remove -fpermissive and retry, we cannot support random flags.

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

[Bug other/82590] auto-host.h error: declaration does not declare anything

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Botcazou  ---
.

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

[Bug bootstrap/56954] Bootstrap failure: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive]

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||mdenber at gmx dot com
 CC||bastl at eclipso dot de

--- Comment #2 from Eric Botcazou  ---
*** Bug 86615 has been marked as a duplicate of this bug. ***

--- Comment #3 from Eric Botcazou  ---
*** Bug 82590 has been marked as a duplicate of this bug. ***

[Bug bootstrap/56954] Bootstrap failure: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive]

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||mdenber at gmx dot com
 CC||bastl at eclipso dot de

--- Comment #2 from Eric Botcazou  ---
*** Bug 86615 has been marked as a duplicate of this bug. ***

--- Comment #3 from Eric Botcazou  ---
*** Bug 82590 has been marked as a duplicate of this bug. ***

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

[matthew.hambley at metoffice dot gov.uk]

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

--- Comment #6 from matthew.hambley at metoffice dot gov.uk ---
> That does look like a problem. But why are the mpfr tests running as part of
> bootstrap? I don't think they do for me.

In which case I think I have misunderstood how the build system works. I
presumed that the dependencies would be tested before they were used. However
you are suggesting that they are not tested until the compiler is tested.

> I only see tversion built as part of "make check"

I have cut "make check install" down to "make install" in my build script and
it does indeed run to completion. Of course now I have an untested compiler
which is a little alarming but it helps identify the source of the problem.

Apologies for the wild goose chase.

[Bug rtl-optimization/87273] [8/9 Regression] ICE in merge_fences, at sel-sched-ir.c:708

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

Virtual Office & Virtual Assistant

[BuBleik SAL]

BuBleik SAL
Virtual Office & Virtual Assistant



Virtual Office: Business Address, Safe Locker, Remote Assistance, Meeting Room, 
Telephone Answering, Voicemail to Email, Fax to Email, Call Forwarding.



Virtual Assistant: Courier Management, Document Archiving, RSVP, Appointment 
Settings, Bookkeeping, Check Collection, Call Ordering and Fulfillment.








SUBSCRIBE NOW[Ads961.com] Professional Advertisement in Lebanon(email) 

b...@adsleb.com (Tel) 

+961 1 411 410 (whatsapp) 

+961 71 072 786If you no longer wish to receive mail from us, you can   
 

unsubscribe

Ads961, Badaro, Beirut, LB, 50-110, Lebanon

[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Sep 11 06:33:39 2018
New Revision: 264201

URL: https://gcc.gnu.org/viewcvs?rev=264201=gcc=rev
Log:
fix PR 86830

2018-09-11  Janus Weil  

PR fortran/86830
* expr.c (gfc_is_simply_contiguous): Handle type-bound procedure calls
with non-polymorphic objects.

2018-09-11  Janus Weil  

PR fortran/86830
* gfortran.dg/typebound_call_30.f90: New test case.

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

[Bug fortran/87277] New: [8/9 regression] Segfault on using array component of class scalar pointer as an actual argument

[pault at gcc dot gnu.org]

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

Bug ID: 87277
   Summary: [8/9 regression] Segfault on using array component of
class scalar pointer as an actual argument
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: pault at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Reported by Andrew Baldwin on clf. This segfaults in 8- and 9-branches.

  MODULE INTS_TYPE_MODULE
TYPE INTS_TYPE
  INTEGER, ALLOCATABLE :: INTS(:)
END TYPE INTS_TYPE
  CONTAINS
SUBROUTINE ALLOCATE_INTS_TYPE (IT_OBJ)
  CLASS (INTS_TYPE), POINTER, INTENT (OUT) :: IT_OBJ

  ALLOCATE (INTS_TYPE :: IT_OBJ)

  SELECT TYPE (IT_OBJ)
  TYPE IS (INTS_TYPE)
CALL ALLOCATE_ARRAY (IT_OBJ%INTS)
  END SELECT

  RETURN
END SUBROUTINE ALLOCATE_INTS_TYPE

SUBROUTINE ALLOCATE_ARRAY (ALLOC_ARR)
  INTEGER, ALLOCATABLE, INTENT (OUT) :: ALLOC_ARR(:)
  INTEGER :: I

  ALLOCATE (ALLOC_ARR(4))

  DO I = 1, SIZE(ALLOC_ARR)
ALLOC_ARR(I) = I
  END DO

  RETURN
END SUBROUTINE ALLOCATE_ARRAY
  END MODULE INTS_TYPE_MODULE

  PROGRAM MFE
USE INTS_TYPE_MODULE
IMPLICIT NONE

CLASS (INTS_TYPE), POINTER :: IT_OBJ

CALL ALLOCATE_INTS_TYPE (IT_OBJ)
  END PROGRAM MFE

The fix is regtesting and will be committed tonight as obvious.

Paul