[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

--- Comment #11 from Richard Biener  ---
Iff 'bne' is supposed to auto-"relax" then it is a GAS issue indeed.

Target maintainers?

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

--- Comment #10 from Richard Biener  ---
So it looks like gas does without -relax simply use bne.s which when used
explicitely results in

valarray.s: Assembler messages:
valarray.s:9: Error: jump not 3..10 bytes away (is 2)

a bne.s is one byte large while a bne.b is two bytes.  Still not sure why
gas chooses bne.b when no .balign is present but not when it is.  Possibly
because when fixing up from bne.s to bne.b the variant with .balign now
suddenly needs to insert nops to fulfill the requested alignment
(with bne.s the .balign is a no-op).

[Bug debug/90131] wrong debug info at -O3

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 18 12:02:40 2019
New Revision: 270441

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

PR debug/90131
* tree-cfgcleanup.c (move_debug_stmts_from_forwarder): Split
out from ...
(remove_forwarder_block): ... here.
(remove_forwarder_block_with_phi): Also move debug stmts here.

* gcc.dg/guality/pr90131.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/guality/pr90131.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfgcleanup.c

[Bug debug/90131] wrong debug info at -O3

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed for GCC 9.

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

--- Comment #8 from Richard Biener  ---
Btw, passing -relax to the assembler makes it assemble OK, producing

Disassembly of section P:

 <_copy>:
   0:   ef 2e   mov.l   r2, r14
   2:   61 0e   cmp #0, r14
   4:   ef 12   mov.l   r1, r2
   6:   21 0a   bne.b   10 <.L7>
   8:   02  rts
   9:   fd 70 40 00 00 00 80nop ; max   #0x8000, r0

0010 <.L7>:
  10:   ef 31   mov.l   r3, r1
  12:   ef e3   mov.l   r14, r3
  14:   7f 8f   smovf
  16:   02  rts
  17:   03  nop

likewise writing bne.b instead of bne in the assembly.  That's odd
since w/o the .balign and without -relax gas produces the same:

 <_copy>:
   0:   ef 2e   mov.l   r2, r14
   2:   61 0e   cmp #0, r14
   4:   ef 12   mov.l   r1, r2
   6:   21 03   bne.b   9 <_copy+0x9>
   8:   02  rts
   9:   ef 31   mov.l   r3, r1
   b:   ef e3   mov.l   r14, r3
   d:   7f 8f   smovf
   f:   02  rts

[Bug c++/90137] Using declaration (constructor inheritance) prevents overriding

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90137

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-04-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It works for me with FSF GCC 8.3.0.  The attached testcase instead emits

> /space/rguenther/install/gcc-8.3/bin/g++ main.cpp -I. -S  -std=gnu++11 -g 
> -Wall -W -Wextra -fPIC
In file included from
/home/space/rguenther/install/gcc-8.3/include/c++/8.3.0/memory:80,
 from using.h:4,
 from main.cpp:1:
/home/space/rguenther/install/gcc-8.3/include/c++/8.3.0/bits/unique_ptr.h: In
instantiation of ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with
_Tp = DerivedPrivate]’:
/home/space/rguenther/install/gcc-8.3/include/c++/8.3.0/bits/unique_ptr.h:274:17:
  required from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp =
DerivedPrivate; _Dp = std::default_delete]’
using.h:14:7:   required from here
/home/space/rguenther/install/gcc-8.3/include/c++/8.3.0/bits/unique_ptr.h:79:16error:
invalid application of ‘sizeof’ to incomplete type ‘DerivedPrivate’
  static_assert(sizeof(_Tp)>0,
^~~

[Bug debug/90131] wrong debug info at -O3

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-18
Version|unknown |9.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
This is mergephi at work:

@@ -101,14 +45,10 @@
   if (i_5 != 9)
 goto ; [90.00%]
   else
-goto ; [10.00%]
-
-   [local count: 107374183]:
-  # DEBUG i => NULL
-  # DEBUG i => 0
+goto ; [10.00%]

[local count: 160259975]:
-  # d_21 = PHI <0(5), 1(8)>
+  # d_21 = PHI <0(4), 1(8)>
   # DEBUG d => NULL
   # DEBUG d => d_21
   if (d_21 == 0)

where remove_forwarder_block_with_phi doesn't bother to move debug stmts
as the fixed CFG cleanup copy tried and now does conservatively.

[Bug bootstrap/90132] make bootstrap fails with -O3 (gcc9 snapshot 20190414)

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90132

--- Comment #3 from Richard Biener  ---
I guess the basic issue again that we warn for unreachable code.  Note
libdecnumber is barely maintained and quite a big mess...

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

--- Comment #4 from Richard Biener  ---
That is, r262804 or more likely r262375 (not yet confirmed).  This currently
causes sub-package FAILs for our GCC 9 package builds.

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Reduced C testcase, fails with -O2, succeeds with -O1:

typedef long unsigned int size_t;
void copy(const void* __restrict__ __a, size_t __n, void* __restrict__ __b)
{
  if (__n != 0)
__builtin_memcpy(__b, __a, __n);
}

-O2 failing assembly:

.file   "valarray.3.ii"
.section P,"ax"
.global _copy
.type   _copy, @function
_copy:
mov.L   r2, r14
cmp #0, r14
mov.L   r1, r2
bne .L7
rts
.balign 8,3,7
.L7:
mov.L   r3, r1
mov.L   r14, r3
smovf
rts
.size   _copy, .-_copy
.ident  "GCC: (GNU) 9.0.1 20190418 (experimental) [trunk revision
269411]"

if I remove the .balign it assembles.  Knowing nothing about RX I can't
say if this is to be solved in the assembler or the compiler but I note
that GCC 8 didn't align and the only backend change done for GCC 9 was
re-orgs of the *_ALIGN target macro stuff with

2018-07-17  Martin Liska  

* config/rx/rx.h (JUMP_ALIGN): Wrap integer values
* config/rx/rx-protos.h (rx_align_for_label): Make it
static function.
* config/rx/rx.c (rx_align_for_label): Change return type
to align_flags.
(rx_max_skip_for_label): Remove TARGET_ASM_*_ALIGN_MAX_SKIP
macro definitions.
into align_flags class.
(LABEL_ALIGN): Likewise.
(LOOP_ALIGN): Likewise.

2018-07-04  Denys Vlasenko  
Martin Liska  

PR middle-end/66240
PR target/45996
PR c/84100
* config/rx/rx.c (rx_option_override): Likewise.
* config/rx/rx.h (JUMP_ALIGN): Use align_jumps_log.
(LABEL_ALIGN): Use align_labels_log.
(LOOP_ALIGN): Use align_loops_align.

which likely caused this regression.

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

--- Comment #2 from Richard Biener  ---
Created attachment 46192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46192=edit
preprocessed source

With a cross to rx-elf

> ./configure --enable-languages=c,c++,lto --target=rx-elf --with-newlib 
> --enable-multilib
> make all-gcc
> ./gcc/cc1plus -fpreprocessed valarray.ii -quiet -dumpbase valarray.cc 
> -auxbase-strip valarray.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual 
> -Wabi=2 -std=gnu++98 -version -fno-implicit-templates 
> -fdiagnostics-show-location=once -frandom-seed=valarray.lo -o valarray.s
> rx-elf-as -m32bit-doubles -mrx-abi -o valarray.o valarray.s
valarray.s: Assembler messages:
valarray.s: Fatal error: Infinite loop encountered whilst attempting to compute
the addresses of symbols in section .text._ZSt15__valarray_copyImEvPKT_mPS0_

trying to reduce that now (the assembly looks innocous).

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

--- Comment #1 from Richard Biener  ---
So the assembler error is for code trying to handle

  /* Do relax().  */
  {
...
/* Most horrible, but gcc may give us some exception data that
   is impossible to assemble, of the form

   .align 4
   .byte 0, 0
   .uleb128 end - start
   start:
   .space 128*128 - 1
   .align 4
   end:

   If the leb128 is two bytes in size, then end-start is 128*128,
   which requires a three byte leb128.  If the leb128 is three
   bytes in size, then end-start is 128*128-1, which requires a
   two byte leb128.  We work around this dilemma by inserting
   an extra 4 bytes of alignment just after the .align.  This
   works because the data after the align is accessed relative to
   the end label.

   This counter is used in a tiny state machine to detect
   whether a leb128 followed by an align is impossible to
   relax.  */
...
/* Until nothing further to relax.  */
while (stretched && -- max_iterations);

if (stretched)
  as_fatal (_("Infinite loop encountered whilst attempting to compute the
addresses of symbols in section %s"),
segment_name (segment));

so it does look like an error on the compiler side.  Though maybe
impossible to avoid.  I'll try to attach a reproducer.

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #12 from Richard Biener  ---
(In reply to Ian Lance Taylor from comment #11)
> Fixed, I hope.

Yes.

[Bug target/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128

--- Comment #8 from Richard Biener  ---
(In reply to Richard Biener from comment #7)
> Benchmarking r270408 on branch vs. trunk on Haswell doesn't show any
> regression
> for me.  Will double-check with up-to-date CPU 2017 tree.

Confirmed.

[Bug target/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |target

--- Comment #7 from Richard Biener  ---
Benchmarking r270408 on branch vs. trunk on Haswell doesn't show any regression
for me.  Will double-check with up-to-date CPU 2017 tree.

[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128

--- Comment #6 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> CPU 2006 436.cactusADM also has an interesting history:
> https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/
> 436_cactusADM_big.png

compared to other benchmarks it is also quite noisy - esp. in the timeframe
of this regression.

[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128

--- Comment #5 from Richard Biener  ---
CPU 2006 436.cactusADM also has an interesting history:
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/436_cactusADM_big.png

[Bug target/90129] Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129

--- Comment #1 from Richard Biener  ---
IIRC we have a duplicate for this (albeit with -msse2 vs. none)

[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128

--- Comment #2 from Richard Biener  ---
Ugh.  Cactus is really ugly code :/  For one there's an invariant switch () in
the innermost loop, expanded to a binary tree (slightly different split point
GCC 8 vs. trunk), obviously unswitching cannot handle this.  This is a general
missed optimization precluding any vectorization attempt here.  Then we spill
the hell out of us because of the way the code is written.  Other than that
I don't see anything obvious here.  It might be that trunk:

5802:   83 fb 06cmp$0x6,%ebx
5805:   0f 84 25 84 00 00   je dc30
<_ZL19ML_BSSN_Advect_BodyPK4
_cGHiiPKdS3_S3_PKiS5_iPKPd+0xdc30>
580b:   0f 8f cf 1d 00 00   jg 75e0
<_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x75e0>
5811:   83 fb 02cmp$0x2,%ebx
5814:   0f 85 06 c0 ff ff   jne1820
<_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x1820>

is worse to the branch predictor than the GCC 8 version

89ee:   0f 84 bc 64 00 00   je eeb0
<_ZL19ML_BSSN_Advect_BodyPK4
_cGHiiPKdS3_S3_PKiS5_iPKPd+0xeeb0>
89f4:   0f 8e 96 45 00 00   jlecf90
<_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0xcf90>
89fa:   8b b4 24 a8 08 00 00mov0x8a8(%rsp),%esi
8a01:   83 fe 06cmp$0x6,%esi
8a04:   0f 85 e6 8e ff ff   jne18f0
<_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x18f0>

(notice the "padding" reload).  That is probably going to depend on final
code layout again of course.  I recall reading a third conditional jump
in a fetch word requires an additional branch predictor slot or so.

So it would be interesting to see if the branch misses accumulate on
that binary tree generated from the loop invariant switch where in
theory those should be all totally predictable.

That said, I'm not yet able to reproduce the slowdown but will try.

[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
So the issue is in ML_BSSN_Advect_Body (the other function rebounded).  I will
have a look.

[Bug c++/90126] gcc can not correctly deal with its own preprocessed output

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Richard Biener  ---
Confirmed.  I think this is odd behavior of the warning (not sure what it is
about).  Note you get no warning when you pass -fpreprocessed.  The key
to the diagnostic is that the anonymous namespace appears in a file
(through a #line directive) that is not the same as the file compiled.
Thus, the following testcase warns:

# 1 "t.C"
namespace {
struct Receiver { int object; };
}
struct Node
{
Receiver receiverQueue;
Node() { }
};
int main(int argc, char* argv[]) { return 0; }

> g++ t2.C

note to put the testcase into a file named t2.C, it doesn't warn when
the filename is t.C.  This is because the warning intends to warn about
anonymous namespaces in headers which, when included from multiple sources
may cause issues.

So I think this behaves as intended and you need to compile preprocessed
source with -fpreprocessed (or use t2.ii filenames) or retain the original
filename.  Or disable this particular warning.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #58 from Richard Biener  ---
(In reply to Richard Biener from comment #49)
> Related testcase from PR61502:
> 
> #include 
> 
> int main()
> {
>int x, y = 1;
>int *volatile v;
>int *p;
> 
>v = 
>p = v;
>if (p ==  + 1) {
>  *p = 2;
>  printf("y = %d\n", y);
>}
> }
> 
> which shows how propagating conditional equivalences (+1 into *p = 2)
> breaks
> alias analysis.

We now optimize the comparison to false via ptrs_compare_unequal given
 + 1 has provenance  and p has provenance   Thus we decided to
ignore that sub-sentence of the standard that seems to allow comparing
such pointers.  So we behave as-if we'd put at least one byte of padding
after each object.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #57 from Richard Biener  ---
(In reply to Richard Biener from comment #56)
> Testcase from PR82177:
> 
> #include 
> #include 
> 
> void f(int*, int*);
> 
> int main()
> {
>   int a=0, y[1], x = 0;
>   uintptr_t pi = (uintptr_t) 
>   uintptr_t yi = (uintptr_t) (y+1);
>   uintptr_t n = pi != yi;
> 
>   if (n) {
> a = 100;
> pi = yi;
>   }
> 
>   if (n) {
> a = 100;
> pi = (uintptr_t) y;
>   }
> 
>   *(int *)pi = 15;
> 
>   printf("a=%d x=%d\n", a, x);
> 
>   f(,y);
> 
>   return 0;
> }

With the C provenance proposal this example is undefined since 'a' is not
exposed (it's address is not converted to an integer).  The testcase
also relies on preserving the order of the variables on the stack.

[Bug debug/81135] Extra debug info generated for unused extern declarations

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81135

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Richard Biener  ---
dup

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

[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964

Richard Biener  changed:

   What|Removed |Added

 CC||peadar at arista dot com

--- Comment #10 from Richard Biener  ---
*** Bug 81135 has been marked as a duplicate of this bug. ***

[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P1

[Bug debug/90109] gstabs flag generates wrong entry for long on x86_64

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
(In reply to nebiun from comment #3)
> Sorry, but the bug is not related to the wrong dimension of a type, but to
> the fact that the bitsize of the same type (K type: long, not long long or
> double or a user type) is showed as 32 bit as typedef and 64 bit if used in
> a structure.

Well, the typedef is "wrong" (but we can't do anything about that w/o
extensions) and the structure layout is "correct" (it seems we can
represent things there correctly).

What would be nice is to somehow not emit the bogus typedef but sth
that wouldn't show this mismatch.  But I get that stabs doesn't have
a way to do this.

That said, dbxout.c might want to issue a warning if we emit "bogus"
stabs and suggest to use -gstabs+.

But I agree, you shouldn't use stabs.  It's not maintained, the world
has moved on to dwarf (and I more than once argued to remove stabs support
from GCC).

[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542

--- Comment #11 from Richard Biener  ---
Nathan, what does it take to re-instantiate -fdump-lang-raw for the C frontend?

[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037

--- Comment #9 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #8)
> So, if we change phionlycprop to look for other const/copy initializations
> that can be eliminated and run a pass between DOM and the erroneous-path
> isolation pass, then the false positive is eliminated (as expected).
> 
> There's two things I don't like about that.  First, it turns phionlycprop
> into a full-fledged constant propagation pass.  phionlycprop is supposed to
> be so fast that we never really notice it.  It accomplishes this by only
> looking at PHI nodes that are degenerates and any constants exposed by
> propagating way the degenerate PHI.  Essentially it's just cleaning up
> painfully obvious cruft left by jump threading.
> 
> To pick up this case we'd have to scan statements in blocks.  We could
> restrict that to blocks where we eliminated  degenerate PHI.  But still. 
> Ugh.
> 
> Second, once phionlycprop is doing more work, I'm less inclined to want to
> add another instance of the pass.
> 
> Finally, once phionlycprop is doing more work one could legitimately ask if
> we should just drop the code and use the lattice copy propagator.
> 
> Just for fun I replaced all the phi-only cprop calls with calls into the
> lattice propagator (including the one I added between DOM and erroneous-path
> optimization).  As expected that fixes the testcase too.  It also happens to
> clean up things slightly better at an earlier point in the optimizer
> pipeline.  I don't know if it's a good trade-off though.

As a middle-ground you can now run non-iterating value-numbering on a
SEME region.  We are already doing that for unrolled loop bodies,
if-converted loop bodies and loop header copies, exactly to (mostly) get
local constant propagation & simplifications done.  IMHO the copied
paths jump threading creates are a perfect candidate for this treatment
as well.  See for example tree-ssa-loop-ch.c where it calls do_rpo_vn
(obviously VN needs up-to-date SSA so the VN is delayed until after all
loop-header copying is done and we remember the SEME regions to VN).

[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565

--- Comment #14 from Richard Biener  ---
I think implementation-wise GCC outrules aliases that are not visible but takes
care of symbols resolving to NULL.  For optimizations of actual accesses it can
assume the symbols do not resolve to NULL since the accesses would trap.  So
the question is whether we should follow suit and declare non-visible weak
declarations similarly undefined as non-visible alias declarations
(for externs and commons).

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #3 from Richard Biener  ---
Btw, I just checked and the build also fails with glibc 2.22 in the same way.

Oddly enough it only fails in a controlled environment but not on a development
machine with the same glibc I do regular testing on.  (controlled environment
aka package builds for SLES 12 based distros)

I configure with

../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--disable-plugin --with-bugurl=https://bugs.opensuse.org/
'--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-9 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux

and build like

setarch x86_64 -R make profiledbootstrap 'STAGE1_CFLAGS=-g -O2'
'BOOT_CFLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -D_FORTIFY_SOURCE=2
-funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE' -j3

the build uses trunk as of r270275

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

--- Comment #2 from Richard Biener  ---
Created attachment 46183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46183=edit
32bit math.gox

Here it is.  The 64bit one looks similar btw.

[Bug debug/90109] gstabs flag generates wrong entry for long on x86_64

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109

Richard Biener  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
GCC 8 seems to get 'long int' correct:

typedef int32 int;
typedef int8 char;
typedef int64 long int;
typedef uint32 unsigned int;
typedef uint32 long unsigned int;
typedef uint32 __int128;
typedef uint32 __int128 unsigned;
typedef int64 long long int;
typedef uint64 long long unsigned int;
typedef int16 short int;
typedef uint16 short unsigned int;
typedef int8 signed char;
typedef uint8 unsigned char;
typedef float float;
typedef double double;
typedef float128 long double;

long double is also wrong.  GCC does

  if (print_int_cst_bounds_in_octal_p (type, low, high))
...
  else
 /* Output other integer types as subranges of `int'.  */
 dbxout_range_type (type, low, high);

probably that's the issue.  It looks like you need to use -gstabs+ to allow
representing those types at all (stabs with GNU extensions).  With -gstabs+
I see

/tmp/t.c:
typedef int32 int;
typedef int8 char;
typedef int64 long int;
typedef uint32 unsigned int;
typedef uint64 long unsigned int;
typedef void __int128;
typedef void __int128 unsigned;
typedef int64 long long int;
typedef uint64 long long unsigned int;
typedef int16 short int;
typedef uint16 short unsigned int;
typedef int8 signed char;
typedef uint8 unsigned char;
typedef float float;
typedef double double;
typedef float128 long double;

(long double still wrong)

So - INVALID?  Jim, you are "remotely" listed as MAINTAINER for stabs.

[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||x86_64-*-*, i?86-*-*,
   ||ppc64le-*-*, aarch64-*-*,
   ||s390x-*-*
   Priority|P3  |P4
   Target Milestone|--- |9.0

[Bug go/90110] New: [9 Regression] libgo fails to build against glibc 2.19

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110

Bug ID: 90110
   Summary: [9 Regression] libgo fails to build against glibc 2.19
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: rguenth at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

When building GCC 9 against glibc 2.19 I get

[ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data 
for 'Float32frombits': expected integer at 79
[ 6667s]13 | import "math"
[ 6667s]   |^
[ 6667s]  ../../../../libgo/go/math/unsafe.go:18: error: expected pointer
[ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data
for 'Float64frombits': expected integer at 79
[ 6667s]13 | import "math"
[ 6667s]   |^
[ 6667s]  ../../../../libgo/go/math/unsafe.go:29: error: expected pointer
[ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data
for 'Float32bits': expected integer at 79
[ 6667s]13 | import "math"
[ 6667s]   |^
[ 6667s]  ../../../../libgo/go/math/unsafe.go:12: error: expected pointer
[ 6667s] ../../../../libgo/go/strconv/atof.go:13:12: error: invalid export data
for 'Float64bits': expected integer at 79
[ 6667s]13 | import "math"
[ 6667s]   |^
[ 6667s]  ../../../../libgo/go/math/unsafe.go:23: error: expected pointer
[ 6667s] Makefile:2838: recipe for target 'strconv.lo' failed
[ 6667s] make[8]: *** [strconv.lo] Error 1

GCC 8 is fine.

[Bug c++/90108] ICE: Segmentation fault (in c_tree_chain_next)

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
So we have a non-GCed INTEGER_TYPE that has a GCed TYPE_NAME.  IIRC changes
there recently, PR89933.

We free that TYPE_NAME here (as expected...):

#1  0x009584ee in duplicate_decls (
newdecl=, 
olddecl=, newdecl_is_friend=false)
at /space/rguenther/src/svn/trunk2/gcc/cp/decl.c:2793
2793  ggc_free (newdecl);

Jakub - you fiddled here, can you look at this one, too?

[Bug tree-optimization/56049] [7/8 Regression] Simplification to constants not done

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
Summary|[7/8/9 Regression]  |[7/8 Regression]
   |Simplification to constants |Simplification to constants
   |not done|not done
  Known to fail||7.4.0, 8.3.0

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

[Bug tree-optimization/56049] [7/8/9 Regression] Simplification to constants not done

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049

--- Comment #24 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 16 07:55:41 2019
New Revision: 270378

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

PR tree-optimization/56049
* tree-ssa-loop-im.c (mem_ref_hasher::equal): Elide alias-set
equality check if alias-set zero will prevail.

* gfortran.dg/pr56049.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr56049.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c

[Bug middle-end/90095] [8/9 Regression] wrong code with -Os -fno-tree-bit-ccp

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
   Target Milestone|9.0 |8.4
Summary|[9 Regression] wrong code   |[8/9 Regression] wrong code
   |with -Os -fno-tree-bit-ccp  |with -Os -fno-tree-bit-ccp

--- Comment #3 from Richard Biener  ---
rev is on the branch.

[Bug middle-end/90095] [9 Regression] wrong code with -Os -fno-tree-bit-ccp

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Blocks||85414


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85414
[Bug 85414] [8 Regression] ICE: in ix86_expand_prologue, at
config/i386/i386.c:13810 with -Og -fgcse

[Bug rtl-optimization/90094] better handling of x == LONG_MIN on x86-64

2019-04-16 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-16
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I guess this also applies to conditional branches.  It might require to copy
a to a scratch register in case it's value is live over the comparison
(but then it saves a reg for the constant).

[Bug tree-optimization/56049] [7/8/9 Regression] Simplification to constants not done

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049

--- Comment #23 from Richard Biener  ---
So we are _nearly_ there on trunk.  LIM has improved up to the point the only
blocker is mismatching alias-sets in mem_ref_hasher::equal and the case in
question for this PR is even handled correctly because refs arrive in the
correct order and the one we'd chose has the ref-all case we'd have to
canonicalize to anyways.  So the following works (and can be slightly
enhanced).

Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c  (revision 270366)
+++ gcc/tree-ssa-loop-im.c  (working copy)
@@ -178,7 +178,15 @@ mem_ref_hasher::equal (const im_mem_ref
&& known_eq (mem1->mem.size, obj2->size)
&& known_eq (mem1->mem.max_size, obj2->max_size)
&& mem1->mem.volatile_p == obj2->volatile_p
-   && mem1->mem.ref_alias_set == obj2->ref_alias_set
+   && (mem1->mem.ref_alias_set == obj2->ref_alias_set
+   /* We are not canonicalizing alias-sets but for the
+  special-case we didn't canonicalize yet and the
+  incoming ref is a alias-set zero MEM we pick
+  the correct one already.  */
+   || (!mem1->ref_canonical
+   && (TREE_CODE (obj2->ref) == MEM_REF
+   || TREE_CODE (obj2->ref) == TARGET_MEM_REF)
+   && obj2->ref_alias_set == 0))
&& types_compatible_p (TREE_TYPE (mem1->mem.ref),
   TREE_TYPE (obj2->ref)));
   else

[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055

--- Comment #4 from Richard Biener  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Martin Liška from comment #2)
> > Fixed on trunk with r250959 which is:
> > 
> > 364bc5b93b76cf88(08 Aug 2017 14:09): [took: 2.844s] result: OK
> > sum: 0.
> > SVN revision: 250959
> > Author: amker
> > * doc/invoke.texi: Document -ftree-loop-distribution for O3.
> > * opts.c (default_options_table): Add OPT_ftree_loop_distribution.
> > 
> > 
> > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250959
> > 138bc75d-0d04-0410-961f-82ee72b054a4
> > 
> > Using:
> > gcc pr90055.c -O3 -ffast-math -march=haswell -mtune=haswell
> > -fno-tree-loop-distribution
> > 
> > it disappeared in r253934:
> > 
> > Author: hubicka
> > * x86-tune-costs.h (core_cost): Fix div, move and sqrt latencies.
> 
> Those look like they are all would cause the issue to go latent.
> 
> > 
> > and it started with r238033.
> 
> This one does it might be the real cause of the issue.

Nope, it just does less peeling for gaps.

[Bug tree-optimization/90071] [7/8 Regression] internal compiler error: SSA corruption

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] internal |[7/8 Regression] internal
   |compiler error: SSA |compiler error: SSA
   |corruption  |corruption
  Known to fail||7.4.0, 8.3.0

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

[Bug debug/90074] wrong debug info at -O3

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90074

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||9.0
Version|unknown |9.0
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed on trunk.

[Bug debug/90074] wrong debug info at -O3

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90074

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 15 12:26:11 2019
New Revision: 270370

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

PR debug/90074
* tree-loop-distribution.c (destroy_loop): Preserve correct
debug info.

* gcc.dg/guality/pr90074.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/guality/pr90074.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug tree-optimization/90071] [7/8/9 Regression] internal compiler error: SSA corruption

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 15 11:59:02 2019
New Revision: 270369

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

PR tree-optimization/90071
* tree-ssa-reassoc.c (init_range_entry): Do not pick up
abnormal operands from def stmts.

* gcc.dg/torture/pr90071.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr90071.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809

--- Comment #9 from Richard Biener  ---
clang doesn't optimize the corresponding C testcase

struct Foo {
  struct Foo *next;
};

void release(struct Foo *next) {
struct Foo *tmp = 0;
for (struct Foo *it = next; it; it = tmp) {
tmp = it->next;
}
}

which means it needs to have a way in the IL to annotate loops as
terminating.

Does the C++ rule apply to all cycles or just to "loops"?  (thinking
of goto, recursion, etc.)

[Bug middle-end/67809] Empty pointer-chasing loops aren't optimized out

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67809

--- Comment #8 from Richard Biener  ---
So it's legal to remove the classical "halt CPU" while (1);?  Interesting...

Does this apply to C++ only?

I presume for libstdc++ we could add a

#pragma GCC loop finite

which tells GCC it can assume the loop eventually terminates.

[Bug ipa/88936] [7/8 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression]  |[7/8 Regression] -fipa-pta
   |-fipa-pta breaks bash   |breaks bash (incorrect
   |(incorrect optimisation of  |optimisation of recursive
   |recursive static function)  |static function)
  Known to fail|9.0 |

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

[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Mon Apr 15 10:09:08 2019
New Revision: 270366

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

PR ipa/88936
* tree.h (auto_var_p): Declare.
* tree.c (auto_var_p): New function, split out from ...
(auto_var_in_fn_p): ... here.
* tree-ssa-structalias.c (struct variable_info): Add shadow_var_uid
member.
(new_var_info): Initialize it.
(set_uids_in_ptset): Also set the shadow variable uid if required.
(ipa_pta_execute): Postprocess points-to solutions assigning
shadow variable uids for locals that may reach their containing
function recursively.
* tree-ssa-ccp.c (fold_builtin_alloca_with_align): Do not
assert but instead check whether the points-to solution is
a singleton.

* gcc.dg/torture/pr88936-1.c: New testcase.
* gcc.dg/torture/pr88936-2.c: Likewise.
* gcc.dg/torture/pr88936-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr88936-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr88936-2.c
trunk/gcc/testsuite/gcc.dg/torture/pr88936-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c
trunk/gcc/tree-ssa-structalias.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug debug/90074] wrong debug info at -O3

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90074

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  Generally loop optimizers are bad when handling debug info, most
of the time dropping them on the floor rather than changing them to resets.
In this particular case it's loop distribution:

@@ -16,33 +25,7 @@
   # DEBUG i => 0
   # DEBUG BEGIN_STMT
   # DEBUG i => 0
-
-   [local count: 719407024]:
-  # i_14 = PHI <0(2), i_8(5)>
-  # ivtmp_4 = PHI <7(2), ivtmp_1(5)>
-  # DEBUG c => NULL
-  # DEBUG i => NULL
-  # DEBUG i => i_14
-  # DEBUG c => NULL
-  # DEBUG c => 0
-  # DEBUG BEGIN_STMT
-  b[i_14][0] = 0;
-  # DEBUG c => 1
-  # DEBUG c => NULL
-  # DEBUG c => 1
-  i_8 = i_14 + 1;
-  # DEBUG i => i_8
-  # DEBUG i => i_8
-  ivtmp_1 = ivtmp_4 - 1;
-  if (ivtmp_1 != 0)
-goto ; [0.00%]
-  else
-goto ; [100.00%]
-
-   [local count: 0]:
-  goto ; [100.00%]
-
-   [local count: 719407023]:
+  __builtin_memset (, 0, 14);
   # DEBUG BEGIN_STMT
   optimize_me_not ();


it's not "easy" to fix things up here, but loop-distribution uses
delete_basic_block and edge redirection which bypasses CFG cleanup
ability to eventually handle this better.

I have a patch.

[Bug sanitizer/90090] [7/8/9 Regression] ICE in mark_reachable_handlers, at tree-eh.c:3938 since r219202

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90090

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/90088] 3 ops LEA should be avoided on Intel CPUs

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088

Richard Biener  changed:

   What|Removed |Added

 Target|Intel x86   |x86_64-*-* i?86-*-*
 CC||hjl at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
We have two related tunables, X86_TUNE_OPT_AGU and X86_TUNE_AVOID_LEA_FOR_ADDR.

Probably related is that most uarchs have extra cost for complex addressing
modes for moves (extra uop to generate the addres).  But I wasn't aware
that there's extra costs for the AGU op itself.

[Bug c++/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org
Version|tree-ssa|8.3.1

[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.5

[Bug tree-optimization/90071] [7/8/9 Regression] internal compiler error: SSA corruption

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071

--- Comment #3 from Richard Biener  ---
Matching expression match.pd:1195, generic-match.c:115
Applying pattern match.pd:1251, generic-match.c:17730
Matching expression match.pd:100, generic-match.c:22
Optimizing range tests e_21(ab) +[, 0] and +[-1, ]
 into (unsigned int) e_21(ab) + 1 <= 1

Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c  (revision 270358)
+++ gcc/tree-ssa-reassoc.c  (working copy)
@@ -2143,7 +2143,8 @@ init_range_entry (struct range_entry *r,
  exp_type = boolean_type_node;
}

-  if (TREE_CODE (arg0) != SSA_NAME)
+  if (TREE_CODE (arg0) != SSA_NAME
+ || SSA_NAME_OCCURS_IN_ABNORMAL_PHI (arg0))
break;
   loc = gimple_location (stmt);
   switch (code)

[Bug tree-optimization/90071] [7/8/9 Regression] internal compiler error: SSA corruption

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
 CC||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
reassoc does this:

@@ -51,9 +75,11 @@
 f:
   _7 = d_20(D) != 0;
   _9 = _4 < 0;
-  _10 = _7 | _9;
+  _18 = (unsigned int) e_21(ab);
+  _16 = _18 + 1;
+  _14 = _16 > 1;
   _17 = _4 > 1;
-  _6 = _10 | _17;
+  _6 = _14 | _7;
   _8 = (int) _6;
   _12 = (long int) _8;
   _13 = (void *) _12;

it's likely folding

  _4 = e.1_3 + 1;
  _9 = _4 < 0;

here.  I'll take a look.

[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant

2019-04-15 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Richard Biener  ---
For -ffast-math doing this as a float FMA is probably fastest.  I'm not sure
whether doing temp1 * 5 as integer operation is any good given on archs like
Zen you'll have a FP <-> INT domain crossing.

[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize

2019-04-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||6.5.0, 8.1.0
   Keywords||needs-bisection, wrong-code
   Last reconfirmed||2019-04-12
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Incorrect result with   |[7 Regression] Incorrect
   |ffast-math + tree-vectorize |result with ffast-math +
   ||tree-vectorize
   Target Milestone|--- |7.5
  Known to fail||7.1.0

--- Comment #1 from Richard Biener  ---
Confirmed - this is likely a duplicate since it seems to be fixed on the GCC 8
branch and trunk.  -mavx2 -mfma triggers the issue.  w/o -mfma the GCC 7 branch
produces -0.0.

The GCC 8 branch doesn't vectorize the loop at t.c:104 but the basic-block at
103.

Note I observe different unrolling between 7 and 8 so the actual issue might
be latent.

Martin, can you bisect what fixed this?

[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)

2019-04-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936

--- Comment #13 from Richard Biener  ---
Testcase using globals instead of parameters:

static int *p;
void bar(int cnt)
{
  int i = 0;
  if (cnt == 0)
{
  p = 
  bar (1);
  if (i != 1)
__builtin_abort ();
}
  else if (cnt == 1)
*p = 1;
}
int main()
{
  bar (0);
  return 0;
}

[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)

2019-04-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936

--- Comment #12 from Richard Biener  ---
Created attachment 46146
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46146=edit
final fix

I am testing the following now which should do less work (but waste more UIDs
to be less conservative).  The ipa-pta-3.c testcase is no longer affected,
we're more optimistically identifying candidates by just looking at a variables
function parameter solutions and globals for locals recursively reaching a
function.

[Bug gcov-profile/90053] [GCOV] A statement in while loop is wrongly marked as not executed when they are within the if(setjmp()) statement

2019-04-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90053

--- Comment #1 from Richard Biener  ---
I think you need to use setjmp/longjmp, not the __builtin variants which have
special semantics.

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

2019-04-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90017

--- Comment #4 from Richard Biener  ---
(In reply to Qirun Zhang from comment #3)
> (In reply to Alexandre Oliva from comment #2)
> > This odd behavior is an artifact of the way GCC lays out the basic blocks,
> > and how GDB interprets the line number program.
> > 
> > The blocks containing the conditional calls to optimize_me_not in line 15
> > are moved to the end of the function, in reverse order, while the rest of
> > the inner loop, with code from lines 12 to 14, remains in sequential order.
> > 
> > What GDB sees then is a long chunk of code all at line 15, the first of
> > which corresponds to the iteration l=8.  l=7 is later, with another line
> > number mark, then l=6 and so on, but without intervening line number
> > changes, it takes it all as a single line.  GDB pays no attention to the
> > is_stmt=1 markers at each and every one of them, let alone to the different
> > view numbers.
> > 
> > So, yeah, definitely consumer issue.
> 
> Hi Alex,
> 
> Are you suggesting that it's a gdb bug? Perhaps, I can report it to gdb
> instead? Thanks.

Yes, reporting to gdb sounds appropriate.

[Bug testsuite/81179] gcc.dg/vect/pr65947-9.c and gcc.dg/vect/pr65947-14.c fail starting with r249553

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81179

Richard Biener  changed:

   What|Removed |Added

   Keywords|wrong-code  |
 Status|ASSIGNED|NEW
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Target Milestone|8.4 |---

[Bug target/81941] Rejects intrinsic use

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81941

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Reconfirmed.

[Bug tree-optimization/82187] missed PRE at -O3

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82187

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2017-09-12 00:00:00 |2019-4-11

--- Comment #3 from Richard Biener  ---
Reconfirmed.

[Bug c/82186] [7 Regression] ICE (segfault), VLA type with inlining

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82186

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
I'd say backporting is good.  Queued.

[Bug debug/82202] Missing debug information in LTO/offload compilation

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82202

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Just noticed this recently again - we need explict -g at link-time to get
debuginfo for an LTO compilation.  IMHO that's a serious issue people might
run into (now that we handle optimization transparently).

[Bug tree-optimization/82282] PRE cannot blindly fold integer-to-pointer/pointer-to-integer round-trips

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82282

Richard Biener  changed:

   What|Removed |Added

 Depends on|82177   |65752

--- Comment #6 from Richard Biener  ---
I think elsewhere I noted that propagating an equivalency is likely what makes
those cases appear.  In this cases it would be phiopt.  Still not doing that
would have some bad effects on optimization.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
[Bug 65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82177
[Bug 82177] Alias analysis too aggressive with integer-to-pointer cast

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359

--- Comment #17 from Richard Biener  ---
We'd need to peel the last iteration as the following shows.  This also means
it is not enough to prove the loop actually iterates.  Peeling the last
iteration means we have to be able to identify that iteration.  Alternatively,
we might be able to re-issue all stores from the last iteration up until
the exit on the exit edge though if there are conditional stores on this
path this might prove interesting.

There's always the option to not apply store-motion here of course.

extern void abort();

typedef int A;
typedef float B;

void __attribute__((noinline,noclone))
foo(A *p, B *q, long unk)
{
  for (long i = 0; i < unk; ++i) {
  *p = 1;
  q[i] = 42;
  }
}

int main(void)
{
  char *mem = __builtin_malloc (sizeof (A) * 5);
  foo((A *)mem + 4, (B *)mem, 5);
  if (*((B *)mem + 4) != 42) abort();
  return 0;
}

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616

--- Comment #52 from Richard Biener  ---
Fixed?  Or shall we take it as recurring bug?

[Bug tree-optimization/66974] -Warray-bounds false positive with -O3

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974
Bug 66974 depends on bug 83202, which changed state.

Bug 83202 Summary: Try joining operations on consecutive array elements during 
tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202

   What|Removed |Added

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

[Bug tree-optimization/83202] Try joining operations on consecutive array elements during tree vectorization

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
The comment#4 case is sth completely different.  If it's really interesting
to re-vectorize already vectorized code please file a different bug.

The other testcases seem to work fine for me now.

[Bug middle-end/82286] [7 Regression] Wrong array subscript is above array bounds

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82286
Bug 82286 depends on bug 83202, which changed state.

Bug 83202 Summary: Try joining operations on consecutive array elements during 
tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202

   What|Removed |Added

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

[Bug tree-optimization/69224] [7 Regression] -Warray-bounds false positive with -O3 and struct pointer parameter

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224
Bug 69224 depends on bug 83202, which changed state.

Bug 83202 Summary: Try joining operations on consecutive array elements during 
tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202

   What|Removed |Added

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 83202, which changed state.

Bug 83202 Summary: Try joining operations on consecutive array elements during 
tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83202

   What|Removed |Added

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

[Bug ipa/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|9.0 |---

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Last reconfirmed|2018-06-21 00:00:00 |2019-4-11
  Known to work||9.0
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
Summary|[8/9 Regression] min(4, |[8 Regression] min(4,
   |strlen(s)) optimized to |strlen(s)) optimized to
   |strlen(s) with -flto|strlen(s) with -flto

--- Comment #36 from Richard Biener  ---
Reconfirmed on the branch.  Not sure what rev. fixed it on the trunk.  Not
working on this.

[Bug libstdc++/90046] New: [9 Regression] fails to build a epiphany-elf cross toolchain with C++ enabled

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90046

Bug ID: 90046
   Summary: [9 Regression] fails to build a epiphany-elf cross
toolchain with C++ enabled
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

[   87s] + ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++ --disable-werror
--with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp
--disable-libvtv --disable-cet --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-9
--program-prefix=epiphany-elf- --target=epiphany-elf --disable-nls
--with-sysroot=/usr/epiphany-elf/sys-root
--with-build-sysroot=/usr/epiphany-elf/sys-root
--with-build-time-tools=/usr/epiphany-elf/bin --with-newlib
--build=x86_64-suse-linux --host=x86_64-suse-linux
...
[ 1411s] libtool: compile: 
/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x8
6_64-suse-linux/./gcc/xgcc -shared-libgcc
-B/home/abuild/rpmbuild/BUILD/gcc-9.0.
1+r270275/obj-x86_64-suse-linux/./gcc -nostdinc++
-L/home/abuild/rpmbuild/BUILD/
gcc-9.0.1+r270275/obj-x86_64-suse-linux/epiphany-elf/libstdc++-v3/src
-L/home/ab
uild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x86_64-suse-linux/epiphany-elf/libstdc
++-v3/src/.libs
-L/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x86_64-suse-
linux/epiphany-elf/libstdc++-v3/libsupc++/.libs -B/usr/epiphany-elf/bin/
-B/usr/
epiphany-elf/lib/ -isystem /usr/epiphany-elf/include -isystem
/usr/epiphany-elf/
sys-include --sysroot=/usr/epiphany-elf/sys-root
-I/home/abuild/rpmbuild/BUILD/g
cc-9.0.1+r270275/libstdc++-v3/../libgcc
-I/home/abuild/rpmbuild/BUILD/gcc-9.0.1+
r270275/obj-x86_64-suse-linux/epiphany-elf/libstdc++-v3/include/epiphany-elf
-I/
home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x86_64-suse-linux/epiphany-elf/libstdc++-v3/include
-I/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/libstdc++-v3/libsupc++
-std=gnu++17 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=memory_resource.lo -fimplicit-templates -g -O2 -c
../../../../../libstdc++-v3/src/c++17/memory_resource.cc -o memory_resource.o
[ 1413s] ../../../../../libstdc++-v3/src/c++17/memory_resource.cc: In member
fun
ction 'void std::pmr::monotonic_buffer_resource::_M_new_buffer(std::size_t,
std:
:size_t)':
[ 1413s] ../../../../../libstdc++-v3/src/c++17/memory_resource.cc:235:62:
error:
 static assertion failed
[ 1413s]   235 | static_assert(alignof(monotonic_buffer_resource::_Chunk)
==
 1);
[ 1413s]   |  
~~~^~
~~
[ 1414s] make[5]: *** [Makefile:569: memory_resource.lo] Error 1
[ 1414s] make[5]: *** Waiting for unfinished jobs

[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||rx-elf
   Priority|P3  |P4
   Host||x86_64-suse-linux
   Target Milestone|--- |9.0

[Bug libstdc++/90045] New: [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045

Bug ID: 90045
   Summary: [9 Regression] fails to build a rx-elf cross toolchain
with C++ enabled
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

[   88s] + ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++ --disable-werror
--with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp
--disable-libvtv --disable-cet --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-9 --program-prefix=rx-elf-
--target=rx-elf --disable-nls --with-sysroot=/usr/rx-elf/sys-root
--with-build-sysroot=/usr/rx-elf/sys-root
--with-build-time-tools=/usr/rx-elf/bin --with-newlib --build=x86_64-suse-linux
--host=x86_64-suse-linux
...

[ 1779s] libtool: compile: 
/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x8
6_64-suse-linux/./gcc/xgcc -shared-libgcc
-B/home/abuild/rpmbuild/BUILD/gcc-9.0.
1+r270275/obj-x86_64-suse-linux/./gcc -nostdinc++
-L/home/abuild/rpmbuild/BUILD/
gcc-9.0.1+r270275/obj-x86_64-suse-linux/rx-elf/libstdc++-v3/src
-L/home/abuild/r
pmbuild/BUILD/gcc-9.0.1+r270275/obj-x86_64-suse-linux/rx-elf/libstdc++-v3/src/.l
ibs
-L/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x86_64-suse-linux/rx-elf
/libstdc++-v3/libsupc++/.libs -B/usr/rx-elf/bin/ -B/usr/rx-elf/lib/ -isystem
/us
r/rx-elf/include -isystem /usr/rx-elf/sys-include
--sysroot=/usr/rx-elf/sys-root
 -I/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/libstdc++-v3/../libgcc
-I/home/
abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x86_64-suse-linux/rx-elf/libstdc++-v
3/include/rx-elf
-I/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r270275/obj-x86_64-suse
-linux/rx-elf/libstdc++-v3/include
-I/home/abuild/rpmbuild/BUILD/gcc-9.0.1+r2702
75/libstdc++-v3/libsupc++ -std=gnu++98 -fno-implicit-templates -Wall -Wextra
-Ww
rite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once
-frandom-seed=
valarray.lo -g -O2 -c ../../../../../libstdc++-v3/src/c++98/valarray.cc -o
valar
ray.o
[ 1779s] /tmp/cceTRmfA.s: Assembler messages:
[ 1779s] /tmp/cceTRmfA.s: Fatal error: Infinite loop encountered whilst
attempti
ng to compute the addresses of symbols in section
.text._ZSt15__valarray_copyImEvPKT_mPS0_
[ 1779s] make[5]: *** [Makefile:646: valarray.lo] Error 1

[Bug rtl-optimization/83530] [7 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||8.0

--- Comment #16 from Richard Biener  ---
Can't be P1.

[Bug regression/81331] [7 Regression] missed Eh delivery in partitioned function

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
 Status|NEW |ASSIGNED
  Known to work||8.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
  Known to fail||7.1.0

--- Comment #17 from Richard Biener  ---
This can't be P1.  But we're still waiting for a backport from Honza.

[Bug target/89399] [7/8 Regression] ICE: RTL check: expected code 'set', 'clobber' or 'clobber_high', have 'parallel' in combine_reaching_defs, at ree.c:783

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #8 from Richard Biener  ---
Not P1.  When did it work?  Is it even a regression?

[Bug c++/89900] [9 Regression] ICE: Segmentation fault (in check_instantiated_arg)

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89900

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #5 from Richard Biener  ---
ice-on-invalid/error-recovery is P4.

[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P3
   Target Milestone|9.0 |---
Summary|[9 Regression] ICE in   |ICE in tree_code_size, at
   |tree_code_size, at  |tree.c:865
   |tree.c:865  |

--- Comment #3 from Richard Biener  ---
Hmm, we don't seem to get consensus here.  I also don't see how this is
a regression, my GCC 8 compiler doesn't know __builtin_has_attribute.

So, removing the regression marker.

Can we, for GCC 9, simply say

 sorry ("unsupported argument to __builtin_has_attribute");

instead of ICEing and/or extending the specification in some ways?

For reference, GCC 8 says

t.c:1:22: warning: implicit declaration of function ‘__builtin_has_attribute’;
did you mean ‘__builtin_va_start’? [-Wimplicit-function-declaration]
 typedef int Assert [(__builtin_has_attribute (1, target("sse")) == 1)];
  ^~~
  __builtin_va_start
t.c:1:50: warning: implicit declaration of function ‘target’
[-Wimplicit-function-declaration]
 typedef int Assert [(__builtin_has_attribute (1, target("sse")) == 1)];
  ^~
t.c:1:13: error: variably modified ‘Assert’ at file scope
 typedef int Assert [(__builtin_has_attribute (1, target("sse")) == 1)];
 ^~

[Bug target/89271] [9 Regression] gcc.target/powerpc/vsx-simode2.c stopped working in GCC 9

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271

--- Comment #18 from Richard Biener  ---
Status update?

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093

--- Comment #38 from Richard Biener  ---
Isn't the issue also latent on all branches?

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871

--- Comment #13 from Richard Biener  ---
Can we xfail/defer the bug?

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763

--- Comment #47 from Richard Biener  ---
What's the state of regressions left?  Can we xfail the rest and defer the bug?

[Bug other/55930] [7/8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.5

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

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
The problem of sel-sched propagating hard-regs is likely older, thus P2 since
this is also not from a real-world program that newly fails to build.

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

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89888

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/89970] [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/89875] [7/8/9 Regression] invalid typeof reference to a member of an incomplete struct accepted at function scope

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89875

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

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

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/89584] [9 Regression] CPU2000 degradations with r268448 (172.mgrid -22%, 252.eon -8%)

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89584

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target|powerpc64-unknown-linux-gnu |powerpc64-unknown-linux-gnu
   ||, x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
A big 252.eon regression can also be seen on Haswell
(https://gcc.opensuse.org/gcc-old/SPEC/CINT/sb-czerny-head-64/252_eon_big.png)

[Bug target/89096] [7/8/9 regression] AIX 7 linker rejects _.ro_ sections by default

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89096

--- Comment #11 from Richard Biener  ---
Not a GCC bug then?

[Bug target/84481] [8/9 Regression] 429.mcf with -O2 regresses by ~6% and ~4%, depending on tuning, on Zen compared to GCC 7.2

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84481

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-11
 Ever confirmed|0   |1

--- Comment #10 from Richard Biener  ---
(In reply to Martin Liška from comment #3)
> Interesting. Do I understand that correctly that it's due to increasing
> addresses of the 3 load instructions: 0x8(%rdx), 0x18(%rdx), 0x30(%rdx) vs.
> 0x18(%rdx) 0x30(%rdx) 0x8(%rdx) ?

I would guess that the hardware prefetcher might be sensitive to this.  But
note that depending on the frontend any two of the loads might issue in
parallel.

It seems this is some kind of list-walking so HW prefetching possibly
doesn't (and should not) trigger.

Anyways, it's probably a cache subsystem "issue".  Ordering memory
references might be an interesting post-reload scheduling heuristic
we could employ here.

  1   2   3   4   5   6   7   8   9   10   >