[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
If you could, I'd appreciate it, if not, I'll find time for it this week.  But
if the bug is in reg-stack, I'll be lost anyway.

[Bug c/69605] printf %f on integers

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
It has undefined behviour.

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
If you could pass it along to me privately, I can verify if it's the same issue
or not easily (that's the nice things about a PARAM, I can just crank up the
limiter and see what happens).  I also happen to have gcc-4.9 and gcc-5
compilers handy to compare against.

l...@redhat.com

Thanks for taking the time to dig this stuff out and report the issues.  We're
using the FSM bits a lot more now and plan to rely on them more in the future. 
So shaking out these cases is important.

[Bug c/69605] printf %f on integers

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
https://gcc.gnu.org/wiki/FAQ#undefinedbut

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #1)
> Confirmed, though there are other PRs similar in nature.  Fixing this isn't
> trivial at all.  E.g. -Wduplicated-cond has the same problem -- that's the
> reason these warnings aren't enabled by -Wall/-Wextra. :(

It isn't trivial, but it may be possible now by seeing that the operators come
from the expansion of different macros, no?

[Bug target/68986] [5 Regression] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #20 from H.J. Lu  ---
Fixed for GCC 5.4.

[Bug rtl-optimization/69606] New: wrong code at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 69606
   Summary: wrong code at -Os and above on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -Os
and above in both 32-bit and 64-bit modes.

This also affects 5.1.x and later, and is a regression from 4.9.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160201 (experimental) [trunk revision 233027] (GCC) 
$ 
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-4.9 -Os small.c; ./a.out
$ 
$ gcc-trunk -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ gcc-5.3 -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ gcc-5.2 -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ gcc-5.1 -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ 


-


char a;
unsigned short b;
int c, d;
unsigned char e;

int
main ()
{
  int f = 1, g = ~a;
  if (b > f)
{
  e = b; 
  d = b | e; 
  g = 0;
}
  c = 1 % g;
  return 0; 
}

[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||openacc
 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from vries at gcc dot gnu.org ---
Looks similar to PR63979.

[Bug target/68986] [5 Regression] internal compiler error: Segmentation fault

[hjl at gcc dot gnu.org]

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

--- Comment #19 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Feb  1 20:20:56 2016
New Revision: 233046

URL: https://gcc.gnu.org/viewcvs?rev=233046=gcc=rev
Log:
Update preferred stack boundary in ix86_update_stack_boundary

__tls_get_addr must be called with 16-byte aligned stack, which is
guaranted by setting preferred_stack_boundary to 128 bits.  Preferred
stack boundary adjustment for __tls_get_addr should be done in
ix86_update_stack_boundary, not ix86_compute_frame_layout Also
there is no need to over-align stack for __tls_get_addr and function
with __tls_get_addr call isn't a leaf function.

gcc/

Backport from mainline
PR target/68986
* config/i386/i386.c (ix86_compute_frame_layout): Move stack
alignment adjustment to ...
(ix86_update_stack_boundary): Here.  Don't over-align stack nor
change stack_alignment_needed for __tls_get_addr.
(ix86_finalize_stack_realign_flags): Use stack_alignment_needed
if __tls_get_addr is called.

gcc/testsuite/

Backport from mainline
PR target/68986
* gcc.target/i386/pr68986-1.c: New test.
* gcc.target/i386/pr68986-2.c: Likewise.
* gcc.target/i386/pr68986-3.c: Likewise.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-3.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c/69605] New: printf %f on integers

[elmerido at yopmail dot com]

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

Bug ID: 69605
   Summary: printf %f on integers
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elmerido at yopmail dot com
  Target Milestone: ---

#include
int main() {
printf("a= %f \n",3.14);
printf("b= %f \n",200);
return 0;
}

returns :
a= 3.14 
b= 3.14 

Compilation gives warning but still generates the binary :
i.c: In function ‘main’:
i.c:6:2: warning: format ‘%f’ expects argument of type ‘double’, but argument 2
has type ‘int’ [-Wformat=]
  printf("b= %f \n",200);
  ^

[Bug c++/68489] arrays of flexible array members are silently accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from Martin Sebor  ---
Bug 28865 provides useful background on this problem.  GCC (in C mode) used to
accept definitions of initialized array objects of structures with flexible
array members.  That feature was removed in response to bug 28865 which pointed
out that the size of such objects (emitted into the assembly in the form of the
.size directive) is incorrect.  G++ 6.0 suffers from both of these problems
because it accepts definitions of such objects.  Prior versions rejected such
code.

The following test case demonstrates the consequences of this problem:

$ cat t.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -Wall -Wextra -Wpedantic -std=c++11
-xc++ t.c && ./a.out 
struct S { char x; int y []; };

struct S s[2] = {
{ 1, { 2, 3 } },
{ 4, { 5, 6 } }
};

int main (void) {
__builtin_printf ("sizeof s = %zu\n"
  "s[0] @%p = { %hhi, { %i, %i } }\n"
  "s[1] @%p = { %hhi, { %i, %i } }\n",
  sizeof (struct S),
   [0], s[0].x, s[0].y [0], s[0].y [1],
   [1], s[1].x, s[1].y [0], s[1].y [1]);

if (   s [0].x != 1 || s [0].y [0] != 2 || s [0].y [1] != 3
|| s [1].x != 4 || s [1].y [0] != 5 || s [1].y [1] != 6)
__builtin_abort ();
}

t.c:6:1: warning: initialization of a flexible array member [-Wpedantic]
 };
 ^
t.c:6:1: warning: initialization of a flexible array member [-Wpedantic]
t.c: In function ‘int main()’:
t.c:14:61: warning: format ‘%p’ expects argument of type ‘void*’, but argument
3 has type ‘S*’ [-Wformat=]
[1], s[1].x, s[1].y [0], s[1].y [1]);
 ^
t.c:14:61: warning: format ‘%p’ expects argument of type ‘void*’, but argument
7 has type ‘S*’ [-Wformat=]
sizeof s = 4
s[0] @0x601048 = { 1, { 2, 3 } }
s[1] @0x60104c = { 2, { 3, 4 } }
Aborted (core dumped)

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Since the above commit, this bug is just latent, but we should fix it anyway.

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #5 from Bernd Schmidt  ---
Jakub, do you want to look at it or should I assign myself?

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #7 from Bernd Schmidt  ---
Taking it and also hoping it's not in reg-stack.

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
(In reply to Jeffrey A. Law from comment #4)
> With the limiter, the time should come back down into the reasonable range
> and I'm going drop this to a P4 once that change goes in.  However, I'm
> going to keep this open because I think fsm_find_thread_path is horrible in
> the amount of work it duplicates and needs to be rewritten.  

I have another test case that currently seems to take about 17 minutes
with -O2.

Hopefully, this second test case is just a duplicate, but I'll wait until
your change has gone in to test it.

Good work and I look forward to seeing your change.

[Bug libgomp/69607] New: undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

Bug ID: 69607
   Summary: undefined reference to MAIN__._omp_fn.0 in
atomic_capture-1.f with -flto
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

With compiler configured for nvptx offloading, and libgomp run with -flto, we
run into:
...
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
...

In more detail:
...
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0xf8): undefined reference
to `MAIN__._omp_fn.21'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x100): undefined reference
to `MAIN__._omp_fn.20'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x108): undefined reference
to `MAIN__._omp_fn.19'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x110): undefined reference
to `MAIN__._omp_fn.18'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x118): undefined reference
to `MAIN__._omp_fn.17'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x120): undefined reference
to `MAIN__._omp_fn.16'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x128): undefined reference
to `MAIN__._omp_fn.15'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x130): undefined reference
to `MAIN__._omp_fn.14'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x138): undefined reference
to `MAIN__._omp_fn.13'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x140): undefined reference
to `MAIN__._omp_fn.12'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x148): undefined reference
to `MAIN__._omp_fn.11'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x150): undefined reference
to `MAIN__._omp_fn.10'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x158): undefined reference
to `MAIN__._omp_fn.9'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x160): undefined reference
to `MAIN__._omp_fn.8'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x168): undefined reference
to `MAIN__._omp_fn.7'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x170): undefined reference
to `MAIN__._omp_fn.6'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x178): undefined reference
to `MAIN__._omp_fn.5'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x180): undefined reference
to `MAIN__._omp_fn.4'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x188): undefined reference
to `MAIN__._omp_fn.3'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x190): undefined reference
to `MAIN__._omp_fn.2'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x198): undefined reference
to `MAIN__._omp_fn.1'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x1a0): undefined reference
to `MAIN__._omp_fn.0'^M
collect2: error: ld returned 1 exit status^M
...

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #18 from Gerhard Steinmetz  
---
FYI, compiling example from comment 17 together with -flto :


$ gfortran-6 -flto -c pr40737_c17.f90
pr40737_last.f90:23:0: internal compiler error: in get_partitioning_class, at
symtab.c:1794


$ gfortran-5.3.1 -flto -c pr40737_c17.f90
pr40737_last.f90:23:0: internal compiler error: in write_symbol, at
lto-streamer-out.c:2547

[Bug fortran/69604] New: ICE in gfc_add_modify_loc, at fortran/trans.c:159

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69604
   Summary: ICE in gfc_add_modify_loc, at fortran/trans.c:159
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

The following examples together with :

$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]


$ cat z1.f90
program p
   x(n) = n()
   print *, x(n)
end


$ cat z2.f90
program p
   x(n) = n(1.0)
   print *, x(n)
end


$ cat z4.f90
program p
   complex :: z[*]
   real :: x[*]
   z = x / cmplx(0.0, x)


yield :

$ gfortran-6 -c z1.f90
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159


$ gfortran-6 -fcoarray=single -c z4.f90
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159


A previous version gives :

$ gfortran-5.3.1  -c z1.f90
internal compiler error: in conv_function_val, at fortran/trans-expr.c:3489

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

While playing around, one example from ./gcc/testsuite/gfortran.dg/
shows the same error with v6.0.0, but not with v5.3.1 :


$ gfortran-6 -c complex_intrinsic_6.f90
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159


$ gfortran-5 -c complex_intrinsic_6.f90
# no ICE


---

Please correct : last line was cut away for example z4.f90 -- add "end"

[Bug target/68741] FAIL: tr1/8_c_compatibility/cstdio/functions.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Mon Feb  1 20:22:43 2016
New Revision: 233047

URL: https://gcc.gnu.org/viewcvs?rev=233047=gcc=rev
Log:
PR target/68741
* inclhack.def (hpux_vsscanf): New fix.
* fixincl.x: Regenerated.
* tests/base/stdio.h [HPUX_VSSCANF_CHECK]: New test.


Modified:
branches/gcc-5-branch/fixincludes/ChangeLog
branches/gcc-5-branch/fixincludes/inclhack.def
branches/gcc-5-branch/fixincludes/tests/base/stdio.h

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
So for the testcase we've got merge points with huge numbers of predecessors,
which as I mentioned before we dutifully try finding paths through each one.

I instrumented the compiler a bit to see what kind of distribution we see in
this code.  I was interested primarily interested in the number of PHI
arguments, but also the number of threaded paths was recorded.

Not surprisingly, the distribution is heavily skewed towards small numbers of
PHI arguments (ie, 2-5).  The largest PHI in GCC an its shared libraries was on
the order of 256 entries, but it was pretty clear handling cases up to 100
would catch the overwhelming majority of cases.  That also sets the bar at one
order of magnitude lower than what the attached testcase needs to not explode.

In terms of # paths threaded in those big nodes, it tends to be either a bunch
(roughly half) or none.  I didn't investigate the bi-modal nature, though I do
know in the provided testcase the thread paths require memory simplifications
to be able to see the jump thread path.  That means they'll need to be picked
up by the old threader when called from DOM,   DOM threads ~2600 paths, so it
seems to be doing its job.

In general, the number of threaded paths wasn't all that interesting as a
datapoint.

With the limiter, the time should come back down into the reasonable range and
I'm going drop this to a P4 once that change goes in.  However, I'm going to
keep this open because I think fsm_find_thread_path is horrible in the amount
of work it duplicates and needs to be rewritten.  It likely accounts for the
remainder of the compile-time performance issues with this test when compared
to gcc-4.9.

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #6 from Gerhard Steinmetz  
---
When running several private scripts, there was a difference between
some scripts including option -fimplicit-none, and some others that didn't.

Reducing and simplifying gave example z0.f90 from comment 1. Explicitly
including "implicit none" into source then gives first example in comment 0.


> Btw, I don't fully understand why "implicit none" should make any
> difference here.

Me too.


> There is also the very closely related PR54107, which is fixed already.

Now interestingly, compiling examples from ./gcc/testsuite/gfortran.dg/
with an additional -fimplicit-none shows the same error message as above
for these sources :

   automatic_char_len_1.f90
   data_value_1.f90
   init_flag_9.f90
   recursive_interface_1.f90
   recursive_interface_2.f90


$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]

$ gfortran-6 -c recursive_interface_1.f90
# ok

$ gfortran-6 -fimplicit-none -c recursive_interface_1.f90
recursive_interface_1.f90:16:0:

   function baz() result(r3)


internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064

[Bug fortran/69603] [5/6 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
 CC||janus at gcc dot gnu.org
Summary|ICE: segfault with  |[5/6 Regression] ICE:
   |-fimplicit-none and |segfault with
   |proc_ptr_comp_24.f90|-fimplicit-none and
   ||proc_ptr_comp_24.f90
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE occurred between revisions r219318 (2015-01-07, compiles) and r219477
(2015-01-12, ICE), possibly r219439. Reduced test

PROGRAM prog
  implicit none
 TYPE object
  PROCEDURE(), POINTER, NOPASS :: f
 END TYPE object
 TYPE container
  TYPE (object), POINTER :: o(:)
 END TYPE container
 TYPE (container) :: c
 TYPE (object) :: o1, o2
 PROCEDURE(), POINTER :: f => NULL()
 o1%f => f
 CALL set_func(o2,o1%f)
CONTAINS
 SUBROUTINE set_func(o,f)
  TYPE (object) :: o
  PROCEDURE(), POINTER :: f
 END SUBROUTINE set_func
END PROGRAM prog

[Bug target/69146] [5 Regression] ICE in extract_insn, at recog.c:2343 on powerpc64le-linux-gnu

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #4 from kelvin at gcc dot gnu.org ---
The spec for __sync_bool_compare_and_swap can be found at 

  https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html

This states that the first argument may be a pointer to "any integral scalar or
pointer type that is 1, 2, 4 or 8 bytes in length", but acknowledges that
"Intel documentation allows only for the use of the types int, long, long long
as well as their unsigned counterparts."

In discussing implementation options, the "spec" says: "Not all operations are
supported by all target processors. If a particular operation cannot be
implemented on the target processor, a warning will be generated and a call an
external function will be generated. The external function will carry the same
name as the builtin, with an additional suffix `_n' where n is the size of the
data type."

On Power, we would need a different implementation depending on whether the
address of the modified data value is properly aligned.  To use, for example,
the lharx and starx instructions, we would need an assurance that the address
is a multiple of two.  In this case, the compiler can see that it is.

However, there are also situations in which the compiler can see that the
argument is not a multiple of 2, such as the following code, in which case we
would presumably need to generate a call to a helper function rather than emit
in-line code:

  class A {
bool m_fn1();
bool b;
short m_role;
  } __attribute ((packed));
  char a;
  bool A::m_fn1() { __sync_bool_compare_and_swap(_role, -1, a);

And there are situations in which the compiler cannot know for sure whether the
address associated with the first argument is properly aligned, such as:

  char a;
  bool __generic_atomizer(short *sp) {
return __sync_bool_compare_and_swap(sp, -1, a);
  }

In general, the compiler will not "know" that a particular shared data value is
always accessed in the same way by all threads.  That is, some threads may
access the value from contexts that are known to the compiler to be aligned and
other threads may access the same value from contexts that cannot determine the
value to be properly aligned.  So there would need to be some sort of
implementation compatibility between the in-lined implementation and the
function-call implementation.

Maybe this is all obvious to implementers and the details need not be
belabored.  I "feel" the necessity to add this comment because the lack of any
discussion about these issues in the "API specification" leaves me with
concerns that application programmers may not know how to use this API
correctly.

What should happen, for example, with the following source?

  class A {
bool i_fn1();
bool b;
double d;
long int i;
   } __attribute__((packed));
   long int larry;
   bool A::i_fn1() { __sync_bool_compare_and_swap(, -1, larry); }

I would be inclined to prohibit this usage, but there is nothing in the API
description that allows me to do so.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
I wonder when/why it started warning, since -Wlogical-op is not new in GCC 6.

This is just a more complex case of PR61534.

[Bug target/69610] [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 37547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37547=edit
another testcase, fails at -O2

$ armv7a-hardfloat-linux-gnueabi-gcc -O2 -march=armv3 -fno-forward-propagate
testcase.c
...
==19259== Invalid read of size 2
==19259==at 0xEBB91D: arm_reload_in_hi(rtx_def**) (arm.c:15446)
==19259==by 0x1042574: gen_reload_inhi(rtx_def*, rtx_def*, rtx_def*)
(arm.md:6422)
==19259==by 0x9CA5C2: operator() (recog.h:302)
==19259==by 0x9CA5C2: check_and_process_move (lra-constraints.c:1186)
==19259==by 0x9CA5C2: curr_insn_transform(bool) (lra-constraints.c:3453)
==19259==by 0x9CB446: lra_constraints(bool) (lra-constraints.c:4421)
==19259==by 0x9B729C: lra(_IO_FILE*) (lra.c:2277)
==19259==by 0x95EF39: do_reload (ira.c:5394)
==19259==by 0x95EF39: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5565)
==19259==by 0xA70D27: execute_one_pass(opt_pass*) (passes.c:2336)
==19259==by 0xA712D7: execute_pass_list_1(opt_pass*) (passes.c:2410)
==19259==by 0xA712E9: execute_pass_list_1(opt_pass*) (passes.c:2411)
==19259==by 0xA71334: execute_pass_list(function*, opt_pass*)
(passes.c:2421)
==19259==by 0x70D023: cgraph_node::expand() (cgraphunit.c:1975)
==19259==by 0x70E925: expand_all_functions (cgraphunit.c:2111)
==19259==by 0x70E925: symbol_table::compile() (cgraphunit.c:2467)
==19259==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==19259== 
testcase.c: In function 'foo':
testcase.c:28:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug testsuite/65940] g++.dg/other/anon5.C requires dwarf4 support in ld

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Author: uros
Date: Mon Feb  1 22:20:47 2016
New Revision: 233056

URL: https://gcc.gnu.org/viewcvs?rev=233056=gcc=rev
Log:
* g++.dg/other/anon5.C (dg-opetions): Use -gdwarf-2 instead of -g.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/anon5.C

[Bug target/69613] New: [6 Regression] wrong code with -O and simple 128bit arithmetics @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 69613
   Summary: [6 Regression] wrong code with -O and simple 128bit
arithmetics @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Output:
$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233030-checking-yes-rtl-df-nographite-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as
--with-sysroot=/usr/aarch64-unknown-linux-gnu --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233030-checking-yes-rtl-df-nographite-aarch64
Thread model: posix
gcc version 6.0.0 20160201 (experimental) (GCC) 

$ aarch64-unknown-linux-gnu-gcc -O testcase.c
$ ./a.out 
8006
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Tested revisions:
r233030 - FAIL
5-branch r233025 - OK
4_9-branch r233024 - OK
4_8-branch r224828 - OK

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
If __NO_FPRS__ is undefined, that means you are compiling for classic hard 
float.  Which means that the soft-fp code is not needed - if you need to 
keep it in libgcc_s.so for binary compatibility, using t-hardfp for 
hard-float multilibs, as on powerpc*-*-linux*, would be better.

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[amodra at gcc dot gnu.org]

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

--- Comment #13 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 00:01:16 2016
New Revision: 233061

URL: https://gcc.gnu.org/viewcvs?rev=233061=gcc=rev
Log:
[RS6000] ABI_V4 init of toc section

Since 4c4a180d lto has turned off flag_pic when linking a fixed
position executable.  So flag_pic is zero in rs6000_file_start.
However, when we get to actually emitting code, flag_pic may be on
again.  This results in undefined references to ".LCTOC1".

PR target/68662
* config/rs6000/rs6000.c (need_toc_init): New var, set it
whenever toc_label_name used.
(rs6000_file_start): Don't set up toc section here,
(rs6000_output_function_epilogue): do so here instead,
(rs6000_xcoff_file_start): and here.
* config/rs6000/rs6000.md (load_toc_aix_si): Set need_toc_init.
(load_toc_aix_di): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md

[Bug target/69610] New: [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3 -ftree-ter (-O0)

[zsojka at seznam dot cz]

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

Bug ID: 69610
   Summary: [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi
(arm.c:15446) with -march=armv3 -ftree-ter (-O0)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv3-*-linux-gnueabi

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

$ armv7a-hardfloat-linux-gnueabi-gcc -v 
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233030-checking-yes-rtl-df-nographite-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--with-float=hard --with-arch=armv7-a --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as
--with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233030-checking-yes-rtl-df-nographite-armv7a-hardfloat
Thread model: posix
gcc version 6.0.0 20160201 (experimental) (GCC) 

$ armv7a-hardfloat-linux-gnueabi-gcc -march=armv3 -ftree-ter testcase.c
...
==11530== Invalid read of size 2
==11530==at 0xEBB91D: arm_reload_in_hi(rtx_def**) (arm.c:15446)
==11530==by 0x1042574: gen_reload_inhi(rtx_def*, rtx_def*, rtx_def*)
(arm.md:6422)
==11530==by 0x9CA5C2: operator() (recog.h:302)
==11530==by 0x9CA5C2: check_and_process_move (lra-constraints.c:1186)
==11530==by 0x9CA5C2: curr_insn_transform(bool) (lra-constraints.c:3453)
==11530==by 0x9CB446: lra_constraints(bool) (lra-constraints.c:4421)
==11530==by 0x9B729C: lra(_IO_FILE*) (lra.c:2277)
==11530==by 0x95EF39: do_reload (ira.c:5394)
==11530==by 0x95EF39: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5565)
==11530==by 0xA70D27: execute_one_pass(opt_pass*) (passes.c:2336)
==11530==by 0xA712D7: execute_pass_list_1(opt_pass*) (passes.c:2410)
==11530==by 0xA712E9: execute_pass_list_1(opt_pass*) (passes.c:2411)
==11530==by 0xA71334: execute_pass_list(function*, opt_pass*)
(passes.c:2421)
==11530==by 0x70D023: cgraph_node::expand() (cgraphunit.c:1975)
==11530==by 0x70DF67: output_in_order(bool) (cgraphunit.c:2213)
==11530==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==11530== 
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This happens only at -O0.

Tested revisions:
trunk r233030 - ICE
5-branch r233025 - ICE
4_9-branch r233024 - OK
4_[876]-branch - OK

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[felix.abecassis at gmail dot com]

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

Felix Abecassis  changed:

   What|Removed |Added

 CC||felix.abecassis at gmail dot 
com

--- Comment #4 from Felix Abecassis  ---
Confirmed again with gcc 5.3.1 on Ubuntu 16.04.
I reused the same test case than Melissa.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
Since EAGAIN and EWOULDBLOCK probably expand from a macro to a constant (or are
they enums? do we track the original form of the enum or only the underlying
value?), this is as hard as:

extern int xxx;
#define XXX xxx
int test (void)
{
  if (!XXX && xxx)
return 4;
  else
return 0;
}

thus, if this is not a regression caused by something else, it is a duplicate.

[Bug c/69609] New: block reordering consumes an inordinate amount of time

[dcb314 at hotmail dot com]

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

Bug ID: 69609
   Summary: block reordering consumes an inordinate amount of time
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 37545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37545=edit
gzipped C source code

The attached code, when compiled by trunk gcc 6.0.0,
with flag -O2, seems to take about 17 minutes.

gcc 5.3.1 seems to take about 16 minutes for the same code.

In a private email, Jeffery Law says: 
>I do note that test is spending most of its time (90%) in block
>reordering, so you might want to go ahead and file it

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Mon Feb  1 22:03:57 2016
New Revision: 233053

URL: https://gcc.gnu.org/viewcvs?rev=233053=gcc=rev
Log:
PR tree-optimization/68580
* params.def (FSM_MAXIMUM_PHI_ARGUMENTS): New param.
* tree-ssa-threadbackward.c
(fsm_find_control_statement_thread_paths): Do not try to walk
through large PHI nodes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def
trunk/gcc/tree-ssa-threadbackward.c

[Bug preprocessor/69543] [6 Regression] _Pragma does not apply within macro

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb  1 22:36:07 2016
New Revision: 233058

URL: https://gcc.gnu.org/viewcvs?rev=233058=gcc=rev
Log:
PR preprocessor/69543
PR c/69558
* c-pragma.c (handle_pragma_diagnostic): Pass input_location
instead of loc to control_warning_option.

* gcc.dg/pr69543.c: New test.
* gcc.dg/pr69558.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69543.c
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog

[Bug c/69612] New: Optimizer does not consider overflow

[roarl at pvv dot org]

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

Bug ID: 69612
   Summary: Optimizer does not consider overflow
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roarl at pvv dot org
  Target Milestone: ---

I found a short code snippet that produces different results after optimizing
with -O2. I believe my code should work as it only uses a simple test to check
if incrementation has overflowed. It looks like the optimizer, having
established that a variable is >= 0, does not believe the variable can become <
0 after incrementing. However, I am relying on just that to catch the overflow.

In the code below, the __attribute__((noinline)) is not necessary to
demonstrate the "effect", however without it the "test" routine would have to
reside in another compilation unit.

% cat bug.c
int __attribute__((noinline)) test(int a) {
if (a < 0)
return 1;
a++;
if (a < 0) // gcc -O2 thinks this can't happen, since a>=0 from above
return 2;
return a;
}

#include 
int main()
{
printf("%d\n", test(0x7FFF));
}

% gcc bug.c -o bug
% ./bug
2
% gcc -O2 bug.c -o bug
% ./bug
-2147483648
% gcc --version
gcc (SUSE Linux) 5.2.1 20151008 [gcc-5-branch revision 228597]
...

[Bug c/69558] [6 Regression] glib2 warning pragmas stopped working

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb  1 22:36:07 2016
New Revision: 233058

URL: https://gcc.gnu.org/viewcvs?rev=233058=gcc=rev
Log:
PR preprocessor/69543
PR c/69558
* c-pragma.c (handle_pragma_diagnostic): Pass input_location
instead of loc to control_warning_option.

* gcc.dg/pr69543.c: New test.
* gcc.dg/pr69558.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69543.c
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/69611] New: Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[andreast at gcc dot gnu.org]

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

Bug ID: 69611
   Summary: Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit
floating point support.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreast at gcc dot gnu.org
  Target Milestone: ---

PowerPC FreeBSD does not support 128-bit floating point yet.

Bootstrap on this target is broken because of undefined references to
__sfp_handle_exceptions.

We build gcc with softfp for our 32-bit embedded targets.
Now the the sfp-machine.h is included even in the non 128-bit t-float128 case.
The definition of the __sfp_handle_exceptions is done in the mentioned header
file while the implementation is done in the sfp-exceptions.c which is only
built when 128-bit float is supported.

To fix this issue we propose to guard the affected region in sfp-machine.h with
this:

Index: config/rs6000/sfp-machine.h
===
--- config/rs6000/sfp-machine.h (revision 233015)
+++ config/rs6000/sfp-machine.h (working copy)
@@ -110,7 +110,7 @@
floating point on pre-ISA 3.0 machines without the IEEE 128-bit floating
point support.  */

-#ifndef __NO_FPRS__
+#if defined(__FLOAT128__)
 #define ISA_BIT(x) (1LL << (63 - x))

 /* Use the same bits of the FPSCR.  */
@@ -151,7 +151,7 @@
   } while (0)

 # define FP_ROUNDMODE  (_fpscr & FP_RND_MASK)
-#endif /* !__NO_FPRS__ */
+#endif /* __FLOAT128__ */

I discussed this with Michael Meissner on #irc. He agrees on this approach.
I'm running a bootstrap and will provide test results from FreeBSD PowerPC
asap.

I'd appreciate a testrun on a GNU/Linux target. I do not have such a setup yet.

TIA,
Andreas

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #7 from Jeffrey A. Law  ---
Major regression resolved.  There's still some work to do, as outlined in the
BZ and in the post for the patch, so keeping this open as  P4.

[Bug rtl-optimization/69592] [6 Regression] Compile-time and memory-use hog in combine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |7.0
Summary|[6 Regression] glib2|[6/7 Regression] glib2
   |warning pragmas stopped |warning pragmas stopped
   |working |working

--- Comment #13 from Jakub Jelinek  ---
Workaround applied, keeping this open to fix it for real for GCC 7.

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|6.0 |7.0
Summary|[6 Regression] _Pragma does |[6/7 Regression] _Pragma
   |not apply within macro  |does not apply within macro

--- Comment #4 from Jakub Jelinek  ---
Workaround applied, keeping this open to fix it for real for GCC 7.

[Bug libstdc++/69608] New: strsteambuf copy ctor and assignment inaccessible

[msebor at gcc dot gnu.org]

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

Bug ID: 69608
   Summary: strsteambuf copy ctor and assignment inaccessible
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As far as I can see, the C++ standard doesn't prevent the copying of
strstreambuf objects.  With the resolution of issue 421 these copies should
have (almost) well-defined semantics.  But the following program fails to
compile with the latest libstdc++.

That said, I'm not sure it's a good idea for the standard to require
implementations to accept the program.  If it did, it seems that the two copies
would share the same underlying character buffer (courtesy of issue 421). 
Accessing the buffer in the copy would be undefined after the copied
strstreambuf object was destroyed.  If this hasn't been discussed in LWG yet it
might be worth bringing it up.  strstreambuf may be deprecated but the same
concern applies to similar user-defined classes that publicly derive from
basic_streambuf and expose an accsible copy ctor or assignment operator of
their own.

$ cat t.cpp && /home/msebor/build/gcc-trunk-bootstrap/gcc/xg++
-B/home/msebor/build/gcc-trunk-bootstrap/gcc -S ... t.cpp
#include 

int main ()
{
std::strstreambuf a;
a = std::strstreambuf (32);
}

In file included from
/src/gcc/trunk/libstdc++-v3/include/backward/strstream:50:0,
 from t.cpp:1:
/src/gcc/trunk/libstdc++-v3/include/backward/backward_warning.h:32:2: warning:
#warning This file includes at least one deprecated or antiquated header which
may be removed without further notice at a future date. Please use a
non-deprecated interface with equivalent functionality instead. For a listing
of replacement headers and interfaces, consult the file backward_warning.h. To
disable this warning use -Wno-deprecated. [-Wcpp]
t.cpp: In function ‘int main()’:
t.cpp:6:30: error: ‘std::strstreambuf& std::strstreambuf::operator=(const
std::strstreambuf&)’ is private within this context
In file included from t.cpp:1:0:
/src/gcc/trunk/libstdc++-v3/include/backward/strstream:102:5: note: declared
private here

[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -mavx and 128bit arithmetics since r215450

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
IMO, we should revert r215450, and fix a couple of cases using narrowing
conversions with gen_lowpart that were introduced after r215450.

Something like:

--cut here--
Index: i386.c
===
--- i386.c  (revision 233041)
+++ i386.c  (working copy)
@@ -43276,7 +43276,7 @@
  be dropped leaving a plain DImode store.  This is indistinguishable
  from a "normal" DImode move, and so we're justified to use movsd,
  which modifies the entire 128-bit register.  */
-  if (to_size == UNITS_PER_WORD && from_size > UNITS_PER_WORD)
+  if (to_size < from_size)  
return true;
 }

Index: sse.md
===
--- sse.md  (revision 233041)
+++ sse.md  (working copy)
@@ -17291,12 +17291,12 @@
&& reload_completed && GENERAL_REG_P (operands[1])"
   [(const_int 0)]
 {
-  emit_insn (gen_vec_setv4si_0 (gen_lowpart (V4SImode, operands[0]),
+  emit_insn (gen_vec_setv4si_0 (gen_rtx_REG (V4SImode, REGNO (operands[0])),
CONST0_RTX (V4SImode),
gen_lowpart (SImode, operands[1])));
   emit_insn (gen_avx2_pbroadcast (operands[0],
-   gen_lowpart (mode,
-operands[0])));
+   gen_rtx_REG (mode,
+REGNO (operands[0];
   DONE;
 })

--cut here--

Please note that sse.md uses constructs like:

op1 = gen_rtx_REG (mode, REGNO (op1));

to generate narrowing conversions involving SSE regs before the mentioned
revision.

[Bug testsuite/65940] g++.dg/other/anon5.C requires dwarf4 support in ld

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #3 from Uroš Bizjak  ---
Fixed.

[Bug rtl-optimization/69592] [6 Regression] Compile-time and memory-use hog in combine

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb  1 22:39:31 2016
New Revision: 233059

URL: https://gcc.gnu.org/viewcvs?rev=233059=gcc=rev
Log:
PR rtl-optimization/69592
* rtlanal.c (nonzero_bits_binary_arith_p): New inline function.
(cached_nonzero_bits): Use it instead of ARITHMETIC_P.
(num_sign_bit_copies_binary_arith_p): New inline function.
(cached_num_sign_bit_copies): Use it instead of ARITHMETIC_P.

* gcc.dg/pr69592.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69592.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). The type of ICE seems to depend of the
use of --enable-checking=release during configure.

[Bug target/69610] [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Looks like a dup.
Feel free to add the testcase to PR 62254 as it is quite small

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

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #6 from ktkachov at gcc dot gnu.org ---
*** Bug 69610 has been marked as a duplicate of this bug. ***

[Bug c/69612] Optimizer does not consider overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
This program triggers undefined behavior.
You can e.g. use -fsanitize=undefined to see it diagnosed at runtime.
Once undefined behavior is reached, anything can happen.

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
I have patches fixing the two issues but when I started to test the patches I
found that LRA actually has >800 additional failures on power8 in comparison
with reload.  So I am going to look at this and try to fix this.

[Bug rtl-optimization/69606] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-02
 CC||rguenther at suse dot de
Version|6.0 |5.3.1
   Target Milestone|--- |5.4
Summary|wrong code at -Os and above |[5/6 Regression] wrong code
   |on x86_64-linux-gnu |at -Os and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It was caused by r220164.

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 01:29:58 2016
New Revision: 233067

URL: https://gcc.gnu.org/viewcvs?rev=233067=gcc=rev
Log:
[RS6000] lqarx and stqcx. registers

lqarx RT and stqcx. RS are valid only with even numbered gprs.  The
predicate to enforce this happens to allow a loophole, closed by this
patch.

PR target/69548
gcc/
* config/rs6000/predicates.md (quad_int_reg_operand): Don't
allow subregs.
gcc/testsuite/
* gcc.target/powerpc/pr69548.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr69548.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/predicates.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gcc dot gnu.org]

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

--- Comment #3 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 01:29:41 2016
New Revision: 233066

URL: https://gcc.gnu.org/viewcvs?rev=233066=gcc=rev
Log:
[RS6000] lqarx and stqcx. registers

lqarx RT and stqcx. RS are valid only with even numbered gprs.  The
predicate to enforce this happens to allow a loophole, closed by this
patch.

PR target/69548
gcc/
* config/rs6000/predicates.md (quad_int_reg_operand): Don't
allow subregs.
gcc/testsuite/
* gcc.target/powerpc/pr69548.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr69548.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/predicates.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gcc dot gnu.org]

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

--- Comment #2 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 01:29:17 2016
New Revision: 233065

URL: https://gcc.gnu.org/viewcvs?rev=233065=gcc=rev
Log:
[RS6000] lqarx and stqcx. registers

lqarx RT and stqcx. RS are valid only with even numbered gprs.  The
predicate to enforce this happens to allow a loophole, closed by this
patch.

PR target/69548
gcc/
* config/rs6000/predicates.md (quad_int_reg_operand): Don't
allow subregs.
gcc/testsuite/
* gcc.target/powerpc/pr69548.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr69548.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.4

--- Comment #5 from Alan Modra  ---
Fixed all active branches

[Bug lto/67548] [5 Regression] LTO drops weak binding with "ld -r"

[amodra at gmail dot com]

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

Bug 68662 Summary: [6 regression] FAIL: gcc.dg/lto/20090210 
c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none 
-fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662

   What|Removed |Added

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

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #14 from Alan Modra  ---
Fixed with workaround. 
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg2.html queued for gcc-7 and
6.1.

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  ---
With the proposed patch, power8 little endian bootstraps fine, and builds the
software floating point emulator and runs the code fine.  I also checked the
power9 generation of hardware __float128 instructions, and it generates the
appropriate instructions.

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|accepts-invalid |
   Last reconfirmed|2014-10-16 00:00:00 |2016-2-1
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
All supported versions of GCC, including the current trunk of 6.0, have the
problem.  The test case seems strictly valid, though, so removing the
accepts-invalid keyword.

[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics @ aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/69614] New: [6 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[zsojka at seznam dot cz]

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

Bug ID: 69614
   Summary: [6 Regression] wrong code with -Os
-fno-expensive-optimizations -fschedule-insns
-mtpcs-leaf-frame -fira-algorithm=priority @ armv7a
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

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

Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -v 
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233030-checking-yes-rtl-df-nographite-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--with-float=hard --with-arch=armv7-a --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as
--with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233030-checking-yes-rtl-df-nographite-armv7a-hardfloat
Thread model: posix
gcc version 6.0.0 20160201 (experimental) (GCC) 

$ armv7a-hardfloat-linux-gnueabi-gcc -Os -fno-expensive-optimizations
-fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority testcase.c
testcase.c:1:0: warning: enabling backtrace support is only meaningful when
compiling for the Thumb
 typedef unsigned short u16;
$ ./a.out 
00020002
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Triggering a wrong code at the arm target takes a lot of time, and even then,
the testcase is not very minimal and there are quite many extra compiler flags.

Tested revisions:
r233030 - FAIL
5-branch r233025 - OK
4_9-branch r233024 - OK
4_8-branch r224828 - OK

[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/69613] [6 Regression] wrong code with -O and simple 128bit arithmetics and vectors @ aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|6.0 |---
Summary|[6 Regression] wrong code   |[6 Regression] wrong code
   |with -O and simple 128bit   |with -O and simple 128bit
   |arithmetics @ aarch64   |arithmetics and vectors @
   ||aarch64

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb  1 08:47:27 2016
New Revision: 233033

URL: https://gcc.gnu.org/viewcvs?rev=233033=gcc=rev
Log:
PR rtl-optimization/69570
* ifcvt.c (bb_ok_for_noce_convert_multiple_sets): Return true only
if there is more than one set, not if there is a single set.

* g++.dg/opt/pr69570.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr69570.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #22 from Jakub Jelinek  ---
Confirmed fixed.

[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69574] [4.9/5/6 Regression] gcc ICE at -O2 and -O3 on x86_64-linux-gnu in hide_evolution_in_other_loops_than_loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug c++/69564] lto and/or C++ make scimark2 LU slower

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto, missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|lto |c++
Summary|lto makes scimark2 LU   |lto and/or C++ make
   |slower  |scimark2 LU slower
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Any reason you are using the c++ driver here?

I get

> gcc-6 -Ofast -flto *.c -lm -B /abuild/rguenther/trunk3-g/gcc
> ./a.out 
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score: 1729.02
FFT Mflops:  1247.04(N=1024)
SOR Mflops:  1537.70(100 x 100)
MonteCarlo: Mflops:   842.21
Sparse matmult  Mflops:  1657.86(N=1000, nz=5000)
LU  Mflops:  3360.29(M=100, N=100)

> gcc-6 -Ofast  *.c -lm -B /abuild/rguenther/trunk3-g/gcc
> ./a.out 
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score: 1645.94
FFT Mflops:  1288.61(N=1024)
SOR Mflops:  1471.29(100 x 100)
MonteCarlo: Mflops:   459.90
Sparse matmult  Mflops:  1665.91(N=1000, nz=5000)
LU  Mflops:  3343.98(M=100, N=100)


Ok, when using g++ to compile things I _do_ get

> g++-6 -Ofast -flto *.c -lm -B /abuild/rguenther/trunk3-g/gcc
> ./a.out 
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score: 1321.43
FFT Mflops:  1261.86(N=1024)
SOR Mflops:  1533.77(100 x 100)
MonteCarlo: Mflops:   850.69
Sparse matmult  Mflops:  1669.90(N=1000, nz=5000)
LU  Mflops:  1290.93(M=100, N=100)

> g++-6 -Ofast  *.c -lm -B /abuild/rguenther/trunk3-g/gcc
> ./a.out 
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score: 1492.12
FFT Mflops:  1279.12(N=1024)
SOR Mflops:  1479.86(100 x 100)
MonteCarlo: Mflops:   433.83
Sparse matmult  Mflops:  1637.11(N=1000, nz=5000)
LU  Mflops:  2630.71(M=100, N=100)

So even without LTO I get a hit in using C++ to compile LU.  Interesting.

[Bug tree-optimization/69588] [4.9 Regression] ICE: tree check: expected ssa_name, have var_decl in unlink_stmt_vdef, at tree-ssa-operands.c:1314

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug testsuite/69590] New: Test script tries to compile source code with "-mthumb" option when running test gcc.dg/binop-xor1.c for powerpc64

[tiago.brusamarello at datacom dot ind.br]

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

Bug ID: 69590
   Summary: Test script tries to compile source code with
"-mthumb" option when running test gcc.dg/binop-xor1.c
for powerpc64
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tiago.brusamarello at datacom dot ind.br
  Target Milestone: ---

When running the test suite for powerpc64 the "gcc.dg/binop-xor1.c" test fails
with the following output:

Executing on host: powerpc64-unknown-linux-gnu-gcc
/opt/x-tools/powerpc64-unknown-linux-gnu_v1.0/test-suite/gcc/testsuite/gcc.dg/binop-xor1.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -O2
-fdump-tree-optimized -S  -o binop-xor1.s(timeout = 300)
spawn powerpc64-unknown-linux-gnu-gcc
/opt/x-tools/powerpc64-unknown-linux-gnu_v1.0/test-suite/gcc/testsuite/gcc.dg/binop-xor1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-optimized
-S -o binop-xor1.s
PASS: gcc.dg/binop-xor1.c (test for excess errors)
Executing on host: powerpc64-unknown-linux-gnu-gcc arm_cortex_m19028.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -mthumb -S  -o
arm_cortex_m19028.s(timeout = 300)
spawn powerpc64-unknown-linux-gnu-gcc arm_cortex_m19028.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mthumb -S -o
arm_cortex_m19028.s
powerpc64-unknown-linux-gnu-gcc: error: unrecognized command line option
'-mthumb'
compiler exited with status 1
output is:
powerpc64-unknown-linux-gnu-gcc: error: unrecognized command line option
'-mthumb'
FAIL: gcc.dg/binop-xor1.c scan-tree-dump-times optimized "\\^" 1

It seems that the test suite is trying to compile code for ARM with a PPC64
compiler.

[Bug tree-optimization/69588] [4.9 Regression] ICE: tree check: expected ssa_name, have var_decl in unlink_stmt_vdef, at tree-ssa-operands.c:1314

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
  Known to work||4.8.5, 5.3.0, 6.0
   Target Milestone|--- |4.9.4
Summary|ICE: tree check: expected   |[4.9 Regression] ICE: tree
   |ssa_name, have var_decl in  |check: expected ssa_name,
   |unlink_stmt_vdef, at|have var_decl in
   |tree-ssa-operands.c:1314|unlink_stmt_vdef, at
   ||tree-ssa-operands.c:1314
 Ever confirmed|0   |1
  Known to fail||4.9.3

--- Comment #1 from Richard Biener  ---
Confirmed on the 4.9 branch, doesn't reproduce on the GCC 5 branch or trunk,
works in 4.8.  We likely have a duplicate for this.

t.ii:19:1: internal compiler error: tree check: expected ssa_name, have
var_decl in unlink_stmt_vdef, at tree-ssa-operands.c:1314
 }
 ^
0x106490e tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree.c:9197
0x5e60c1 tree_check(tree_node*, char const*, int, char const*, tree_code)
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree.h:2724
0xf3aca4 unlink_stmt_vdef(gimple_statement_base*)
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-ssa-operands.c:1314
0xe10aa8 optimize_clobbers
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-eh.c:3449
0xe13521 cleanup_empty_eh
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-eh.c:4415
0xe13a44 cleanup_all_empty_eh
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-eh.c:4546
0xe13aca execute_cleanup_eh_1
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-eh.c:4576
0xe13b1a execute_cleanup_eh
/space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-eh.c:4601

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/69564] lto and/or C++ make scimark2 LU slower

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
It looks like we get different BB order out of C++ than C but otherwise no real
code-differences as far as I can see.

[Bug c++/69564] lto and/or C++ make scimark2 LU slower

[vincenzo.innocente at cern dot ch]

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

--- Comment #5 from vincenzo Innocente  ---
it is a regression 
gcc version 4.9.3 (GCC) 
c++ -Ofast *.c; ./a.out
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
gcc -Ofast *.c; ./a.out
c++ -v
Composite Score: 2449.06
FFT Mflops:  2046.03(N=1024)
SOR Mflops:  1654.04(100 x 100)
MonteCarlo: Mflops:   813.44
Sparse matmult  Mflops:  2962.08(N=1000, nz=5000)
LU  Mflops:  4769.72(M=100, N=100)
---
gcc -Ofast *.c -lm; ./a.out
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score: 2475.22
FFT Mflops:  2064.19(N=1024)
SOR Mflops:  1633.01(100 x 100)
MonteCarlo: Mflops:   810.37
Sparse matmult  Mflops:  2970.47(N=1000, nz=5000)
LU  Mflops:  4898.06(M=100, N=100)

[Bug tree-optimization/69184] [6 Regression] ICE in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2685

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Smaller testcase for -Ofast -floop-interchange on aarch64:
int a, b, c, e, f, g;
int d[1];
static int *h = 
long i;

int
fn1 (short p1)
{
  return p1 + a;
}

void
fn2 ()
{
  for (; f; f++)
{
  int *j = 
  e = 1;
  for (; e; e++)
{
  i = b ?: b;
  *j ^= fn1 (d[e]);
  if (*h)
break;
}
}
}

[Bug other/69582] [meta-bug] Cilk+

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
36 open items on the list.

[Bug c++/69564] lto and/or C++ make scimark2 LU slower

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  ---
> Any reason you are using the c++ driver here?
Because I am interested in C++ performance
never imagined that the c++ front-end could make a difference on such a code...
>From my point of view it is even a more severe regression than just "lto"

[Bug c++/69564] lto and/or C++ make scimark2 LU slower

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
(In reply to vincenzo Innocente from comment #3)
> > Any reason you are using the c++ driver here?
> Because I am interested in C++ performance
> never imagined that the c++ front-end could make a difference on such a
> code...
> From my point of view it is even a more severe regression than just "lto"

Yeah, didn't try to figure out whether the C vs. C++ thing is a 
regression.  But I suspect the change to the C++ loop lowering.

Certainly needs closer investigation.

[Bug c/69578] -Wuninitialized not issuing warning.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
It does if you enable -O1 (but not with -O0 or -O2+)

[Bug libstdc++/69581] [6 Regression] r232586 broke arm-cross-compiler bootstrap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-01
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
Oops, yes, the guards should not get defined when including the header in
"pass-through" mode where it just does #include_next

[Bug tree-optimization/69574] [4.9/5/6 Regression] gcc ICE at -O2 and -O3 on x86_64-linux-gnu in hide_evolution_in_other_loops_than_loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
So we try to instantiate

{(unsigned char) d_lsm.14_51, +, 255}_4

in _4s outer loop where _51 is defined on the exit edge of an inner loop of a
preceeding sibling loop of 4 ({0, +, 255}_2).

So somehow instantiation misses to replace that with the "overall effect" of
that loop.  When trying to build the above polynomial chrec we then reach

140   if (!no_evolution_in_loop_p (left, loop_num, )
141   || !val)
142 return chrec_dont_know;

which does

static inline bool
no_evolution_in_loop_p (tree chrec, unsigned loop_num, bool *res)
{
  tree scev;

  if (chrec == chrec_not_analyzed_yet
  || chrec == chrec_dont_know
  || chrec_contains_symbols_defined_in_loop (chrec, loop_num))
return false;

  STRIP_NOPS (chrec);
  scev = hide_evolution_in_other_loops_than_loop (chrec, loop_num);
  *res = !tree_contains_chrecs (scev, NULL);
  return true;

and

tree
hide_evolution_in_other_loops_than_loop (tree chrec,
 unsigned loop_num)
{
  struct loop *loop = get_loop (cfun, loop_num), *chloop;
  if (automatically_generated_chrec_p (chrec))
return chrec;

  switch (TREE_CODE (chrec))
{
case POLYNOMIAL_CHREC:
  chloop = get_chrec_loop (chrec);

  if (chloop == loop)
return build_polynomial_chrec
  (loop_num,
   hide_evolution_in_other_loops_than_loop (CHREC_LEFT (chrec),
loop_num),
   CHREC_RIGHT (chrec));

  else if (flow_loop_nested_p (chloop, loop))
/* There is no evolution in this loop.  */
return initial_condition (chrec);

  else
{
  gcc_assert (flow_loop_nested_p (loop, chloop));
  return hide_evolution_in_other_loops_than_loop (CHREC_LEFT (chrec),
  loop_num);

which asserts this kind of "nesting" doesn't happen.

One way to "paper over" this issue is doing the following though it might
be that the problem lies further up and we shouldn't call this function
in this particular way.

Index: tree-chrec.c
===
--- tree-chrec.c(revision 233033)
+++ tree-chrec.c(working copy)
@@ -728,12 +728,12 @@ hide_evolution_in_other_loops_than_loop
/* There is no evolution in this loop.  */
return initial_condition (chrec);

+  else if (flow_loop_nested_p (loop, chloop))
+   return hide_evolution_in_other_loops_than_loop (CHREC_LEFT (chrec),
+   loop_num);
+
   else
-   {
- gcc_assert (flow_loop_nested_p (loop, chloop));
- return hide_evolution_in_other_loops_than_loop (CHREC_LEFT (chrec),
- loop_num);
-   }
+   return chrec_dont_know;

 default:
   return chrec;

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc*-*-*|powerpc*-*-*, aarch64
 Status|RESOLVED|REOPENED
   Keywords||wrong-code
   Last reconfirmed||2016-02-01
 CC||ktkachov at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1
Summary|spec2006 test case  |[6 Regression] spec2006
   |416.gamess fails with the   |test case 416.gamess fails
   |g++ 6.0 compiler starting   |with the g++ 6.0 compiler
   |with r232508|starting with r232508
   Target Milestone|--- |6.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Reopening at Wilco's request

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
I fixed my reduction script, now reducing about ~14MB of pre-processed source
files.

[Bug tree-optimization/69579] [4.9/5/6 Regression] gcc ICE at -O3 and __sigsetjmp with “tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases”

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|6.0 |4.9.4

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

[Bug tree-optimization/69588] New: ICE: tree check: expected ssa_name, have var_decl in unlink_stmt_vdef, at tree-ssa-operands.c:1314

[moltonel at gmail dot com]

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

Bug ID: 69588
   Summary: ICE: tree check: expected ssa_name, have var_decl in
unlink_stmt_vdef, at tree-ssa-operands.c:1314
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moltonel at gmail dot com
  Target Milestone: ---

Originally filed downstream at https://bugs.gentoo.org/show_bug.cgi?id=568260

I did my best to check for duplicates but this is my first foray into the gcc
bugzilla and I'm a bit overwhelmed.


template  class error_info {
public:
  typedef T value_type;
  error_info(value_type const &);
  ~error_info() throw();
};

template  void operator<<(E, error_info);
int a;
void vfork();
template 
error_info::error_info(value_type const &) {}

template  error_info::~error_info() throw() {}

void Run() {
  error_info("") << error_info(a);
  vfork();
}



$ /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -fPIC -c reduced.cpp -o reduced.o
reduced.cpp: In function ‘void Run()’:
reduced.cpp:17:29: warning: deprecated conversion from string constant to
‘error_info::value_type {aka char*}’ [-Wwrite-strings]
   error_info("") << error_info(a);
 ^
reduced.cpp:19:1: internal compiler error: tree check: expected ssa_name, have
var_decl in unlink_stmt_vdef, at tree-ssa-operands.c:1314
 }
 ^

[Bug ipa/69589] New: [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[marxin at gcc dot gnu.org]

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

Bug ID: 69589
   Summary: [6 Regression] ICE in initialize_node_lattices, at
ipa-cp.c:971
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

Following ICE comes from Firefox test-suite, I was able to reduce the number of
pre-processed source files to 3 to expose the internal compiler error.

$ c++ -flto -O2 -rdynamic Unified_cpp_js_src*.ii
lto1: internal compiler error: in initialize_node_lattices, at ipa-cp.c:971
0x113c6c8 initialize_node_lattices
../../gcc/ipa-cp.c:971
0x113c6c8 ipcp_propagate_stage
../../gcc/ipa-cp.c:2927
0x113da3c ipcp_driver
../../gcc/ipa-cp.c:4606
0x113da3c execute
../../gcc/ipa-cp.c:4698

Source files:
https://drive.google.com/file/d/0B0pisUJ80pO1SWtLUnNVQkZwZFU/view?usp=sharing

I tried to reduce it with creduce (now having capability to reduce multiple
files), but it does not process any simplification.

Thanks,
Martin

[Bug tree-optimization/69368] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #2 from Wilco  ---
This still fails on AArch64 in exactly the same way with latest trunk - can
someone reopen this? I don't seem to have the right permissions...

[Bug tree-optimization/69588] [4.9 Regression] ICE: tree check: expected ssa_name, have var_decl in unlink_stmt_vdef, at tree-ssa-operands.c:1314

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
This was fixed in

commit 977e64ea305887b145a89901387242702718f0ab
Author: jason 
Date:   Wed Jul 30 17:27:14 2014 +

PR lto/53808
PR c++/61659
* pt.c (push_template_decl_real): Set DECL_COMDAT on templates.
(check_explicit_specialization): Clear it on specializations.
* decl.c (duplicate_decls, start_decl): Likewise.
(grokmethod, grokfndecl): Set DECL_COMDAT on inlines.
* method.c (implicitly_declare_fn): Set DECL_COMDAT.  Determine
linkage after setting the appropriate flags.
* tree.c (decl_linkage): Don't check DECL_COMDAT.
* decl2.c (mark_needed): Mark clones.
(import_export_decl): Not here.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213307
138bc75d-0d04-0410-961f-82ee72b054a4

gcc5 and gcc6 are ok.

[Bug c/69602] [6 Regresion] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0
Summary|over-ambitious logical-op   |[6 Regresion]
   |warning on EAGAIN vs|over-ambitious logical-op
   |EWOULDBLOCK |warning on EAGAIN vs
   ||EWOULDBLOCK

[Bug testsuite/69586] [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-01
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
Summary|FAIL: gcc.dg/uninit-21.c|[6 Regression] FAIL:
   |for target defaulting to|gcc.dg/uninit-21.c for
   |short enum  |target defaulting to short
   ||enum
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I will have a looksee.

[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug c/69591] New: gcc.dg/and-1.c scan-assembler-not nand fails on powerpc64-linux-gnu

[tiago.brusamarello at datacom dot ind.br]

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

Bug ID: 69591
   Summary: gcc.dg/and-1.c scan-assembler-not nand fails on
powerpc64-linux-gnu
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tiago.brusamarello at datacom dot ind.br
  Target Milestone: ---

Besides being resolved by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33512,
it still happens in 4.9.1 for powerpc64-linux-gnu:

Executing on host: powerpc64-unknown-linux-gnu-gcc
/opt/x-tools/powerpc64-unknown-linux-gnu_v1.0/test-suite/gcc/testsuite/gcc.dg/and-1.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -S  -o and-1.s   
(timeout = 300)
spawn powerpc64-unknown-linux-gnu-gcc
/opt/x-tools/powerpc64-unknown-linux-gnu_v1.0/test-suite/gcc/testsuite/gcc.dg/and-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o and-1.s
PASS: gcc.dg/and-1.c (test for excess errors)
PASS: gcc.dg/and-1.c scan-assembler and
FAIL: gcc.dg/and-1.c scan-assembler-not nand

Assembler output:

.file   "and-1.c"
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl f
.section".opd","aw"
.align 3
f:
.quad   .L.f,.TOC.@tocbase,0
.previous
.type   f, @function
.L.f:
neg 9,3
nand 9,9,3
and 3,9,3
extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   f,.-.L.f
.ident  "GCC: (crosstool-NG 1.20.0) 4.9.1"

[Bug fortran/69554] [6 Regression] Multi-location diagnostics writes too many lines

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez  ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Manuel López-Ibáñez from comment #7)
> > Please take this as a humble general suggestion: Fortran maintainers should
> > enforce during patch review that any new diagnostic has a corresponding
> > testcase triggering it in the testsuite.
> 
> I think you are right, on general principles.  We usually try this.
> You can get a lot of test cases testing for runtime errors, because
> you can only test for a single error with each test case...

I don't know much about Fortran, but in C/C++, the parser tries to continue
after an error, even if it has to skip whole functions. Thus, putting errors
into different dummy functions allows testing many errors per file.

> However, this would not have helped in this case.  The problem here
> was that the testsuite is lenient enough to allow for random
> junk to appear between two error messages (which is understandable,
> given that we only want to check for the particular error messages,
> and there is a lot of stuff in between), that nobody thought of this
> particular case (it only came to light when I wanted to test a new
> error message with two locations).

The code here should collapse those multi-line errors into:

https://sourceware.org/svn/gcc/trunk/gcc/testsuite/lib/gfortran-dg.exp

#  [name]:[line]: Error: Some error at (1) and (2)
#  [name]:[line2]: Error: Some error at (1) and (2)

Unless there are two location lines, the test will (should, otherwise there is
a bug) fail. In my testsuite log of r230753, there is not a single test for
this error. Such a testcase would have detected this bug.

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[sbergman at redhat dot com]

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

--- Comment #24 from Stephan Bergmann  ---
(In reply to Manuel López-Ibáñez from comment #23)
> That is weird. If you use "GCC diagnostic warning" instead of "ignored", you
> should be able to see some changes in locations between -O0 and -O1 and
> before/after the bug appeared, don't you?

No.  The reported locations remain unaffected (errors/warnings at test.cc:12:5
and test.cc:12:7, notes at test.cc:9:34).  Just that (after replacing "ignored"
with "warning") they get reported as errors with -O1 and r232893 included, and
as warnings otherwise (i.e., either with -O0 and r232893 included, or with
either -O0/1 and r232893 reverted).

[Bug rtl-optimization/69592] New: [6 Regression] Compile-time and memory-use hog in combine

[rguenth at gcc dot gnu.org]

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

Bug ID: 69592
   Summary: [6 Regression] Compile-time and memory-use hog in
combine
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: compile-time-hog, memory-hog
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37539=edit
preprocessed source

When building mozilla-nss on 32bit i586 (and the preprocesed source on x86_64)
one can observe the build taking > 1GB of memory (didn't see if it eventually
finishes).

It "hangs" in a deep recursion of 

#0  0x00dce437 in copy_rtx (orig=0x76140978)
at /space/rguenther/src/svn/trunk3/gcc/rtl.c:275
#1  0x00dce5aa in copy_rtx (orig=0x76140a08)
at /space/rguenther/src/svn/trunk3/gcc/rtl.c:332
#2  0x0171c451 in get_last_value (x=0x761409f0)
at /space/rguenther/src/svn/trunk3/gcc/combine.c:13174
#3  0x01714688 in reg_nonzero_bits_for_combine (x=0x761409f0, 
mode=CCCmode, known_x=0x0, known_mode=VOIDmode, known_ret=0, 
nonzero=0x7fff68e0)
at /space/rguenther/src/svn/trunk3/gcc/combine.c:9859
#4  0x00dd8967 in nonzero_bits1 (x=0x761409f0, mode=CCCmode, 
known_x=0x0, known_mode=VOIDmode, known_ret=0)
at /space/rguenther/src/svn/trunk3/gcc/rtlanal.c:4317
#5  0x00dd82e5 in cached_nonzero_bits (x=0x761409f0, mode=CCCmode, 
known_x=0x0, known_mode=VOIDmode, known_ret=0)
at /space/rguenther/src/svn/trunk3/gcc/rtlanal.c:4207
#6  0x00dd8cf5 in nonzero_bits1 (x=0x76140a68, mode=CCCmode, 
known_x=0x0, known_mode=VOIDmode, known_ret=0)
at /space/rguenther/src/svn/trunk3/gcc/rtlanal.c:4452
...
#201 0x00dd974a in cached_num_sign_bit_copies (x=0x76778060, 
mode=CCCmode, known_x=0x0, known_mode=VOIDmode, known_ret=0)
at /space/rguenther/src/svn/trunk3/gcc/rtlanal.c:4712
#202 0x00dd812b in num_sign_bit_copies (x=0x76778060, mode=CCCmode)
at /space/rguenther/src/svn/trunk3/gcc/rtlanal.c:4163
#203 0x0171b3fd in record_value_for_reg (reg=0x76778ab0, 
insn=0x76496280, value=0x76778060)
at /space/rguenther/src/svn/trunk3/gcc/combine.c:12734
#204 0x0171b4b9 in record_dead_and_set_regs_1 (dest=0x76778ab0, 
setter=0x76778ac8, data=0x76496280)
at /space/rguenther/src/svn/trunk3/gcc/combine.c:12763
#205 0x00dd3bcd in note_stores (x=0x76778ac8, fun=
0x171b40d , 
data=0x76496280) at /space/rguenther/src/svn/trunk3/gcc/rtlanal.c:1860


where we see

#203 0x0171b3fd in record_value_for_reg (reg=0x76778ab0, 
insn=0x76496280, value=0x76778060)
at /space/rguenther/src/svn/trunk3/gcc/combine.c:12734
12734   = num_sign_bit_copies (value, GET_MODE (reg));
(gdb) p debug_rtx (value)
(compare:CCC (plus:SI (reg:SI 1900 [ lo ])
(reg:SI 1903 [ tm ]))
(reg:SI 1900 [ lo ]))

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[sbergman at redhat dot com]

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

--- Comment #22 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #20)
> Does the http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02347.html workaround
> help here in any way?

No, unfortunately not.  Doesn't change the behaviour in any way.