[Bug c++/89325] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.4.0, 8.2.0, 9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r236129 and is probably hidden on trunk due to r265744.

[Bug c++/89326] New: [RFE] Highlight `required from here` in compile-error output

[Hi-Angel at yandex dot ru]

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

Bug ID: 89326
   Summary: [RFE] Highlight `required from here` in compile-error
output
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
  Target Milestone: ---

Compile-errors of constructors and templates can give a lot of output. Usually
the first thing in debugging is to figure out where the offending code is used.
This place in output is marked with `required from here`, but it's very hard to
find the magic words in the output, even more so given there are sentences
"required from" without "here" that go along the call stack.

Usually just below the "required from here" is a highlighted word "error", but
it often appears in other places as well.

# Steps to reproduce (in terms of terminal commands):

$ cat test.cpp
#include 

struct NoCopy {
NoCopy(const NoCopy&) = delete;
NoCopy(NoCopy&&)  = default;
};

int main() {
// Child ch{{}};
std::list l = {NoCopy{}};
}
╭─constantine@constantine-N61Ja  /tmp ‹node-›  ‹› 
╰─$ g++ test.cpp
In file included from
/usr/include/c++/8.2.1/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from /usr/include/c++/8.2.1/bits/allocator.h:46,
 from /usr/include/c++/8.2.1/list:61,
 from test.cpp:1:
/usr/include/c++/8.2.1/ext/new_allocator.h: In instantiation of ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up = NoCopy;
_Args = {const NoCopy&}; _Tp = std::_List_node]’:
/usr/include/c++/8.2.1/bits/alloc_traits.h:475:4:   required from ‘static
void std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = NoCopy; _Args = {const NoCopy&}; _Tp =
std::_List_node; std::allocator_traits
>::allocator_type = std::allocator >]’
/usr/include/c++/8.2.1/bits/stl_list.h:645:33:   required from
‘std::__cxx11::list<_Tp, _Alloc>::_Node* std::__cxx11::list<_Tp,
_Alloc>::_M_create_node(_Args&& ...) [with _Args = {const NoCopy&}; _Tp =
NoCopy; _Alloc = std::allocator; std::__cxx11::list<_Tp, _Alloc>::_Node
= std::_List_node]’
/usr/include/c++/8.2.1/bits/stl_list.h:1903:10:   required from ‘void
std::__cxx11::list<_Tp, _Alloc>::_M_insert(std::__cxx11::list<_Tp,
_Alloc>::iterator, _Args&& ...) [with _Args = {const NoCopy&}; _Tp = NoCopy;
_Alloc = std::allocator; std::__cxx11::list<_Tp, _Alloc>::iterator =
std::_List_iterator]’
/usr/include/c++/8.2.1/bits/stl_list.h:1235:4:   required from ‘void
std::__cxx11::list<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {const
NoCopy&}; _Tp = NoCopy; _Alloc = std::allocator]’
/usr/include/c++/8.2.1/bits/stl_list.h:1832:6:   required from ‘void
std::__cxx11::list<_Tp, _Alloc>::_M_initialize_dispatch(_InputIterator,
_InputIterator, std::__false_type) [with _InputIterator = const NoCopy*; _Tp =
NoCopy; _Alloc = std::allocator]’
/usr/include/c++/8.2.1/bits/stl_list.h:769:9:   required from
‘std::__cxx11::list<_Tp, _Alloc>::list(std::initializer_list<_Tp>, const
allocator_type&) [with _Tp = NoCopy; _Alloc = std::allocator;
std::__cxx11::list<_Tp, _Alloc>::allocator_type = std::allocator]’
test.cpp:10:36:   required from here
/usr/include/c++/8.2.1/ext/new_allocator.h:136:4: error: use of deleted
function ‘NoCopy::NoCopy(const NoCopy&)’
  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^~
test.cpp:4:5: note: declared here
 NoCopy(const NoCopy&) = delete;

# Expected

"required from here" is highlighted with some color

# Actual

"required from here" is of the same font/color as the rest of the text.

[Bug c/89312] snprintf warning is unparsable and not confusing

[martin at netbsd dot org]

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

--- Comment #4 from Martin Husemann  ---
This is scary.

So in the future there will be valid reasons for the truncation warning, but
you are not offering any way to suppress the totally useless false positives?

My problem with this warning is that (as of gcc 7.4) it has a S/N ratio very
close to 0. snprintf will truncate the output? Yes, that is what the standard
says and what I expect from it.

There is no usefull more targeted workaround than turning it off.

I actually did sucessfully quell the warning with this idiom:

  char buf[STRLEN];
  int r = snprintf(buf, sizeof(buf), format, );
  if (r >= sizeof(buf))
buf[sizeof(buf)-1] = 0;

but that is of course totally stupid (and hopefully gcc will eliminate the if
() part completely (but since the warning goes away, it seems not to do that).

We always compile all stuff with -Wall and -Werror, we even dealt with the very
painfull (and much too simplistic) case fallthrough checker. But with the
format truncation there is no option but to either make the code worse or turn
it off completely.

[Bug lto/88858] ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox build with LTO and PGO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||9.0
  Known to fail||7.4.0, 8.2.0

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

[Bug lto/88858] ICE in rtl_verify_fallthru, at cfgrtl.c:2930 in Firefox build with LTO and PGO

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Wed Feb 13 06:57:38 2019
New Revision: 268835

URL: https://gcc.gnu.org/viewcvs?rev=268835=gcc=rev
Log:
Remove a barrier when EDGE_CROSSING is removed (PR lto/88858).

2019-02-13  Martin Liska  

PR lto/88858
* cfgrtl.c (remove_barriers_from_footer): New function.
(try_redirect_by_replacing_jump): Use it.
(cfg_layout_redirect_edge_and_branch): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c

[Bug sanitizer/89323] Asan memory leak detection on x86 platform

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Martin Liška  ---
> works for current clang:
> 
> clang-6.0 -g -fsanitize=address -fno-omit-frame-pointer -m32  asantest.c  &&
> ./a.out 
> 
> AddressSanitizer:DEADLYSIGNAL
> =
> ==6318==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
> 0xf74f2a66 bp 0xfff26cb8 sp 0xfff26854 T0)
> 
> 

No, you forgot to provide ./a.out argument. That's why you see a SEGV.
Please try latest clang release (7) and test it. If it's failing, please report
upstream bug https://github.com/google/sanitizers/issues.

[Bug sanitizer/89323] Asan memory leak detection on x86 platform

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Martin Liška  ---
I can confirm that LSAN does not work for -m32 on current trunk. It was enabled
in:

commit 1e39eaad45fc92b49e189badf0a5a675fbfb4ad0
Author: Francis Ricci 
Date:   Tue Mar 28 21:56:44 2017 +

Enable i386 builds for darwin lsan

Summary:
Now that __thread is no longer used for lsan on darwin, i386 builds
can be enabled.

Reviewers: kcc, kubamracek

Subscribers: danalbert, srhines, mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D29995

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298946
91177308-0d34-0410-b5e6-96231b3b80d8

[Bug c++/89325] New: False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone

[thehans at gmail dot com]

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

Bug ID: 89325
   Summary: False warnings about "optimization attribute" on
operators when -fno-ipa-cp-clone
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thehans at gmail dot com
  Target Milestone: ---

Created attachment 45687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45687=edit
minimum test case

This is an issue I was having where g++ was outputting over 56,000 spurious
warnings for a project I was building. 

I found that the problem only came from including Eigen/Core header amongst
various project headers that declared operators.

I was able to use singledelta to minimize the test case down to the attached
file.

After the #pragma which comes from Eigen, it seems to break g++'s ability to
differentiate between different operator signatures and just warns that they
are all previously defined with different attributes.


Here is the warning output from g++:
testcase-min.i:4:37: warning: optimization attribute on 'int& operator<<(int&,
const B&)' follows definition but the attribute doesn't match [-Wattributes]
 int <<(int , const B );
 ^
testcase-min.i:1:35: note: previous definition of 'int& operator<<(int&, const
A&)' was here
 class A {  private:   friend int <<(int , const A ) {  return
i;  }  };
   ^~~~

[Bug gcov-profile/89307] -fprofile-generate binary may be too slow in multithreaded environment due to cache-line conflicts on counters

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please attach WIP patch you have?

[Bug target/89324] ICE in extract_constrain_insn, at recog.c:2211 on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||aarch64-linux-gnu
   Last reconfirmed||2019-2-13
 CC||jgreenhalgh at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org
   Host||x86_64-pc-linux-gnu
   Target Milestone|--- |9.0

[Bug target/89324] New: ICE in extract_constrain_insn, at recog.c:2211 on aarch64

[marxin at gcc dot gnu.org]

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

Bug ID: 89324
   Summary: ICE in extract_constrain_insn, at recog.c:2211 on
aarch64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ cat ice.f90
module a
contains
  pure function myotherlen()
myotherlen = 99
  end  
  subroutine b
characterx
block
   character(myotherlen()) c
   c = "abc"
   x = c
end block

end  
end

$ aarch64-linux-gnu-gcc ice.f90 -fsanitize=undefined -fno-schedule-insns -O2 -c
ice.f90
ice.f90:14:0:

   14 | end
  | 
Error: insn does not satisfy its constraints:
(insn 85 16 22 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (reg/f:DI 31 sp)
(const_int -3 [0xfffd])))
(set (reg/f:DI 19 x19 [110])
(plus:DI (reg/f:DI 31 sp)
(const_int 3 [0x3])))
]) "ice.f90":10:0 314 {subdi3_compare1_imm}
 (nil))
during RTL pass: cprop_hardreg
ice.f90:14:0: internal compiler error: in extract_constrain_insn, at
recog.c:2211
0x5d848d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/rtl-error.c:108
0x5d84b3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/rtl-error.c:118
0x5d7a28 extract_constrain_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/recog.c:2211
0xabec97 copyprop_hardreg_forward_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/regcprop.c:801
0xabf7e4 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/regcprop.c:1307

[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation

[amodra at gmail dot com]

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

--- Comment #17 from Alan Modra  ---
> On platforms where varargs have a different calling
> signature from normal functions, this would be an ABI change.

True, but in C terms, gfortran is currently doing this:
void f (char *res, int reslen);
..
  f (res, 20, , , , , , , );
That's why I said we have "lying prototypes".

The patch in comment #12 changes things to
void f (char *res, int reslen, ...);
..
  f (res, 20, , , , , , , );

Which at least makes the prototype and call compatible in that translation
unit.  We have ABI violations in both cases as neither prototype matches the
actual function definition.  Yes, my patch is just a hack, but..

> It would probably make more sense to build the decl from the call
> itself.
This would require major surgery, I think.  Another option would be to pass
info to the backend that the call is really not prototyped despite the presence
of those "hidden" args.

For now, I'm going to post a backend patch for this problem, in
rs6000_function_parms_need_stack:

  /* FIXME: Fortran arg lists can contain hidden parms, fooling
 prototype_p into saying the function is prototyped when in fact
 the number and type of args is unknown.  See PR 87689.  */
  if (!incoming && (strcmp (lang_hooks.name, "GNU F77") == 0
|| lang_GNU_Fortran ()))
return true;

[Bug sanitizer/89323] Asan memory leak detection on x86 platform

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-02-13
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
>works for current clang:
Have you tried a current gcc because compare a 3 year old GCC to a 6 month old
clang is not right.

[Bug sanitizer/89323] New: Asan memory leak detection on x86 platform

[ganeshemb at gmail dot com]

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

Bug ID: 89323
   Summary: Asan memory leak detection on x86 platform
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ganeshemb at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Hi,

Asan memory leak detection does not seem to on x86 platform.

Sample C program with memory leak

cat asantest.c

#include 
#include 
#include 

int main (int argc, char *argv[])
{
char *name = (char*) malloc(10);
strcpy(name, argv[1]);
printf("Hello, %s!\n", name);
return 0;
}


`gcc -g -m32 -fsanitize=address -fno-omit-frame-pointer asantest.c -o santest`

```
objdump -a asantest

asantest: file format elf32-i386
```
```
 ldd asantest
linux-gate.so.1 (0xf778a000)
libasan.so.3 => /usr/lib32/libasan.so.3 (0xf71e)
```
```
gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 
```
when program run as shown below , no leaks were detected.

```
./asantest world
Hello, world!
```
when program run with ASAN_OPTIONS , following error is shown.

```
ASAN_OPTIONS=detect_leaks=1 ./asantest world
==8192==AddressSanitizer: detect_leaks is not supported on this platform.
```
My system info

```
 lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
```
```
uname -r
4.9.0-8-amd64
```

works for current clang:

clang-6.0 -g -fsanitize=address -fno-omit-frame-pointer -m32  asantest.c  &&
./a.out 

AddressSanitizer:DEADLYSIGNAL
=
==6318==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0xf74f2a66 bp 0xfff26cb8 sp 0xfff26854 T0)



Thanks in advance.

[Bug c++/67823] ICE in tsubst_copy, at cp/pt.c:13635

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Assuming fixed, please reopen if that's not the case.

[Bug c++/71829] g++-6: internal compiler error: Segmentation fault (program cc1plus)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Marek Polacek  ---
GCC 6 is not supported anymore; no preprocessed source provided.  Please reopen
if this still fails.

[Bug c++/77304] ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed now:

77304.C: In instantiation of ‘static void* A::g() [with T = int]’:
77304.C:17:21:   required from here
77304.C:9:12: error: invalid use of member function ‘template >
void A::f() [with S  = ; T = int]’ (did you forget
the ‘()’ ?)
9 | return (void *) f < a >;
  |^~~~
  |()

I'll add the test.

[Bug c++/86961] ICE in finish_member_declaration when an alias template is used

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/67491] [meta-bug] concepts issues

[mpolacek at gcc dot gnu.org]

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

Bug 87113 Summary: ICE in adjust_temp_type at cp/constexpr.c:1205
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87113

   What|Removed |Added

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

[Bug c++/87113] ICE in adjust_temp_type at cp/constexpr.c:1205

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed by r266877.

[Bug c++/88003] ICE on outside definition of inner function-local class in poplevel_class, at cp/name-lookup.c:4325

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
That is, with this version of the test:

auto test() {
  struct O { 
struct N;
  };  
  return O();
}

typedef decltype(test()) TN;
struct TN::N {};

[Bug c++/88003] ICE on outside definition of inner function-local class in poplevel_class, at cp/name-lookup.c:4325

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-13
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Started with r185768, before:

88003.C:1:11: error: ‘test’ function uses ‘auto’ type specifier without
trailing return type
88003.C:8:23: error: ‘test’ was not declared in this scope
88003.C:8:23: error: ‘test’ was not declared in this scope
88003.C:8:28: error: invalid type in declaration before ‘;’ token
88003.C:9:8: error: ‘TN’ is not a class, namespace, or enumeration
88003.C:9:14: error: expected unqualified-id before ‘{’ token

[Bug c++/89048] constant evaluation in trailing return type rejected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-02-13
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
WAITING thus.

[Bug c++/88982] ICE in tsubst_pack_expansion, at cp/pt.c:12221

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r247842.  Before that:

88982.C: In instantiation of ‘struct A’:
88982.C:10:14:   required from here
88982.C:2:73: error: type mismatch in nontype parameter pack
   template class ...Cs, Cs ...Vs> struct B {
 ^
88982.C:2:73: error: could not convert template argument
‘#‘nontype_argument_pack’ not supported by dump_expr#’ from
‘Cs’ to ‘Cs’
88982.C:2:73: error: type mismatch in nontype parameter pack
88982.C:2:73: error: could not convert template argument
‘#‘nontype_argument_pack’ not supported by dump_expr#’ from
‘Cs’ to ‘Cs’
88982.C:10:16: error: ‘B’ in ‘struct A’ does not name a
template type
 A::B b;
^

[Bug c++/88982] ICE in tsubst_pack_expansion, at cp/pt.c:12221

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #14)
> Comment on attachment 45685 [details]
> I am testing this
> 
> The movsi change doesn't look entirely right to me.  While OImode or TImode
> is not allowed in ext sse regs unless AVX512VL, that is not the case for
> SImode, so for SImode if one or both operands are ext sse regs and
> !TARGET_AVX512VL, we need to use MODE_XI and use the pattern with %g1, %g0
> in there.

No need to set MODE_XI:

if (EXT_REX_SSE_REG_P (operands[0])
  || EXT_REX_SSE_REG_P (operands[1]))
{
  if (TARGET_AVX512VL)
return "vmovdqa32\t{%1, %0|%0, %1}"; 
  else
return "vmovdqa32\t{%g1, %0|%0, %g1}";
}
  else
return "%vmovdqa\t{%1, %0|%0, %1}";

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu  ---
[hjl@gnu-4 gcc]$ cat /tmp/z.c
/* { dg-do compile { target { ! ia32 } } } */
/* { dg-options "-O2 -march=skylake-avx512" } */

extern long long i;

long long
foo1 (void)
{
  register long long xmm16 __asm ("xmm16") = i;
  asm volatile ("" : "+v" (xmm16));
  register long long xmm17 __asm ("xmm17") = xmm16;
  asm volatile ("" : "+v" (xmm17));
  return xmm17;
}

/* { dg-final { scan-assembler-times
"vmovdqa32\[^\n\r]*xmm1\[67]\[^\n\r]*xmm1\[67]" 1 } } */
/* { dg-final { scan-assembler-not "%zmm\[0-9\]+" } } */
[hjl@gnu-4 gcc]$ gcc -S -O2 -march=skylake-avx512 /tmp/z.c   -mno-avx512vl
[hjl@gnu-4 gcc]$ cat z.s
.file   "z.c"
.text
.p2align 4,,15
.globl  foo1
.type   foo1, @function
foo1:
.LFB0:
.cfi_startproc
vmovq   i(%rip), %xmm16
vmovdqa64   %xmm16, %xmm17  <<< This is an AVX512VL instruction.
vmovq   %xmm17, %rax
ret
.cfi_endproc
.LFE0:
.size   foo1, .-foo1
.ident  "GCC: (GNU) 8.2.1 20190209 (Red Hat 8.2.1-8)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-4 gcc]$

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu  ---
[hjl@gnu-4 gcc]$ cat /tmp/y.c
/* { dg-do compile { target { ! ia32 } } } */
/* { dg-options "-O2 -march=skylake-avx512 -mprefer-vector-width=512" } */

extern float d;

void
foo1 (float x)
{
  register float xmm16 __asm ("xmm16") = x;
  asm volatile ("" : "+v" (xmm16));
  d = xmm16;
}

/* { dg-final { scan-assembler-not "%zmm\[0-9\]+" } } */
[hjl@gnu-4 gcc]$ gcc -S -O2 -march=skylake-avx512 /tmp/y.c
-mprefer-vector-width=512
[hjl@gnu-4 gcc]$ cat y.s
.file   "y.c"
.text
.p2align 4,,15
.globl  foo1
.type   foo1, @function
foo1:
.LFB0:
.cfi_startproc
vmovaps %zmm0, %zmm16
vmovss  %xmm16, d(%rip)
ret
.cfi_endproc
.LFE0:
.size   foo1, .-foo1
.ident  "GCC: (GNU) 8.2.1 20190209 (Red Hat 8.2.1-8)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-4 gcc]$

[Bug go/89193] "make distclean" leaves stuff in gotools/

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Thanks, should be fixed.

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
[hjl@gnu-4 gcc]$ cat /tmp/x.c 
/* { dg-do compile { target { ! ia32 } } } */
/* { dg-options "-O2 -march=skylake-avx512 -mprefer-vector-width=512" } */

extern double d;

void
foo1 (double x)
{
  register double xmm16 __asm ("xmm16") = x;
  asm volatile ("" : "+v" (xmm16));
  d = xmm16;
}

/* { dg-final { scan-assembler-not "%zmm\[0-9\]+" } } */
[hjl@gnu-4 gcc]$  gcc -S -O2 -march=skylake-avx512 /tmp/x.c
-mprefer-vector-width=512
[hjl@gnu-4 gcc]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  foo1
.type   foo1, @function
foo1:
.LFB0:
.cfi_startproc
vmovapd %zmm0, %zmm16
vmovsd  %xmm16, d(%rip)
ret
.cfi_endproc
.LFE0:
.size   foo1, .-foo1
.ident  "GCC: (GNU) 8.2.1 20190209 (Red Hat 8.2.1-8)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-4 gcc]$

[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Actually, the error message:

z1.c:7:1: error: unable to generate reloads for impossible constraints:

is a new LRA test that I added as part of one of my other commits that is
catching the illegal register constraints being used, so this is a correct
error message.  That said, we probably should still catch this earlier in
expand_asm_stmt().

[Bug go/89193] "make distclean" leaves stuff in gotools/

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Feb 13 00:10:06 2019
New Revision: 268830

URL: https://gcc.gnu.org/viewcvs?rev=268830=gcc=rev
Log:
PR go/89193
* Makefile.am (mostlyclean-local): Avoid getting an error from
chmod.  Remove check-vet-dir and gocache-test.
* Makefile.in: Regenerate.

Modified:
trunk/gotools/ChangeLog
trunk/gotools/Makefile.am
trunk/gotools/Makefile.in

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
I'm not sure exactly what assert it is, because there is no assert on that line
of go-gcc.cc.  But it is most likely an assertion saying that when compiling a
struct composite literal, the number of fields in the struct does not match the
number of values in the composite literal.  That should be impossible, since
the compiler fills in zero values as needed.  So unfortunately I'm not sure
that is all that helpful.

[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts

[walter.zwieflhofer at ineosteamuk dot com]

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

--- Comment #3 from zwieflhofer  ---
Contacted NCAR, the providers of the source code. The bug is known to them and
they have a workaround:
Set
-DBUILD_RRTMG_FAST=0
to
-DBUILD_RRTMG_FAST=1


From my side, this bug report can be closed. 


But I expect it to resurface as more wrf users are moving to the later gcc
compiler versions.

[Bug target/88308] ICE in maybe_record_trace_start, at dwarf2cfi.c:2309

[acsawdey at gcc dot gnu.org]

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

--- Comment #4 from acsawdey at gcc dot gnu.org ---
Tracked down the difference between -m32 and -m64. In the -m64 case,
rs6000_emit_move calls force_const_mem and that will set LABEL_PRESERVE_P on a
label_ref that it finds, which is what marks the jump table label for
preservation. In the -m32 case, none of this if tests succeed inside the case
E_SImode/E_DImode and as a result rs6000_emit_move does not call
force_const_mem.

It really seems to me like the label for the jump table should be marked for
preservation somewhere more definite than this.

[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #3 from Peter Bergner  ---
This is not a bug in my code, it's just that before my commit, we did not catch
the illegal asm constraint usage and LRA "fixed" up the code without
complaining, but given it generated code different than what the used
requested, it silently generated "wrong" code.

With my commit, we're now generating code that LRA knows is wrong and so ICEs. 
I think the fix is to catch the illegal asm constraint usage and emit a useful
error message, similar to what I did for PR87600 (r265942).  I'll see if I add
some extra test(s) to catch this scenario.  I'm actually surprised the tests I
added didn't catch this already, so there must be something special about this
test case I didn't check for.

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

[sean.wang at wdc dot com]

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

--- Comment #2 from sean.wang at wdc dot com ---
I can certainly try. Based on the backtrace, do you have an educated guess on
what type of condition in the code that I can try to isolate? For example, what
does the assert condition mean? Thank you.

[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2

[kugan at gcc dot gnu.org]

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

--- Comment #6 from kugan at gcc dot gnu.org ---

> 
> Note the difference in mode for aarch64_classify_address. Not sure if this
> is because of the way my patch changes ivopt.

Yes, it ws my mistake in iv-use. with attached patch, I now get
cmp w3, 0
ble .L1
sub w3, w3, #1
mov x4, 0
cntwx5
ptrue   p1.s, all
lsr w3, w3, 1
add w3, w3, 1
whilelo p0.s, xzr, x3
.p2align 3,,7
.L3:
ld2w{z4.s - z5.s}, p0/z, [x1, x4, lsl 2]
ld2w{z2.s - z3.s}, p0/z, [x2, x4, lsl 2]
add z0.s, z4.s, z2.s
sub z1.s, z5.s, z3.s
st2w{z0.s - z1.s}, p0, [x0, x4, lsl 2]
whilelo p0.s, x5, x3
incbx4, all, mul #2
incwx5
ptest   p1, p0.b
bne .L3
.L1:
ret
.cfi_endproc

I will post the patch for review after stage-1 opens. In the meantime any
review is appreciated. Especially the part where iv-use is setup and
get_alias_ptr_type_for_ptr_address.

[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #45661|0   |1
is obsolete||

--- Comment #5 from kugan at gcc dot gnu.org ---
Created attachment 45686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45686=edit
ivopt patch v2

[Bug libstdc++/89322] Use of new and -lsupc++ requires -lstdc++ on architectures without atomics

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-12
 Ever confirmed|0   |1

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Comment on attachment 45685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45685
I am testing this

The movsi change doesn't look entirely right to me.  While OImode or TImode is
not allowed in ext sse regs unless AVX512VL, that is not the case for SImode,
so for SImode if one or both operands are ext sse regs and !TARGET_AVX512VL, we
need to use MODE_XI and use the pattern with %g1, %g0 in there.

[Bug tree-optimization/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |tree-optimization

--- Comment #13 from Martin Sebor  ---
The patch referenced in comment #9 suppresses the warning for printf and
fprintf (leaving it for sprintf).

[Bug c/89312] snprintf warning is unparsable and not confusing

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I understand your frustration but there is no good way to tell a benign
truncation from a potentially dangerous bug, so GCC errs on the side of caution
here.

The -Wformat-truncation option detects a number of other kinds of problems, not
just truncation, so turning it off for the whole project will prevent those
other kinds of bugs from being detected.  Among these are passing null pointers
as arguments to %s directives, or unterminated arrays, as shown in the test
case below.  In the future, GCC will detect other problems, including passing
unintialized arrays to %s and overlapping copies.  So I would suggest to
consider using more targeted suppression techniques such as testing the return
value.

$ cat t.c && gcc -S -O2 -Wall t.c
const char a[4] = { '1', '2', '3', '4' };

void f (char *d, unsigned n, const char *s)
{
  __builtin_snprintf (d, n, "a = %s", a);

  if (s)   // typo: should have been 'if (!s)'
return;

  __builtin_snprintf (d, n, "s = %s", s);
}

t.c: In function ‘f’:
t.c:5:34: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-truncation=]
5 |   __builtin_snprintf (d, n, "a = %s", a);
  |  ^~   ~
t.c:1:12: note: referenced argument declared here
1 | const char a[4] = { '1', '2', '3', '4' };
  |^
t.c:10:3: warning: ‘%s’ directive argument is null [-Wformat-truncation=]
   10 |   __builtin_snprintf (d, n, "s = %s", s);
  |   ^~

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|7.5 |9.0

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
Created attachment 45685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45685=edit
I am testing this

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #5)
> actually since all the bugs seem to be about different targets triggering
> that assert in different ways, would it be possible to replace it with an
> internal_error() that provides a bit more information as to how exactly the
> compiler got there?

That is why there is a backtrace.  The assert is just asserting we can't create
any new psedu registers as the register allocator has happened already. 
Basically the backend can't directly use copy_to_mode_reg/gen_reg_rtx after
register allocation.  How do you print where you can from when it is two layers
deep?  Also this is why there is a backtrace printed out to help out.

[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
I'll have a look.

[Bug go/89321] cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
In order to fix this problem I will most likely need some way to reproduce it. 
Can you share a cut down version of the source code that triggers the problem? 
Do you happen to know if the problem occurs when compiling for amd64?

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Eric Gallager from comment #2)
> > > There are other bugs open based on that assert failing; lemme see if I can
> > > find them...
> > 
> > There might be but this is a target specific related to
> > ix86_expand_split_stack_prologue.
> 
> oh ok never mind then

actually since all the bugs seem to be about different targets triggering that
assert in different ways, would it be possible to replace it with an
internal_error() that provides a bit more information as to how exactly the
compiler got there? Right now the assertion failing isn't very informative and
has probably led me to mark more bugs as related than need to be...

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---

(In reply to Andrew Pinski from comment #3)
> (In reply to Eric Gallager from comment #2)
> > There are other bugs open based on that assert failing; lemme see if I can
> > find them...
> 
> There might be but this is a target specific related to
> ix86_expand_split_stack_prologue.

oh ok never mind then

[Bug target/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #2)
> There are other bugs open based on that assert failing; lemme see if I can
> find them...

There might be but this is a target specific related to
ix86_expand_split_stack_prologue.

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
[hjl@gnu-4 tmp]$ cat x.c
/* { dg-do compile } */
/* { dg-options "-O2 -march=skylake-avx512" } */

extern int i;

int
foo1 (void)
{
  register int xmm16 __asm ("xmm16") = i;
  asm volatile ("" : "+v" (xmm16));
  register int xmm17 __asm ("xmm17") = xmm16;
  asm volatile ("" : "+v" (xmm17));
  return xmm17;
}

int
foo2 (void)
{
  register int xmm1 __asm ("xmm1") = i;
  asm volatile ("" : "+v" (xmm1));
  register int xmm17 __asm ("xmm17") = xmm1;
  asm volatile ("" : "+v" (xmm17));
  return xmm1;
}

/* { dg-final { scan-assembler-not "%zmm\[0-9\]+" } } */
[hjl@gnu-4 tmp]$  gcc -S -O2 -march=skylake-avx512 x.c
[hjl@gnu-4 tmp]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  foo1
.type   foo1, @function
foo1:
.LFB0:
.cfi_startproc
vmovd   i(%rip), %xmm16
vmovdqa32   %zmm16, %zmm17
vmovd   %xmm17, %eax
ret
.cfi_endproc
.LFE0:
.size   foo1, .-foo1
.p2align 4,,15
.globl  foo2
.type   foo2, @function
foo2:
.LFB1:
.cfi_startproc
vmovd   i(%rip), %xmm1
vmovdqa32   %zmm1, %zmm17
vmovd   %xmm1, %eax
ret
.cfi_endproc
.LFE1:
.size   foo2, .-foo2
.ident  "GCC: (GNU) 8.2.1 20190209 (Red Hat 8.2.1-8)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-4 tmp]$

[Bug c++/89316] ICE in gen_reg_rtx, at emit-rtl.c:1155

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #1)
> Confirmed on trunk and gcc-8.
> 
> It's failing this assertion:
> 
> 1155gcc_assert (can_create_pseudo_p ());
> 
> since:
> 
> (gdb) p reload_completed
> $3 = 1

There are other bugs open based on that assert failing; lemme see if I can find
them...

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Reverting that patch on gcc-8-branch fixes the bug:

--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -1166,7 +1166,6 @@ edge_badness (struct cgraph_edge *edge, bool dump)
overall_growth += 256 * 256 - 256;
  denominator *= overall_growth;
 }
-  denominator *= ipa_fn_summaries->get (caller)->self_size + growth;

   badness = - numerator / denominator;


That line is different on trunk, so I only tested on gcc-8-branch.

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #45682|0   |1
is obsolete||

--- Comment #14 from Jonathan Wakely  ---
Created attachment 45684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45684=edit
Testcase for both bugs

This new attachment can be used to reproduce both bugs, for any GCC version
from 5.1.0 onwards, with -O1.

By default it shows the memory leak, but when BAD_WEAK_PTR_BUG is defined it
demonstrates the unexpected exception.

Defining FIXME makes both bugs go away.

I've confirmed that the original bug is caused by
_M_weak_this._M_refcount._M_pi being null:

(gdb) p tg
$1 = {_M_ptr = 0x614e80, _M_refcount = {_M_pi = 0x614e70}}
(gdb) p *tg._M_ptr
$2 = {> = {_M_weak_this = {_M_ptr =
0x614e80, _M_refcount = {_M_pi = 0x0}}}, data = 0x614ea0}

Bisecting from 4.9 to 5.1 shows the bug started with r221859:

2015-04-03  Jan Hubicka

   PR ipa/65076
   * ipa-inline.c (edge_badness): Add combined size to the denominator.

[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

Will Wray  changed:

   What|Removed |Added

 CC||wjwray at gmail dot com

--- Comment #15 from Will Wray  ---
Created attachment 45683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45683=edit
Proposed patch including updated tests

Accept braces around scalar initializer within aggregate init,
previously rejected; this patch accepts without a warning.

Reject braced empty-brace value-initialization of scalar variable
previously accepted.

Maintain C++98 rejection of scalar braced-init.

See Bug 88572 for details, standards links and extra test code.

Log:
PR c++/88572
* decl.c (reshape_init_r): Remove condition that was incorrectly
rejecting braces around scalar initializer within aggregate init. 
Produce no warning. Replace with condition rejecting braced-init
of scalar variable, including empty-brace value-initialization
that was being incorrectly accepted. Produce same error for both.

PR c++/88572
* g++.dg/cpp0x/initlist69.C: Update 2 tests; changed error, OK.
* g++.dg/cpp1z/direct-enum-init1.C: Update 3 tests; changed error.
* g++.dg/init/brace1.C: Update 1 test; error only on c++98. Add
  1 test with one more set of braces; error on too many braces.
* g++.dg/init/brace2.C: Add 1 test; empty-brace scalar init fail.
* g++.dg/init/union2.C: Update 1 test; error only on c++98. Add
  1 test with one more set of braces; error on too many braces.
* g++.dg/warn/Wbraces2.C: Update 3 test; 1 error only on c++98.
  2 now give invalid conversion instead of braces error on >98.

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #9 from John David Anglin  ---
Still present on hppa-linux.

[Bug libstdc++/89322] New: Use of new and -lsupc++ requires -lstdc++ on architectures without atomics

[jifl-bugzilla at jifvik dot org]

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

Bug ID: 89322
   Summary: Use of new and -lsupc++ requires -lstdc++ on
architectures without atomics
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jifl-bugzilla at jifvik dot org
  Target Milestone: ---

Long-standing behaviour is that if you don't want to link against the behemoth
of full libstdc++, but are still using simple C++ like new and delete, you can
link against libsupc++.

ARM9 and ARM9e (ARM arch v5) at least don't have atomic intrinsics, and
therefore the libstdc++ atomicity support relies on gthread_mutexes. When using
new, the unwinder is always pulled in to the final image (even with nothrow),
and the unwinder has a dependency in
libsupc++/eh_throw.cc:__gxx_exception_cleanup() on an atomic decrement which in
turn causes a dependency on __gnu_cxx::__exchange_and_add() as can be seen
here:

/[...]/bin/../lib/gcc/arm-eabi/7.3.0/../../../../arm-eabi/lib/arm9/nointerwork/libsupc++.a(eh_throw.o):
In function `__gxx_exception_cleanup(_Unwind_Reason_Code,
_Unwind_Control_Block*)':
(.text._ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP21_Unwind_Control_Block+0x24):
undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
collect2: error: ld returned 1 exit status

(This is a toolchain for which an arm9 multilib combo is present).

__exchange_and_add does exist in libstdc++, courtesy of
libstdc++-v3/src/c++98/atomicity.cc. To fix the above error, you need to link
with full -lstdc++, but you shouldn't need to. I guess atomicity related
functions should live in libsupc++, not libstdc++. This doesn't affect more
recent ARM architectures as they have atomic intrinics so there is no
dependency on __gnu_cxx::__exchange_and_add() when wanting to do the atomic
decrement. But it would affect any architecture (ARM or other) which doesn't
have atomic intrinsics.

Personally I can deal with the workaround, but this probably still wants to be
fixed. Some people may not want or have full libstdc++.

[Bug middle-end/64242] Longjmp expansion incorrect

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #22 from John David Anglin  ---
Also fails on hppa*-*-*.

[Bug middle-end/89284] gcc -fsanitize=undefined inhibits -Wuninitialized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-12
 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end
 Blocks||24639
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
You're right that the sanitizers tend to interfere with GCC middle-end warnings
(there are a number of reports about this in Bugzilla -- see for example bug
82076 and the comments there).  Usually the complaints are about the
instrumentation causing false positives, but as the simplified test case below
shows, it can cause false negatives as well.  It may be possible to improve
things but in general the consensus seems to be that given the current
architecture it's unavoidable.  Documenting this in the manual as you suggest
in the upstream discussion sounds like a good idea.

I'm going to confirm this until someone has looked into in more detail how
feasible avoiding the false negative might be in this instance. 

$ cat pr89284.c && gcc -O2 -S -Wall -Wno-unused -fsanitize=undefined,address
pr89284.c
struct A
{
  _Bool a;
  int i;
};

void f (void)
{
  struct A a;

  if (a.i) {   // -Wuninitialized (good)
struct A b = a;
  }
}

void g (void)
{
  struct A a;

  if (a.a) {   // missing -Wuninitialized
struct A b = a;
  }
}
pr89284.c: In function ‘f’:
pr89284.c:11:8: warning: ‘a.i’ is used uninitialized in this function
[-Wuninitialized]
   11 |   if (a.i) {   // -Wuninitialized (good)
  |   ~^~


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Alexandre Duret-Lutz from comment #6)
> I mentioned in my first comment that I had also cases that threw
> bad_weak_ptr.
> I've been able to reproduce those as follows:
> 
> % cat badwptr.cc
> #include 
> 
> class blob final: public std::enable_shared_from_this
> {
> };
> 
> int main()
> {
>   std::shared_ptr tg = std::make_shared();
>   return tg->shared_from_this().use_count();

At this line GDB shows that tg._M_ptr->_M_weak_this._M_refcount is not set
correctly:

(gdb) p *tg._M_ptr
$6 = {> = {_M_weak_this = {_M_ptr =
0x614e80, _M_refcount = {_M_pi = 0x0}}}, data = 0x614ea0}
(gdb) p tg 
$7 = {_M_ptr = 0x614e80, _M_refcount = {_M_pi = 0x614e70}}

The _M_weak_this._M_refcount._M_pi member should be the same pointer as
tg._M_refcount._M_pi.

This suggests that __weak_count::_M_assign didn't work properly, and that could
also explain why the weak count isn't correctly decremented in the other test
case, if _M_pi is null here:

  ~__weak_count() noexcept
  {
if (_M_pi != nullptr)
{
  _M_pi->_M_weak_release();
}
#ifdef FIXME
else __builtin_puts("null");
#endif
  }

That would explain why _M_weak_release() isn't called.

So if the two bugs have the same root cause, it seems to be a problem in
__weak_count::_M_assign, failing to set _M_pi here:

  __weak_count&
  operator=(const __shared_count<_Lp>& __r) noexcept
  {
_Sp_counted_base<_Lp>* __tmp = __r._M_pi;
if (__tmp != nullptr)
  __tmp->_M_weak_add_ref();
if (_M_pi != nullptr)
  _M_pi->_M_weak_release();
_M_pi = __tmp;
return *this;
  }





> }
> 
> % g++ -g -O badwptr.cc
> % ./a.out
> terminate called after throwing an instance of 'std::bad_weak_ptr'
>   what():  bad_weak_ptr
> 
> When compiled with -O2 or -O0, the program exits with $?=2 as expected.

[Bug go/89321] New: cross build with riscv64 gccgo compilation failed due to assert in constructor_expression

[sean.wang at wdc dot com]

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

Bug ID: 89321
   Summary: cross build with riscv64 gccgo compilation failed due
to assert in constructor_expression
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: sean.wang at wdc dot com
CC: cmang at google dot com
  Target Milestone: ---

* Built cross toolchain for riscv64 via gcc master branch commit hash
<4426330625ecc522a5214a990d88a68dc197b15f>

* glibc from 2.28 release branch

* Go build command: 
 /usr/local/go/bin/go/bin/go [build -o /artifacts/xx/ -compiler gccgo -v
-work -x -gccgoflags -w -s -g3 -X main.gitHash=xxx -g3 -X main.g
tUnixTime=0 -extldflags "-static -Wl,--no-export-dynamic" ./xxx]
WORK=/tmp/go-build855483278

* gccgo command:
 /scratch/cross-gccgo/tools/bin/gccgo -c -g
-fgo-pkgpath=/xxx/xxx/internal/xxx-o $WORK/b296/_go_.o -I
$WORK/b296/_importcfgroot_ ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go
./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go
./xxx.go ./xxx.go ./xxx.go ./xxx.g\
o ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go ./xxx.go
./xxx.go

* gccgo compilation warning:
 /deps/riscv64/include/libavutil/mem.h:186:1: warning: 'allg: 'alloc_size'
attribute ignored on a function returning[-Wattributes]
   186 | av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb,
size_t size);
   | ^

* gccgo internal compiler error:
--BEGIN--
# /xx/xxx/internal/xxx
go1: internal compiler error: in constructor_expression, at
go/go-gcc.cc:1811
0x638fb5 Gcc_backend::constructor_expression(Btype*,
std::vector > const&, Location)
/scratch/cross-gccgo/src/gcc/gcc/go/go-gcc.cc:1811
0x6265de
Struct_construction_expression::do_get_backend(Translate_context*)
   
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/expressions.cc:13091
0x628393
Array_construction_expression::get_constructor(Translate_context*, Btype*)
   
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/expressions.cc:13315
0x68dff2 Temporary_statement::do_get_backend(Translate_context*)
   
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/statements.cc:548
0x64f7ad Block::get_backend(Translate_context*)
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/gogo.cc:
0x689fac Block_statement::do_get_backend(Translate_context*)
   
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/statements.cc:1860
0x64f7ad Block::get_backend(Translate_context*)
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/gogo.cc:
0x652b4e Function::build(Gogo*, Named_object*)
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/gogo.cc:6141
0x65377b Named_object::get_backend(Gogo*, std::vector >&, std::vector >&,
std::vector >&)
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/gogo.cc:8228
0x65beb1 Gogo::write_globals()
/scratch/cross-gccgo/src/gcc/gcc/go/gofrontend/gogo.cc:1443
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
--END --

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

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf  ---
Moving the check from gfc_define_st_label to gfc_reference_st_label:

Index: symbol.c
===
--- symbol.c(revision 268826)
+++ symbol.c(working copy)
@@ -2743,10 +2743,6 @@
  "DO termination statement which is not END
DO"
  " or CONTINUE with label %d at %C", labelno))
return;
- if (type == ST_LABEL_DO_TARGET
- && !gfc_notify_std (GFC_STD_F2018_OBS, "Labeled DO statement "
- "at %L", label_locus))
-   return;
  break;

default:
@@ -2804,6 +2800,11 @@
  "Shared DO termination label %d at %C", labelno))
 return false;

+  if (type == ST_LABEL_DO_TARGET
+  && !gfc_notify_std (GFC_STD_F2018_OBS, "Labeled DO statement "
+ "at %L", _current_locus))
+return false;
+
   if (lp->referenced != ST_LABEL_DO_TARGET)
 lp->referenced = type;
   rc = true;

fixes the issue for me.  It consequently needs adjustment to the test case
f2018_obs.f90, since it references the line with the "do 99 ..." instead
of the do termination line.

I am wondering about the location of the error marker.  E.g. for

subroutine gfcbug151 ()
  do 99 i = 1, 10
99   continue
end subroutine gfcbug151

I get:

gfcbug151.f90:2:17:

2 |   do 99 i = 1, 10
  | 1
Warning: Fortran 2018 obsolescent feature: Labeled DO statement at (1)

But I think this is ok.

Should I submit the above, or are there better suggestions?

[Bug target/89229] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #10)
> Though, is this really a regression? I mean, have we ever emitted better
> code?

It isn't a regression.

[Bug target/89229] [7/8/9 Regression] Unnecessary ZMM in movoi_internal_avx/movti_internal

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression]|[7/8/9 Regression]
   |Unnecessary ZMM in  |Unnecessary ZMM in
   |movoi_internal_avx/movti_in |movoi_internal_avx/movti_in
   |ternal  |ternal

--- Comment #10 from Jakub Jelinek  ---
Though, is this really a regression? I mean, have we ever emitted better code?

[Bug c++/85250] Builtin operator overload resolution fails to consider user-defined conversion template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-12
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #2 from Martin Sebor  ---
Confirmed with the simplified test case below.  Not a regression.

$ cat pr85250.C && gcc -S -Wall pr85250.C
template  struct X;
template  struct X { typedef T U; };

struct A {
  template::U = 0>
  operator T();
};

int main()
{
  A a;
  return 1 + a;
}
pr85250.C: In function ‘int main()’:
pr85250.C:12:12: error: no match for ‘operator+’ (operand types are ‘int’ and
‘A’)
   12 |   return 1 + a;
  |  ~ ^ ~
  |  |   |
  |  int A

[Bug target/89229] [7/8 Regression] Unnecessary ZMM in movoi_internal_avx/movti_internal

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
[hjl@gnu-4 i386]$ cat pr89229-2.c
/* { dg-do compile } */
/* { dg-options "-O2 -march=skylake-avx512" } */

typedef __int128 __m128t __attribute__ ((__vector_size__ (16), __may_alias__));

__m128t
foo (void)
{
  register __int128 xmm16 __asm ("xmm16") = (__int128) -1;
  asm volatile ("" : "+v" (xmm16));
  return (__m128t) xmm16;
}

/* { dg-final { scan-assembler-not "%zmm\[0-9\]+" } } */
[hjl@gnu-4 i386]$ gcc -O2 -march=skylake-avx512 -S pr89229-2.c -o /tmp/x.s
[hjl@gnu-4 i386]$ cat /tmp/x.s
.file   "pr89229-2.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
vpternlogd  $0xFF, %zmm16, %zmm16, %zmm16  <<< Should be xmm16
vmovdqa64   %xmm16, %xmm0
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 8.2.1 20190209 (Red Hat 8.2.1-8)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-4 i386]$

[Bug c++/89144] [9 Regression] GCC emits undefined references when a constexpr initializer_list appears in a template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/89144] [9 Regression] GCC emits undefined references when a constexpr initializer_list appears in a template function

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Feb 12 21:18:51 2019
New Revision: 268827

URL: https://gcc.gnu.org/viewcvs?rev=268827=gcc=rev
Log:
PR c++/89144 - link error with constexpr initializer_list.

In this PR, we were unnecessarily rejecting a constexpr initializer_list
with no elements.  This seems like a fairly useless degenerate case, but it
makes sense to avoid allocating an underlying array at all if there are no
elements and instead use a null pointer, like the initializer_list default
constructor.

If the (automatic storage duration) list does have initializer elements, we
continue to reject the declaration, because the initializer_list ends up
referring to an automatic storage duration temporary array, which is not a
suitable constant initializer.  If we make it static, it should be OK
because we refer to a static array.  The second hunk fixes that case.  It
also means we won't diagnose some real errors in templates, but those
diagnostics aren't required, and we'll get them when the template is
instantiated.

* call.c (convert_like_real) [ck_list]: Don't allocate a temporary
array for an empty list.
* typeck2.c (store_init_value): Don't use cxx_constant_init in a
template.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist11.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist11a.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/typeck2.c

[Bug rtl-optimization/89313] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:2962

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-12
 CC||bergner at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Component|c   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r264897:

r264897 | bergner | 2018-10-05 22:12:30 -0400 (Fri, 05 Oct 2018) | 26 lines

gcc/
PR rtl-optimization/86939
PR rtl-optimization/87479
* ira.h (non_conflicting_reg_copy_p): New prototype.
* ira-lives.c (ignore_reg_for_conflicts): New static variable.
(make_hard_regno_dead): Don't add conflicts for register
ignore_reg_for_conflicts.
(make_object_dead): Likewise.
(non_conflicting_reg_copy_p): New function.
(process_bb_node_lives): Set ignore_reg_for_conflicts for copies.
Remove special conflict handling of REAL_PIC_OFFSET_TABLE_REGNUM.
* lra-lives.c (ignore_reg_for_conflicts): New static variable.
(make_hard_regno_dead): Don't add conflicts for register
ignore_reg_for_conflicts.  Remove special conflict handling of
REAL_PIC_OFFSET_TABLE_REGNUM.  Remove now unused argument
check_pic_pseudo_p and update callers.
(mark_pseudo_dead): Don't add conflicts for register
ignore_reg_for_conflicts.
(process_bb_lives): Set ignore_reg_for_conflicts for copies.

[Bug target/89318] [9 Regression] arm bootstap failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed then.

[Bug target/89318] [9 Regression] arm bootstap failure

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #5)
> Note the
> (insn:TI 64 23 27 (parallel [
> (set (mem/f/c:SI (plus:SI (reg/f:SI 13 sp)
> (const_int 8 [0x8])) [25 data.fn+0 S4 A64])
> (reg/f:SI 12 ip [117]))
> (set (mem/f/c:SI (plus:SI (reg/f:SI 13 sp)
> (const_int 12 [0xc])) [4 data.user+0 S4 A32])
> (reg/f:SI 13 sp))
> ]) "../../gcc-9-20190210/isl/isl_union_multi.c":69:51 347 {*arm_strd}
>  (expr_list:REG_DEAD (reg/f:SI 12 ip [117])
> (nil)))
> insn is there, but passes the constraints.  Do you have the r268766 fix in?

no, I have 268755 snapshot.

[Bug middle-end/89303] [8 Regression] memory leak with shared_ptr and enable_shared_from_this

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #45672|0   |1
is obsolete||

--- Comment #12 from Jonathan Wakely  ---
Created attachment 45682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45682=edit
Further reduced testcase

[Bug target/89318] [9 Regression] arm bootstap failure

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Note the
(insn:TI 64 23 27 (parallel [
(set (mem/f/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 8 [0x8])) [25 data.fn+0 S4 A64])
(reg/f:SI 12 ip [117]))
(set (mem/f/c:SI (plus:SI (reg/f:SI 13 sp)
(const_int 12 [0xc])) [4 data.user+0 S4 A32])
(reg/f:SI 13 sp))
]) "../../gcc-9-20190210/isl/isl_union_multi.c":69:51 347 {*arm_strd}
 (expr_list:REG_DEAD (reg/f:SI 12 ip [117])
(nil)))
insn is there, but passes the constraints.  Do you have the r268766 fix in?

[Bug target/89318] [9 Regression] arm bootstap failure

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Can't reproduce with a cross:
./cc1 -quiet -nostdinc -march=armv7-a -mtune=cortex-a9 -mfpu=vfpv3-d16
-mfloat-abi=hard -O2 pr89318.i
succeeds

[Bug target/89318] [9 Regression] arm bootstap failure

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
the instruction looks like created by your patch?

  * config/arm/ldrdstrd.md: Change peepholes to generate PARALLEL SImode
sets instead of single DImode set and define new insns to match this.

[Bug c++/89320] [9 regression] r268774 caused: FAIL: gnat.dg/vect5.adb

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Dup

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

[Bug middle-end/89294] [9 regression] ICE in valid_constant_size_p, at tree.c:7524

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #4 from H.J. Lu  ---
*** Bug 89320 has been marked as a duplicate of this bug. ***

[Bug c++/89320] New: [9 regression] r268774 caused: FAIL: gnat.dg/vect5.adb

[hjl.tools at gmail dot com]

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

Bug ID: 89320
   Summary: [9 regression] r268774 caused: FAIL: gnat.dg/vect5.adb
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

r268774 caused:

spawn -ignore SIGHUP
/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc/gnatmake
--GCC=/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc/xgcc
--GNATBIND=/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc/gnatbind
--GNATLINK=/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc/gnatlink
-cargs
-B/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc
-largs
--GCC=/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc/xgcc
-B/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc
 -margs
--RTS=/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/x86_64-pc-linux-gnu/./libada
-q -f /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gnat.dg/vect5.adb
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O3 -msse2 -fno-vect-cost-model
-fdump-tree-vect-details -c -u -S -o vect5.s^M
+===GNAT BUG DETECTED==+^M
| 9.0.1 20190212 (experimental) (x86_64-pc-linux-gnu) GCC error:   |^M
| tree check: expected class 'constant', have 'binary' (mult_expr) in  |^M
| valid_constant_size_p, at tree.c:7524|^M
| Error detected at vect5.ads:24:51|^M
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |^M
| Use a subject line meaningful to you and us to track the bug.|^M
| Include the entire contents of this bug box in the report.   |^M
| Include the exact command that you entered.  |^M
| Also include sources listed below.   |^M
+==+^M
^M
Please include these source files with error report^M
Note that list may not be accurate in some cases,^M
so please double check that the problem can still^M
be reproduced with the set of files listed.^M
Consider also -gnatd.n switch (see debug.adb).^M
^M
/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/x86_64-pc-linux-gnu/./libada/adainclude/system.ads^M
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gnat.dg/vect5.adb^M
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gnat.dg/vect5.ads^M
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gnat.dg/vect5_pkg.ads^M
/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/x86_64-pc-linux-gnu/./libada/adainclude/s-secsta.ads^M
/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/x86_64-pc-linux-gnu/./libada/adainclude/s-parame.ads^M
/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/x86_64-pc-linux-gnu/./libada/adainclude/s-stoele.ads^M
^M
compilation abandoned^M
gnatmake:
"/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gnat.dg/vect5.adb"
compilation error^M
compiler exited with status 1
Executing on host:
/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc/gnatclean
-c -q -n vect5   (timeout = 300)
spawn -ignore SIGHUP
/export/users/hjl/build/gnu/tools-build/gcc-mmx-native/build-x86_64-linux/gcc/gnatclean
-c -q -n vect5^M
FAIL: gnat.dg/vect5.adb 3 blank line(s) in output
FAIL: gnat.dg/vect5.adb (test for excess errors)

[Bug target/89318] [9 Regression] arm bootstap failure

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
Created attachment 45681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45681=edit
preprocessed isl_aff.i

[Bug fortran/87689] PowerPC64 ELFv2 function parameter passing violation

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
(In reply to Alan Modra from comment #12)
> A little more sophisticated.
> 
>   * fortran/trans-types.c (gfc_get_function_type): Use a varargs decl
>   unless we have args other than hidden ones.

Without having looked at exactly what the patch does: This sounds wrong
to em. On platforms where varargs have a different calling
signature from normal functions, this would be an ABI change.

It would probably make more sense to build the decl from the call
itself.

[Bug tree-optimization/89317] Ineffective code from std::copy

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
If we avoid changing the type from int16_t to uint16_t, we get 2 calls to
memmove. They don't get expanded, probably because we fail to simplify the size
to 16 in gimple:
  _1 = [(void *)this_5(D) + 16B];
  _2 = _5(D)->data1;
  _10 = _1 - _2;

[Bug tree-optimization/89317] Ineffective code from std::copy

[bugzi...@poradnik-webmastera.com]

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

--- Comment #2 from Daniel Fruzynski  ---
Yes, I mean inefficient.

[Bug target/89318] arm bootstap failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can you please attach preprocessed isl_aff.i ?

[Bug target/89318] [9 Regression] arm bootstap failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |9.0
Summary|arm bootstap failure|[9 Regression] arm bootstap
   ||failure

[Bug tree-optimization/89317] Ineffective code from std::copy

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
You mean inefficient, right? The effects are correct as far as I can see.

[Bug tree-optimization/89314] [7/8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target

[wschmidt at gcc dot gnu.org]

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

--- Comment #26 from Bill Schmidt  ---
Yes, that indeed helps!  With that we see it once per directory prior to
running the tests, like the other existing checks.  Thanks!

[Bug c++/89311] Brace initialization needlessly invokes destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Jonathan Wakely  ---
(In reply to Raphael Kubo da Costa from comment #0)
> This is related to bug 85552 and bug 57082 as far as I can see.

Yes, it seems like a dup of one or both.

[Bug c++/89299] __attribute__ cleanup does not accept template function

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
For now I suggest this patch for the docs:

--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -6815,6 +6815,11 @@ does not allow the exception to be caught, only to
perform an action.
 It is undefined what happens if @var{cleanup_function} does not
 return normally.

+In C++ the @var{cleanup_function} must be a normal function.
+Other types of callable such as a function templates,
+lambda expressions or function objects with @code{operator()}
+are not supported.
+
 @item common
 @itemx nocommon
 @cindex @code{common} variable attribute

[Bug target/89319] PowerPC generates poor code when using attribute((vector_size(32))

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
I expect this is a DUP of bug 55266 and many others. Vector lowering for
unsupported sizes is not done very cleverly...
Not closing in case there are some mitigations you can do in the ppc backend.

[Bug c++/88368] [7/8/9 Regression] Improper ``use of deleted function''

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/88294] [9 Regression] ICE on (invalid) C++11 code: in tsubst_copy, at cp/pt.c:15391

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/89297] [9 Regression] ICE: unexpected expression 'id' of kind overload

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|ICE: unexpected expression  |[9 Regression] ICE:
   |'id' of kind overload   |unexpected expression 'id'
   ||of kind overload

[Bug tree-optimization/89314] [7/8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jakub at gcc dot gnu.org
  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.5

[Bug testsuite/88920] [9 regression] GCC is not configured to support amdgcn-unknown-amdhsa as offload target

[jakub at gcc dot gnu.org]

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

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

For that I agree it is annoying, does the following patch fix it?
There is another issue, once any test uses dg-allow-blank-lines-in-output,
empty lines are allowed in all following tests.

[Bug rtl-optimization/89275] [9 Regression] Slowdown in mcperf on POWER

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can anyone reproduce that and if yes, can it be bisected?

[Bug sanitizer/89308] [8 only] The sanitizers do no longer work on GCC 8 with newer kernels

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I looked through the various patches for the sanitizer stuff and the important
one that is missing is the one that disables ASLR when the sanitizers are in
use.  This would "solve" the issue where the thread sanitizer tests fail
depending on how ASLR has laid out memory (something I see all the time with
gcc-8 and recent kernels).

However, the thing that prompted this bug report

https://github.com/openbmc/openbmc-build-scripts/commit/282e33011ea62fe80bff2c5ab0e9ef9446d6c551

is dealing with the *address* sanitizer and I haven't seen that sort of
problem.  It looks like it occurs when they are building openbmc which I have
never done.

[Bug c++/89315] [9 Regression] Cannot convert to std::initializer_list - fails with gcc9 works with gcc8

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-12
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |9.0
Summary|Cannot convert to   |[9 Regression] Cannot
   |std::initializer_list - |convert to
   |fails with gcc9 works with  |std::initializer_list -
   |gcc8|fails with gcc9 works with
   ||gcc8
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Ugh, another r268321 :(.

[Bug target/89319] PowerPC generates poor code when using attribute((vector_size(32))

[g...@the-meissners.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 45678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45678=edit
Power9 assembly code to show the poor code generation

This was the assembly code using -O3 -mcpu=power9