税+++票+++业++务

[ootza]

gcc-bugs@gcc.gnu.org
+
开各地正规普通税票，点优惠，包真。
详电：赵小姐
手机：136-202-176-05
业务QQ：1007-255-090
++15:29
皮铜关乃毫功透功蹬

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[abel at gcc dot gnu.org]

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

--- Comment #9 from Andrey Belevantsev  ---
Eric, thanks for pointing me out to the old PR.  From that and what I could
understand here from the sched logs, it's not clear to me how to correctly
clone REG_ARGS_SIZE insns, so the safest patch of forbidding that completely
works fine.  Alexander, if you have an idea of what can be checked in the
scheduler to relax that, please let me know, I'm happy to implement that.

The safe patch is just like this:

diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 85ff5bd3eb4..05d7eaa72c7 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -3024,6 +3024,10 @@ init_global_and_expr_for_insn (insn_t insn)
   else
 force_unique_p = false;

+/* Do not copy REG_ARGS_SIZE insns as we fail to adjust them properly
(PR86979).  */
+if (find_reg_note (insn, REG_ARGS_SIZE, NULL))
+  force_unique_p = true;
+
 if (targetm.sched.get_insn_spec_ds)
   {
spec_done_ds = targetm.sched.get_insn_spec_ds (insn);

[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[dongjianqiang2 at huawei dot com]

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

--- Comment #23 from John Dong  ---
diff -urp a/gcc/expr.c b/gcc/expr.c
--- a/gcc/expr.c2019-01-09 03:19:03.750205982 +0800
+++ b/gcc/expr.c2019-01-09 03:38:23.414174738 +0800
@@ -10760,6 +10760,16 @@ expand_expr_real_1 (tree exp, rtx target
&& GET_MODE_CLASS (ext_mode) == MODE_INT)
  reversep = TYPE_REVERSE_STORAGE_ORDER (type);

+   int modePrecision = GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE
(tem)));
+   int typePrecision = TYPE_PRECISION (TREE_TYPE (tem));
+   int shiftSize = modePrecision - typePrecision;
+   rtx regTarget = gen_reg_rtx (GET_MODE (op0));
+
+   if (shiftSize && REG_P (op0))
+ op0 = expand_shift (LSHIFT_EXPR, GET_MODE (op0), op0,
+ shiftSize, regTarget,
+ TYPE_UNSIGNED (TREE_TYPE (tem)));
+
op0 = extract_bit_field (op0, bitsize, bitpos, unsignedp,
 (modifier == EXPAND_STACK_PARM
  ? NULL_RTX : target),

Tried to fix the bug when expand.

[Bug target/88765] New: powerpc64le-linux-gnu sub-optimal code generation for builtin atomic ops

[npiggin at gmail dot com]

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

Bug ID: 88765
   Summary: powerpc64le-linux-gnu sub-optimal code generation for
builtin atomic ops
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
  Target Milestone: ---
Target: powerpc64le-linux-gnu

gcc version 8.2.0 (Debian 8.2.0-4) 

Linux uses a lot of non-trivial operations, and implementing them with
compare_exchange results in sub-optimal code generation. A common one is
add_unless_zero, which is commonly used with RCU to take a reference count, or
fail if the last reference had already gone (which is a very rare case).

---
#include 

bool add_unless_zero(unsigned long *mem, unsigned long inc)
{
unsigned long val;
do {
val = __atomic_load_n(mem, __ATOMIC_RELAXED);
if (__builtin_expect(val == 0, false))
return false;
} while (__builtin_expect(!__atomic_compare_exchange_n(mem,
, val + inc, true,
__ATOMIC_RELAXED, __ATOMIC_RELAXED), false));

return true;
}
---
This compiles to:

add_unless_zero:
.L4:
ld 10,0(3)
cmpdi 7,10,0
add 8,10,4
beq 7,.L5
ldarx 9,0,3
cmpd 0,9,10
bne 0,.L3
stdcx. 8,0,3
.L3:
bne 0,.L4
li 3,1
blr
.L5:
li 3,0
blr

Better would be

add_unless_zero:
.L4:
ldarx 9,0,3
cmpdi 0,9,0
add 9,9,4
bne 0,.L5
stdcx. 8,0,3
bne 0,.L4
li 3,1
blr
.L5:
li 3,0
blr

Using extended inline asm to implement these is an adequate workaround.
Unfortunately that does not work on 128 bit powerpc because no register pair
constraint, and much worse code generation with builtins. Changing types to
__int128_t gives a bad result:

add_unless_zero:
lq 10,0(3)
mr 6,3
or. 9,10,11
addc 3,11,4
mr 7,11
adde 11,10,5
beq 0,.L16
std 28,-32(1)
std 29,-24(1)
std 30,-16(1)
std 31,-8(1)
.L12:
lqarx 28,0,6
xor 9,29,7
xor 10,28,10
or. 9,9,10
bne 0,.L4
mr 30,11
mr 31,3
stqcx. 30,0,6
.L4:
mfcr 3,128
rlwinm 3,3,3,1
bne 0,.L17
.L2:
ld 28,-32(1)
ld 29,-24(1)
ld 30,-16(1)
ld 31,-8(1)
blr
.L17:
lq 10,0(6)
or. 9,10,11
addc 3,11,4
mr 7,11
adde 11,10,5
bne 0,.L12
li 3,0
b .L2
.L16:
li 3,0
blr

Closer to ideal would be

add_unless_zero:
.Lagain:
   lqarx   6,0,3
   or. 8,6,7
   addc6,6,4
   adde7,7,5
   beq 0,.Lfail
   stqcx.  6,0,3
   bne 0,.Lagain
   li  3,1
   blr
.Lfail:
   li  3,0
   blr

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[juergen.reuter at desy dot de]

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

--- Comment #16 from Jürgen Reuter  ---
Yes, after the problem occurred, I did a completely clean new build of gmp,
mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/
--with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mpc=/usr/local/
--enable-checking=release --enable-languages=c,c++,fortran,lto),
all the tools our software depends, and our software. It turns out that
external C++ libraries linked into our (Fortran) project via bind(C) are not a
problem if they have been built via libtool, such that a .dylib, a .a and a .la
file are present. The two projects that have problem either exist as .dylib and
.a produced by hand-written configure and makefiles (i.e. not using autotools),
or only as dynamic libraries produced via cmake and make.

[Bug c++/87436] [7 Regression] G++ produces >300MB .rodata section to initialize struct with big array

[metalcaedes at gmail dot com]

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

--- Comment #13 from Daniel Gibson  ---
Great, thanks a lot for fixing this!

[Bug tree-optimization/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||crazylht at gmail dot com,
   ||wei3.xiao at intel dot com,
   ||xuepeng.guo at intel dot com
 Resolution|WORKSFORME  |---
Summary|[9 Regression] SPEC |[9 Regression] r263772
   |CPU2017, CPU2006 520/620,   |miscompiled 520.omnetpp_r
   |403 runfails after r263772  |in SPEC CPU 2017
   |with march=skylake-avx512   |

--- Comment #3 from H.J. Lu  ---
On Intel machine with AVX512F,  r263772 miscompiled 520.omnetpp_r in SPEC
CPU 2017 with

-DSPEC -DSPEC_CPU -DNDEBUG -Isimulator/platdep -Isimulator -Imodel
-DWITH_NETBUILDER -DSPEC_AUTO_SUPPRESS_OPENMP  -fno-unsafe-math-optimizations
-mfpmath=sse -g -march=native -Ofast -funroll-loops -flto -DSPEC_LP64 

Program received signal SIGSEGV, Segmentation fault.
0x004a8ddb in cObject::isName (s=, this=)
at simulator/cobject.h:118
118 bool isName(const char *s) const {return !opp_strcmp(getName(),s);}
(gdb) bt
#0  0x004a8ddb in cObject::isName (s=, 
this=) at simulator/cobject.h:118
#1  cComponent::findPar (this=0x699040, parname=0x669c58 "bs")
at simulator/ccomponent.cc:143
#2  0x004acdb4 in cComponent::par (this=0x699040, 
parname=0x669c58 "bs") at simulator/ccomponent.cc:133
#3  0x004be27c in cNEDNetworkBuilder::doParam (this=0x7fffd500, 
component=0x699040, paramNode=0x669bd0, isSubcomponent=)
at simulator/cnednetworkbuilder.cc:179
#4  0x004c0020 in cNEDNetworkBuilder::doParams (isSubcomponent=false, 
paramsNode=, component=0x699040, this=0x7fffd500)
at simulator/cnednetworkbuilder.cc:139
#5  cNEDNetworkBuilder::addParametersAndGatesTo (this=0x7fffd500, 
component=0x699040, decl=0x695e60) at simulator/cnednetworkbuilder.cc:105
#6  0x0048a1bd in cDynamicModuleType::addParametersAndGatesTo (
module=0x699040, this=)
at /export/ssd/git/gcc-test-spec/usr/include/c++/9.0.0/bits/stl_tree.h:211
#7  cModuleType::create (this=, modname=, 
parentmod=, vectorsize=, 
index=) at simulator/ccomponenttype.cc:156
#8  0x004643aa in cModuleType::create (parentmod=0x0, 
modname=, this=)
at simulator/ccomponenttype.cc:106
--Type  for more, q to quit, c to continue without paging--
#9  cSimulation::setupNetwork (network=, this=)
at simulator/csimulation.cc:369
#10 Cmdenv::run (this=0x624d80) at simulator/cmdenv.cc:253
#11 0x0051673c in EnvirBase::run (this=0x624d80, argc=, 
argv=, configobject=0x61a640) at simulator/envirbase.cc:230
#12 0x004421b2 in setupUserInterface(int, char**, cConfiguration*)
[clone .constprop.0] (argc=argc@entry=5, argv=argv@entry=0x7fffdc18,
cfg=0x0)
at simulator/startup.cc:234
#13 0x0042f2fd in main (argc=5, argv=0x7fffdc18)
at simulator/main.cc:39
(gdb) 
...
  0x004a8db5 <+325>:lea0x1(%r15),%rbx
   0x004a8db9 <+329>:   mov0x58(%rbp),%r8
   0x004a8dbd <+333>:   lea(%rbx,%rbx,2),%rdi
   0x004a8dc1 <+337>:   lea(%r8,%rdi,8),%rdi
   0x004a8dc5 <+341>:   mov(%rdi),%r9
   0x004a8dc8 <+344>:   mov%ebx,%r12d
   0x004a8dcb <+347>:   mov0x30(%r9),%rax
   0x004a8dcf <+351>:   cmp$0x4a8080,%rax
   0x004a8dd5 <+357>:   je 0x4a8d20 
=> 0x004a8ddb <+363>:   callq  *%rax
   0x004a8ddd <+365>:   mov%rax,%rdi
   0x004a8de0 <+368>:   test   %rax,%rax
   0x004a8de3 <+371>:   jne0x4a8d47 
   0x004a8de9 <+377>:   cmpb   $0x0,0x0(%r13)
   0x004a8dee <+382>:   jne0x4a8d57 
   0x004a8df4 <+388>:   add$0x8,%rsp
   0x004a8df8 <+392>:   pop%rbx
   0x004a8df9 <+393>:   pop%rbp
   0x004a8dfa <+394>:   mov%r12d,%eax
   0x004a8dfd <+397>:   pop%r12
   0x004a8dff <+399>:   pop%r13
   0x004a8e01 <+401>:   pop%r14
   0x004a8e03 <+403>:   pop%r15
   0x004a8e05 <+405>:   retq   
   0x004a8e06 <+406>:   nopw   %cs:0x0(%rax,%rax,1)
   0x004a8e10 <+416>:   callq  *%rax
   0x004a8e12 <+418>:   mov%rax,%rdi
--Type  for more, q to quit, c to continue without paging--q
Quit
(gdb) p/x $rax
$1 = 0x5c8d48009b85
(gdb) p/x *(long *) $rax
Cannot access memory at address 0x5c8d48009b85
(gdb) 

This address looks odd.

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

[hjl.tools at gmail dot com]

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

Bug 87214 Summary: [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 
2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Agreed.  Thanks for the test case.  I'm working on a patch.

[Bug fortran/86322] ICE in reference_record with data statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Tue, Jan 08, 2019 at 09:40:29PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> Naw, it is is not due to my patch.  Rather my patch has
> exposed or uncovered a bug in gfortran.  gfortran needs
> to check
> 
> F2018:C877 (R839) A data-i-do-object or a variable that appears as a
>data-stmt-object shall not be an object designator in which a pointer
>appears other than as the entire rightmost part-ref .
> 
> In decl.c (gfc_match_data), gfortran needs a check for C877.
> I haven't gotten around to fixing this yet, and I likely won't
> for the foreseeable future.
> 

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 267735)
+++ gcc/fortran/decl.c  (working copy)
@@ -655,6 +655,15 @@ gfc_match_data (void)
 "near %C in DATA statement");
  goto cleanup;
}
+
+ if (e->symtree->n.sym->ts.type == BT_DERIVED
+ && e->symtree->n.sym->attr.pointer
+ && e->ref->type == REF_COMPONENT)
+   {
+ gfc_error ("part-ref with pointer attribute near %L is not "
+"rightmost component of data-stmt-object", >where);
+ goto cleanup;
+   }
}

   m = top_val_list (new_data);

The above is marginally correct.  It may be a starting point for
someone who cares about this bug and wants to fix it.  The patch
checks if the leftmost part-ref has the pointer attribute and 
the variable is a REF_COMPONENT, which means that a part-ref
other than the rightmost component has the pointer attribute.
This is the simple case.  A better patch would need to check
each part-ref for the pointer attribute.  That is none of a, b,
c, d, or e in a%b%c%d%e%i can have a pointer attribute.

Note, this works

program bar
   type a
 integer, pointer :: i
   end type a
   type b
 type(a) j
   end type b
   integer, target, save :: k = 42
   type(b) x
   data x%j%i/k/
   print *, x%j%i
end program bar

This gives an ICE like the one reported in this PR.  'j'
has the pointer attribute and so the program should be
rejected.

program bah
   type a
 integer :: i
   end type a
   type b
 type(a), pointer :: j
   end type b
   integer, target, save :: k = 42
   type(b) x
   data x%j%i /k/
   print *, x%j%i
end program bah

[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
Note that there are also such cases as

static int x;
struct s { int a[sizeof(x)]; } inline *f (void) { return 0; }

where the reference to x is part of the return type (still syntactically 
part of the inline definition, so I think still included in what should be 
diagnosed).  So it will be necessary to track references to identifiers 
with internal linkage in such contexts which might or might not turn out 
to be part of an inline definition - not just (for example) in what might 
or might not be a function prototype scope for an inline function.

[Bug target/88756] [nvptx, openacc] Override too many num_workers in nvptx plugin, instead of erroring out

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Author: vries
Date: Wed Jan  9 00:07:55 2019
New Revision: 267747

URL: https://gcc.gnu.org/viewcvs?rev=267747=gcc=rev
Log:
[libgomp, testsuite, openacc] Don't use const int for dimensions

Const int is handled differently at -O0 for -xc and -xc++, which can cause
noise
in testsuite/libgomp.oacc-c-c++-common test-cases (which are both run for c and
c++) if const int is used for launch dimensions.

Fix this by using #defines instead.

2019-01-09  Tom de Vries  

PR target/88756
* testsuite/libgomp.oacc-c-c++-common/reduction-1.c (ng, nw, vl): Use
#define instead of "const int".
* testsuite/libgomp.oacc-c-c++-common/reduction-2.c (ng, nw, vl): Same.
* testsuite/libgomp.oacc-c-c++-common/reduction-3.c (ng, nw, vl): Same.
* testsuite/libgomp.oacc-c-c++-common/reduction-4.c (ng, nw, vl): Same.
* testsuite/libgomp.oacc-c-c++-common/reduction-5.c (ng, nw, vl): Same.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-3.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-4.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-5.c

[Bug c++/88744] class non-type template parameters doesn't work with default template parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/88744] class non-type template parameters doesn't work with default template parameters

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jan  8 23:54:47 2019
New Revision: 267744

URL: https://gcc.gnu.org/viewcvs?rev=267744=gcc=rev
Log:
PR c++/88744
* g++.dg/cpp2a/nontype-class12.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class12.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/88744] class non-type template parameters doesn't work with default template parameters

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Err, this one:

#define SA(X) static_assert((X),#X)

struct S {
  int a;
  int b;
  constexpr S(int a_, int b_) : a{a_}, b{b_} { }
};

template
struct X {
  static constexpr int i = s.a;
  static constexpr int j = s.b;
};
X x; // ok, X<{1, 2}>
X<{3, 4}> x2;

SA (x.i == 1);
SA (x.j == 2);
SA (x2.i == 3);
SA (x2.j == 4);

[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
Fixed for GCC 9, but I might make the minimal fix on the gcc-8-branch.

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Tue Jan  8 23:15:49 2019
New Revision: 267743

URL: https://gcc.gnu.org/viewcvs?rev=267743=gcc=rev
Log:
Pretty printer test fixes and improvements

Test that StdUniquePtrPrinter correctly prints std::unique_ptr objects
using the old layout, prior to the PR libstdc++/77990 changes.

The printer test for a valueless std::variant started to fail because
the PR libstdc++/87431 fix meant it no longer became valueless. Change
the test to use a type that is not trivially copyable, so that the
exception causes it to become valueless.

* testsuite/libstdc++-prettyprinters/compat.cc: Test printer support
for old std::unique_ptr layout.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Fix std::variant test
to become valueless. Add filesystem::path tests.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/compat.cc
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc

[Bug libstdc++/77990] unique_ptr::unique_ptr(T*) imposes CopyConstructible on the deleter

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue Jan  8 23:15:49 2019
New Revision: 267743

URL: https://gcc.gnu.org/viewcvs?rev=267743=gcc=rev
Log:
Pretty printer test fixes and improvements

Test that StdUniquePtrPrinter correctly prints std::unique_ptr objects
using the old layout, prior to the PR libstdc++/77990 changes.

The printer test for a valueless std::variant started to fail because
the PR libstdc++/87431 fix meant it no longer became valueless. Change
the test to use a type that is not trivially copyable, so that the
exception causes it to become valueless.

* testsuite/libstdc++-prettyprinters/compat.cc: Test printer support
for old std::unique_ptr layout.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Fix std::variant test
to become valueless. Add filesystem::path tests.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/compat.cc
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx17.cc

[Bug c++/88744] class non-type template parameters doesn't work with default template parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-08
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
But actually this works so I'm not sure if there's anything to be done except
adding the test.

#define SA(X) static_assert((X),#X)

struct S {
  int a;
  int b;
  constexpr S(int, int) : a(1), b(2) { }
};

template
struct X {
  static constexpr int i = s.a;
  static constexpr int j = s.b;
};
X x; // ok, X<{1, 2}>

SA (x.i == 1);
SA (x.j == 2);

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #14)
> Well, it seems that r267488 from Dec 31 was still working, on the other
> hand, I saw a problem on the other MACbook definitely around at latest Dec
> 26 or so. Probably before Christmas. It might be that small updates did not
> trigger a complete recompilation of the trunk? 

Have you done a complete clean rebuild of both compiler and application?
( partial rebuilds are hard to analyse at the best of times ).

31st is after most of the Darwin-specific changes went in.

I will look at the transcripts tomorrow/

[Bug fortran/88376] [7/8/9 Regression] ICE in is_illegal_recursion, at fortran/resolve.c:1689

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, Jan 08, 2019 at 08:35:21PM +, janus at gcc dot gnu.org wrote:
> 
> --- Comment #2 from janus at gcc dot gnu.org ---
> (In reply to Dominique d'Humieres from comment #1)
> > The change of behavior occurred between revision r258235 (2018-03-04, error)
> > and r258362 (2018-03-08, ICE) and has been back ported to GCC6 and 7.
> 
> Based on this information, I'd guess that r258347 is the culprit:
> 
> 2018-03-07  Steven G. Kargl  
> 
> PR fortran/64124
> PR fortran/70409
> * decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.
> 

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 267735)
+++ gcc/fortran/resolve.c   (working copy)
@@ -1686,8 +1686,6 @@ is_illegal_recursion (gfc_symbol* sym, gfc_namespace* 
   || gfc_fl_struct (sym->attr.flavor))
 return false;

-  gcc_assert (sym->attr.flavor == FL_PROCEDURE);
-
   /* If we've got an ENTRY, find real procedure.  */
   if (sym->attr.entry && sym->ns->entries)
 proc_sym = sym->ns->entries->sym;

[Bug c/88718] Strange inconsistency between old style and new style definitions of inline functions.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5,
   ||4.9.4, 5.4.0, 6.4.0, 7.3.0,
   ||8.2.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The first test case was never diagnosed.  Suppressing the error for
the second test case would be easy but I agree that we want it in both cases so
that the following is diagnosed as well as I think it should be:

  static int x;

  inline int f (int (*p)[sizeof x])
  {
return sizeof *p;
  }

[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
Author: redi
Date: Tue Jan  8 23:00:46 2019
New Revision: 267742

URL: https://gcc.gnu.org/viewcvs?rev=267742=gcc=rev
Log:
PR libstdc++/87855 fix optional for types with non-trivial copy/move

When the contained value is not trivially copy (or move) constructible
the union's copy (or move) constructor will be deleted, and so the
_Optional_payload delegating constructors are invalid. G++ fails to
diagnose this because it incorrectly performs copy elision in the
delegating constructors. Clang does diagnose it (llvm.org/PR40245).

The solution is to avoid performing any copy (or move) when the
contained value's copy (or move) constructor isn't trivial. Instead the
contained value can be constructed by calling _M_construct. This is OK,
because the relevant constructor doesn't need to be constexpr when the
contained value isn't trivially copy (or move) constructible.

Additionally, this patch removes a lot of code duplication in the
_Optional_payload partial specializations and the _Optional_base partial
specialization, by hoisting it into common base classes.

The Python pretty printer for std::optional needs to be adjusted to
support the new layout. Retain support for the old layout, and add a
test to verify that the support still works.

PR libstdc++/87855
* include/std/optional (_Optional_payload_base): New class template
for common code hoisted from _Optional_payload specializations. Use
a template for the union, to allow a partial specialization for
types with non-trivial destructors. Add constructors for in-place
initialization to the union.
(_Optional_payload(bool, const _Optional_payload&)): Use _M_construct
to perform non-trivial copy construction, instead of relying on
non-standard copy elision in a delegating constructor.
(_Optional_payload(bool, _Optional_payload&&)): Likewise for
non-trivial move construction.
(_Optional_payload): Derive from _Optional_payload_base and use it
for everything except the non-trivial assignment operators, which are
defined as needed.
(_Optional_payload): Derive from the specialization
_Optional_payload and add a destructor.
(_Optional_base_impl::_M_destruct, _Optional_base_impl::_M_reset):
Forward to corresponding members of _Optional_payload.
(_Optional_base_impl::_M_is_engaged, _Optional_base_impl::_M_get):
Hoist common members from _Optional_base.
(_Optional_base): Make all members and base class public.
(_Optional_base::_M_get, _Optional_base::_M_is_engaged): Move to
_Optional_base_impl.
* python/libstdcxx/v6/printers.py (StdExpOptionalPrinter): Add
support for new std::optional layout.
* testsuite/libstdc++-prettyprinters/compat.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/compat.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/optional
trunk/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug fortran/68426] Simplification of SPREAD with a derived type element is unimplemented

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from Thomas Koenig  ---
This deceptively simple patch seems to do the job:

Index: simplify.c
===
--- simplify.c  (Revision 267736)
+++ simplify.c  (Arbeitskopie)
@@ -7572,7 +7572,7 @@ gfc_simplify_spread (gfc_expr *source, gfc_expr *d
return NULL;
 }

-  if (source->expr_type == EXPR_CONSTANT)
+  if (source->expr_type == EXPR_CONSTANT || source->expr_type ==
EXPR_STRUCTURE)
 {
   gcc_assert (dim == 0);

[Bug c++/88538] parse error with class nontype template parameter

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
This should work with GCC 9 now.  Thanks for the report Hana!

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[juergen.reuter at desy dot de]

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

--- Comment #14 from Jürgen Reuter  ---
Well, it seems that r267488 from Dec 31 was still working, on the other hand, I
saw a problem on the other MACbook definitely around at latest Dec 26 or so.
Probably before Christmas. It might be that small updates did not trigger a
complete recompilation of the trunk? 
This one is failing:
gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
static_1.exe .libs/static_1.exe_prclib_dispatcher.o 
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hepmc
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/lcio
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hoppet
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/looptools
-L/usr/local/packages/OpenLoops/lib -L/usr/local/lib -L../src
./.libs/static_1_lib.a
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/models
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core/.libs/libwhizard_main.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libomega.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/omega/src/.libs/libomega_core.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libwhizard.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/vamp/src/.libs/libvamp.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe1/src/.libs/libcirce1.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe2/src/.libs/libcirce2.a
-lcuttools -lopenloops -loneloop -lolcommon -lrambo /usr/local/lib/libLHAPDF.a
/usr/local//lib/libHepMC.a -llcio /usr/local/lib/libstdc++.a
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs
-lm 

while that one is working:

gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
static_1.exe .libs/static_1.exe_prclib_dispatcher.o 
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hepmc
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/lcio
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/hoppet
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/looptools
-L/usr/local/packages/OpenLoops/lib -L/usr/local/lib -L../src
./.libs/static_1_lib.a
-L/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/models
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/whizard-core/.libs/libwhizard_main.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libomega.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/omega/src/.libs/libomega_core.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/src/.libs/libwhizard.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/vamp/src/.libs/libvamp.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe1/src/.libs/libcirce1.a
/Users/reuter/Physik/whizard/trunk/_build_quasi_naked/circe2/src/.libs/libcirce2.a
-lcuttools -lopenloops -loneloop -lolcommon -lrambo /usr/local/lib/libLHAPDF.a
-L/usr/local/lib/gcc/x86_64-apple-darwin18.2.0/9.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin18.2.0/9.0.0/../../..
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/src/.libs
-L/usr/local/packages/gcc_9.0/_build/x86_64-apple-darwin18.2.0/libstdc++-v3/libsupc++/.libs
-lSystem -lgcc_ext.10.5 /usr/local//lib/libHepMC.a -lstdc++ -llcio -lm

But that's probably not very helpful for you.

[Bug c++/88538] parse error with class nontype template parameter

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jan  8 22:33:04 2019
New Revision: 267741

URL: https://gcc.gnu.org/viewcvs?rev=267741=gcc=rev
Log:
PR c++/88538 - braced-init-list in template-argument-list.
* parser.c (cp_parser_template_argument): Handle braced-init-list when
in C++20.

* g++.dg/cpp2a/nontype-class11.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/79593] [7/8/9 Regression] Poor/Worse code generation for FPU on versions after 6

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  8 22:29:56 2019
New Revision: 267740

URL: https://gcc.gnu.org/viewcvs?rev=267740=gcc=rev
Log:
PR rtl-optimization/79593
* config/i386/i386.md (reg = mem; mem = reg): New define_peephole2.

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

[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[ebotcazou at gcc dot gnu.org]

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

--- Comment #22 from Eric Botcazou  ---
> Is it really pure RTL, therefore not used in tree? So the above patch using
> BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?

I wouldn't say incorrect, just inappropriate and unnecessary.  And, yes, it
isn't used at the tree level and should stay so IMO.  BYTES_BIG_ENDIAN alone
already implicitly enforces a numbering on bits.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #12)
> No, unfortunately a working svn # is difficult, I first observed it by doing
> svn up on another Macbook around Christmas. 

hmm ... that's tricky - a busy time .. so looks like well have to try to
detective work.

> What do you mean by transcripts?

the output of the build process, for a clean build (most interesting will be
link lines etc.) ..

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[juergen.reuter at desy dot de]

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

--- Comment #12 from Jürgen Reuter  ---
No, unfortunately a working svn # is difficult, I first observed it by doing
svn up on another Macbook around Christmas. What do you mean by transcripts?

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Thanks.
So, can you for that sort.i do -da -fdump-tree-all when compiled both with
stage1 and stage2 and see where things start to differ?
Or, try to change either:
STAGE1_TFLAGS += -fno-checking
STAGE2_CFLAGS += -fno-checking
STAGE2_TFLAGS += -fno-checking
in toplevel Makefile.in to -fchecking=1 or
STAGE3_CFLAGS += -fchecking=1
STAGE3_TFLAGS += -fchecking=1
after it to -fno-checking and see if the comparison failures go away.  That
would verify your -fno-checking idea.  If that proves to be true, where
sort.i.* starts to differ could hint on what TU from stage1 or stage2 could be
rebuilt with -fno-checking or -fchecking=1 to see if the difference goes away. 
Or do a binary search among *.o files.
Sorry I can't help more, but this really isn't debuggable with cross-compilers.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #10)
> The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that
> the problem is also solved when I use the libtool flag -static instead of
> -static-libtool-libs for libtool to build these executables.

Thanks, can you identify a "working" svn #?

Is it possible to attach a transcript of the build(s) with the three cases -
two working and one not?

We did make a number of commits over Christmas and, if there's a regression,
would like to pin it down as soon as possible.

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #5)
> Hmm, the test case is explicitly adding the options
> -ffpe-trap=overflow,invalid, so is this a test case error?  We tell it to
> trap on invalid fp operations which we force it to do when generating the
> signaling nan value.  Removing the above option allows the reduced test case
> to not die.
> 
> bergner@pike:~/gcc/BUGS/PR88678$ gfortran -ffpe-trap=invalid -static bug.f90 
> bergner@pike:~/gcc/BUGS/PR88678$ ./a.out 
> 
> Program received signal SIGFPE: Floating-point exception - erroneous
> arithmetic operation.
> 
> Backtrace for this error:
> #0  0x10001b1b
> Floating point exception
> bergner@pike:~/gcc/BUGS/PR88678$ gfortran -static bug.f90 
> bergner@pike:~/gcc/BUGS/PR88678$ ./a.out 
> bergner@pike:~/gcc/BUGS/PR88678$

The testcase is correct.  It appears that powerpc is
claiming that it has the ability for a user to manipulate
the floating-point exception handling, but it appears
something is going sideways.  This is why all ieee testcases
are now failing only on powerpc64.

See my comment #3.  I assume that fpu-target.h is pulling
in libgfortran/config/fpu-glibc.h, and either that file
is broken or as your backtrace in comment #2 suggests
sysdeps/powerpc/fpu/feenablxcpt.c is broken.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[juergen.reuter at desy dot de]

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

--- Comment #10 from Jürgen Reuter  ---
The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that the
problem is also solved when I use the libtool flag -static instead of
-static-libtool-libs for libtool to build these executables.

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #8)

Thanks!

I've been using gmp-6.1.2, mpfr-3.1.6, mpc-1.1.0 isl-0.20 on all my recent
builds (for trunk, gcc-8 and gcc-7)
You don't (I think) mention whether the GCC you're using is trunk or 8 or 7?
I usually bootstrap gap  with the compiler, but that ought not to be
necessary.



I assume that all the code is built with the same compiler?

> here is the non-working library resolution:
> static_1.exe:
> lib/libcuttools.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> lib/libopenloops.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> lib/liboneloop.dylib (compatibility version 0.0.0, current version 0.0.0)
> lib/libolcommon.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> lib/librambo.dylib (compatibility version 0.0.0, current version 0.0.0)
> /usr/local/lib/liblcio.2.12.dylib (compatibility version 2.12.0, current
> version 2.12.1)
> /usr/local/lib/libgfortran.5.dylib (compatibility version 6.0.0, current
> version 6.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1252.200.5)
> /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> /usr/local/lib/libquadmath.0.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> 
> and this is the working one:
> 
> static_1.exe:
> lib/libcuttools.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> lib/libopenloops.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> lib/liboneloop.dylib (compatibility version 0.0.0, current version 0.0.0)
> lib/libolcommon.dylib (compatibility version 0.0.0, current version
> 0.0.0)
> lib/librambo.dylib (compatibility version 0.0.0, current version 0.0.0)
> /usr/local/lib/liblcio.2.12.dylib (compatibility version 2.12.0, current
> version 2.12.1)
> /usr/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> version 7.26.0)

^^^ this is the installation from the same compiler that you used to build the
non-working example above?

> /usr/local/lib/libgfortran.5.dylib (compatibility version 6.0.0, current
> version 6.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1252.200.5)
> /usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> /usr/local/lib/libquadmath.0.dylib (compatibility version 1.0.0, current
> version 1.0.0)

* If you invoke the exe with 
DYLD_PRINT_LIBRARIES=1 
you can confirm that it is, indeed, using the libraries listed there...

* So the linker/assembler/otool/ar/nm/strip/etc you're using come from Xcode
10.1?

* GCC binaries built with debug enabled are debugable by lldb, if you don't
have a working GDB.
(I use -Og -g3 as build options, FWIW)

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[mikpelinux at gmail dot com]

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

--- Comment #3 from Mikael Pettersson  ---
Created attachment 45384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45384=edit
pre-processed source for libiberty/sort.c

One of the smallest .o files that differ is from libiberty's sort.c
(pre-processed source attached as sort.i; sorry haven't had time to minimize
it).  stage1 and stage2 generate different code for this file:

> stage1-gcc/xgcc -Bstage1-gcc -O2 -S -o sort.s-stage1 sort.i
> stage2-gcc/xgcc -Bstage2-gcc -O2 -S -o sort.s-stage2 sort.i
> diff -u sort.s-stage[12] | wc
109 4602005
> diff -u sort.s-stage[12] | head
--- sort.s-stage1   2019-01-08 22:10:50.288929388 +0100
+++ sort.s-stage2   2019-01-08 22:10:59.148975673 +0100
@@ -21,21 +21,23 @@
 sort_pointers:
@ args = 0, pretend = 0, frame = 1024
@ frame_needed = 0, uses_anonymous_args = 0
-   push{r4, r5, r6, r7, r8, lr}
-   lsl r7, r0, #2
+   push{r4, r5, r6, r7, r8, r9, lr}
+   lsl r8, r0, #2

I wasn't able to trigger anything with -fcompare-debug, using either of the
stage1 or stage2 compilers.

Looking though the build log, I noticed that stage1 compiles stage2 with
-fno-checking, while stage2 compiles stage3 with -fchecking=1.  (This is
deliberate according to the top-level Makefile.tpl.)  Stage1 generates the same
code for sort.i with -fno-checking or -fchecking=1, and stage2 does the same.

Finally I checked the stage3 compiler and it generates the exact same code as
the stage1 does.

To me it looks like -fno-checking (possibly in combination with
--enable-checking=release) causes some breakage somewhere.

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jan 08, 2019 at 08:37:11PM +, bergner at gcc dot gnu.org wrote:
> Confirmed.  I don't think the mentioned revision caused the problem, other 
> than
> adding a new test case that fails the same way.  I simplified test case fails
> for me with gcc 7.3.  I don't have anything older to test with.
> 
> bergner@pike:~/gcc/BUGS/PR88678$ cat bug.f90 
> program foo
>use ieee_arithmetic
>implicit none
>real x
>x = ieee_value(x, ieee_signaling_nan)
>if (.not. ieee_is_nan(x)) stop 1
> end program foo

The backtrace in comment #2 has

#0  0x3fffb17f0477 in ???
#1  0x3fffb14f1694 in feenableexcept
 at ../sysdeps/powerpc/fpu/feenablxcpt.c:44
#2  0x3fffb1765e73 in __ieee_exceptions_MOD_ieee_support_halting
 at /home/seurer/gcc/gcc-test2/libgfortran/ieee/ieee_exceptions.F90:193

So, this is a better testcase.

program foo
  use ieee_arithmetic
  logical flag
  flag = ieee_supporting_halting(ieee_signaling_nan)
end program

[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning

[davmac at davmac dot org]

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

--- Comment #8 from Davin McCall  ---
(In reply to ensadc from comment #7)
> Note that the "never defined" part is also misleading: the warning persists
> when `i::dispatch` does have a definition

Yes; and actually, I note that in the original test case I supplied, the
dispatch function doesn't have a definition, but it doesn't have internal
linkage either.

So, I think the warning really is spurious and it's not just a case of it
saying "declared static" where it should say "has internal linkage".

[Bug fortran/86322] [9 Regression] ICE in reference_record with data statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Jan 08, 2019 at 08:15:46PM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322
> 
> janus at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||janus at gcc dot gnu.org
> 
> --- Comment #3 from janus at gcc dot gnu.org ---
> I have not verified, but I'm pretty sure the regression is due to r260808:
> 
> 2018-05-27  Steven G. Kargl  
> 
>  * decl.c (match_data_constant):  Fortran 2018 allows pointer
>  initialization in a data statement.
> 

Naw, it is is not due to my patch.  Rather my patch has
exposed or uncovered a bug in gfortran.  gfortran needs
to check

F2018:C877 (R839) A data-i-do-object or a variable that appears as a
   data-stmt-object shall not be an object designator in which a pointer
   appears other than as the entire rightmost part-ref .

In decl.c (gfc_match_data), gfortran needs a check for C877.
I haven't gotten around to fixing this yet, and I likely won't
for the foreseeable future.

[Bug target/88457] ICE: Max. number of generated reload insns per insn is achieved (90)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  8 21:36:21 2019
New Revision: 267739

URL: https://gcc.gnu.org/viewcvs?rev=267739=gcc=rev
Log:
PR target/88457
* gcc.target/powerpc/pr88457.c: Remove -m32, -c and -mcpu=e300c3 from
dg-options.  Require ppc_cpu_supports_hw effective target instead of
powerpc64*-*-*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr88457.c

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[juergen.reuter at desy dot de]

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

--- Comment #8 from Jürgen Reuter  ---
Yes I know: 
here is the non-working library resolution:
static_1.exe:
lib/libcuttools.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/libopenloops.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/liboneloop.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/libolcommon.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/librambo.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/liblcio.2.12.dylib (compatibility version 2.12.0, current
version 2.12.1)
/usr/local/lib/libgfortran.5.dylib (compatibility version 6.0.0, current
version 6.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1252.200.5)
/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/local/lib/libquadmath.0.dylib (compatibility version 1.0.0, current
version 1.0.0)

and this is the working one:

static_1.exe:
lib/libcuttools.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/libopenloops.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/liboneloop.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/libolcommon.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/librambo.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/liblcio.2.12.dylib (compatibility version 2.12.0, current
version 2.12.1)
/usr/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.26.0)
/usr/local/lib/libgfortran.5.dylib (compatibility version 6.0.0, current
version 6.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1252.200.5)
/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/local/lib/libquadmath.0.dylib (compatibility version 1.0.0, current
version 1.0.0)

[Bug rtl-optimization/87305] [9 Regression] Segfault in end_hard_regno in setup_live_pseudos_and_spill_after_risky_transforms on aarch64 big-endian

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #2)
> 
> Vlad, could you please have a look?

I've just started to work on it.

[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[wilco at gcc dot gnu.org]

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

--- Comment #21 from Wilco  ---
(In reply to Eric Botcazou from comment #20)
> > BITS_BIG_ENDIAN is just a convenience to the target code writer.  The other
> > four do matter, and are quite obvious really (and all four are necessary).
> 
> Yes, I agree that BITS_BIG_ENDIAN shouldn't matter here, it's pure RTL stuff.

Is it really pure RTL, therefore not used in tree? So the above patch using
BITS_BIG_ENDIAN for tree stuff would be incorrect to use it?

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #7 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #6)
> In the linking before I do see the following warning:

> ld: warning: direct access in function 'operator new[](unsigned long,
> std::nothrow_t const&) [clone .cold]' from file
> '/usr/local/lib/libstdc++.a(new_opvnt.o)' to global weak symbol 'operator
> new[](unsigned long, std::nothrow_t const&)' from file
> '/usr/local/lib/libstdc++.a(new_opvnt.o)' means the weak symbol cannot be
> overridden at runtime. This was likely ca

This is almost certainly a "red herring".. (of course, "almost certainly" until
proven).

> Not totally sure what that means.

GCC can optimise code to split it into parts that are frequently executed (or
'hot') and parts that are not ('cold').

The externally-visible function typically calls the .cold part to do some setup
(or it might be an exceptional or abort path).  In order to facilitate debug,
the cold part of the function has a label (__x.cold:) which is visible to
the linker.

In fact, one would never call that symbol from outside the TU in which it's
created (it's linker-visible, but not a global) .. 

.. but the linker's complaint here is that if one overrides the externally
visible weak "new" symbol that wouldn't override the __new.cold one.

However, the only caller of __new.cold is __new, and therefore if you override
__new, nothing will be trying to call __new.cold.  So IMO (probably we should
file a radar) the linker warning is bogus (or at least overly conservative).

 The problem appears that libtool links the
> static stdc++ library into my test binary (via --static-libtool-libs), which
> causes the warning above, and the malloc runtime error. When I link in by
> hand the dynamic library via -lstdc++ then the warning goes away as well as
> the runtime error.

* It's hard to deduce what's going on/changed without some specific points as
Dominque says...

"then"[working]  and "now" [first known not-working] could do with some
definition - plus if possible where the actual failure is (with a backtrace)

* It's generally not possible for folks here to reproduce problems by trying to
replicate your builds - this is a volunteer workforce, with highly constrained
time resources ;) .. we will need you to narrow things down

* It's quite possible that when you link statically - you are getting the
compiler's libstdc++ .. and when you link the shared version, it's being
resolved to the one installed in /usr/lib.

Please post as minimum the output of "otool -Lv " for both the working
(lstdc++) and non-working (--static-libtool-libs).

[Bug rtl-optimization/88331] [9 Regression] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987

[mateuszb at poczta dot onet.pl]

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

--- Comment #14 from mateuszb at poczta dot onet.pl ---
The patch from comment #13 solve my problems. Thanks!

[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[ebotcazou at gcc dot gnu.org]

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

--- Comment #20 from Eric Botcazou  ---
> BITS_BIG_ENDIAN is just a convenience to the target code writer.  The other
> four do matter, and are quite obvious really (and all four are necessary).

Yes, I agree that BITS_BIG_ENDIAN shouldn't matter here, it's pure RTL stuff.

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
Hmm, the test case is explicitly adding the options
-ffpe-trap=overflow,invalid, so is this a test case error?  We tell it to trap
on invalid fp operations which we force it to do when generating the signaling
nan value.  Removing the above option allows the reduced test case to not die.

bergner@pike:~/gcc/BUGS/PR88678$ gfortran -ffpe-trap=invalid -static bug.f90 
bergner@pike:~/gcc/BUGS/PR88678$ ./a.out 

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x10001b1b
Floating point exception
bergner@pike:~/gcc/BUGS/PR88678$ gfortran -static bug.f90 
bergner@pike:~/gcc/BUGS/PR88678$ ./a.out 
bergner@pike:~/gcc/BUGS/PR88678$

[Bug fortran/84245] [7/8/9 Regression] ICE in delete_root, at fortran/bbt.c:150

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> Changed between 20161023 and 20161030 :

I see two possible candidates (guessing for the second):
* r241450
* r241630

[Bug target/88764] New: [nvptx, libgomp, testsuite] Update testsuite for default vector length larger than 32

[vries at gcc dot gnu.org]

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

Bug ID: 88764
   Summary: [nvptx, libgomp, testsuite] Update testsuite for
default vector length larger than 32
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With the nvptx vector-length patches arriving on trunk, it starts to become
important to run the libgomp openacc testsuite with a vector-length default of
larger than 32, at the most extreme: 1024, f.i. by setting:
...
-#define PTX_DEFAULT_VECTOR_LENGTH PTX_WARP_SIZE
+#define PTX_DEFAULT_VECTOR_LENGTH PTX_CTA_SIZE
...
or by using -fopenacc-dim=::1024 as default in the libgomp testsuite.

There are however test-cases that assume default vector_length of 32, so we
need some way to indicate this, f.i. (or to start with) an effective target
openacc_default_vector_length_32, and update those test-cases.

Focusing on the execution failures, with '#define PTX_DEFAULT_VECTOR_LENGTH
PTX_CTA_SIZE' I see these tests failing with insufficient resources:
...
FAIL: libgomp.oacc-fortran/kernels-loop-2.f95 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-fortran/kernels-loop-2.f95 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions  execution test
FAIL: libgomp.oacc-fortran/kernels-loop-2.f95 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0  -O3 -g  execution test
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop-2.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-loop-2.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
...

and these tests failing due to a hard-coded check verifying default vector
length is 32:
...
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/parallel-dims.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/parallel-dims.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test
...

[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-08
 CC||bergner at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Peter Bergner  ---
Confirmed.  I don't think the mentioned revision caused the problem, other than
adding a new test case that fails the same way.  I simplified test case fails
for me with gcc 7.3.  I don't have anything older to test with.

bergner@pike:~/gcc/BUGS/PR88678$ cat bug.f90 
program foo
   use ieee_arithmetic
   implicit none
   real x
   x = ieee_value(x, ieee_signaling_nan)
   if (.not. ieee_is_nan(x)) stop 1
end program foo
bergner@pike:~/gcc/BUGS/PR88678$ gfortran -ffpe-trap=invalid -static bug.f90 
bergner@pike:~/gcc/BUGS/PR88678$ ./a.out 

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x10001b1b
Floating point exception

bergner@pike:~/gcc/BUGS/PR88678$ gdb ./a.out
(gdb) break * 0x1000aad8
Breakpoint 1 at 0x1000aad8
(gdb) run
Starting program: /home/bergner/gcc/BUGS/PR88678/a.out 

Breakpoint 1, 0x1000aad8 in __ieee_arithmetic_MOD_ieee_value_4 ()
1: x/i $pc
=> 0x1000aad8 <__ieee_arithmetic_MOD_ieee_value_4+120>: fsqrts  f1,f1
(gdb) info registers f1
f1 -1   (raw 0xbff0)
(gdb) stepi

Program received signal SIGFPE, Arithmetic exception.
0x1000aad8 in __ieee_arithmetic_MOD_ieee_value_4 ()
1: x/i $pc
=> 0x1000aad8 <__ieee_arithmetic_MOD_ieee_value_4+120>: fsqrts  f1,f1



So it seems, we still have floating point exceptions enabled when we try and
generate the signaling nan value which is causing the SIGFPE.  Who was supposed
to disable them before we execute the fsqrt with -1 as the source value?

[Bug fortran/88376] [7/8/9 Regression] ICE in is_illegal_recursion, at fortran/resolve.c:1689

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org,
   ||kargl at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> The change of behavior occurred between revision r258235 (2018-03-04, error)
> and r258362 (2018-03-08, ICE) and has been back ported to GCC6 and 7.

Based on this information, I'd guess that r258347 is the culprit:

2018-03-07  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk

[joseph at codesourcery dot com]

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

--- Comment #16 from joseph at codesourcery dot com  ---
On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote:

> FYI, what I am following are the Linux From Scratch guidelines, which build 
> the
> initial gcc like this (with both c and C++ support, disabling libstdc++ 
> build):
> http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html
> Then after building the glibc, they do build the libstdc++ alone like this:
> http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html

Those instructions use libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes 
with glibc, which haven't been needed since my commit 
e7dbb1bec3be35897acb18aa277807ed276384c5, "Weaken two NPTL configure link 
tests to compile tests.", March 2012.

I advise looking at how glibc's build-many-glibcs.py does things for the 
modern approach for bootstrapping a cross-compilation toolchain for a 
target using glibc.  (Although some pieces may need adjusting if what you 
want is a native toolchain using unusual directory arrangements, which 
some of those LFS instructions seem to suggest.)

[Bug fortran/53320] -fcheck=pointer should diagnose pointer-assignment of a noncontiguous tgt to a CONTIGUOUS ptr

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #1)
> Duplicate or pr49232?

pr49232 was about compile-time warnings, this is about
run-time checks.

[Bug fortran/86322] [9 Regression] ICE in reference_record with data statement

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
I have not verified, but I'm pretty sure the regression is due to r260808:

2018-05-27  Steven G. Kargl  

 * decl.c (match_data_constant):  Fortran 2018 allows pointer
 initialization in a data statement.

[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #14 from Eric Botcazou  ---
> ICE still occurs with current trunk (r267728) patched with
> gcc9-pr88331.patch from PR88331. r266345 seems to give quite a hard time for
> cygwin / mingw targets, might be worth reverting as the gcc 9 release is
> comming up.

I agree, the patch is quite weird and should not have been accepted.

[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk

[romain.geissler at amadeus dot com]

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

--- Comment #15 from Romain Geissler  ---
Thanks for these remarks.

FYI, what I am following are the Linux From Scratch guidelines, which build the
initial gcc like this (with both c and C++ support, disabling libstdc++ build):
http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html
Then after building the glibc, they do build the libstdc++ alone like this:
http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html

With this PR I just found out that either my understanding of LFS is wrong,
either LFS itself is. Indeed I don't like much that when configured using my
bootstrap scripts libstdc++ doesn't use the C compiler but the C++ one to find
C headers. I will have a look to sort this out.

[Bug fortran/88653] Is this a compiler bug?

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #23 from Thomas Koenig  ---
Well, if it is a problem in the cygwin binary distribution, it
is not a gfortran bug.

Also, since it works for me when installing from cygwin, this
does not appear to be a general problem.

Please report this to cygwin, there is not really anything
that we can do here.

[Bug c++/88572] error: braces around scalar initializer - should be a warning

[wjwray at gmail dot com]

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

--- Comment #12 from Will Wray  ---
On further investigation the logic of using first_initializer_p looks correct.

The comment on reshape_init suggests that it wasn't intended for scalar init:

 /* Undo the brace-elision allowed by [dcl.init.aggr] in a
brace-enclosed aggregate initializer.

INIT is the CONSTRUCTOR containing the list of initializers describing
a brace-enclosed initializer for an entity of the indicated aggregate TYPE.

In fact, reshape_init is used more broadly to error-check braced-init-list -
- the first substantive case is direct enum init, a scalar init special-case.
Perhaps the general scalar case should be dealt with here at the top level.
Instead the recursive call to reshape_init_r is done next
setting first_initializer_p to true - the only place it is set true
(the true value will be forwarded to reshape_init_class for class type).

So, for a scalar init, the tree type passed to reshape_init is SCALAR_TYPE_P.
This is passed down to reshape_init_r with first_initializer_p set true.

Entering reshape_init_r we have

  if (first_initializer_p && !CP_AGGREGATE_TYPE_P (type)
  && has_designator_problem (d, complain))
return error_mark_node;

Here, first_initializer_p && !CP_AGGREGATE_TYPE_P (type) covers scalar init
(and other non-aggregate init).

Arriving at our block, we also enter a context requiring a single-initializer

  /* A non-aggregate type is always initialized with a single
 initializer.  */
  if (!CP_AGGREGATE_TYPE_P (type))

and then further filter down to CONSTRUCTOR with BRACE_ENCLOSED_INITIALIZER_P
and, specifically of SCALAR_TYPE_P

  if (TREE_CODE (stripped_init) == CONSTRUCTOR
  /* Don't complain about a capture-init.  */
  && !CONSTRUCTOR_IS_DIRECT_INIT (stripped_init)
  && BRACE_ENCLOSED_INITIALIZER_P (stripped_init))  /* p7626.C */
{
  if (SCALAR_TYPE_P (type))


> I understood it to mean something like {{1}, 2} is the first,
> ^^^

Me too, but taking "outermost CONSTRUCTOR node" to mean the actual outer type
here (first_initializer_p==true) and with only a single scalar initializer:

  like scalar_type{{1}}not {   {1} }
   ^^^  scalar_type^^^

So, I've convinced myself that my patch follows the existing logic.
It'd be good to get review from someone not suffering from confirmation bias.

[Bug fortran/88653] Is this a compiler bug?

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  ---
> Apparently, this is some kind of cygwin problem.

Did you report the problem to cygwin?

[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from janus at gcc dot gnu.org ---
Fixed with r267735. Closing.

[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc

[sbence92 at gmail dot com]

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

--- Comment #13 from Bence Szabó  ---
ICE still occurs with current trunk (r267728) patched with gcc9-pr88331.patch
from PR88331. r266345 seems to give quite a hard time for cygwin / mingw
targets, might be worth reverting as the gcc 9 release is comming up.

[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Jan  8 19:29:01 2019
New Revision: 267735

URL: https://gcc.gnu.org/viewcvs?rev=267735=gcc=rev
Log:
2019-01-08  Janus Weil  

PR fortran/88047
* class.c (gfc_find_vtab): For polymorphic typespecs, the components of
the class container may not be available (in case of invalid code).

2019-01-08  Janus Weil  

PR fortran/88047
* gfortran.dg/class_69.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/class_69.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88761] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-08
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Like PR 88752, started with r259043.

[Bug c++/88752] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Nevertheless the ICE seems to have started with r259043.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[ebotcazou at gcc dot gnu.org]

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

Bug 88721 Summary: [9 regression] -Wmaybe-uninitialized warnings in sparc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88721

   What|Removed |Added

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

[Bug bootstrap/88721] [9 regression] -Wmaybe-uninitialized warnings in sparc.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
.

[Bug debug/88723] [9 regression] PR debug/88635 patch breaks testsuite_shared.cc compilation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Jan  8 19:09:52 2019
New Revision: 267734

URL: https://gcc.gnu.org/viewcvs?rev=267734=gcc=rev
Log:
PR bootstrap/88721
* config/sparc/sparc.c (function_arg_slotno): Set *PPREGNO & *PPADDING
to -1 on entry.

PR debug/88723
* config/sparc/sparc.c (sparc_delegitimize_address): Deal with naked
UNSPECs and UNSPEC_MOVE_GOTDATA specifically.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c

[Bug bootstrap/88721] [9 regression] -Wmaybe-uninitialized warnings in sparc.c

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Jan  8 19:09:52 2019
New Revision: 267734

URL: https://gcc.gnu.org/viewcvs?rev=267734=gcc=rev
Log:
PR bootstrap/88721
* config/sparc/sparc.c (function_arg_slotno): Set *PPREGNO & *PPADDING
to -1 on entry.

PR debug/88723
* config/sparc/sparc.c (sparc_delegitimize_address): Deal with naked
UNSPECs and UNSPEC_MOVE_GOTDATA specifically.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c

[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
(In reply to Segher Boessenkool from comment #18)
> Well, it is always possible to generate code with the opposite endianness to
> what the hardware "wants".  It just won't be very fast code.
> 
> BITS_BIG_ENDIAN is just a convenience to the target code writer.  The other
> four do matter, and are quite obvious really (and all four are necessary).

What I'm suggesting is that if you have a non-standard endian layout (eg.
FLOAT_WORDS_BIG_ENDIAN, WORDS_BIG_ENDIAN and REG_WORDS_BIG_ENDIAN are not the
same as BYTES_BIG_ENDIAN), optimizations which depend the particular layout
should be disabled. There are far too few occurrences of these macros to
believe that all possible combinations will work correctly on all optimizations
that rely on it.

[Bug c++/88752] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Confirmed but the reduced testcase seems to be overreduced because it's not
valid anymore.

[Bug tree-optimization/88763] New: Better Output for Loop Unswitching

[marius.messerschmidt at googlemail dot com]

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

Bug ID: 88763
   Summary: Better Output for Loop Unswitching
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marius.messerschmidt at googlemail dot com
  Target Milestone: ---

I work on a project where we heavily rely on the loop-unswitching feature of
GCC (-funswitch-loops). I started working with the log generated by
-fdump-tree-unswitch.

I started noticing, that the output of the option is very limited. It does only
report a few cases where the optimizer could not unswitch a loop. But in the
source file (gcc/tree-ssa-loop-unswitch.c) there are quite a lot more checks
that lead to a not unswitched loop. Especially the "not invariant" case could
be realy helpfull in the logs.
I tried to implement further warnings, but I do not fully understand every case
in the file, so I am asking someone with better understanding of the internals
of GCC to either fix the bug or explain a few things for me.

Many thanks in Advance :)

[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries

[juergen.reuter at desy dot de]

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

--- Comment #6 from Jürgen Reuter  ---
In the linking before I do see the following warning:
ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
'/usr/local/lib/libstdc++.a(new_opvnt.o)' to global weak symbol 'operator
new[](unsigned long, std::nothrow_t const&)' from file
'/usr/local/lib/libstdc++.a(new_opvnt.o)' means the weak symbol cannot be
overridden at runtime. This was likely ca
Not totally sure what that means. The problem appears that libtool links the
static stdc++ library into my test binary (via --static-libtool-libs), which
causes the warning above, and the malloc runtime error. When I link in by hand
the dynamic library via -lstdc++ then the warning goes away as well as the
runtime error.

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[wilco at gcc dot gnu.org]

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

--- Comment #20 from Wilco  ---
I see Kyrill added some examples that show LLVM knows how to unroll loops:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760

This kind of thing is much worse than a trailing loop, both for branch
prediction and codesize:

andsx12, x11, 7
beq .L70
cmp x12, 1
beq .L55
cmp x12, 2
beq .L57
cmp x12, 3
beq .L59
cmp x12, 4
beq .L61
cmp x12, 5
beq .L63
cmp x12, 6
bne .L72

[Bug c++/88754] [7/8/9 Regression] Constructor call wrongly assumed to be a variable declaration

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

  Known to work||3.4.0, 3.4.6, 4.1.0, 4.1.1
Summary|Constructor call wrongly|[7/8/9 Regression]
   |assumed to be a variable|Constructor call wrongly
   |declaration |assumed to be a variable
   ||declaration
  Known to fail||4.1.2, 4.2.0, 5.0, 6.0,
   ||7.0, 8.0, 9.0

--- Comment #2 from Volker Reichelt  ---
Unlike PR37213 this is actually a regression that was introduced in GCC 4.1.2.
The code compiled fine with GCC 3.4.0 - GCC 4.1.1.

[Bug c/81980] Spurious -Wmissing-format-attribute and missing -Wformat for va_list in 32-bit mode

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
Summary|Spurious|Spurious
   |-Wmissing-format-attribute  |-Wmissing-format-attribute
   |warning in 32-bit mode  |and missing -Wformat for
   ||va_list in 32-bit mode
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #5 from Martin Sebor  ---
The same problem also results in a missing -Wformat for the following test
case:

  #include 

  void f (va_list va)
  {
__builtin_printf ("%s", va);
  }

It's only diagnosed without -m32:

$ gcc -S -Wall -Wmissing-format-attribute t.c
t.c: In function ‘f’:
t.c:5:23: warning: format ‘%s’ expects argument of type ‘char *’, but argument
2 has type ‘__va_list_tag *’ [-Wformat=]
5 |   __builtin_printf ("%s", va);
  |  ~^   ~~
  |   |   |
  |   |   __va_list_tag *
  |   char *


One way to deal with it would be compare the name of the type of the argument
to "va_list"  Another might be to treat __builtin_va_list as a type distinct
from char* when it's defined to be char*.

[Bug tree-optimization/88739] [7/8/9 Regression] Big-endian union bug

[segher at gcc dot gnu.org]

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

--- Comment #18 from Segher Boessenkool  ---
Well, it is always possible to generate code with the opposite endianness to
what the hardware "wants".  It just won't be very fast code.

BITS_BIG_ENDIAN is just a convenience to the target code writer.  The other
four do matter, and are quite obvious really (and all four are necessary).

[Bug c++/88762] New: C++17 Deduction guide and operator expression produces missing template argument error

[pkeir at outlook dot com]

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

Bug ID: 88762
   Summary: C++17 Deduction guide and operator expression produces
missing template argument error
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

Created attachment 45383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45383=edit
C++ file which produces the error.

I believe the code below/attached should compile with:

g++ -c -std=c++17 gcc-deduction-expr.cpp

The code is already reduced, but I also tried changing the operator for a
method; and only using operator+ once; but the error disappears in both cases.
The code compiles with Clang. Here is the error:

error: missing template arguments after ‘Foo’
   (Foo{x} + Foo{y}) + Foo{z};
^~~

The code:

template 
struct Foo {
  Foo operator+(Foo &) { return f; }
  T 
};
template  Foo(T) -> Foo;

void zod()
{
  int x,y,z;
  (Foo{x} + Foo{y}) + Foo{z};
}

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Or, do we have any machine in the compile farm on which this can be reproduced?
If so, could you give instructions for that please?

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
(In reply to Jakub Jelinek from comment #18)
> The duffs device doesn't need to be done with computed jump, it can be done
> with 3 conditional branches + 3 comparisons too.  The advantage of doing
> that is especially if the iter isn't really very small, by doing it that way
> you don't need those 4 unrolled iterations + one scalar loop.

While that is better than an indirect branch, it still branches into the loop,
so you don't benefit from optimization across the loop. So using a trailing
loop is better in most cases.

> Of course, if iter is very short, it might be easier/more efficient to
> duplicate iter more times than 4 and do something else.

If iter is a small constant then peeling makes sense as you can completely
remove the loop counter and branches. Eg. for N=3 you end up with something
like this:

if (n >= 2)
  iter1
  iter2
  n -= 2
if (n != 0)
  iter3

[Bug target/88717] Unnecessary vzeroupper

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #9 from H.J. Lu  ---
Fixed for GCC 9.

[Bug target/88717] Unnecessary vzeroupper

[hjl at gcc dot gnu.org]

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

--- Comment #8 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jan  8 17:40:18 2019
New Revision: 267732

URL: https://gcc.gnu.org/viewcvs?rev=267732=gcc=rev
Log:
x86: Don't generate vzeroupper if caller passes AVX/AVX512 registers

There is no need to generate vzeroupper if caller passes arguments in
AVX/AVX512 registers.

Tested on i686 and x86-64 with and without --with-arch=native.

gcc/

PR target/88717
* config/i386/i386.c (ix86_avx_u128_mode_exit): Call
ix86_avx_u128_mode_entry.

gcc/testsuite/

PR target/88717
* gcc.target/i386/pr88717.c: New test.

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

[Bug c++/88761] New: ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions

[joel.falcou at lri dot fr]

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

Bug ID: 88761
   Summary: ICE in tsubst_copy, at cp/pt.c:15478 when chaining
lambda calls & fold-expressions
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel.falcou at lri dot fr
  Target Milestone: ---

The following code:

https://godbolt.org/z/RFZ_k6

compiles fine on g++ 7.x but fails in all g++ 8.x including trunk with an ICE
in tsubst_copy, at cp/pt.c:15478

Unrolling various fold-expression by hand has no effect, nor does capture of
the variable differently (value, mutable lambda etc...)

[Bug c++/88548] [9 Regression] this accepted in static member functions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Should be fixed for GCC 9.

[Bug c++/88548] [9 Regression] this accepted in static member functions

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jan  8 17:37:51 2019
New Revision: 267731

URL: https://gcc.gnu.org/viewcvs?rev=267731=gcc=rev
Log:
PR c++/88548 - this accepted in static member functions.
* parser.c (cp_debug_parser): Adjust printing of
local_variables_forbidden_p.
(cp_parser_new): Set local_variables_forbidden_p to 0 rather than
false.
(cp_parser_primary_expression): When checking
local_variables_forbidden_p, use THIS_FORBIDDEN or
LOCAL_VARS_FORBIDDEN.
(cp_parser_lambda_body): Update the type of
local_variables_forbidden_p.  Set it to 0 rather than false.
(cp_parser_condition): Adjust call to cp_parser_declarator.
(cp_parser_explicit_instantiation): Likewise.
(cp_parser_init_declarator): Likewise.
(cp_parser_declarator): New parameter.  Use it.
(cp_parser_direct_declarator): New parameter.  Use it to set
local_variables_forbidden_p.  Adjust call to cp_parser_declarator.
(cp_parser_type_id_1): Adjust call to cp_parser_declarator.
(cp_parser_parameter_declaration): Likewise.
(cp_parser_default_argument): Update the type of
local_variables_forbidden_p.  Set it to LOCAL_VARS_AND_THIS_FORBIDDEN
rather than true.
(cp_parser_member_declaration): Tell cp_parser_declarator if we saw
'static' or 'friend'.
(cp_parser_exception_declaration): Adjust call to cp_parser_declarator.
(cp_parser_late_parsing_default_args): Update the type of
local_variables_forbidden_p.  Set it to LOCAL_VARS_AND_THIS_FORBIDDEN
rather than true.
(cp_parser_cache_defarg): Adjust call to cp_parser_declarator.
(cp_parser_objc_class_ivars): Likewise.
(cp_parser_objc_struct_declaration): Likewise.
(cp_parser_omp_for_loop_init): Likewise.
* parser.h (cp_parser): Change the type of local_variables_forbidden_p
to unsigned char.
(LOCAL_VARS_FORBIDDEN, LOCAL_VARS_AND_THIS_FORBIDDEN, THIS_FORBIDDEN):
Define.

* g++.dg/cpp0x/this1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/this1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #18 from Jonathan Wakely  ---
The minimal fix is:

PR libstdc++/87855 fix optional for types with non-trivial copy/move

When the contained value is not trivially copy (or move) constructible
the union's copy (or move) constructor will be deleted, and so the
_Optional_payload delegating constructors are invalid. G++ fails to
diagnose this because it incorrectly performs copy elision in the
delegating constructors. Clang does diagnose it (llvm.org/PR40245).

The solution is to avoid performing any copy (or move) when the
contained value's copy (or move) constructor isn't trivial. Instead the
contained value can be constructed by calling _M_construct. This is OK,
because the relevant constructor doesn't need to be constexpr when the
contained value isn't trivially copy (or move) constructible.

PR libstdc++/87855
* include/std/optional: Adjust whitespace.
(_Optional_payload<_Tp, true, C, M>): Use _M_construct to construct
the contained object when it isn't trivially copy/move constructible.


--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -334,11 +334,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   constexpr
   _Optional_payload(bool __engaged, const _Optional_payload& __other)
-  : _Optional_payload(__engaged ?
- _Optional_payload(__ctor_tag{},
-   __other._M_payload) :
- _Optional_payload(__ctor_tag{}))
-  { }
+  : _M_engaged(__engaged)
+  {
+   if (__engaged)
+ _M_construct(__other._M_payload);
+  }

   constexpr
   _Optional_payload(bool __engaged, _Optional_payload&& __other)
@@ -453,20 +453,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   constexpr
   _Optional_payload(bool __engaged, const _Optional_payload& __other)
-  : _Optional_payload(__engaged ?
- _Optional_payload(__ctor_tag{},
-   __other._M_payload) :
- _Optional_payload(__ctor_tag{}))
-  { }
-
-  constexpr
-  _Optional_payload(bool __engaged, _Optional_payload&& __other)
   : _Optional_payload(__engaged
  ? _Optional_payload(__ctor_tag{},
- std::move(__other._M_payload))
+ __other._M_payload)
  : _Optional_payload(__ctor_tag{}))
   { }

+  constexpr
+  _Optional_payload(bool __engaged, _Optional_payload&& __other)
+  : _M_engaged(__engaged)
+  {
+   if (__engaged)
+ _M_construct(std::move(__other._M_payload));
+  }
+
   _Optional_payload(const _Optional_payload&) = default;
   _Optional_payload(_Optional_payload&&) = default;

@@ -573,19 +573,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   constexpr
   _Optional_payload(bool __engaged, const _Optional_payload& __other)
-  : _Optional_payload(__engaged ?
- _Optional_payload(__ctor_tag{},
-   __other._M_payload) :
- _Optional_payload(__ctor_tag{}))
-  { }
+  : _M_engaged(__engaged)
+  {
+   if (__engaged)
+ _M_construct(std::move(__other._M_payload));
+  }

   constexpr
   _Optional_payload(bool __engaged, _Optional_payload&& __other)
-  : _Optional_payload(__engaged
- ? _Optional_payload(__ctor_tag{},
- std::move(__other._M_payload))
- : _Optional_payload(__ctor_tag{}))
-  { }
+  : _M_engaged(__engaged)
+  {
+   if (__engaged)
+ _M_construct(std::move(__other._M_payload));
+  }

   _Optional_payload(const _Optional_payload&) = default;
   _Optional_payload(_Optional_payload&&) = default;



However, I have a better patch on the way, which hoists all those constructors
into a new base so we only need to fi it in one place (not three).

[Bug middle-end/88758] [9 Regression] 186.crafty in SPEC CPU 2000 failed to build

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Unfortunately, the testcase isn't really usable, because it
fails to link when this ICE is fixed (plus contains uninitialized use).

The problem is that while for non-VECTOR_CST_STEPPED_P VECTOR_CSTs it is just
fine when initializer_each_zero_or_onep checks only the encoded elts, if there
are fewer than subparts, the last one is repeated.  But, with
VECTOR_CST_STEPPED_P, the one after last one needs to be computed.
unsigned HOST_WIDE_INT nelts = vector_cst_encoded_nelts (expr);
if (VECTOR_CST_STEPPED_P (expr)
&& !TYPE_VECTOR_SUBPARTS (TREE_TYPE (expr)).is_constant ())
  return false;
seems to had this in mind, the only problem is that it results in nelts being
larger than vector_cst_encoded_nelts for those VECTOR_CST_STEPPED_P csts.  With
the attached patch, it will do what it did before for the encoded elts,
vector_cst_elt just returns what was used before.

[Bug tree-optimization/88760] New: GCC unrolling is suboptimal

[ktkachov at gcc dot gnu.org]

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

Bug ID: 88760
   Summary: GCC unrolling is suboptimal
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

One of the hot loops in 510.parest_r from SPEC2017 can be approximated through:
unsigned int *colnums;
double *val;

struct foostruct
{
  unsigned int rows;
  unsigned int *colnums;
  unsigned int *rowstart;
};

struct foostruct *cols;

void
foo (double *dst, const double *src)
{
  const unsigned int n_rows = cols->rows;
  const double *val_ptr = [cols->rowstart[0]];
  const unsigned int *colnum_ptr = >colnums[cols->rowstart[0]];  

  double *dst_ptr = dst;
  for (unsigned int row=0; rowrowstart[row+1]];
  while (val_ptr != val_end_of_row)
s += *val_ptr++ * src[*colnum_ptr++];
  *dst_ptr++ = s;
}
}


At -Ofast -mcpu=cortex-a57 on aarch64 GCC generates a tight FMA loop:
.L4:
ldr w3, [x7, x2, lsl 2]
cmp x6, x2
ldr d2, [x5, x2, lsl 3]
add x2, x2, 1
ldr d1, [x1, x3, lsl 3]
fmadd   d0, d2, d1, d0
bne .L4


LLVM unrolls the loop more intelligently:
.LBB0_8:// %vector.body
//   Parent Loop BB0_2 Depth=1
// =>  This Inner Loop Header: Depth=2
ldp w21, w22, [x20, #-8]
ldr d5, [x1, x21, lsl #3]
ldp d3, d4, [x7, #-16]
ldr d6, [x1, x22, lsl #3]
ldp w21, w22, [x20], #16
fmadd   d2, d6, d4, d2
fmadd   d1, d5, d3, d1
ldr d5, [x1, x21, lsl #3]
ldr d6, [x1, x22, lsl #3]
add x5, x5, #4  // =4
addsx19, x19, #2// =2
ldp d3, d4, [x7], #32
fmadd   d1, d5, d3, d1
fmadd   d2, d6, d4, d2
b.ne.LBB0_8


With -funroll-loops GCC does do unrolling, but it does it differently:

andsx12, x11, 7
beq .L70
cmp x12, 1
beq .L55
cmp x12, 2
beq .L57
cmp x12, 3
beq .L59
cmp x12, 4
beq .L61
cmp x12, 5
beq .L63
cmp x12, 6
bne .L72
.L65:
ldr w14, [x4, x2, lsl 2]
ldr d3, [x3, x2, lsl 3]
add x2, x2, 1
ldr d4, [x1, x14, lsl 3]
fmadd   d0, d3, d4, d0
.L63:
ldr w5, [x4, x2, lsl 2]
ldr d5, [x3, x2, lsl 3]
add x2, x2, 1
ldr d6, [x1, x5, lsl 3]
fmadd   d0, d5, d6, d0
.L61:
ldr w9, [x4, x2, lsl 2]
ldr d7, [x3, x2, lsl 3]
add x2, x2, 1
ldr d16, [x1, x9, lsl 3]
fmadd   d0, d7, d16, d0


On the whole of 510.parest_r this makes LLVM about 6% faster than GCC on
Cortex-A57.

Perhaps this can be used as a motivating testcase to move the GCC unrolling
discussions forward?

[Bug tree-optimization/65425] code optimization leads to spurious FP exception

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
 has my comments 
on ways in which libm functions can be "const/pure with exceptions".  It 
would be possible to have attributes to describe the ways in which most 
libm functions are const apart from rounding mode, exceptions and errno.

I didn't discuss there any possibilities relating to functions raising 
some exceptions but not others, or the possible exceptions depending on 
-ffinite-math-only.  For example, sin can raise inexact and underflow for 
finite arguments, as well as invalid for infinite arguments; cos can raise 
inexact for finite arguments but not underflow.  Most functions can raise 
inexact.

(There's also the difference between raising exception flags, which is 
what's available when using standard facilities, and actually generating a 
signal and calling a signal handler, when using feenableexcept which is a 
GNU extension.  -ftrapping-math covers both at present.)

[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk

[joseph at codesourcery dot com]

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

--- Comment #14 from joseph at codesourcery dot com  ---
On Tue, 8 Jan 2019, romain.geissler at amadeus dot com wrote:

>  - binutils, with a linker configured to look for system libraries in a
> non-standard folder, empty for now
>  - gcc, without libstdc++

The first GCC should be --enable-languages=c --disable-shared 
--without-headers --with-newlib (where --with-newlib means "define 
inhibit_libc", as required to stop libgcc from needing libc headers in 
some cases) - you may need various other --disable- options for other GCC 
libraries that can't be built without glibc headers (see the full options 
used in glibc's build-many-glibcs.py for a list that is sufficient).  In 
particular, libstdc++ should not be built until glibc has been built.

>  - glibc, using the above binutils/gcc, which fills in the non standard lib
> folder with only a libc.
>  - libstdc++, using the above binutils/gcc/glibc.

A second GCC should be built with all languages you want, shared libraries 
enabled (in particular, once you've built glibc you can build a proper 
shared libgcc with DT_NEEDED pointing correctly to libc, which you can't 
until glibc has been built).

It's true that ideally the host-side code in GCC would be built just once 
(but libgcc built twice), but that's not currently supported by the GCC 
build system.

> Note that this is just the beginning of the bootstrap. After this other
> gcc/libstdc++ are being built, and this time the configure script works
> unpatched.

Two GCC builds suffice with modern (c. 2012 and later; GCC 4.9 and later, 
glibc 2.17 and later, roughly) tools.  The stripped glibc shared libraries 
built with the first GCC using the above process should be identical to 
the stripped glibc shared libraries resulting from any longer alternating 
series of GCC and glibc builds.

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

[hubicka at ucw dot cz]

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

--- Comment #20 from Jan Hubicka  ---
> Looking at our nightly spec runs, the bzip2 degradation has indeed been 
> cleaned
> up. But it looks like 175.vpr degraded another 2% or so over the last couple
> days.
Knowing what inline decision matters for VPR, I can try to fix it too.
It seems that the time accounting bug I fixed this weekend cured a lot
of mysteries I did not understand.  I have one additional patch to
adjust way we compute badness metric which I plan to commit todar or
tomorrow (there was downtime with LNT spec testers). It may affect these
two benchmarks again - I am still waiting for runs to finish.

Honza

[Bug rtl-optimization/88331] [9 Regression] ICE in rtl_verify_bb_layout, at cfgrtl.c:2987

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Created attachment 45381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45381=edit
gcc9-pr88331.patch

I don't see how that could ever work when assign_stack_local_1 is called from
anywhere but the expand pass, one can't emit random code somewhere blindly
otherwise (e.g. from the RA).  I think for now it is best to revert to previous
behavior when it isn't called during expansion, and if really needed, we can
figure out a way for GCC10 how to tell the RA it should emit the alignment
itself.

[Bug middle-end/46495] target.h and function.h require tm.h

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Tue, 8 Jan 2019, egallager at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46495
> 
> Eric Gallager  changed:
> 
>What|Removed |Added
> 
>  CC||egallager at gcc dot gnu.org
> 
> --- Comment #1 from Eric Gallager  ---
> (In reply to Jorn Wolfgang Rennecke from comment #0)
> > Because of their dependence on CUMULATIVE_ARGS and HARD_REG_SET,
> > target.h and function.h include tm.h  This needs to be rectified to stop
> > the uncontrolled use of target macros.
> 
> How?

See bug 46500 for the introduction of cumulative_args_t.  There's still 
HARD_REG_SET to resolve (maybe similarly).

[Bug libbacktrace/88745] Darwin lacks an implementation for libbacktrace

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I tried to start doing this in my fork of gdb but I didn't get very far; here's
a brief TODO:

1. Get filetype.awk to recognize mach-o binaries
2. Add a mach-o case to the switch on libbacktrace_cv_sys_filetype in
configure.ac
3. Add a macho.c file to compile to macho.lo to use as the FORMAT_FILE in that
case

[Bug ipa/85103] [8/9 Regression] Performance regressions on SPEC with r257582

[pthaugen at gcc dot gnu.org]

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

--- Comment #19 from Pat Haugen  ---
(In reply to Jan Hubicka from comment #18)
> which makes it to be inlined. Does it solve the perofmrance problem for both
> benchmarks?

Looking at our nightly spec runs, the bzip2 degradation has indeed been cleaned
up. But it looks like 175.vpr degraded another 2% or so over the last couple
days.

[Bug c++/88757] [9 Regression] GCC wrongly treats dependent name as a type when it should be treated as a value

[d25fe0be at outlook dot com]

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

--- Comment #2 from d25fe0be@  ---
Oops, I didn't realize this. Thank you for clarifying.

[Bug target/88717] Unnecessary vzeroupper

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to 刘袋鼠 from comment #6)
> (In reply to H.J. Lu from comment #5)
> > (In reply to 刘袋鼠 from comment #4)
> > > 
> > > My thought is AVX_U128_DIRTY would be set when ymm/zmm appeared, and
> > > AVX_U128_CLEAN for xmm, AVX_U128_ANY for other situations. This also works
> > > for this case.
> > > 
> > 
> > Your change touches many difference places.  Please do
> > 
> > 1. For each line of change, find a testcase to verify that it is needed.
> > 2. Bootstrap GCC with --with-arch=native and all languages.  Run the 
> > complete
> > GCC testssuites with and without your whole patch.

A simpler patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00415.html

[Bug fortran/88653] Is this a compiler bug?

[mtekeev at yandex dot ru]

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

Murat Tekeev  changed:

   What|Removed |Added

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

--- Comment #21 from Murat Tekeev  ---
Unfortunately, I was happy too soon. I made a mistake - with Fortran 7.4 these
files still do not compile. Apparently
I installed the latest version of Cygwin on three different machines, the
installation is fine, but not all files are compiled.
I don't know what the problem is. With gfortran 7.3 no problems. 
I will continue to use gfortran 7.3 and wait until the next version of Cygwin
is released.
Apparently, this is some kind of cygwin problem.

[Bug fortran/88653] Is this a compiler bug?

[mtekeev at yandex dot ru]

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

--- Comment #20 from Murat Tekeev  ---
Unfortunately, I was happy too soon. I made a mistake - with Fortran 7.4 these
files still do not compile. Apparently
I installed the latest version of Cygwin on three different machines, the
installation is fine, but not all files are compiled.
I don't know what the problem is. With gfortran 7.3 no problems. 
I will continue to use gfortran 7.3 and wait until the next version of Cygwin
is released.
Apparently, this is some kind of cygwin problem.

[Bug fortran/88653] Is this a compiler bug?

[mtekeev at yandex dot ru]

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

--- Comment #19 from Murat Tekeev  ---
Unfortunately, I was happy too soon. I made a mistake - with Fortran 7.4 these
files still do not compile. Apparently
I installed the latest version of Cygwin on three different machines, the
installation is fine, but not all files are compiled.
I don't know what the problem is. With gfortran 7.3 no problems. 
I will continue to use gfortran 7.3 and wait until the next version of Cygwin
is released.
Apparently, this is some kind of cygwin problem.