[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #31 from Martin Liška  ---
> But if using "--enable-lto" and "-fno-strict-aliasing", the issue cannot be
> solved. In order to solve the issue, besides those options,
> “__attribute__((noipa))” has to be added to the uv_unref(uv_handle_t*)
> function. So you recommend this solution, right?

No, with -fno-strict-aliasing one should not need the noipa attribute. I can
take a look why it's not helping.

[Bug tree-optimization/49379] warning from linker: alignment lost for -ftree-vectorize optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
We are no longer increasing alignment of commons (and generally recommend
-fno-common because of that).

[Bug c++/89994] [8 Regression] ICE (segfault) in compare_ics

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
It's rejected on trunk since r268606.

[Bug c++/89994] [8 Regression] ICE (segfault) in compare_ics

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
The ICE is much older that GCC-8:

  acafca510c97652f(09 Oct 2014 07:40): [took: 2.880s] result: OK
pr89994.cc:18:21: error: parameter ‘’ includes reference to array of
unknown bound ‘const long int []’
   b(const long (&)[]);
 ^
pr89994.cc:23:16: internal compiler error: Segmentation fault
 blaspp<1> k({4})
^

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I see the expected result when replacing '-0.0' with '0.0'.
Well, negative zero should be equal to the positive one according to standard.

[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

JunMa  changed:

   What|Removed |Added

 CC||JunMa at linux dot alibaba.com

--- Comment #1 from JunMa  ---
in function f, the conversion of stmt  _1 = (long unsigned int) n_3 is
extending, while in function g,  the conversion of stmt  _1 = (long unsigned
int) n_3 is truncating. 
For integer type truncation, gcc compute the range of target only if the range
size of source is less than what the precision of the target type can
represent.

I think this can be relaxed when the target type of truncation is unsigned.

[Bug debug/89892] gcc generates wrong debug information at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
  Known to fail||8.3.0

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug debug/88882] gcc generates wrong debug information at -O1

[rguenth at gcc dot gnu.org]

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

Bug 89892 Summary: gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89892

   What|Removed |Added

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

[Bug debug/89905] gcc generates wrong debug information at -Og

[rguenth at gcc dot gnu.org]

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

Bug 89892 Summary: gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89892

   What|Removed |Added

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

[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
The original makefile set the variable with:

  ifeq ($(OS),linux)
old_kernel:=$(shell [ "$$(uname -r | cut -d'-' -f1)" \< "2.6.39" ] && echo
1)
ifeq ($(old_kernel),1)
  UDFLAGS+=-version=Linux_Pre_2639
endif
  endif

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Target||arm-none-linux-gnueabihf
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-04-08
  Component|middle-end  |fortran
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can't reproduce.  Can you please add -v to the compiler commandline and paste
the output again?

Btw, I get

> ./f951 -quiet t.f90 -O
t.f90:2:32:

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

so for me it is rejected (r270165).

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |c++
   Severity|normal  |enhancement

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (9.0).

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #5 from Richard Biener  ---
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.

[Bug target/89877] [ARC] miscompilation due to missing cc clobber in longlong.h: add_ssaaaa()/sub_ddmmss()

[claziss at gmail dot com]

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

--- Comment #4 from Claudiu Zissulescu  ---
Backported to gcc 8 branch revision 270200.

[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 #6 from Andrew Pinski  ---
(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.

If it does not allow it, then adding copysign is needed.

[Bug middle-end/89992] Vectorizer is sensitive to guessed profile

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|Vectorizer is very  |Vectorizer is sensitive to
   |sensitive to function calls |guessed profile
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It's simply that inlining makes the guessed profile not consider the loop worth
optimizing for speed.  Part of that is because the loop ends up in main()
which we know is executed exactly once and bb->count is less than the entry
block count so we hit

maybe_hot_count_p (struct function *fun, profile_count count)
{
...
  if (node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
  && count < (ENTRY_BLOCK_PTR_FOR_FN (fun)->count.apply_scale (2, 3)))
return false;

this is probably due to predictors saying that

  if (__eax <= 6)
return 0; // return from main

is likely (it gets 66% hit predicted).  The foo() != 0 gets even probability
and the following == 230 test gets only 11% probability to hit.

The "fun" of static profile... (and doing benchmarking in main()).

But it doesn't have anything to do with the vectorizer or calls.

[Bug c++/89994] [8 Regression] ICE (segfault) in compare_ics

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

[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 #2 from JunMa  ---
After a bit more thinking, the behavior of gcc trunk is right. the range of n_3
in truncation from int128 to long unsigned int equal to the range of long
unsigned int. for example: if n_3 = 0x1, then _1 is 0 which is less
than 7.

so this is not a bug.

[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 #3 from JunMa  ---
(In reply to JunMa from comment #2)
> After a bit more thinking, the behavior of gcc trunk is right. the range of
> n_3 in truncation from int128 to long unsigned int equal to the range of
> long unsigned int. for example: if n_3 = 0x1, then _1 is 0 which is
> less than 7.
> 
> so this is not a bug.

sorry, when n_3 = 0x1000  , _1 is 0.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-04-08
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
There's another dup for this.  But I wonder why it works in GCC 8 (maybe it
only works with -fno-checking after all).

So, can you try if GCC 8 fails the same way with -fchecking?

[Bug c++/89914] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Apr  8 08:13:50 2019
New Revision: 270201

URL: https://gcc.gnu.org/viewcvs?rev=270201&root=gcc&view=rev
Log:
/cp
2019-04-08  Paolo Carlini  

PR c++/89914
* semantics.c (trait_expr_value): Don't use TYPE_NOTHROW_P
when maybe_instantiate_noexcept fails.
(classtype_has_nothrow_assign_or_copy_p): Likewise.
* method.c (implicitly_declare_fn): Avoid passing error_mark_node
to build_exception_variant.

/testsuite
2019-04-08  Paolo Carlini  

PR c++/89914
* g++.dg/ext/has_nothrow_constructor-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/has_nothrow_constructor-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/89914] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  ---
Fixed.

[Bug middle-end/89992] Vectorizer is sensitive to guessed profile

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> It's simply that inlining makes the guessed profile not consider the loop
> worth
> optimizing for speed.  Part of that is because the loop ends up in main()
> which we know is executed exactly once and bb->count is less than the entry
> block count so we hit
> 
> maybe_hot_count_p (struct function *fun, profile_count count)
> {
> ...
>   if (node->frequency == NODE_FREQUENCY_EXECUTED_ONCE
>   && count < (ENTRY_BLOCK_PTR_FOR_FN (fun)->count.apply_scale (2,
> 3)))
> return false;
> 
> this is probably due to predictors saying that
> 
>   if (__eax <= 6)
> return 0; // return from main
> 
> is likely (it gets 66% hit predicted).  The foo() != 0 gets even probability
> and the following == 230 test gets only 11% probability to hit.
> 
> The "fun" of static profile... (and doing benchmarking in main()).
> 
> But it doesn't have anything to do with the vectorizer or calls.

As Richi says, static probability of calling 'do_test' in main is 3.8%. You can
use __builtin_expect{,_with_probability} if you want to make the path more
probable.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Is the code valid? Is there a compiler that accepts that?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc-*-linux-gnu |powerpc-*-linux-gnu
   ||powerpc64le-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed also on ppc64le (thus likely on any doloop capable target which SMS
needs).  Note that SMS is unmaintained.

The issue is that set_recurrence_length is called with a graph with
18662 back-arcs and the longest_simple_path does work on the order
of the graph size because it uses sbitmaps.  Using bitmaps doesn't
help here though.  I guess the underlying algorithm for
set_recurrence_length simply isn't scalable and needs to be replaced.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
This has nothing to do with PR89996 and is not AVR specific either.
Following can reproduce it on x86_64-linux:

unsigned int sprintf (char *str, const char *fmt, ...);

int
foo (char *s)
{
  return sprintf (s, "foo");
}

and s/unsigned int/unsigned short/ on AVR.
I'll handle it.

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

[asolokha at gmx dot com]

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

Bug ID: 90004
   Summary: [graphite] ICE: Segmentation fault (in
scop_get_dependences(scop*))
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gfortran-9.0.0-alpha20190407 snapshot (r270192) ICEs when compiling the
following testcase w/ -O1 -floop-nest-optimize -fwrapv:

subroutine rp (n2, qv)
  integer :: qv
  integer :: n2(5,5,3,0:qv)
  integer :: fi, pj

  do fi = 1, 4
 do pj = 1, 2
n2(fi,pj,1,0) = 0
n2(fi,pj,2,0) = 0
n2(fi,pj,3,0) = 0
n2(fi,pj,1,qv) = 0
n2(fi,pj,2,qv) = 0
n2(fi,pj,3,qv) = 0
 enddo
  enddo

  do fi = 1, 3
 n2(fi,fi,2,0) = 0
 n2(fi,fi,2,qv) = 0
  enddo
end subroutine rp

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190407 -O1
-floop-nest-optimize -fwrapv -c mlsputpr.f90
during GIMPLE pass: graphite
mlsputpr.f90:1:0:

1 | subroutine rp (n2, qv)
  | 
internal compiler error: Segmentation fault
0xd83f96 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/toplev.c:326
0x14ba478 scop_get_dependences(scop*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/graphite-dependences.c:316
0x14ba9f6 optimize_isl
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/graphite-optimize-isl.c:126
0x14ba9f6 apply_poly_transforms(scop*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/graphite-optimize-isl.c:212
0x14b4be0 graphite_transform_loops()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/graphite.c:468
0x14b5190 graphite_transforms
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/graphite.c:538
0x14b5190 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190407/work/gcc-9-20190407/gcc/graphite.c:615

I have isl 0.21 installed on this machine.

[Bug c++/90005] New: 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

Bug ID: 90005
   Summary: No error produced for the wrong type of string used in
gcc >= 5.0
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pawel.wrobel at nielsen dot com
  Target Milestone: ---

Hello,

I have the question regarding the following behaviour of gcc 8.3 (it behaves
the same way from version 5.0 up to 8.3 - when I tested with the
https://gcc.godbolt.org/).

When I compile following program (it has an obvious omission - missing .c_str()
conversion of std::string to char*) 

#include 
#include 
int main()
{ 
  std::string txt("there");
  printf("Hello %s ! \n", txt);
}

On the gcc 4.9 and before - it correctly notifies me with an error like : 

: In function 'int main()':

:6:30: error: cannot pass objects of non-trivially-copyable type
'std::string {aka class std::basic_string}' through '...'
   printf("Hello %s ! \n", txt);
Compiler returned: 1



However, starting from the gcc 5.0 and above (gcc 8.3 included) - no error is
generated - and the binary is being produced. It obviously prints the garbage
when run ("Hello (`e !"). So lack of the error should be considered as an bug ?
Or maybe do I need to provide some special flag for this error message to
appear and stop the compilation in gcc 5.0 and above ? 
Both the gcc <= 4.9 works correctly here (and the newer clang compilers also
point out this error correctly). Can I make the gcc >= 5.0 to generate an error
here with some flag ?

[Bug c/90006] New: gcc loops indefinitely around vect_get_constant_vectors on -O2 -ftree-slp-vectorize -fno-math-errno

[slyfox at inbox dot ru]

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

Bug ID: 90006
   Summary: gcc loops indefinitely around
vect_get_constant_vectors on -O2 -ftree-slp-vectorize
-fno-math-errno
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Compiler looping on libavcodec/pngenc.c (ffmpeg-4.1) is originally reported atn
https://bugs.gentoo.org/682694.

Here is a minimal reproducer against gcc-8.3.0:

// $ cat bug.c
// Now to reproduce:
// $ /usr/bin/x86_64-pc-linux-gnu-gcc -m32 -O2 -ftree-slp-vectorize
-fno-math-errno -c bug.c -o bug.o -Wall

long int lrint(double x);

int a, b;
union c {
  int d;
};

int e() {
  int f, g, h;
  long i, j, k;
  double l, m = b = lrint(0.3127);
  a = b >> 16 >> 8 & 255;
  ((union c *)e)->d = a;
  k = m;
  h = k >> 16 >> 8 & 255;
  ((union c *)(e + 4))->d = h;
  j = lrint(l);
  g = j >> 16 >> 8 & 255;
  ((union c *)(e + 8))->d = g;
  i = lrint(0.292);
  f = i >> 16 >> 8 & 255;
  ((union c *)(e + 12))->d = f;
  return 0;
}

$ LANG=C /usr/bin/x86_64-pc-linux-gnu-gcc -m32 -O2 -ftree-slp-vectorize
-fno-math-errno -c bug.c -o bug.o -Wall
bug.c: In function 'e':
bug.c:20:7: warning: 'l' is used uninitialized in this function
[-Wuninitialized]
   j = lrint(l);
   ^~~~


'perf' says looping happens in 'vect_get_constant_vectors':

vec::length (this=0x7fff0b1593b0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/vec.h:1303
1303  unsigned length (void) const
(gdb) bt
#0  vec::length (this=0x7fff0b1593b0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/vec.h:1303
#1  vect_get_constant_vectors (op=, slp_node=0x1eaade0,
vec_oprnds=0x7fff0b1593b0, op_num=0, number_of_vectors=1)
at /usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:3741
#2  0x00c74ef8 in vect_get_slp_defs (ops=ops@entry=...,
slp_node=slp_node@entry=0x1eaade0, vec_oprnds=vec_oprnds@entry=0x7fff0b1594b8)
at /usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:3877
#3  0x00c3cfb6 in vectorizable_call (gs=0x7f2fdde4e3f0,
gsi=0x7fff0b159670, vec_stmt=0x7fff0b159590, slp_node=0x1eaade0)
at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-stmts.c:3387
#4  0x00c4dfaf in vect_transform_stmt (stmt=stmt@entry=0x7f2fdde4e3f0,
gsi=gsi@entry=0x7fff0b159670, grouped_store=grouped_store@entry=0x7fff0b15966f, 
slp_node=slp_node@entry=0x1eaade0, slp_node_instance=) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-stmts.c:9557
#5  0x00c78a05 in vect_schedule_slp_instance (node=0x1eaade0,
instance=, bst_map=)
at /usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:4214
#6  0x00c787f4 in vect_schedule_slp_instance (node=0x1ea9830,
instance=0x1ea7060, bst_map=0x1eab2c0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:4104
#7  0x00c787f4 in vect_schedule_slp_instance (node=0x1ea9870,
instance=0x1ea7060, bst_map=0x1eab2c0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:4104
#8  0x00c787f4 in vect_schedule_slp_instance (node=0x1ea98b0,
instance=0x1ea7060, bst_map=0x1eab2c0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:4104
#9  0x00c787f4 in vect_schedule_slp_instance (node=0x1ea98f0,
instance=0x1ea7060, bst_map=0x1eab2c0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:4104
#10 0x00c793cb in vect_schedule_slp (vinfo=0x1d05270) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:4283
#11 0x00c7bbc4 in vect_slp_bb (bb=bb@entry=0x7f2fddd08270) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vect-slp.c:3277
#12 0x00c7d5a7 in (anonymous namespace)::pass_slp_vectorize::execute
(this=, fun=0x7f2fdde4c000)
at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/tree-vectorizer.c:978
#13 0x0098ca57 in execute_one_pass (pass=0x1cf2ff0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/passes.c:2497
#14 0x0098d1c8 in execute_pass_list_1 (pass=0x1cf2ff0) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/passes.c:2586
#15 0x0098d1da in execute_pass_list_1 (pass=0x1cf2f90) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/passes.c:2587
#16 0x0098d1da in execute_pass_list_1 (pass=0x1cf1110) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/passes.c:2587
#17 0x0098d219 in execute_pass_list (fn=0x7f2fdde4c000, pass=) at /usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/passes.c:2597
#18 0x006e4dbd in cgraph_node::expand (this=0x7f2fdde5) at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gcc-8.3.0/gcc/context.h:48
#19 0x006e5e75 in expand_all_functions () at
/usr/src/debug/sys-devel/gcc-8.3.0-r1/gc

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Have you tried -Wformat ?

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

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Reproducible on 8.3.0 and today's gcc master built as:

/home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
-B/home/slyfox/dev/git/gcc-native-quick/gcc -v
Reading specs from /home/slyfox/dev/git/gcc-native-quick/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-native-quick/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-native-quick/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,lto
--disable-bootstrap --with-multilib-list=m64
--prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed
--disable-nls CFLAGS='-O1 ' CXXFLAGS='-O1 '
--with-sysroot=/usr/x86_64-HEAD-linux-gnu
Thread model: posix
gcc version 9.0.1 20190408 (experimental) (GCC)

[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #32 from Martin Liška  ---
I can confirm it works for me with:

diff --git a/common.gypi b/common.gypi
index 9502e92..3d8f04f 100644
--- a/common.gypi
+++ b/common.gypi
@@ -195,8 +195,8 @@
 'ldflags': ['<(pgo_use)'],
   },],
   ['enable_lto=="true"', {
-'cflags': ['<(lto)'],
-'ldflags': ['<(lto)'],
+'cflags': ['<(lto) -fno-strict-aliasing'],
+'ldflags': ['<(lto) -fno-strict-aliasing'],
   },],
 ],
   },],

[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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P4  |P3
   Target Milestone|9.0 |7.5
Summary|[9 regression] AVR ICE: |[7/8/9 regression] ICE:
   |verify_gimple failed in |verify_gimple failed in
   |printf-return-value |printf-return-value

--- Comment #5 from Jakub Jelinek  ---
I think this started with r213951, though that is just a guess, our bisect
seeder gave weird answers.

[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 #8 from Martin Liška  ---
I took back what I took back ;)
The intermediate format file is created from GCDA file and contains information
for multiple source files. So that it does not make sense to
"--preserve-paths"/"--hash-filenames". I'll add data_file field to the JSON
file and close this issue.

[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 #2 from Pawel  ---
Hi,

Thanks, 

Adding -Wformat indeed show up a waring here : 

$ g++ -Wformat main.cpp -o out 
main.cpp: In function ‘int main()’:
main.cpp:6:30: warning: format ‘%s’ expects argument of type ‘char*’, but
argument 2 has type ‘std::string* {aka std::basic_string*}’ [-Wformat=]
   printf("Hello %s ! \n", txt);


I can make it into an error using the -Werror flag then - however - that seems
to be too strict. In the actual, real-scenario code, I think, I cannot afford
to use the -Werror flag globally - since it will turn many of otherwise
harmless warnings into errors.

Is there a reason why this is considered to be 'just a harmless warning' by
newer(>=5.0) gcc - whereas other gcc(<5.0)/complers consider this a "hard
problem" (doing this omission changes program into printing the complete
garbage, so just a warning seems to be a little too soft there)...
The warning/error message also is so different between gcc versions here..

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Because GCC allows passing non pods via varargs now.  This is an explicit
change due to newer c++ changes.

You could do -Werror=format to get only the format warnings changed to errors.

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

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #3)
> Because GCC allows passing non pods via varargs now.  This is an explicit
> change due to newer c++ changes.

Right. The C++ standard says:

"Passing a potentially-evaluated argument of class type (Clause 11) having a
non-trivial copy constructor, a non-trivial move constructor, or a non-trivial
destructor, with no corresponding parameter, is conditionally-supported with
implementation-defined semantics."

GCC supports passing a non-trivial type such as std::string to "...", with
implementation-defined semantics. Some other compilers do not support it.

But printf still requires a char* for a %s argument, which is what -Wformat
will warn about. Passing invalid arguments to printf often results in complete
garbage, e.g. printf("%s", &printf). That's not specific to passing a
std::string, it's just how printf works: you need to pass the right arguments.

[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.

[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 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

[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 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

[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 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 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 #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 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 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 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

[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 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 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&action=edit
gcc9-pr89998.patch

Untested fix.

[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 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 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 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 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&root=gcc&view=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 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 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, &progress);
1431bmap = eliminate_divs_eq(bmap, &progress);
1432bmap = eliminate_divs_ineq(bmap, &progress);
1433bmap = isl_basic_map_gauss(bmap, &progress);
1434/* requires equalities in normal form */
1435bmap = normalize_divs(bmap, &progress);

and isl_basic_map_gauss has paths where it can return NULL.

[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&root=gcc&view=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 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 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 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&root=gcc&view=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 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&root=gcc&view=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 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 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 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 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&root=gcc&view=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 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&root=gcc&view=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 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

Martin Liška  changed:

   What|Removed |Added

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

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

[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&action=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 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&root=gcc&view=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/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 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 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 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 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

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

[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&action=edit
Proposed patch

Untested on trunk yet

[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

--- 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 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, &x);
}

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

[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 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 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 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 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++/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 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 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 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&action=edit
gcc9-pr89888.patch

Untested fix.

[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 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 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 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.