[Bug tree-optimization/90018] [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
On trunk, r265457 fixed 527.cam4_r in SPEC CPU 2017 with:

-march=native -Ofast -funroll-loops

[Bug tree-optimization/90018] [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-09
   Target Milestone|--- |8.4
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
r265452, which was backported to GCC 8 as r265453, caused the same failure
on trunk.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[juergen.reuter at desy dot de]

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

--- Comment #40 from Jürgen Reuter  ---
Are there any news on this?

[Bug tree-optimization/90020] [8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

[eggert at cs dot ucla.edu]

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

--- Comment #1 from eggert at cs dot ucla.edu ---
Created attachment 46107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46107=edit
gcc -O2 -Os compiled output for x86-64

The attached x.s file shows the incorrect generated code, compiled with gcc -O2
-Os.

[Bug tree-optimization/90020] New: [8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs

[eggert at cs dot ucla.edu]

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

Bug ID: 90020
   Summary: [8 regression] -O2 -Os x86-64 wrong code generated for
GNU Emacs
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 46106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46106=edit
source code illustrating the bug

In:

https://lists.gnu.org/r/emacs-devel/2019-04/msg00209.html

Madhu reports several crashes when compiling applications with 'gcc -O2 -Os' on
x86-64. Madhu isolated the example to a crash with GNU Emacs, and I narrowed
this down to 'gcc -O2 -Os' generating incorrect code for Emacs. I further
narrowed it down to the attached file x.i. I used gcc 8.3.1 20190223 (Red Hat
8.3.1-2) on x86-64 to compile it like this:

gcc -O2 -Os -S x.i

and am attaching a copy of the input x.i and the output x.s. GCC miscompiled
the subroutine 'select_window'. The source code looks like this:

Lisp_Object
select_window (Lisp_Object window)
{
  CHECK_TYPE (WINDOWP (window) && BUFFERP (XWINDOW (window)->contents),
  builtin_lisp_symbol (1214), window);
  struct window *w = XWINDOW (window);
  return w->contents;
}

but the assembly language looks like this:

select_window:
pushq   %rbp
pushq   %rbx
movq%rdi, %rbx
pushq   %rcx
callWINDOWP
movq3(%rbx), %rbp
...

and that last movq is incorrect, because it dereferences %rbx ('window' in the
source code) even though it is not known whether WINDOWP returned true. In the
source code, if WINDOWP(window) returns false then 'window' is never used
except as an undereferenced pointer value, and it is possible for
WINDOWP(window) to return false without dereferencing 'window' so it is not
safe for the caller to assume that 'window' is dereferenceable. The incorrect
code causes GCC to dump core.

This problem does not occur with GCC 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04).
Madhu observed the problem with GCC 8.2 so I suspect the problem was introduced
in GCC 8.

I don't know which GCC component is causing the problem and am guessing
tree-optimization.

[Bug c++/90019] New: [8 regression] Bogus ambiguous overload error for NTTP pack of disjoint enable_ifs unless there is an unsupplied default argument

[redbeard0531 at gmail dot com]

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

Bug ID: 90019
   Summary: [8 regression] Bogus ambiguous overload error for NTTP
pack of disjoint enable_ifs unless there is an
unsupplied default argument
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

This code compiles fine with 7 and trunk but fails with gcc8:
https://godbolt.org/z/v1HN8B

#include 

// gcc8 thinks these are ambiguous for <0>
template ...> void foo(){}
template ...> void foo(){}

// but somehow these arn't for <0>, but are for <0,0> !?
template ...> void bar(){}
template ...> void bar(){}

void test() {
bar<0>(); // works
bar<0,0>(); // boom
foo<0>(); // boom
}

[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range

[JunMa at linux dot alibaba.com]

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

--- Comment #5 from JunMa  ---
(In reply to Martin Sebor from comment #4)
> You're right that the conversion from int128_t to unsigned long can result
> in truncation, so the range of the result is that of unsigned long.  Yet I
> suspect that relying on it is more likely unintentional and a bug.  The
> question in my mind is whether narrowing int128_t conversions should be
> diagnosed just in these contexts (i.e., -Wstringop-overflow) or in others as
> well.

We have no idea whether these truncations is intentional or not in gcc side,
maybe we need a new option such as Wstringop-truncation to do this.

[Bug target/90015] riscv: typo "intterupt" in diagnostic

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson  ---
I tested Jakub's patch with 32-bit elf and 64-bit linux cross compilers.  There
were no regressions.  The patch is OK.

[Bug tree-optimization/90018] New: [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

Bug ID: 90018
   Summary: [8 Regression] r265453 miscompiled 527.cam4_r in SPEC
CPU 2017
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86-64 with AVX512, r265453 miscompiled 527.cam4_r in SPEC CPU 2017 with:

-march=native -Ofast -funroll-loops

527.cam4_r segfaults immediately. GCC 7 branch and master branch are OK.

[Bug debug/90017] New: gcc generates wrong debug information at -O3

[qrzhang at gatech dot edu]

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

Bug ID: 90017
   Summary: gcc generates wrong debug information at -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It seems to be a recent regression, starting at r269302.
It only affects "-O3" and trunk.
The correct value is "l=0". With -O3, it generates l=8.


$ gcc-trunk -v
gcc version 9.0.1 20190408 (experimental) [trunk revision 270202] (GCC)

#correct output#
$ gcc-trunk -g abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4004a5: file abc.c, line 15.

Breakpoint 1, main () at abc.c:15
15optimize_me_not();
$1 = 0

#wrong output#
$ gcc-trunk -g abc.c -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400470: file abc.c, line 15.

Breakpoint 1, main () at abc.c:15
15optimize_me_not();
$1 = 8







$ cat abc.c
__attribute__((noipa))  optimize_me_not(){
   __asm__ volatile ("" : : : "memory");
 }

int a, b;
int c[][2] = {{2}, {5}, 2};
int main() {
  {
int l;
for (; b <= 1; b++) {
  l = 0;
  for (; l <= 8; l++) {
a ^= c[b + 1][b];
if (a)
  optimize_me_not();
  }
}
  }
}


$ cat cmds
b 15
r
p l
k
q

[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 #15 from kugan at gcc dot gnu.org ---
(In reply to Wilco from comment #11)
> There is also something odd with the way the loop iterates, this doesn't
> look right:
> 
> whilelo p0.s, x3, x4
> incwx3
> ptest   p1, p0.b
> bne .L3

I am not sure I understand this. I tried with qemu using an execution testcase
and It seems to work.

whilelo p0.s, x4, x5
incwx4
ptest   p1, p0.b
bne .L3
In my case I have the above (register allocation difference only) incw is
correct considering two vector word registers? Am I missing something here?

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[kargl at gcc dot gnu.org]

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

--- Comment #23 from kargl at gcc dot gnu.org ---
Created attachment 46105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46105=edit
fix g++ problem with pow(z,0.5) where imag(z) = -0.

This patch has only been tested with the original test provided by the
reporter.

[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 #14 from kugan at gcc dot gnu.org ---
Created attachment 46104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46104=edit
testcase

[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 #46040|0   |1
is obsolete||

--- Comment #13 from kugan at gcc dot gnu.org ---
Created attachment 46103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46103=edit
ivopt changes alone

[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 #12 from kugan at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> (In reply to kugan from comment #9)
> > Created attachment 46040 [details]
> > patch
> 
> Wasn't sure whether this patch was WIP or the final version
> for review, but we need to do something more generic than
> dividing by 4.  I think the test will still fail with "int"
> changed to "short" for example.
> 
> I also don't think the new candidate should be tied to the
> mask/load store functions.  Maybe one approach would be to
> check when adding a zero-based candidate for a use in:
> 
>   /* Record common candidate with initial value zero.  */
>   basetype = TREE_TYPE (iv->base);
>   if (POINTER_TYPE_P (basetype))
> basetype = sizetype;
>   record_common_cand (data, build_int_cst (basetype, 0), iv->step, use);
> 
> whether the use actually benefits from this unscaled iv.
> If the use is USE_REF_ADDRESS, we could compare the cost
> of an address with an unscaled index with the cost of an address
> with a scaled index.  I think the natural scale value to try
> would be GET_MODE_INNER (TYPE_MODE (mem_type)).

Thanks for the comments. I agree this is the right place. But I am not sure if
checking the cost at this point is what IV opt generally does. In general,
IV-opt adds candidates which can be helpful and later decides the optimal set. 

If we are to use get_computation_cost to see the costs, we have to create
iv_cand and then discard. Since we are adding only one candidate and that too
for SVE like targets, I am thinking that it is OK. If you still prefer to check
the cost, I will change that.

Attached patch (only the ivopt changes) and testcase

[Bug d/88150] Use sections_elf_shared.d on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Iain Buclaw  ---
> I've got a (horrible?) hack for getting tls_modid from Solaris.

Cool, and not really horrible ;-)  It's already this way in Solaris 9 (I
happen to have access to those sources and just checked), so we can
assume this is stable.

> Looking at dlinfo(RTLD_DI_LINKMAP):
>
> https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8b3a1ffd1d4/usr/src/cmd/sgs/rtld/common/dlfcns.c#L1927-L1934

I missed that because I initially looked only at public headers for
tlsmodid, and Rt_map is private to ld.so.1.  This is intentionally
missing from dlinfo(3C), too.  I only found it in 's
rd_loadobj_t, but it seemed hard to apply librtld_db to the current
process instead of one being debugged...

> Interestingly, Solaris sets the first tlsmodid to zero.
>
> https://github.com/illumos/illumos-gate/blob/8a06b3d6467c15646e663c05086378f16288af85/usr/src/cmd/sgs/rtld/common/tls.c#L52-L60
>
> This is in stark contrast to what elf_shared expects, given that there's an
> assert that it is always non-zero if _tlsSize is set.

Right: 0 had been used for the tlsmodid of the main executable until
dlpi_tls_modid was added to dl_phdr_info for Solaris 11.5 (still in
beta) when this would-be incompatibility with the Linux and BSD versions
was noticed.  It was only changed to 1 once it could be determined that
it was safe to do so.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #22 from Steve Kargl  ---
On Mon, Apr 08, 2019 at 10:17:00PM +, redi at gcc dot gnu.org wrote:
> (In reply to kargl from comment #19)
> > I get the expected.  So, if you're on a system that has
> > _GLIBCXX_USE_C99_COMPLEX, you won't see the bug.
> 
> Wow, why isn't libstdc++ using the C99  functions on FreeBSD?
> 

Because it is all or nothing.  See comment #8 and #9 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
If you're too busy to look at PR89125 the upshot is that
FreeBSD is missing ccoshl, ccosl, cexpl, csinhl, csinl,
ctanhl, and ctanl.  I have BSD licensed versions of 
ccoshl, ccosl, cexpl, csinhl, and csinl, but testing
on FreeBSD ran into what I consider to be a very bad
bug in clang (FreeBSD system compiler).

[Bug d/88150] Use sections_elf_shared.d on Solaris

[ibuclaw at gdcproject dot org]

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

--- Comment #10 from Iain Buclaw  ---
I've got a (horrible?) hack for getting tls_modid from Solaris.

Looking at dlinfo(RTLD_DI_LINKMAP):

https://github.com/illumos/illumos-gate/blob/4e0c5eff9af325c80994e9527b7cb8b3a1ffd1d4/usr/src/cmd/sgs/rtld/common/dlfcns.c#L1927-L1934

The lmp variable returned is originally an Rt_map*, layout is:
---
struct Rt_map
{
Link_map rt_public;
const char* rt_pathname;
c_ulong rt_padstart;
c_ulong rt_padimlen; 
c_ulong rt_msize;
uint rt_flags;
uint rt_flags1;
c_ulong rt_tlsmodid;
}
---

Let's do a little test...
---
case PT_TLS: // TLS segment
assert(!pdso._tlsSize); // is unique per DSO
static if (OS_Have_Dlpi_Tls_Modid)
{
pdso._tlsMod = info.dlpi_tls_modid;
pdso._tlsSize = phdr.p_memsz;
}
else version (Solaris)
{
Rt_map* map;
version (Shared)
dlinfo(handleForName(info.dlpi_name), RTLD_DI_LINKMAP, );
else
dlinfo(RTLD_SELF, RTLD_DI_LINKMAP, );
pdso._tlsMod = map.rt_tlsmodid;
pdso._tlsSize = phdr.p_memsz;
}
else
{
pdso._tlsMod = 0;
pdso._tlsSize = 0;
}
break;
---

Inspecting this in gdb
---
(gdb) p map
$1 = (struct Rt_map *) 0xfedb001
(gdb) p *map
$2 = {rt_public = {l_addr = 4275896320, 
l_name = 0xfc0f02e4
"/mnt/build/i386-pc-solaris2.11/./libphobos/libdruntime/.libs/libgdruntime.so.76",
l_ld = 0xfedd00d4, l_next = 0xfedb0678, l_prev = 0xfef206c8, l_refname = 0x0}, 
  rt_pathname = 0xfc0f0334
"/mnt/build/i386-pc-solaris2.11/libphobos/libdruntime/.libs/libgdruntime.so.76.0.3",
rt_padstart = 4275896320, rt_padimlen = 1272912, rt_msize = 1272912, rt_flags =
272761348, 
  rt_flags1 = 1155, rt_tlsmodid = 2}
---

And there it is, a valid rt_tlsmodid.

Interestingly, Solaris sets the first tlsmodid to zero.

https://github.com/illumos/illumos-gate/blob/8a06b3d6467c15646e663c05086378f16288af85/usr/src/cmd/sgs/rtld/common/tls.c#L52-L60

This is in stark contrast to what elf_shared expects, given that there's an
assert that it is always non-zero if _tlsSize is set.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[kargl at gcc dot gnu.org]

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

--- Comment #21 from kargl at gcc dot gnu.org ---
Created attachment 46102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46102=edit
fix g++ problem with sqrt(z) where z is complex and imag(z) = -0

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to Steve Kargl from comment #16)
> If Andrew is correct and a builtin is called,

Wasn't that me, not Andrew?

> you might find
> my results if you use -fno-builtins (check spelling).

No, same results. Calling __builtin_csqrt doesn't necessarily mean GCC
evaluates it. Without optimisation it still generates a call to csqrt from
libc.

> Looking at ./libstdc++-v3/include/std/complex, one finds.
> 
>   // 26.2.8/13 sqrt(__z): Returns the complex square root of __z.
>   // The branch cut is on the negative axis.
>   template
> complex<_Tp>
> __complex_sqrt(const complex<_Tp>& __z)
> {
>   _Tp __x = __z.real();
>   _Tp __y = __z.imag();
> 
>   if (__x == _Tp())
> {
>   _Tp __t = sqrt(abs(__y) / 2);
>   return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
> }
>   else
> {
>   _Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
>   _Tp __u = __t / 2;
>   return __x > _Tp()
> ? complex<_Tp>(__u, __y / __t)
> : complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
> }
> }
> 
> Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?

Yes, but that code shouldn't be used for modern targets ...

(In reply to kargl from comment #19)
> I get the expected.  So, if you're on a system that has
> _GLIBCXX_USE_C99_COMPLEX, you won't see the bug.

Wow, why isn't libstdc++ using the C99  functions on FreeBSD?

I'll have to look into that.

> It is likely that everywhere that a construct of the
> form __y < _Tp() ? -__u : __u appear, it needs to use
> copysign.

That won't always work, because the generic functions should really only get
used when _Tp is not one of float, double or long double. And in that case
there might be no copysign for the type.

For float, double and long double we should be using the libc routines. So the
bug is that FreeBSD isn't using them.

The _original_ bug report is for std::pow though, and on Ubuntu, which does use
glibc. Comment 9 needs more analysis.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[kargl at gcc dot gnu.org]

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

--- Comment #19 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #18)
> On Mon, Apr 08, 2019 at 08:03:36PM +, pinskia at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
> > 
> > --- Comment #17 from Andrew Pinski  ---
> > >Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?
> > 
> > No, you missed this part:
> > // The branch cut is on the negative axis.
> 
> No, I didn't miss that part.
> 
> > So maybe the bug is inside FreeBSD and Window's libm.  Glibc fixed the 
> > branch
> > cuts issues back in 2012 for csqrt but the other OS's did not change theirs.
> 
> For the C++ code in comment, on x86_64-*-freebsd.
> 
> % g++8 -o z a.cpp -lm && ./z
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
>   sqrt(z) = (0,0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,-0.000429243887758258)
> 
> The last two lines are definitely wrong.
> 
> troutmask:sgk[209] nm z | grep csqrt
> troutmask:sgk[210] nm z | grep sqrt
> 0040156b W _ZSt14__complex_sqrtIdESt7complexIT_ERKS2_
> 0040143d W _ZSt4sqrtIdESt7complexIT_ERKS2_
>  U sqrt@@FBSD_1.0
> 
> There is no reference to csqrt in the exectuable.  If I change
> /usr/local/lib/gcc8/include/c++/complex to use copysign
> to account for __y = -0 like
> 
>   template
> complex<_Tp>
> __complex_sqrt(const complex<_Tp>& __z)
> {
>   _Tp __x = __z.real();
>   _Tp __y = __z.imag();
> 
>   if (__x == _Tp())
> {
>   _Tp __t = sqrt(abs(__y) / 2);
> //  return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
>   return complex<_Tp>(__t, copysign(__t, __y));
> }
>   else
> {
>   _Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
>   _Tp __u = __t / 2;
> //  return __x > _Tp()
> //? complex<_Tp>(__u, __y / __t)
> //: complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
>   return __x > _Tp()
> ? complex<_Tp>(__u, __y / __t)
> : complex<_Tp>(abs(__y) / __t, copysign(__u, __y));
> }
> }
> 
> 
> The C++ code in comment #10 gives
> 
>  g++8 -o z a.cpp -lm && ./z
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
>   sqrt(z) = (0,-0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,0.000429243887758258)
> 
> The correct answer.  QED.

BTW, if change /usr/local/lib/gcc8/include/c++/complex back to
no using copysign(), and instead change

#if _GLIBCXX_USE_C99_COMPLEX
  inline __complex__ float
  __complex_sqrt(__complex__ float __z) { return __builtin_csqrtf(__z); }

to 

#if _GLIBCXX_USE_C99_COMPLEX || SOMETHING_UGLY
  inline __complex__ float
  __complex_sqrt(__complex__ float __z) { return __builtin_csqrtf(__z); }

and do 

 g++8 -DSOMETHING_UGLY -o z a.cpp -lm && ./z
z = (-1.84250315177824e-07,-0)
   pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
  sqrt(z) = (0,-0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,0.000429243887758258)

I get the expected.  So, if you're on a system that has
_GLIBCXX_USE_C99_COMPLEX, you won't see the bug.

It is likely that everywhere that a construct of the
form __y < _Tp() ? -__u : __u appear, it needs to use
copysign.

[Bug translation/89939] messages for translation must not contain embedded macro parameters

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Dominique d'Humieres  ---
*** Bug 90014 has been marked as a duplicate of this bug. ***

[Bug fortran/90014] Untranslatable Fortran diagnostics

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Dup.

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

[Bug c/448] -related issues (C99 issues)

[coypu at sdf dot org]

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

--- Comment #44 from coypu  ---
(In reply to jos...@codesourcery.com from comment #31)
> GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), 

Speaking for NetBSD only:
as of https://gcc.gnu.org/viewcvs/gcc?view=revision=253323 , we
include netbsd-stdint.h for all netbsd targets.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #18 from Steve Kargl  ---
On Mon, Apr 08, 2019 at 08:03:36PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
> 
> --- Comment #17 from Andrew Pinski  ---
> >Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?
> 
> No, you missed this part:
> // The branch cut is on the negative axis.

No, I didn't miss that part.

> So maybe the bug is inside FreeBSD and Window's libm.  Glibc fixed the branch
> cuts issues back in 2012 for csqrt but the other OS's did not change theirs.

For the C++ code in comment, on x86_64-*-freebsd.

% g++8 -o z a.cpp -lm && ./z
z = (-1.84250315177824e-07,-0)
   pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
  sqrt(z) = (0,0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,-0.000429243887758258)

The last two lines are definitely wrong.

troutmask:sgk[209] nm z | grep csqrt
troutmask:sgk[210] nm z | grep sqrt
0040156b W _ZSt14__complex_sqrtIdESt7complexIT_ERKS2_
0040143d W _ZSt4sqrtIdESt7complexIT_ERKS2_
 U sqrt@@FBSD_1.0

There is no reference to csqrt in the exectuable.  If I change
/usr/local/lib/gcc8/include/c++/complex to use copysign
to account for __y = -0 like

  template
complex<_Tp>
__complex_sqrt(const complex<_Tp>& __z)
{
  _Tp __x = __z.real();
  _Tp __y = __z.imag();

  if (__x == _Tp())
{
  _Tp __t = sqrt(abs(__y) / 2);
//  return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
  return complex<_Tp>(__t, copysign(__t, __y));
}
  else
{
  _Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
  _Tp __u = __t / 2;
//  return __x > _Tp()
//? complex<_Tp>(__u, __y / __t)
//: complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
  return __x > _Tp()
? complex<_Tp>(__u, __y / __t)
: complex<_Tp>(abs(__y) / __t, copysign(__u, __y));
}
}


The C++ code in comment #10 gives

 g++8 -o z a.cpp -lm && ./z
z = (-1.84250315177824e-07,-0)
   pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
  sqrt(z) = (0,-0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,0.000429243887758258)

The correct answer.  QED.

[Bug c/448] -related issues (C99 issues)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||coypu at sdf dot org

--- Comment #43 from Eric Gallager  ---
(In reply to Eric Gallager from comment #39)
> (In reply to jos...@codesourcery.com from comment #38)
> > I think the correct state is NEW.  There is a well-defined set of target 
> > OSes that lack the target macro definitions describing those targets' 
> > stdint.h types, each of which should be straightforward to fix for someone 
> > with access to the target OS in question to examine its headers and run 
> > tests.
> 
> That's still these ones, right?
> 
> (In reply to jos...@codesourcery.com from comment #31)
> > The following targets still appear to be missing this type information in 
> > GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), 
> > VxWorks, SymbianOS, LynxOS, QNX, TPF.  Others have either been fixed, or 
> > obsoleted and removed.
> 
> cc-ing maintainers of those ports

coypu at sdf dot org seems to be a de facto maintainer for NetBSD these days so
cc-ing them as well

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski  ---
>Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?

No, you missed this part:
// The branch cut is on the negative axis.

So maybe the bug is inside FreeBSD and Window's libm.  Glibc fixed the branch
cuts issues back in 2012 for csqrt but the other OS's did not change theirs.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #16 from Steve Kargl  ---
On Mon, Apr 08, 2019 at 07:20:22PM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
> 
> --- Comment #13 from Jonathan Wakely  ---
> (In reply to Steve Kargl from comment #10)
> > %  g++8 -o z  a.cpp -lm && ./z
> > z = (-1.84250315177824e-07,-0)
> >pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
> >   sqrt(z) = (0,0.000429243887758258)
> > sqrt(conj(z)) = (0,0.000429243887758258)
> > conj(sqrt(z)) = (0,-0.000429243887758258)
> > 
> > This looks wrong.
> 
> I can't reproduce this, I get:
> 
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
>   sqrt(z) = (0,-0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,0.000429243887758258)
> 

My results are for i585-*-freebsd, which doesn't use glibc.
If Andrew is correct and a builtin is called, you might find
my results if you use -fno-builtins (check spelling).

Looking at ./libstdc++-v3/include/std/complex, one finds.

  // 26.2.8/13 sqrt(__z): Returns the complex square root of __z.
  // The branch cut is on the negative axis.
  template
complex<_Tp>
__complex_sqrt(const complex<_Tp>& __z)
{
  _Tp __x = __z.real();
  _Tp __y = __z.imag();

  if (__x == _Tp())
{
  _Tp __t = sqrt(abs(__y) / 2);
  return complex<_Tp>(__t, __y < _Tp() ? -__t : __t);
}
  else
{
  _Tp __t = sqrt(2 * (std::abs(__z) + abs(__x)));
  _Tp __u = __t / 2;
  return __x > _Tp()
? complex<_Tp>(__u, __y / __t)
: complex<_Tp>(abs(__y) / __t, __y < _Tp() ? -__u : __u);
}
}

Doesn't this gets the wrong answer for __y = -0 (as -0 < 0 is false)?

[Bug target/90016] New: aarch64: reference to undeclared N in help for command line option

[roland.illig at gmx dot de]

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

Bug ID: 90016
   Summary: aarch64: reference to undeclared N in help for command
line option
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From aarch64.opt:

-msve-vector-bits=  Set the number of bits in an SVE vector
register to N.

In a previous version, the text was "-msve-vector-bits=N", and in that version
the "set to N" made sense. After changing the N to , the N refers to an
undefined identifier.

[Bug target/90015] riscv: typo "intterupt" in diagnostic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Steve Kargl from comment #10)
> > %  g++8 -o z  a.cpp -lm && ./z
> > z = (-1.84250315177824e-07,-0)
> >pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
> >   sqrt(z) = (0,0.000429243887758258)
> > sqrt(conj(z)) = (0,0.000429243887758258)
> > conj(sqrt(z)) = (0,-0.000429243887758258)
> > 
> > This looks wrong.
> 
> I can't reproduce this, I get:
> 
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
>   sqrt(z) = (0,-0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,0.000429243887758258)

My bet now comes to the fact there have been improvements to glibc which
changed the behavior here   

Also I used the wrong term, it is the branch cut that is the issue.  Most of
the branch cuts were fixed in glibc in 2012; though there might have been some
fixed later on.

[Bug libstdc++/89851] [9 Regression] std::variant comparison operators violate [variant.relops]

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This seems to have been fixed recently.

[Bug target/90015] New: riscv: typo "intterupt" in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 90015
   Summary: riscv: typo "intterupt" in diagnostic
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

risvc.c:

error ("%qs function cannot have different intterupt type.", "interrupt");

intterupt should be interrupt

[Bug libstdc++/90008] [9 Regression] variant attempts to copy rhs in comparison operators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1118,7 +1118,7 @@ namespace __variant
 { \
   bool __ret = true; \
   __do_visit<__detail::__variant::__visit_with_index>( \
-[&__ret, &__lhs, __rhs] \
+[&__ret, &__lhs] \
 (auto&& __rhs_mem, auto __rhs_index) mutable \
   -> __detail::__variant::__variant_idx_cookie \
 { \

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Which is unsurprising because std::sqrt(z) just calls
__builtin_csqrt(z.__rep())

[Bug fortran/90014] New: Untranslatable Fortran diagnostics

[jakub at gcc dot gnu.org]

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

Bug ID: 90014
   Summary: Untranslatable Fortran diagnostics
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

gcc/po/gcc.pot has:
#. Macros for unified error messages.
#: fortran/frontend-passes.c:3746
msgid "Incorrect extent in argument B in MATMUL intrinsic in dimension "
msgstr ""

#: fortran/frontend-passes.c:3749
msgid "Array bound mismatch for dimension "
msgstr ""

which is what exgettext creates for:
#define B_ERROR(n) _("Incorrect extent in argument B in MATMUL intrinsic in " \
 "dimension " #n ": is %ld, should be %ld")

#define C_ERROR(n) _("Array bound mismatch for dimension " #n " of array " \
 "(%ld/%ld)")
and
B_ERROR(1) or C_ERROR(1) or C_ERROR(2).

This simply won't work, exgettext isn't able to deal with that kind of
stringification.
Either use %d and somehow propagate the value as another argument, or
use B_ERROR_1, C_ERROR_1 and C_ERROR_2 macros that won't use this kind of
stringification.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Steve Kargl from comment #10)
> %  g++8 -o z  a.cpp -lm && ./z
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
>   sqrt(z) = (0,0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,-0.000429243887758258)
> 
> This looks wrong.

I can't reproduce this, I get:

z = (-1.84250315177824e-07,-0)
   pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
  sqrt(z) = (0,-0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,0.000429243887758258)

[Bug d/90013] New: wrong quotes in diagnostics

[roland.illig at gmx dot de]

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

Bug ID: 90013
   Summary: wrong quotes in diagnostics
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

The GCC standard for diagnostics is:

* placeholders are quoted: use %qs instead of a simple %s
* quotes are written % instead of `this' or `this` or 'this' or
"this" or similar variants

Since the D diagnostics are marked with "gcc-internal-format", as a translator
I expect that I can use the full range of these placeholders. The current
diagnostics only use the simple %s, therefore my assumption might be wrong. If
it is, it's the fault of the program that generates the .pot file. That should
be fixed to not mark these strings as gcc-internal-format then.

[Bug d/90012] New: untranslateable placeholder in expressionsem.c

[roland.illig at gmx dot de]

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

Bug ID: 90012
   Summary: untranslateable placeholder in expressionsem.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From expressionsem.c:

const char *p = v->isParameter() ? "parameter" : "local";
e->error("cannot take address of scope %s %s in @safe function %s",
p, v->toChars(), sc->func->toChars());

As a translator I have no chance of translating the first %s since it is passed
literally.

Please add a check to the diagnostics linter that can detect this case.
Detecting this case is possible since:

* p is only ever assigned a string literal
* that string literal is never passed through _(...)
* that string literal is passed as a replacement for a %s into a message

Translating GCC is a huge amount of work. If only 1% of the messages is broken
like this, this means 130 bug reports. That 1% is a pretty good estimate, based
on my experience. I'd like that rate to be in the order of 0.1%.

[Bug translation/90011] [9 Regression] trailing space in diagnostic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-08
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|trailing space in   |[9 Regression] trailing
   |diagnostic  |space in diagnostic
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r263523, before that it has been followed by inside {} and thus
the space was intentional, but now it is not.  I'll handle this.

[Bug translation/90011] New: trailing space in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 90011
   Summary: trailing space in diagnostic
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Please teach the diagnostics linter to reject the following code from
cp/typeck2.c:

  pedwarn (loc, OPT_Wnarrowing,
   "narrowing conversion of %qE from %qH to %qI ",

There is no hint anywhere near this code that the trailing space might be
intentional. Therefore it should be rejected before the commit.

It should be allowed if there is a comment above the statement explaining why
the trailing space is intentional.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Steve Kargl from comment #11)
> unless [Note: ...] is non-normative text.

That's exactly what it is.

But we can still aim to meet the intended behaviour.

[Bug testsuite/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kelvin at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #15 from kelvin at gcc dot gnu.org ---
Patched and backported.

[Bug c/89888] [7/8/9 Regression] When switch controlling expression is promoted from type narrower than int, GCC does not diagnose identical cases

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug middle-end/89977] missing -Wstringop-overflow with an out-of-bounds int128_t range

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
You're right that the conversion from int128_t to unsigned long can result in
truncation, so the range of the result is that of unsigned long.  Yet I suspect
that relying on it is more likely unintentional and a bug.  The question in my
mind is whether narrowing int128_t conversions should be diagnosed just in
these contexts (i.e., -Wstringop-overflow) or in others as well.

[Bug fortran/51961] [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> What is allocate supposed to do if the array and the mold are not
> conformable?

AFAICS the mold expr is normally only used for the type, provided the shape of
the allocate-object is specified explicitly, as in Tobias' example:

allocate (a(2), mold=b)   ! Valid - but not accepted

I tend to agree that this might be valid. Then 'a' should be allocated with two
elements and using the type from 'b'.


However, if the shape is not specified explicitly, then it can be taken from
the source-expr (therefore the rank needs to agree) as in this example:

allocate (a, mold=b)  ! correctly rejected?

From F08 section 9.7.1.2:

When an ALLOCATE statement is executed for an array with no
allocate-shape-spec-list, the bounds of source-expr determine the bounds of the
array. Subsequent changes to the bounds of source-expr do not affect the array
bounds.

I would conclude that this second case is invalid, however this is not
reflected in C638, which might possibly be an oversight in Fortran 2008. AFAICS
Fortran 2018 changes nothing in this regard.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl  ---
On Mon, Apr 08, 2019 at 02:32:38PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> I don't have a copy of the C++ standard, so take this specualtion.
> pow(z,0.5) is equivalent to sqrt(z).  From the C standard, one has
> 
> conj(csqrt(z)) = csqrt(conj(z)).
> 
> g++ does not enforce this when the imaginary part is -0;
> while gcc does.

(code snipped)

> % gcc8 -o z c.c -lm && ./z
>  z = CMPLX(-1.8425031517782417e-07, -0.e+00)
>   cpow(z, 0.5) = CMPLX( 2.6283607659835831e-20, -4.2924388775825818e-04)
>   csqrt(z) = CMPLX( 0.e+00, -4.2924388775825818e-04)
> csqrt(conj(z)) = CMPLX( 0.e+00,  4.2924388775825818e-04)
> conj(csqrt(z)) = CMPLX( 0.e+00,  4.2924388775825818e-04)

(code snipped)

> %  g++8 -o z  a.cpp -lm && ./z
> z = (-1.84250315177824e-07,-0)
>pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
>   sqrt(z) = (0,0.000429243887758258)
> sqrt(conj(z)) = (0,0.000429243887758258)
> conj(sqrt(z)) = (0,-0.000429243887758258)
> 
> This looks wrong.

It is wrong.  From n4810.pdf, page 1102,

  template complex sqrt(const complex& x);

  Returns: The complex square root of x, in the range of the right
  half-plane. [Note: The semantics of this function are intended to
  be the same in C++ as they are for csqrt in C. -- end note]

unless [Note: ...] is non-normative text.

[Bug middle-end/89998] [7/8/9 regression] ICE: verify_gimple failed in printf-return-value

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||msebor at gcc dot gnu.org
 Blocks||85741

--- Comment #7 from Martin Sebor  ---
This is another instance of the mismatched built-in signature problem.  With
-Wextra GCC 9 prints:

  warning: mismatch in return type of built-in function ‘sprintf’; expected
‘int’ [-Wbuiltin-declaration-mismatch]
1 | unsigned int sprintf (char *str, const char *fmt, ...);

As we discussed, having the warning for the declaration disable treating the
function as a built-in will avoid these bugs.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug libstdc++/90008] [9 Regression] variant attempts to copy rhs in comparison operators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/90010] valgrind error with snprintf and -Wall

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
I forgot to mention that I have also set a valgrind option:

$ set | fgrep VAL
VALGRIND_OPTS=--expensive-definedness-checks=yes
$

Might be significant.

[Bug c++/90010] New: valgrind error with snprintf and -Wall

[dcb314 at hotmail dot com]

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

Bug ID: 90010
   Summary: valgrind error with snprintf and -Wall
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ source code:

extern "C" __inline __attribute__((__gnu_inline__)) int snprintf(...) {}
class a {
  char b[4096];
  void c();
};
void a::c() {
  char d[4096];
  snprintf(d, sizeof(d), "%s/power/runtime_suspended_time", b);
}

on a valgrind version of recent gcc trunk:

$ ~/gcc/results.270150.valgrind/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results.270150.valgrind/bin/g++
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.270150.valgrind/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure
--prefix=/home/dcb/gcc/results.270150.valgrind --disable-bootstrap
--disable-multilib --disable-werror --enable-checking=valgrind
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 9.0.1 20190404 (experimental) (GCC) 
[dcb@localhost dcbTest]$ 

with compile flag -Wall, makes this:

$ ~/gcc/results.270150.valgrind/bin/g++ -c -Wall bug514.cc
bug514.cc:1:57: warning: declaration of ‘int snprintf(...)’ conflicts with
built-in declaration ‘int snprintf(char*, long unsigned int, const char*, ...)’
[-Wbuiltin-declaration-mismatch]
1 | extern "C" __inline __attribute__((__gnu_inline__)) int snprintf(...)
{}
  | ^~~~
bug514.cc: In function ‘int snprintf(...)’:
bug514.cc:1:72: warning: no return statement in function returning non-void
[-Wreturn-type]
1 | extern "C" __inline __attribute__((__gnu_inline__)) int snprintf(...)
{}
  |   
^
==30913== Conditional jump or move depends on uninitialised value(s)
==30913==at 0x483BB9D: strnlen (vg_replace_strmem.c:428)
==30913==by 0x137D3F3: pp_format(pretty_printer*, text_info*)
(pretty-print.c:1374)
==30913==by 0x1373D62: diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) (diagnostic.c:1015)
==30913==by 0xB5F828: format_string_diagnostic_t::emit_warning_n_va(int,
unsigned long, char const*, char const*, __va_list_tag (*) [1]) const
(substring-locations.c:216)

[Bug fortran/90002] ICE: free_expr0(): Bad expr type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
This fixes the ICE, but it may also leak memory for one
of the bounds.

Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c (revision 270181)
+++ gcc/fortran/array.c (working copy)
@@ -324,10 +324,22 @@ gfc_free_array_spec (gfc_array_spec *as)
   if (as == NULL)
 return;

-  for (i = 0; i < as->rank + as->corank; i++)
+  if (as->corank == 0)
 {
-  gfc_free_expr (as->lower[i]);
-  gfc_free_expr (as->upper[i]);
+  for (i = 0; i < as->rank; i++)
+   {
+ gfc_free_expr (as->lower[i]);
+ gfc_free_expr (as->upper[i]);
+   }
+}
+  else
+{
+  int n = as->rank + as->corank - (as->cotype == AS_EXPLICIT ? 1 : 0);
+  for (i = 0; i < n; i++)
+   {
+ gfc_free_expr (as->lower[i]);
+ gfc_free_expr (as->upper[i]);
+   }
 }

   free (as);

[Bug target/89993] Inconsistent incoming stack boundary

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to H.J. Lu from comment #0)
> > It looks like the default incoming stack isn't a constant:
> And where is the bug?

The bug is that -mstackrealign has different behaviors on tail call,
depending on if -mincoming-stack-boundary=4 or

__m128 x;

is used.  I am expecting the same tail call optimization with

-mstackrealign -S -O2

for

int tst2Foo(int*, int*, int);

int tst1Foo(int* pSrc, int* pDst, int len)
{
  return tst2Foo(pSrc, pDst, len);
}

and

#include 

int tst2Foo(int*, int*, int, __m128*);

int tst1Foo(int* pSrc, int* pDst, int len)
{
  __m128 x;
  return tst2Foo(pSrc, pDst, len, );
}

with and without -mincoming-stack-boundary=4.

[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler

[zhroma at ispras dot ru]

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

--- Comment #4 from Roman Zhuykov  ---
Thanks for testcase.
2-3 weeks ago I already caught and fixed this on my local branch, see some info
in the bottom.

Current algorithm which finds recurrence_length for all DDG strongly connected
components works in like O(N^6) time, where N in the number of nodes in DDG.
The time is so bad mostly for graphs with lots of edges, like almost N^2 edges.
Richard's suggestion is right - it will be still something like O(N^5) in worst
case even without bitmap overhead for such graphs. My proposed algorithm works
in O(N^3). Algorithm of finding SCCs itself is also not optimal (maybe up to
O(N^4)), but here it left untouched.

For some situations, when amount of edges is smaller (like equal to N), new
algorithm can be unfortunately slower than old one. But I think it's better
here to add some bail-out when we got more than 1000 nodes for example.

Before creating this patch, I tested special version of it, where both
approaches were in action and asserts were inserted to check that algorithms
results (longest_simple_path values) are absolutely the same. I can publish
this special version if needed.

I wonder how regression test can be created for such a situation?

[Testing]
Proposed patch with a bunch of ~25 other patches was tested a lot:
*(1) Bootstrapped and regtested on x86_64
*(2) Cross-compiler regtest on aarch64, arm, powerpc, powerpc64, ia64 and s390
*(3) Also done (1) and (2) with -fmodulo-sched enabled by default
*(4) Also done (1) and (2) with -fmodulo-sched and
-fmodulo-sched-allow-regmoves enabled by default
*(5) Moreover, all (1-4) was also done with 4.9, 5, 6, 7, and 8 branches, on
active branches an trunk date was 20190327.

More than 250 compiler instances built and tested in total (counting
both "unpatched" vs "patched").
No new failures which can relate to this algorithm were found.
"Special version" was also tested in practically same scenarios (and one more
week before, like 20190320), but not exactly all of them.

But still have to retest it separately without all my stuff :)

[PS] Last month I spent a lot of time updating my patches described here
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01647.html and have locally added
several other patches, including this fix. My updated branches are not
published yet, because there are still some unsolved issues, I can't fix some
bugzilla PRs also. I'll try to add comments in another modulo-sched-related PRs
soon.

[Bug c/89990] request warning: Use of out of scope compound literals

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I agree that this would be a very useful enhancement.

The value of a pointer becomes indeterminate after the lifetime of the object
to which it points has ended.  Even reading such a pointer is undefined, never
mind dereferencing it.  GCC could use that to issue helpful diagnostics even in
absence of any evidence that the pointer is dereferenced, such as in the
modified example below:

   int foo (mytype *ptr)
   {
 if (!ptr) {
   ptr = &(mytype) { };
 }

 bar (ptr);   // undefined
   }

This applies not just to compound literals but to all other objects, including
auto, allocated, and thread local storage.

[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler

[zhroma at ispras dot ru]

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

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at ispras dot ru

--- Comment #3 from Roman Zhuykov  ---
Created attachment 46099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46099=edit
Proposed patch

Untested on trunk yet

[Bug c/89888] [7/8/9 Regression] When switch controlling expression is promoted from type narrower than int, GCC does not diagnose identical cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/89993] Inconsistent incoming stack boundary

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #0)
> It looks like the default incoming stack isn't a constant:
And where is the bug?

[Bug c/89888] [7/8/9 Regression] When switch controlling expression is promoted from type narrower than int, GCC does not diagnose identical cases

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Guess this started with r84947 aka
https://gcc.gnu.org/ml/gcc-patches/2004-07/msg01859.html
So, if we want to error here, we should move what check_case_bounds does
(except for the fold + convert) from c_add_case_labels to start of
c_do_switch_warnings.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Mon, Apr 08, 2019 at 09:59:22AM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
> 
> --- Comment #7 from Jonathan Wakely  ---
> I think it's allowed. The standards have very little to say about accuracy of
> any mathematical functions, and complex(0, 0.0) == complex(0,
> -0.0) is true according to the standard, because +0.0 == -0.0 is true.
> 


I don't have a copy of the C++ standard, so take this specualtion.
pow(z,0.5) is equivalent to sqrt(z).  From the C standard, one has

conj(csqrt(z)) = csqrt(conj(z)).

g++ does not enforce this when the imaginary part is -0;
while gcc does.

% cat c.c
#include 
#include 

int
main(void)
{
   double complex z, t0, t1, t2, t3;

   z = CMPLX(-1.8425031517782417e-07, -0.0);
   t0 = cpow(z, 0.5);
   t1 = csqrt(z);
   t2 = csqrt(conj(z));
   t3 = conj(csqrt(z));
   printf(" z = CMPLX(% .16le, % .16le)\n", creal(z), cimag(z));
   printf("  cpow(z, 0.5) = CMPLX(% .16le, % .16le)\n", creal(t0), cimag(t0));
   printf("  csqrt(z) = CMPLX(% .16le, % .16le)\n", creal(t1), cimag(t1));
   printf("csqrt(conj(z)) = CMPLX(% .16le, % .16le)\n", creal(t2), cimag(t2));
   printf("conj(csqrt(z)) = CMPLX(% .16le, % .16le)\n", creal(t3), cimag(t3));
   return 0;
}
% gcc8 -o z c.c -lm && ./z
 z = CMPLX(-1.8425031517782417e-07, -0.e+00)
  cpow(z, 0.5) = CMPLX( 2.6283607659835831e-20, -4.2924388775825818e-04)
  csqrt(z) = CMPLX( 0.e+00, -4.2924388775825818e-04)
csqrt(conj(z)) = CMPLX( 0.e+00,  4.2924388775825818e-04)
conj(csqrt(z)) = CMPLX( 0.e+00,  4.2924388775825818e-04)


mobile:kargl[210] cat a.cpp
#include 
#include 
#include 

int
main(int argc, char *argv[])
{
   std::complex z, t0, t1, t2, t3;
   z  = std::complex(-1.8425031517782417e-07, -0.0);
   t0 = std::pow(z, 0.5);
   t1 = std::sqrt(z);
   t2 = std::sqrt(std::conj(z));
   t3 = std::conj(std::sqrt(z));
   std::cout << "z = " << std::setprecision(15) << z  << std::endl;
   std::cout << "   pow(z,0.5) = " << std::setprecision(15) << t0 << std::endl;
   std::cout << "  sqrt(z) = " << std::setprecision(15) << t1 << std::endl;
   std::cout << "sqrt(conj(z)) = " << std::setprecision(15) << t2 << std::endl;
   std::cout << "conj(sqrt(z)) = " << std::setprecision(15) << t3 << std::endl;
   return 0;
}

%  g++8 -o z  a.cpp -lm && ./z
z = (-1.84250315177824e-07,-0)
   pow(z,0.5) = (2.62836076598358e-20,-0.000429243887758258)
  sqrt(z) = (0,0.000429243887758258)
sqrt(conj(z)) = (0,0.000429243887758258)
conj(sqrt(z)) = (0,-0.000429243887758258)

This looks wrong.

[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses

[rearnsha at gcc dot gnu.org]

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

Bug 83033 Summary: aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033

   What|Removed |Added

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

[Bug target/83033] aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from Richard Earnshaw  ---
Fixed

[Bug tree-optimization/90006] [7/8/9 Regression] gcc loops indefinitely around vect_get_constant_vectors on -O2 -ftree-slp-vectorize -fno-math-errno

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Apr  8 13:54:02 2019
New Revision: 270210

URL: https://gcc.gnu.org/viewcvs?rev=270210=gcc=rev
Log:
2019-04-08  Richard Biener  

PR tree-optimization/90006
* tree-vect-data-refs.c (vect_get_smallest_scalar_type): Handle
calls like lrint.

* gcc.dg/vect/bb-slp-pr90006.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr90006.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug target/90009] New: [nvptx] ICE when OpenACC region has num_workers>1

[cltang at gcc dot gnu.org]

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

Bug ID: 90009
   Summary: [nvptx] ICE when OpenACC region has num_workers>1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cltang at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

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

./mainline/bin/gcc -w -fopenacc -O2 nvptx-worker2-ice.c
during RTL pass: mach
nvptx-worker2-ice.c: In function ‘foo._omp_fn.0’:
nvptx-worker2-ice.c:6:11: internal compiler error: Segmentation fault
6 |   #pragma acc parallel num_workers(2)
  |   ^
0xe9b265 crash_signal
/scratch/cltang/openacc/trunk/gcc/toplev.c:326
0x132ed7e nvptx_skip_par
/scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:4585
0x132f53a nvptx_neuter_pars
/scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:4791
0x132f325 nvptx_neuter_pars
/scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:4733
0x132fd9a nvptx_reorg
/scratch/cltang/openacc/trunk/gcc/config/nvptx/nvptx.c:5025
0xe38c94 execute
/scratch/cltang/openacc/trunk/gcc/reorg.c:3992
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload: fatal error: ./mainline/bin/x86_64-pc-linux-gnu-accel-nvptx-none-gcc
returned 1 exit status
compilation terminated.

[Bug sanitizer/89941] sanitizer fails to build on mips-unknown-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug libstdc++/90008] New: [9 Regression] variant attempts to copy rhs in comparison operators

[antoshkka at gmail dot com]

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

Bug ID: 90008
   Summary: [9 Regression] variant attempts to copy rhs in
comparison operators
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

_VARIANT_RELATION_FUNCTION_TEMPLATE accidentally accepts the second visitable
by copy in `__do_visit<__detail::__variant::__visit_with_index>`. 

The following test fails right now, but worked in GCC-8:

#include 

struct user_defined {
user_defined();
user_defined(const user_defined&) = delete;
user_defined(user_defined&&) = delete;
};

bool operator==(const user_defined& x, const user_defined& y) { return true; }

using v_t = std::variant;

auto test(const v_t& v, const v_t& v2) {
return v == v2;
}

[Bug sanitizer/89941] sanitizer fails to build on mips-unknown-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Apr  8 13:08:30 2019
New Revision: 270208

URL: https://gcc.gnu.org/viewcvs?rev=270208=gcc=rev
Log:
Add missing libsanitizer extra patch (r259664) (PR sanitizer/89941).

2019-04-08  Martin Liska  

PR sanitizer/89941
* sanitizer_common/sanitizer_platform_limits_linux.cc (defined):
Reapply patch from r259664.
* sanitizer_common/sanitizer_platform_limits_posix.h (defined):
Likewise.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h

[Bug target/83033] aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Author: rearnsha
Date: Mon Apr  8 12:59:24 2019
New Revision: 270207

URL: https://gcc.gnu.org/viewcvs?rev=270207=gcc=rev
Log:
The fma_forest, fma_root_node and func_fma_steering classes lack a
copy constructor.  However, they contain pointers to allocated memory
so this omission can be regarded as poor style.  We don't need to copy
such objects, so declare the copy constructor private to inhibit
accidental copying.

2019-04-08  Andrea Corallo  

PR target/83033
* config/aarch64/cortex-a57-fma-steering.c (fma_forest): Prohibit copy
construction.
(fma_root_node): Likewise.
(func_fma_steering): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/cortex-a57-fma-steering.c

[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #25 from Jakub Jelinek  ---
Fixed.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||srinath.parvathaneni at arm 
dot co
   ||m

--- Comment #23 from Thomas Koenig  ---
*** Bug 89987 has been marked as a duplicate of this bug. ***

[Bug fortran/89987] ICE on GCC trunk and GCC 8 on arm-none-linux-gnueabihf target with “-O1” option

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Thomas Koenig  ---
Resolving as duplicate then.

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

[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr  8 12:36:58 2019
New Revision: 270206

URL: https://gcc.gnu.org/viewcvs?rev=270206=gcc=rev
Log:
PR rtl-optimization/89865
* config/i386/i386.md: Add peepholes for z = x; x ^= y; x != z.

* gcc.target/i386/pr49095.c: Don't expect any RMW sequences.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr49095.c

[Bug rtl-optimization/89865] [9 Regression] FAIL: gcc.target/i386/pr49095.c scan-assembler-times \\\\), % 45

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr  8 12:35:22 2019
New Revision: 270205

URL: https://gcc.gnu.org/viewcvs?rev=270205=gcc=rev
Log:
PR rtl-optimization/89865
* config/i386/i386.md
(SWI12 peephole for mem {+,-,&,|,^}= x; mem != 0): Fix up operand
numbers not to clash with the additional operands[4].
(peepholes for mem {+,-,&,|,^}= x; mem != 0): New peephole2s
with extra register copy in the middle.

* gcc.target/i386/pr49095.c: Adjust number of expected RMW spots
on ia32.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr49095.c

[Bug fortran/89987] ICE on GCC trunk and GCC 8 on arm-none-linux-gnueabihf target with “-O1” option

[srinath.parvathaneni at arm dot com]

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

--- Comment #4 from Srinath Parvathaneni  
---
(In reply to Thomas Koenig from comment #3)
> Can you update to a revision after r270150 and try again?

On gcc trunk this got fixed as follows.
$ ./arm-none-linux-gnueabihf-gfortran test.f90 -O1
test.f90:2:26:

2 |   k = transfer (transfer (e, e), 1)
  |  1
Error: 'SOURCE' argument of 'TRANSFER' intrinsic at (1) must not be a PROCEDURE

[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Closing this as fixed.

[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Mon Apr  8 12:16:15 2019
New Revision: 270204

URL: https://gcc.gnu.org/viewcvs?rev=270204=gcc=rev
Log:
Add data_file to GCOV interm. format (PR gcov-profile/89961).

2019-04-08  Martin Liska  

PR gcov-profile/89961
* doc/gcov.texi: Document data_file.
* gcov.c (generate_results): Add data_info into JSON output.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi
trunk/gcc/gcov.c

[Bug tree-optimization/90004] [graphite] ICE: Segmentation fault (in scop_get_dependences(scop*))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
 CC||rguenth at gcc dot gnu.org,
   ||spop at gcc dot gnu.org,
   ||tobi-grosser at web dot de
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can reproduce on x86_64-linux with -m32 with ISL 0.21 but not ISL 0.20.  The
crash happens inside ISL though:

internal compiler error: Segmentation fault
0x1239033 crash_signal
/tmp/trunk/gcc/toplev.c:326
0x7effbfe50fdf ???
   
/usr/src/debug/glibc-2.22/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x22b65b0 normalize_divs
/tmp/trunk/isl/isl_map_simplify.c:1044
0x22b7b59 isl_basic_map_simplify
/tmp/trunk/isl/isl_map_simplify.c:1435
0x22986e8 isl_basic_map_intersect
/tmp/trunk/isl/isl_map.c:3569
0x2298d35 map_intersect_internal
/tmp/trunk/isl/isl_map.c:3703
0x2298e5e map_intersect
/tmp/trunk/isl/isl_map.c:3729
0x22932d8 isl_map_align_params_map_map_and
/tmp/trunk/isl/isl_map.c:1442
0x2298ea7 isl_map_intersect
/tmp/trunk/isl/isl_map.c:3739
0x2298ee0 isl_set_intersect
/tmp/trunk/isl/isl_map.c:3744
0x22a0be2 isl_map_partial_lexopt_aligned_pw_multi_aff
/tmp/trunk/isl/isl_map.c:6799
0x22a1252 isl_map_partial_lexopt_aligned
/tmp/trunk/isl/isl_map.c:6877
0x22a0ff5 isl_map_partial_lexopt
/tmp/trunk/isl/isl_map_lexopt_templ.c:182
0x22a12c2 isl_map_partial_lexmax
/tmp/trunk/isl/isl_map.c:6892
0x227ad0f restricted_partial_lexmax
/tmp/trunk/isl/isl_flow.c:590
0x227b005 last_source
/tmp/trunk/isl/isl_flow.c:651
0x227c62f compute_val_based_dependences
/tmp/trunk/isl/isl_flow.c:1204
0x227cda2 access_info_compute_flow_core
/tmp/trunk/isl/isl_flow.c:1338
0x227fbfc compute_single_flow
/tmp/trunk/isl/isl_flow.c:3094
0x227fef2 compute_flow_schedule
/tmp/trunk/isl/isl_flow.c:3178
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Program received signal SIGSEGV, Segmentation fault.
0x022b65b0 in normalize_divs (bmap=0x0, progress=0x7fffd078)
at /tmp/trunk/isl/isl_map_simplify.c:1044
1044for (i = 0; i < bmap->n_eq; ++i)
...
#19 0x01fa482d in scop_get_dependences (scop=0x34ea320)
at /tmp/trunk/gcc/graphite-dependences.c:316
316   flow = isl_union_access_info_compute_flow (ai);

not sure if it is still GCCs fault in the end or not.  At least there's

(gdb) l
1430bmap = eliminate_unit_divs(bmap, );
1431bmap = eliminate_divs_eq(bmap, );
1432bmap = eliminate_divs_ineq(bmap, );
1433bmap = isl_basic_map_gauss(bmap, );
1434/* requires equalities in normal form */
1435bmap = normalize_divs(bmap, );

and isl_basic_map_gauss has paths where it can return NULL.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
The pattern of the offending instruction is defined as

(define_insn "*float2"
  [(set (match_operand:MODEF 0 "register_operand" "=f,v,v")
(float:MODEF
  (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]

since RA is nowadays able to reload input operand of alternative 0:

(insn 17 35 15 2 (set (reg:DF 95)
(float:DF (reg:SI 98))) "pr90007.c":8:21 172 {*floatsidf2}
 (expr_list:REG_DEAD (reg:SI 98)
(nil)))

via memory:

(insn 17 35 37 2 (set (reg:DF 8 st [95])
(float:DF (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int -4 [0xfffc])) [1 %sfp+-4 S4 A32])))
"pr90007.c":8:21 172 {*floatsidf2}
 (nil))

sel-sched is not prepared for this, uses:

--cut here--
/* Estimate the cost of issuing INSN on DFA state STATE.  */
static int
estimate_insn_cost (rtx_insn *insn, state_t state)
{
  static state_t temp = NULL;
  int cost;

  if (!temp)
temp = xmalloc (dfa_state_size);

  memcpy (temp, state, dfa_state_size);
  cost = state_transition (temp, insn);

  if (cost < 0)
return 0;
  else if (cost == 0)
return 1;
  return cost;
}
--cut here--

that calls state_transition, which tries to calculate and verify constraints
via the following call sequence:

#4  0x0064ea7f in extract_constrain_insn_cached
(insn=insn@entry=0x7fffea669940) at ../../git/gcc/gcc/recog.c:2223
#5  0x01217c4f in get_attr_type (insn=insn@entry=0x7fffea669940) at
../../git/gcc/gcc/config/i386/i386.md:2288
#6  0x0124994c in internal_dfa_insn_code_bdver1 (insn=0x7fffea669940)
at ../../git/gcc/gcc/config/i386/i386.md:15343
#7  0x01233169 in dfa_insn_code (insn=0x27) at insn-automata.c:158875
#8  state_transition (state=0x21a7af0, insn=insn@entry=0x7fffea669940) at
insn-automata.c:27818

and crashes due to unmet constraints.

[Bug middle-end/89725] [8 Regression] ICE in get_fnname_from_decl, at varasm.c:1723

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
   |get_fnname_from_decl, at|get_fnname_from_decl, at
   |varasm.c:1723   |varasm.c:1723

--- Comment #12 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/89725] [8 Regression] ICE in get_fnname_from_decl, at varasm.c:1723

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Mon Apr  8 11:52:18 2019
New Revision: 270203

URL: https://gcc.gnu.org/viewcvs?rev=270203=gcc=rev
Log:
2019-04-01  Bin Cheng  

PR tree-optimization/89725
* tree-chrec.c (chrec_contains_symbols): New parameter.  Handle outer
loop's chrec as invariant symbol.
* tree-chrec.h (chrec_contains_symbols): New parameter.
* tree-data-ref.c (analyze_miv_subscript): Pass new argument.
(build_classic_dist_vector_1, add_other_self_distances): Bypass access
function of loops not in DDR's loop_nest.
* tree-data-ref.h (index_in_loop_nest): Add unreachable check.

* gcc.dg/tree-ssa/pr89725.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89725.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.c
trunk/gcc/tree-chrec.h
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-data-ref.h

[Bug tree-optimization/90006] [7/8/9 Regression] gcc loops indefinitely around vect_get_constant_vectors on -O2 -ftree-slp-vectorize -fno-math-errno

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
OK, so the issue is we rely on vect_get_smallest_scalar_type to get us the
expected vectors for the call input but that doesn't work here.

[Bug ipa/89989] missed devirtualization opportunity on final function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67184

--- Comment #2 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> Related to PR 65143.

I don't hink so, that's about virtual bases. It is related to PR 67184 though.

[Bug c++/67184] Missed optimization with C++11 final specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2016-01-29 00:00:00 |2019-4-8

--- Comment #6 from Jonathan Wakely  ---
(In reply to Giovanni Deretta from comment #0)
> I would expect call(wV&) to generate the same code as call(oV&).

Except of course it should be a direct call to V::foo(), not oV::foo().

As I showed in Bug 69445 the devirtualization does happen when the final
overrider is in the derived class:

struct Base {
  virtual void foo() const {};
  virtual void bar() const {}
};

struct C final : Base {
  void foo() const { }
};

void func(const C & c) {
  c.foo();  // optimized away
  c.bar();
}

It doesn't happen when the final overrider comes from the base.

[Bug tree-optimization/90006] [7/8/9 Regression] gcc loops indefinitely around vect_get_constant_vectors on -O2 -ftree-slp-vectorize -fno-math-errno

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
   Priority|P3  |P2
  Known to work||5.5.0
   Target Milestone|--- |7.5
Summary|gcc loops indefinitely  |[7/8/9 Regression] gcc
   |around  |loops indefinitely around
   |vect_get_constant_vectors   |vect_get_constant_vectors
   |on -O2 -ftree-slp-vectorize |on -O2 -ftree-slp-vectorize
   |-fno-math-errno |-fno-math-errno
  Known to fail||6.5.0

[Bug middle-end/89998] [7/8/9 regression] ICE: verify_gimple failed in printf-return-value

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug tree-optimization/90006] gcc loops indefinitely around vect_get_constant_vectors on -O2 -ftree-slp-vectorize -fno-math-errno

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-08
  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||7.4.0, 8.3.0, 9.0

--- Comment #2 from Richard Biener  ---
Confirmed.  It needs -march=x86-64 passed to cc1 to enable SSE2 or
alternatively -msse2.

[Bug ipa/89989] missed devirtualization opportunity on final function

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Related to PR 65143.

[Bug c++/78873] Virtual call after conversion to base class pointer is not devirtualized

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Ambroz Bizjak from comment #0)
> But I think it is not valid; the result of the reinterpret_cast does not
> point to a Liar object, so the static_cast done in TestDevirtualuzation
> *should* be invalid. I couldn't find a clear statement in the standard about
> this though.

I don't think the implicit derived-to-base conversion sequence (which the
static_cast performs explicitly) does require the object to really point to a
Liar. The inverse static_cast, casting Iface* to Liar*, would be invalid if it
doesn't point to a Liar.

So on that basis, GCC is correct not to devirtualize in TestDevirtualuzation.
The Intel compiler also does an indirect call there. Clang calls Impl::foo()
directly though.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug ipa/89989] missed devirtualization opportunity on final function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
 Ever confirmed|0   |1

[Bug fortran/89987] ICE on GCC trunk and GCC 8 on arm-none-linux-gnueabihf target with “-O1” option

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
Can you update to a revision after r270150 and try again?

This looks like an exact dup of PR 89904.

[Bug c++/90005] No error produced for the wrong type of string used in gcc >= 5.0

[pawel.wrobel at nielsen dot com]

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

--- Comment #7 from Pawel  ---
The "-Werror=format" solution seems to work for me - it triggers the error here
(missing .c_str()) even for the gcc >= 5.0 - leaving all the other, non-related
warnings untouched.

Thanks

[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Slightly reduced -std=c++2a -fconcepts:
namespace a {
  template  struct b;
  template  using aa = c;
  template  bool ab;
  struct ac;
  template  using ad = ac;
  template  class ae { ae(c); };
}
namespace af {
  namespace ag { struct ah { typedef int ai; }; }
  template 
  struct d { typedef ag::ah e; };
  namespace ag {
template  class aj>
struct al { template  struct am { typedef aj e; }; };
template  class ak> struct an { typedef al ai; };
template  class ak> struct ao { typedef an e; };
template  struct aq;
template 
struct aq> { typedef d::e
e; };
template  class F { static bool cb() { typedef
typename bz::template am::e cc; new cc; } };
template  class, typename cd, typename d> class ce {
static bool cb() { F::cb; } };
  }
}
template  concept cf = a::b::g;

struct {
  template  struct ch;
  template  using cj = ch>;
  template  auto operator()(ci &&) noexcept(cj()) {}
} begin;
template  bool ck = requires(ap t) { begin(t); };
template  bool cl = ck;
namespace a::cg {
  template  bool cn = cl;
  template  bool cm = cn;
}
template  concept dc = requires(t co) { co; };
template  concept cr = a::ab<>;
template  class K { template > cq c(); };
namespace cs {
  template  bool u = a::cg::cm>;
  template  bool cu = u;
}
template  requires cs::cu> void y(w, x);
namespace cv::alignment::cw::cx::affine::cy { auto z = [] {}; auto cz = [] {};
auto da = [] {}; auto db = [] {}; }
using namespace cv::alignment::cw;
template  struct dg;
template  class dd;
using de = af::d, dg,
dg, dg>;
namespace df { template  class H { virtual void dh(); }; }
template  void df::H::dh() { auto cw = this; auto dj = int{},
dk = cw; y(dk, dj); }
namespace df { typedef af::ag::ao::e dl; }
bool dm = af::ag::ce::e>::cb;

[Bug c++/90005] No error produced for the wrong type of string used in gcc >= 5.0

[pawel.wrobel at nielsen dot com]

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

--- Comment #6 from Pawel  ---
Hi,

Thanks for the explanation. Indeed, for example, the clang does not support the
non-POD(ex. std::string) to variadic function - as : 
error: cannot pass non-trivial object of type 'std::__cxx11::string' (aka
'basic_string') to variadic function;

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #5)
> The issue is
> 
> std::pow (__x=..., __y=@0x7fffdcb8: 0.5)
> at /home/space/rguenther/install/gcc-9.0/include/c++/9.0.1/complex:1027
> (gdb) l
> 1022{
> 1023#if ! _GLIBCXX_USE_C99_COMPLEX
> 1024  if (__x == _Tp())
> 1025return _Tp();
> 1026#endif
> 1027  if (__x.imag() == _Tp() && __x.real() > _Tp())
> 1028return pow(__x.real(), __y);
> 
> where __x.imag () == _Tp() says true for -0.0 == 0.0.  This means
> std::pow will return the same values for r + -0.0i and r + 0.0i,
> not sure if that is allowed by the C++ standard.

But __x.real() > _Tp() is false here, so that branch isn't taken anyway.

Instead the pow(val, 0.5) result comes from:

  _Complex double val = -1.8425031517782417e-07 + -0.0 * I;
  _Complex double t = __builtin_clog(val);
  double rho = exp(0.5 * __real__ t);
  double theta = 0.5 * __imag__ t;
  _Complex result = rho * cos(theta) + rho * sin(theta) * I;
  __builtin_printf("%f\n", __imag__ result);

[Bug rtl-optimization/90007] New: [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[asolokha at gmx dot com]

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

Bug ID: 90007
   Summary: [9 Regression] ICE in extract_constrain_insn_cached,
at recog.c:2223
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-9.0.0-alpha20190407 snapshot (r270192) ICEs when compiling the following
testcase w/ -march=bdver1 (=bdver2) -mfpmath=387 -O1 (-O2, -O3, -Ofast)
-fschedule-insns -fselective-scheduling:

void
qj (int b9, int r9, int k4, int k0, int e7)
{
  (void) b9;
  (void) r9;
  (void) k4;

  while (!!k0 == e7 * 1.1)
{
}
}

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20190407 -march=bdver1 -mfpmath=387 -O1
-fschedule-insns -fselective-scheduling -c nhzbpwxv.c
nhzbpwxv.c: In function 'qj':
nhzbpwxv.c:11:1: error: insn does not satisfy its constraints:
   11 | }
  | ^
(insn 39 0 0 (set (reg:DF 95)
(float:DF (reg:SI 36 r8 [ e7 ]))) 172 {*floatsidf2}
 (expr_list:REG_DEAD (reg:SI 98)
(nil)))
during RTL pass: sched1
nhzbpwxv.c:11:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2223
0x66a363 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/rtl-error.c:108
0x66a389 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/rtl-error.c:118
0x6685a6 extract_constrain_insn_cached(rtx_insn*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/recog.c:2223
0x12b020f get_attr_type(rtx_insn*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/config/i386/i386.md:2288
0x12d6805 internal_dfa_insn_code_bdver1(rtx_insn*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/config/i386/i386.md:15343
0x12c4100 dfa_insn_code
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/build/gcc/insn-automata.c:158875
0x12c4100 state_transition(void*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/build/gcc/insn-automata.c:158890
0xd0b74a estimate_insn_cost
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:4293
0xd17aab get_expr_cost
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:4324
0xd17aab choose_best_insn
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:4353
0xd17aab find_best_expr
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:4403
0xd17aab fill_insns
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:5550
0xd17aab schedule_on_fences
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:7368
0xd17aab sel_sched_region_2
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:7506
0xd185e8 sel_sched_region_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:7548
0xd1a111 sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:7649
0xd1a111 sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:7634
0xd1acc8 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sel-sched.c:7735
0xcf915d rest_of_handle_sched
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sched-rgn.c:3717
0xcf915d execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/sched-rgn.c:3827

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
Also isn't it true that this is just a different quadrant of the solution? 
That is the answer is correct but which quadrant being selected is different?

That is (a^0.5) actually has two answers where the imaginary part can be
positive or negative?  That is they are conjugate of each other.

[Bug fortran/89987] ICE on GCC trunk and GCC 8 on arm-none-linux-gnueabihf target with “-O1” option

[srinath.parvathaneni at arm dot com]

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

--- Comment #2 from Srinath Parvathaneni  
---
$ ./arm-none-linux-gnueabihf-gfortran test.f90 -S -O1 -v
Using built-in specs.
COLLECT_GCC=./arm-none-linux-gnueabihf-gfortran
Target: arm-none-linux-gnueabihf
Configured with:
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/configure
--with-arch=armv7-a --with-fpu=neon --with-float=hard --with-mode=thumb
--with-isl=/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/build-native-arm-none-linux-gnueabihf/host-tools
--without-cloog --build=arm-none-linux-gnueabihf
--host=arm-none-linux-gnueabihf --target=arm-none-linux-gnueabihf --prefix=/usr
--enable-languages=c,c++,fortran --enable-plugin --enable-gnu-indirect-function
--with-gmp=/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/build-native-arm-none-linux-gnueabihf/host-tools
--with-mpfr=/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/build-native-arm-none-linux-gnueabihf/host-tools
--with-mpc=/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/build-native-arm-none-linux-gnueabihf/host-tools
--with-gnu-ld --with-plugin-ld=ld --with-pkgversion=fsf-trunk.1858
--disable-libsanitizer
Thread model: posix
gcc version 9.0.1 20190404 (experimental) (fsf-trunk.1858) 
COLLECT_GCC_OPTIONS='-S' '-O1' '-v'  '-mfloat-abi=hard' '-mfpu=neon' '-mthumb'
'-mtls-dialect=gnu' '-march=armv7-a+simd'

/home/sripar01/STP/fsf-8/usr/bin/../libexec/gcc/arm-none-linux-gnueabihf/9.0.1/f951
test.f90 -quiet -dumpbase test.f90 -mfloat-abi=hard -mfpu=neon -mthumb
-mtls-dialect=gnu -march=armv7-a+simd -auxbase test -O1 -version -o test.s
-fintrinsic-modules-path
/home/sripar01/STP/fsf-8/usr/bin/../lib/gcc/arm-none-linux-gnueabihf/9.0.1/finclude
GNU Fortran (fsf-trunk.1858) version 9.0.1 20190404 (experimental)
(arm-none-linux-gnueabihf)
compiled by GNU C version 9.0.1 20190404 (experimental), GMP version
4.3.2, MPFR version 3.1.6, MPC version 1.0.3, isl version
isl-0.18-e8d574175192-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (fsf-trunk.1858) version 9.0.1 20190404 (experimental)
(arm-none-linux-gnueabihf)
compiled by GNU C version 9.0.1 20190404 (experimental), GMP version
4.3.2, MPFR version 3.1.6, MPC version 1.0.3, isl version
isl-0.18-e8d574175192-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
during GIMPLE pass: ccp
test.f90:3:0:

3 | end
  | 
internal compiler error: in fold_convert_loc, at fold-const.c:2552
0x438231 fold_convert_loc(unsigned int, tree_node*, tree_node*)
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/fold-const.c:2552
0x78dfb5 evaluate_stmt
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:1997
0x78eea1 visit_assignment
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:2352
0x7f905b ssa_propagation_engine::simulate_stmt(gimple*)
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-propagate.c:230
0x7f927d ssa_propagation_engine::simulate_block(basic_block_def*)
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-propagate.c:337
0x7fa33b ssa_propagation_engine::ssa_propagate()
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-propagate.c:802
0x787197 do_ssa_ccp
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:2471
0x787197 execute
   
/tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:2515

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
I think it's allowed. The standards have very little to say about accuracy of
any mathematical functions, and complex(0, 0.0) == complex(0,
-0.0) is true according to the standard, because +0.0 == -0.0 is true.

[Bug c++/90003] internal compiler error: in tsubst_decl, at cp/pt.c:13783

[rene.r...@fu-berlin.de]

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

--- Comment #2 from rene.r...@fu-berlin.de ---
Yes, sorry. this works fine with gcc-7 and gcc-8.
I also used multidelta to reduce the preprocessed file.