[Bug tree-optimization/69452] New: gcc ICE at -O3 on x86_64-linux-gnu in with “verify_ssa failed”

[helloqirun at gmail dot com]

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

Bug ID: 69452
   Summary: gcc ICE at -O3 on x86_64-linux-gnu in with “verify_ssa
failed”
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at only -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. The other
optimization levels work just fine.

Unlike PR69341, it does not depend on the graphite loop transformation
infrastructure.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160123 (experimental) [trunk revision 232764] (GCC)



$ gcc-trunk -O3 abc.c
abc.c: In function 'fn2':
abc.c:9:6: error: definition in block 42 follows the use
 void fn2() {
  ^~~

for SSA_NAME: _93 in statement:
c_lsm.20_116 = r_75 != 0 ? _93 : _71;
abc.c:9:6: internal compiler error: verify_ssa failed
0xd55112 verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1039
0xa9037d execute_function_todo
../../gcc/gcc/passes.c:1965
0xa90bfb execute_todo
../../gcc/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ cat abc.c
short a, f, h;
struct S0 {
  int f0;
} b;
char c, d, e, j, k;
int g;
char fn1(char p1, int p2) { return 7 >> p2 ? p1 : p2; }
void fn2() {
  int l, m, n;
  struct S0 o = {0};
  for (;;) {
int p = 1, r = e;
unsigned q = 6;
l = r == 0 ? q : q % r;
n = l;
c = f;
k = fn1(p, n ^ e);
char s = k;
j = s / 6;
if (j) {
  int t = d, u = m = d ? t : t / d;
  h = a || u;
  b.f0 = h;
  for (; d;)
;
} else {
  b = o;
  if (d != g)
for (;;)
  ;
}
  }
}
int main() {}

[Bug driver/69451] want a high-level option to disable optimizations that harm debuggability

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from Eric Botcazou  ---
No, -Og behaves as other -Ox options and overrides earlier options.  I don't
think that we want another, parallel circuitry alongside -Og.

[Bug fortran/66094] Handle transpose(A) in inline matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jan 24 09:11:50 2016
New Revision: 232774

URL: https://gcc.gnu.org/viewcvs?rev=232774=gcc=rev
Log:
2016-01-24  Thomas Koenig  

PR fortran/66094
* frontend-passes.c (enum matrix_case):  Add case A2B2T for
MATMUL(A,TRANSPoSE(B)) where A and B are rank 2.
(inline_limit_check):  Also add A2B2T.
(matmul_lhs_realloc):  Handle A2B2T.
(check_conjg_variable):  Rename to
(check_conjg_transpose_variable):  and also count TRANSPOSE.
(inline_matmul_assign):  Handle A2B2T.

2016-01-24  Thomas Koenig  

PR fortran/66094
* gfortran.dg/inline_matmul_13.f90:  New test.
* gfortran.dg/matmul_bounds_8.f90:  New test.
* gfortran.dg/matmul_bounds_9.f90:  New test.
* gfortran.dg/matmul_bounds_10.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/inline_matmul_13.f90
trunk/gcc/testsuite/gfortran.dg/matmul_bounds_10.f90
trunk/gcc/testsuite/gfortran.dg/matmul_bounds_8.f90
trunk/gcc/testsuite/gfortran.dg/matmul_bounds_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug other/69453] New: unrecognized command line option suggestions should take negation into account

[trippels at gcc dot gnu.org]

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

Bug ID: 69453
   Summary: unrecognized command line option suggestions should
take negation into account
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Unrecognized command line option suggestions should take negation into account:

markus@x4 tmp % g++ --Wno-narrowing
g++: error: unrecognized command line option ‘--Wno-narrowing’; did you mean
‘-Wnarrowing’?
g++: fatal error: no input files
compilation terminated.

"did you mean ‘-Wno-narrowing’" would be nicer.

[Bug fortran/66094] Handle transpose(A) in inline matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Still to do: MATMUL(TRANSPOSE(A),B).

MATMUL(TRANSPOSE(A),TRANSPOSE(B)) would be silly.

[Bug other/69453] unrecognized command line option suggestions should take negation into account

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Even the following:
-fmo-unroll-loops

Should recommend -fno-unroll-loops instead of -funroll-loops .

The n and m switch up happens when you are typing the command manually and very
quickly without looking at the keyboard.

[Bug target/37595] funcs.c:323: internal compiler error: Segmentation fault

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
The test case compiles fine with recent trunk (6.0) on both powerpc64 and
powerpc64le.  Closing as fixed since there's been no feedback in 7 years.

[Bug target/28366] Divide with vectors cause extra stores (and more stack space) (with VMX)

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Actually, the code you get for -mcpu=power6 looks "fine."  The originally
reported problem was for use of stvewx to store single vector elements, rather
than using stvx to store entire vectors.  This is now happening for
-mcpu=power6.  By the way, you get the same code if you use -mcpu=power7
-mno-vsx, as the xvdivsp instruction requires the VSX feature.

So in my view we can probably close this one as a WORKSFORME at this point.

[Bug rtl-optimization/69460] New: ARM Cortex M0 produces suboptimal code vs Cortex M3

[strntydog at gmail dot com]

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

Bug ID: 69460
   Summary: ARM Cortex M0 produces suboptimal code vs Cortex M3
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: strntydog at gmail dot com
  Target Milestone: ---

Created attachment 37451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37451=edit
Test Source

Tested on GCC 4.9 and 5.2, under Linux (Ubuntu 15.10/64 bit)
I am using the pre-built toolchains available at
https://launchpad.net/gcc-arm-embedded

When compiling for a Cortex M0 target i noticed some poor code generation with
regard to literal tables.  I compared that code generation to code generation
to Cortex M3 and it produces much better code.  It became apparent that the
code generated for the M3 was actually legal M0 code and so could execute
unmodified on a M0 core.  Accordingly, the Cortex M0 is needlessly producing
suboptimal code vs the same code compiled for Cortex M3.

There are six tests in the test case, all accessing memory via different
patterns.  ALL generate suboptimal code for Cortex M0 vs the Cortex M3 code
generator, yet all code produced is legal Cortex M0 code. Example of the
sub-optimal code generation:

Test 6:

/* Write 8 bit values to known register locations - using an array */
void test6(void)
{
volatile uint8_t* const r = (uint8_t*)(0x40002800U); // Register Array

r[0] = 0xFF;
r[1] = 0xFE;
r[2] = 0xFD;
r[3] = 0xFC;
r[4] = 0xEE;
r[8] = 0xDD;
r[12] = 0xCC;
}

Which, at -Os for -mcpu-cortex-m0 results in:
00ec :
  ec: 22ff movs r2, #255 ; 0xff
  ee: 4b0a ldr r3, [pc, #40] ; (118 )
  f0: 701a strb r2, [r3, #0]
  f2: 4b0a ldr r3, [pc, #40] ; (11c )
  f4: 3a01 subs r2, #1
  f6: 701a strb r2, [r3, #0]
  f8: 4b09 ldr r3, [pc, #36] ; (120 )
  fa: 3a01 subs r2, #1
  fc: 701a strb r2, [r3, #0]
  fe: 4b09 ldr r3, [pc, #36] ; (124 )
 100: 3a01 subs r2, #1
 102: 701a strb r2, [r3, #0]
 104: 4b08 ldr r3, [pc, #32] ; (128 )
 106: 3a0e subs r2, #14
 108: 701a strb r2, [r3, #0]
 10a: 4b08 ldr r3, [pc, #32] ; (12c )
 10c: 3a11 subs r2, #17
 10e: 701a strb r2, [r3, #0]
 110: 4b07 ldr r3, [pc, #28] ; (130 )
 112: 3a11 subs r2, #17
 114: 701a strb r2, [r3, #0]
 116: 4770 bx lr
 118: 40002800 .word 0x40002800
 11c: 40002801 .word 0x40002801
 120: 40002802 .word 0x40002802
 124: 40002803 .word 0x40002803
 128: 40002804 .word 0x40002804
 12c: 40002808 .word 0x40002808
 130: 4000280c .word 0x4000280c

Each element accessed in the array of bytes has resulted in the address of that
element appearing in the literal table. 

By comparison the M3 build generates :

0094 :
  94: 4b07 ldr r3, [pc, #28] ; (b4 )
  96: 22ff movs r2, #255 ; 0xff
  98: 701a strb r2, [r3, #0]
  9a: 22fe movs r2, #254 ; 0xfe
  9c: 705a strb r2, [r3, #1]
  9e: 22fd movs r2, #253 ; 0xfd
  a0: 709a strb r2, [r3, #2]
  a2: 22fc movs r2, #252 ; 0xfc
  a4: 70da strb r2, [r3, #3]
  a6: 22ee movs r2, #238 ; 0xee
  a8: 711a strb r2, [r3, #4]
  aa: 22dd movs r2, #221 ; 0xdd
  ac: 721a strb r2, [r3, #8]
  ae: 22cc movs r2, #204 ; 0xcc
  b0: 731a strb r2, [r3, #12]
  b2: 4770 bx lr
  b4: 40002800 .word 0x40002800

ALL of which is LEGAL M0 Code.

The Cortex M0 compile is:
72 Bytes Long, 22 Instructions and 7 Literal Table Entries and 7 reads from
Code Space.

The Cortex M3 compile (which generates legal M0 code) is:
36 Bytes Long, 16 Instructions and 1 Literal Table Entry and 1 read from Code
Space.

Significantly more efficient in every respect.

Given that Cortex M0 cores usually have less resources than Cortex M3 cores, I
would expect the code generation to be the same between them, unless there is
an ability to use an instruction which only exists on a Cortex M3.  This
inefficient code generation will make Cortex M0 cores seem much less efficient
and much slower than they are in reality.

Attached is a the test case and a script to build it.

The script builds the code for M0 and M3, it then dumps the M3 assembler,
patches it so that it can be assembled as M0 assembler and assembles the
result.
The reason for that is to confirm that the M3 generated code is LEGAL M0 Code,
which it is.

[Bug rtl-optimization/69460] ARM Cortex M0 produces suboptimal code vs Cortex M3

[strntydog at gmail dot com]

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

--- Comment #1 from strntydog at gmail dot com ---
Created attachment 37452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37452=edit
Script to build the test and generate output files

This script builds the test.c file for both Cortex M0 and M3 it then checks if
the M3 code generated is legal M0 code by trying to assemble the M3 code output
as M0 assembler.

[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[wjl at icecavern dot net]

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

--- Comment #12 from Wesley J. Landaker  ---
This bug is marked fixed, but it is still present in g++ 5.3.1.

$ g++ --version
g++ (Debian 5.3.1-4) 5.3.1 20151219
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -std=c++14 x.cpp
1 1 0 0 1 1 0 0

[Bug target/28314] cpp: x86/powerpc inconsistency for the __linux macro

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org
  Known to fail||4.1.2, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.0

--- Comment #2 from Martin Sebor  ---
This hasn't changed in 10 years.  Should the bug be closed as WONTFIX?

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #4 from Jerry DeLisle  ---
I will take this one.

[Bug rtl-optimization/69460] ARM Cortex M0 produces suboptimal code vs Cortex M3

[strntydog at gmail dot com]

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

--- Comment #2 from strntydog at gmail dot com ---
This code generation problem was also reported at:
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1502611

[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[wjl at icecavern dot net]

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

--- Comment #13 from Wesley J. Landaker  ---
However, it is fixed the 6.0 preview version, which is good!

$ g++ --version
g++ (Debian 6-20160117-1) 6.0.0 20160117 (experimental) [trunk revision 232481]
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -std=c++14 x.cpp
$ ./a.out
0 0 0 0 0 0 0 0

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
  Known to work||4.9.3
Summary|internal compiler error:|[5/6 Regression] internal
   |Segmentation fault  |compiler error:
   ||Segmentation fault

--- Comment #4 from Markus Trippelsdorf  ---
PR69454 testcase only crashes with gcc-6:

markus@x4 VEX % cat guest_amd64_helpers.i
typedef struct { long long w64[2]; } V128;
extern V128* fn2(void);
long long a;
V128 b;
void fn1() {
  V128 *c = fn2();
  c->w64[0] = a ^ b.w64[0];
}

markus@x4 VEX % gcc -c -m32 -mpreferred-stack-boundary=2 -O2
guest_amd64_helpers.i
guest_amd64_helpers.i: In function ‘fn1’:
guest_amd64_helpers.i:8:1: internal compiler error: Segmentation fault
 }
 ^

0xb2051f crash_signal
../../gcc/gcc/toplev.c:335
0x7f543f74614f ???
   
/home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xe3d804 ix86_expand_prologue()
../../gcc/gcc/config/i386/i386.c:12751
0xff543a gen_prologue()
../../gcc/gcc/config/i386/i386.md:12451
0xe248e8 target_gen_prologue
../../gcc/gcc/config/i386/i386.md:18466
0x87a6ff thread_prologue_and_epilogue_insns()
../../gcc/gcc/function.c:6037
0x87b1d2 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6588
0x87b1d2 execute
../../gcc/gcc/function.c:6630


Reduced testcase, crashes for gcc-5 and gcc-6:

markus@x4 tmp % cat tracesig.ii
struct {
  char msgdata[][8];
} __thread *mythread;
char *fn1() { return mythread->msgdata[1]; }

markus@x4 tmp % g++ -c -fPIC -mpreferred-stack-boundary=5
-mincoming-stack-boundary=4 tracesig.ii
tracesig.ii: In function ‘char* fn1()’:
tracesig.ii:4:44: internal compiler error: Segmentation fault
 char *fn1() { return mythread->msgdata[1]; }
^

0xcfb38f crash_signal
../../gcc/gcc/toplev.c:335
0x7f22485a914f ???
   
/home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1017c94 ix86_expand_prologue()
../../gcc/gcc/config/i386/i386.c:12751
0x11cf8ca gen_prologue()
../../gcc/gcc/config/i386/i386.md:12451
0xffed78 target_gen_prologue
../../gcc/gcc/config/i386/i386.md:18466
0xa5649f thread_prologue_and_epilogue_insns()
../../gcc/gcc/function.c:6037
0xa56f72 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6588
0xa56f72 execute
../../gcc/gcc/function.c:6630
Please submit a full bug report,

[Bug tree-optimization/64992] More optimize opportunity

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Well, if the value range for one MULT_EXPR operand is [0, 1], then it will
never overflow, and is enough to know the other operand is ~[0, 0] and it can
be optimized to the [0, 1] range operand.

[Bug c++/65108] Missing DWARF info for static const class members

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Indeed, Foo::one is not a definition, but Bar::two is a definition.

https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition

[Bug libstdc++/64903] is_partitioned should not apply a predicate more than (last - first) times

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
No, it hasn't.

[Bug fortran/69455] [5/6 Regression] Assembler error(s) when using intrinsic modules in two BLOCK

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |5.4
Summary|[5/6 Regression] Linking|[5/6 Regression] Assembler
   |error(s) when using |error(s) when using
   |intrinsic modules in two|intrinsic modules in two
   |BLOCK   |BLOCK

--- Comment #4 from Dominique d'Humieres  ---
Fix the summary.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at gcc dot gnu.org]

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

--- Comment #15 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Jan 24 13:13:38 2016
New Revision: 232776

URL: https://gcc.gnu.org/viewcvs?rev=232776=gcc=rev
Log:
2016-01-24  Dominique d'Humieres  

PR fortran/68283
gfortran.dg/pr68283.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr68283.f90

[Bug middle-end/69454] ix86_expand_prologue internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
*** Bug 69454 has been marked as a duplicate of this bug. ***

[Bug fortran/69455] [5/6 Regression] Linking error(s) when using intrinsic modules in two BLOCK

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
FWIW I see the same kind of behaviour with 5.3.0 on Linux

$ ./gcc/gfortran -Bgcc -B x86_64-linux-gnu/libgfortran -B
x86_64-linux-gnu/libquadmath pr69455.f95 -std=f2008 -o f
 /tmp/ccKZf0Hi.s: Assembler messages:
 /tmp/ccKZf0Hi.s:115: Error: symbol `iso_c_binding_MOD_wp' is already
defined
 /tmp/ccKZf0Hi.s:121: Error: symbol `iso_c_binding_MOD_ik' is already
defined

(U10.04)

[Bug fortran/69455] [5/6 Regression] Linking error(s) when using intrinsic modules in two BLOCK

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
For the record, the test in comment 1 is a reduced version of the James Van
Busker's long test at
https://groups.google.com/forum/#!topic/comp.lang.fortran/WzM5bNfB-hw.

The following code

module kind
  integer, parameter :: INT32=4, INT64=8, REAL32=4, REAL64=8
end module kind

block
  use kind, only: wp => REAL32, ik => INT32 
  print *, ik, wp
end block

block
  use kind, only: wp => REAL64, ik => INT64
  print *, ik, wp
end block

end

compiles and executes without problem on trunk.

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

[mark at gcc dot gnu.org]

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

--- Comment #5 from Mark Wielaard  ---
Thanks for finding the duplicate and creating a small reproducer. This is
indeed a GCC 6 regression. valgrind builds fine with gcc (GCC) 5.3.1 20151207
(Red Hat 5.3.1-2) but fails with gcc (GCC) 6.0.0 20160123 (experimental).

But it looks like we were just lucky since you were able to tweak the
reproducer to also fail with 5.3.

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Or do this which makes libstdc++ use that non-standard function rather than
define it's own conflicting overload:

--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2186,7 +2186,7 @@ AC_DEFUN([GLIBCXX_CHECK_MATH11_PROTO], [
   fi
   AC_MSG_RESULT([$glibcxx_cv_math11_overload])
   ;;
-*-*-*gnu* | *-*-aix*)
+*-*-*gnu* | *-*-aix* | *-*-hpux*)
   # If  defines the obsolete isinf(double) and isnan(double)
   # functions (instead of or as well as the C99 generic macros) then we
   # can't define std::isinf(double) and std::isnan(double) in 

But if we already use fixincludes on  for HPUX then suppressing the
declarations is another option. Glibc 2.23 only defines those XOpen functions
when:

#if !defined __cplusplus || __cplusplus < 201103L /* Conflicts with C++11.  */

[Bug bootstrap/69329] [6 Regression] --with-build-config=bootstrap-asan fails because LSAN_OPTIONS is not honored

[miyuki at gcc dot gnu.org]

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

--- Comment #5 from Mikhail Maltsev  ---
(In reply to Jakub Jelinek from comment #4)
> And
> $(if $(LSAN_OPTIONS),"LSAN_OPTIONS=$(LSAN_OPTIONS)")
> doesn't work either?  That would match more what is there for other options.

It works fine. https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01832.html

[Bug fortran/67063] segfault in opening a formatted file at second time with status="replace"

[textdirected at gmail dot com]

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

--- Comment #8 from HEMMI, Shigeru  ---
FYI,

At the moment(Sun Jan 24 20:32:54 JST 2016), this bug fixed perfectly.
Currently, am using gfortran of "gcc version 5.3.0 (x86_64-posix-seh-rev0,
Built by MinGW-W64 project)".

Let me express my appreciation to all developers of gfortran and MinGW-W64
project.

Best regards,

[Bug fortran/69455] [5/6 Regression] Linking error(s) when using intrinsic modules in two BLOCK

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Similar problem with

block
  use, intrinsic :: ISO_FORTRAN_ENV, only: wp => REAL32, ik => INT32 
  print *, ik, wp
end block

block
  use, intrinsic :: ISO_FORTRAN_ENV, only: wp => REAL64, ik => INT64
  print *, ik, wp
end block

end

While the following variant compiles and executes as expected

  use ISO_FORTRAN_ENV, only: wp => REAL64, ik => INT64 
block
  use ISO_FORTRAN_ENV, only: wp => REAL32, ik => INT32 
  print *, ik, wp
end block
  print *, ik, wp

end

[Bug fortran/69455] [5/6 Regression] Assembler error(s) when using intrinsic modules in two BLOCK

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
The problem is gone if I revert revision r229540.

[Bug middle-end/69454] New: ix86_expand_prologue internal compiler error: Segmentation fault

[mark at gcc dot gnu.org]

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

Bug ID: 69454
   Summary: ix86_expand_prologue internal compiler error:
Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark at gcc dot gnu.org
  Target Milestone: ---

$ gcc --version
gcc (GCC) 6.0.0 20160123 (experimental)

  svn co svn://svn.valgrind.org/valgrind/trunk valgrind
  cd valgrind
  ./autogen.sh
  ./configure
  make

gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -I../VEX/pub
-DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVGPV_x86_linux_vanilla=1 -Ipriv 
-m32 -mpreferred-stack-boundary=2 -O2 -g -std=gnu99 -Wall -Wmissing-prototypes
-Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
-Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat
-Wformat-security -Wignored-qualifiers -Wmissing-parameter-type
-Wold-style-declaration -fno-stack-protector -fno-strict-aliasing -fno-builtin 
-fomit-frame-pointer -Wbad-function-cast -fstrict-aliasing  -MT
priv/libvex_x86_linux_a-guest_amd64_helpers.o -MD -MP -MF
priv/.deps/libvex_x86_linux_a-guest_amd64_helpers.Tpo -c -o
priv/libvex_x86_linux_a-guest_amd64_helpers.o `test -f
'priv/guest_amd64_helpers.c' || echo './'`priv/guest_amd64_helpers.c
priv/guest_amd64_helpers.c: In function ‘amd64g_dirtyhelper_AES’:
priv/guest_amd64_helpers.c:4183:1: internal compiler error: Segmentation fault
 }
 ^

0xb20c5f crash_signal
/home/mark/src/gcc/gcc/toplev.c:335
0xe3dc74 ix86_expand_prologue()
/home/mark/src/gcc/gcc/config/i386/i386.c:12752
0xff594a gen_prologue()
/home/mark/src/gcc/gcc/config/i386/i386.md:12451
0xe250a8 target_gen_prologue
/home/mark/src/gcc/gcc/config/i386/i386.md:18466
0x87b4af thread_prologue_and_epilogue_insns()
/home/mark/src/gcc/gcc/function.c:6037
0x87bf82 rest_of_handle_thread_prologue_and_epilogue
/home/mark/src/gcc/gcc/function.c:6588
0x87bf82 execute
/home/mark/src/gcc/gcc/function.c:6630
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:2142: recipe for target
'priv/libvex_x86_linux_a-guest_amd64_helpers.o' failed
make[3]: *** [priv/libvex_x86_linux_a-guest_amd64_helpers.o] Error 1
make[3]: Leaving directory '/opt/local/src/valgrind/VEX'

[Bug fortran/69455] New: [5/6 Regression] Linking error(s) when using intrinsic modules in two BLOCK

[dominiq at lps dot ens.fr]

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

Bug ID: 69455
   Summary: [5/6 Regression] Linking error(s) when using intrinsic
modules in two BLOCK
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

When linking the following code

block
  use, intrinsic :: iso_c_binding, only: wp => c_float, ik => c_int
  print *, ik, wp
end block

block
  use, intrinsic :: iso_c_binding, only: wp => c_double, ik => c_long
  print *, ik, wp
end block

end

with gfortran 5.3.0  or trunk (6.0), I get the following error on
x86_64-apple-darwin14

/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccR0DlmQ.s:95:29: error:
invalid symbol redefinition
.zerofill __DATA,__pu_bss2,_iso_c_binding_MOD_wp,4,2
   ^
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccR0DlmQ.s:97:29: error:
invalid symbol redefinition
.zerofill __DATA,__pu_bss2,_iso_c_binding_MOD_ik,4,2
   ^

The change occurred on trunk between revisions r229482 (2015-10-28, OK) and
r229608 (2015-10-30, errors), possibly r229540 (pr67885).

Comparing the assembly between the two revisions I see

-   .globl _iso_c_binding_MOD_wp
-   .zerofill __DATA,__pu_bss2,_iso_c_binding_MOD_wp,4,2
-   .globl _iso_c_binding_MOD_ik
-   .zerofill __DATA,__pu_bss2,_iso_c_binding_MOD_ik,4,2
-   .globl _iso_c_binding_MOD_wp
-   .zerofill __DATA,__pu_bss2,_iso_c_binding_MOD_wp,4,2
-   .globl _iso_c_binding_MOD_ik
-   .zerofill __DATA,__pu_bss2,_iso_c_binding_MOD_ik,4,2

where the '-' were for r229608.

[Bug fortran/68283] [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

[dominiq at gcc dot gnu.org]

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

--- Comment #14 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Jan 24 13:12:44 2016
New Revision: 232775

URL: https://gcc.gnu.org/viewcvs?rev=232775=gcc=rev
Log:
2016-01-24  Dominique d'Humieres 

PR fortran/68283
* primary.c (gfc_variable_attr): revert revision r221955,
call gfc_internal_error only if there is no error.

2016-01-24  Dominique d'Humieres  

PR fortran/68283
gfortran.dg/pr68283.f90: New test.



Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69452] [6 Regression] gcc ICE at -O3 on x86_64-linux-gnu in with verify_ssa failed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/69452] [6 Regression] gcc ICE at -O3 on x86_64-linux-gnu in with verify_ssa failed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||richard.guenther at gmail dot 
com
   Assignee|law at redhat dot com  |unassigned at gcc dot 
gnu.org

--- Comment #2 from Jeffrey A. Law  ---
This looks like a latent bug in tree-ssa-loop-im.c introduced by Richi a few
years ago when he added handling of invariant PHIs.

It appears that the code assumes that a dominator walk is sufficient to order
invariant statements moved.  However, consider a diamond CFG

a
   / \
  b   c
   \ /
d

a dominates b, c & d.  

Valid dominator walk orders would be

a, b, c, d
a, b, d, c
a, c, b, d
a, c, d, b
a, d, b, c
a, d, c, b

Note carefully that we could visit d before b or c.  So a pass which assumes
that we always visit b & c before d for correctness is fundamentally flawed.

The move_computations::before_dom_children call back is visited by the dom
walker and just inserts instructions on the appropriate edge.  Each instruction
is inserted on the edge *when it's appropriate block is visited*.  So if we
have an invariant in d which depends on invariants in b & c, a domwalk can not
be relied upon to order those statements.

The obviously question is how can that happen in SSA?  There can't be a
statement in d that depends on something in b & c because b & c don't dominate
d.  But wait...  PHI nodes.  A PHI can be defined in d which has arguments
defined in b & c.

That's precisely what's happening with this BZ.  We have a PHI in block d which
is fed by values in blocks c & b.  However, the order of visitation in the
domwalk is b, d, c resulting in something like this:

_71 = (char) pretmp_85;
c_lsm.17_116 = r_75 != 0 ? _93 : _71;
_93 = (char) pretmp_85;

Which is obviously invalid SSA (ignore that _71 and _93 have the same value).

What's key to remember here is that a domwalk will not guarantee that blocks
defining arguments in a PHI will be visited before the PHI itself -- even in
loop-free code.

If we're going to keep the current design of the invariant-motion code, then we
probably need to do something like a topological sort of the statements on the
edges before we commit the edge insertions.

We could also consider sorting the blocks for the dominator walk.  There's been
a few cases through the years where that would be helpful, but not in a really
significant way, just minor stuff we'd catch earlier in the optimizer pipeline
if we had a better visitation order.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ard.biesheuvel at linaro dot org]

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

ard.biesheuvel at linaro dot org changed:

   What|Removed |Added

 CC||ard.biesheuvel at linaro dot 
org

--- Comment #46 from ard.biesheuvel at linaro dot org ---
One issue that this causes, which I did not see mentioned anywhere in the
thread, is that the use of adrp/add and adrp/ldr imposes a 4 KB section
alignment. In EDK2 Tianocore (UEFI reference implementation), we deliberately
use -mcmodel=large to get around this requirement, since code size is a big
deal when executing from NOR flash, and the architecture of EDK2 (lots and lots
of small separately linked binaries) makes
the overhead of 4 KB section alignment prohibitive. (It uses 32 byte section
alignment unless there are objects like a vector table that require more)

[Bug bootstrap/69329] [6 Regression] --with-build-config=bootstrap-asan fails because LSAN_OPTIONS is not honored

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law  ---
WRT c#10.  I've never looked at any enabling/disabling aspects of REE.  But it
can exploit using implicit and explicit extensions in the IL to remove later
extensions in the IL.

It also handles cases that combine can't (like multiple reaching definitions).

So unless there's a strong need to avoid ree, enabling it seems like a win on
most, if not all, architectures.

[Bug c++/24663] Template instantiation generating a zero-sized array doesn't fail

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
Author: ppalka
Date: Sun Jan 24 17:45:21 2016
New Revision: 232778

URL: https://gcc.gnu.org/viewcvs?rev=232778=gcc=rev
Log:
Revert "Fix the remaining PR c++/24666 blockers"

gcc/cp/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Removed:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/11858] Name lookup error ignored when instantiated from expression within sizeof() in template function parameter

[ppalka at gcc dot gnu.org]

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

--- Comment #8 from Patrick Palka  ---
Author: ppalka
Date: Sun Jan 24 17:45:21 2016
New Revision: 232778

URL: https://gcc.gnu.org/viewcvs?rev=232778=gcc=rev
Log:
Revert "Fix the remaining PR c++/24666 blockers"

gcc/cp/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Removed:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/24666] [meta-bug] arrays decay to pointers too early

[ppalka at gcc dot gnu.org]

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

--- Comment #4 from Patrick Palka  ---
Author: ppalka
Date: Sun Jan 24 17:45:21 2016
New Revision: 232778

URL: https://gcc.gnu.org/viewcvs?rev=232778=gcc=rev
Log:
Revert "Fix the remaining PR c++/24666 blockers"

gcc/cp/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Removed:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/24664] Template instantiation generating an array of voids doesn't fail

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
Author: ppalka
Date: Sun Jan 24 17:45:21 2016
New Revision: 232778

URL: https://gcc.gnu.org/viewcvs?rev=232778=gcc=rev
Log:
Revert "Fix the remaining PR c++/24666 blockers"

gcc/cp/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* decl.c (grokdeclarator): Don't decay array parameter type to
a pointer type if it's dependent.
(grokparms): Invoke strip_top_quals instead of directly invoking
cp_build_qualified_type.
* pt.c (decay_dependent_array_parm_type): New static function.
(type_unification_real): Call decay_dependent_array_parm_type
to decay a dependent array parameter type to its corresponding
pointer type before unification.
(more_specialized_fn): Likewise.
(get_bindings): Likewise.
* tree.c (cp_build_qualified_type): Trivial typofix in
documentation.

gcc/testsuite/ChangeLog:

Revert:
2016-01-18  Patrick Palka  

PR c++/11858
PR c++/24663
PR c++/24664
* g++.dg/template/pr11858.C: New test.
* g++.dg/template/pr24663.C: New test.
* g++.dg/template/unify12.C: New test.
* g++.dg/template/unify13.C: New test.
* g++.dg/template/unify14.C: New test.
* g++.dg/template/unify15.C: New test.
* g++.dg/template/unify16.C: New test.
* g++.dg/template/unify17.C: New test.


Removed:
trunk/gcc/testsuite/g++.dg/template/pr11858.C
trunk/gcc/testsuite/g++.dg/template/pr24663.C
trunk/gcc/testsuite/g++.dg/template/unify12.C
trunk/gcc/testsuite/g++.dg/template/unify13.C
trunk/gcc/testsuite/g++.dg/template/unify14.C
trunk/gcc/testsuite/g++.dg/template/unify15.C
trunk/gcc/testsuite/g++.dg/template/unify16.C
trunk/gcc/testsuite/g++.dg/template/unify17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/11858] Name lookup error ignored when instantiated from expression within sizeof() in template function parameter

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Patch reverted due to numerous issues mentioned in the following thread:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01463.html

[Bug c++/24666] [meta-bug] arrays decay to pointers too early

[ppalka at gcc dot gnu.org]

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

Bug 11858 Summary: Name lookup error ignored when instantiated from expression 
within sizeof() in template function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11858

   What|Removed |Added

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

[Bug fortran/69456] New: Namelist value with trailing sign is ignored without error

[jschwab at gmail dot com]

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

Bug ID: 69456
   Summary: Namelist value with trailing sign is ignored without
error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jschwab at gmail dot com
  Target Milestone: ---

I recently encountered the following unexpected behavior in 4.9.4. I built
trunk on 20160123 (r232765) and confirmed this behavior still exists.

If a real value in a namelist has a trailing sign, its value is ignored and the
 value remains unmodified.  I expected this to lead to a runtime error when
reading the namelist.

I read the code for the function parse_real in libgfortran/io/list_read.c and
this behavior appears to exist because the value '1+1' is permitted as a
shorthand for '1e+1'.  This was also surprising to me.

I read the Fortran 2008 specification.  I had difficulty fully understanding
it, but I failed to find a place where it said that exponent-letter can be
legally omitted.  A look at the list of gfortran vendor extensions as well as a
web search also failed to provide additional information.


A sample program (adapted from pr56743) demonstrating this behavior is below:

implicit none
real :: r1 = -1
real :: r2 = -1
real :: r3 = -1
real :: r4 = -1
namelist /nml/ r1, r2, r3, r4

write (*, nml=nml)
open (99, file='nml.dat', status="replace")
write(99,*) ""
write(99,*) "  r1=1+"! BUG: wrong result: Unmodified, no error
write(99,*) "  r2=1-"! BUG: wrong result: Unmodified, no error
write(99,*) "  r3=1+1"   ! Treated as 1e+1?!
write(99,*) "  r4=1-1"   ! Treated as 1e-1?!

write(99,*) "/"

rewind(99)
read (99, nml=nml)
write (*, nml=nml)
close (99, status="delete")

end


The output of this program is

 R1= -1.,
 R2= -1.,
 R3= -1.,
 R4= -1.,
 /

 R1= -1.,
 R2= -1.,
 R3=  10.000,
 R4= 0.10001,
 /

[Bug c++/24666] [meta-bug] arrays decay to pointers too early

[ppalka at gcc dot gnu.org]

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

Bug 24663 Summary: Template instantiation generating a zero-sized array doesn't 
fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24663

   What|Removed |Added

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

[Bug c++/24666] [meta-bug] arrays decay to pointers too early

[ppalka at gcc dot gnu.org]

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

Bug 24664 Summary: Template instantiation generating an array of voids doesn't 
fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24664

   What|Removed |Added

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

[Bug c++/24664] Template instantiation generating an array of voids doesn't fail

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Patch reverted due to numerous issues mentioned in the following thread:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01463.html

[Bug c++/24663] Template instantiation generating a zero-sized array doesn't fail

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Patch reverted due to numerous issues mentioned in the following thread:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01463.html

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
If you fixinclude it, you should keep the int isnan (...) decl for C (and
perhaps for C++98 too), only hide it for C++11 and later.

[Bug fortran/69298] Array finalisers seem to be given the wrong array when the array is a member variable.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
 Blocks||37336
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I confirm a problem during the execution of the test:

thing 10
Finalising stuff_type 4

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

from 4.9 up to trunk (6.0), finalization being not implemented in 4.8.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug fortran/69298] Array finalisers seem to be given the wrong array when the array is a member variable.

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Created attachment 37448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37448=edit
Self-contained variant

[Bug c++/65221] typedef-name identifier not resolved in static member instantiation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #2 from Andrew Pinski  ---
Even doing this:
template< typename A >
struct X
{
  using this_type = X;
//  typedef X this_type;
  static this_type inst;
};

template< typename A >
typename X::thistype X::inst;


Does not work.  So configrmed.

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Josiah Schwab from comment #0)
> 
> I read the code for the function parse_real in libgfortran/io/list_read.c
> and this behavior appears to exist because the value '1+1' is permitted as a
> shorthand for '1e+1'.  This was also surprising to me.
> 
> I read the Fortran 2008 specification.  I had difficulty fully understanding
> it, but I failed to find a place where it said that exponent-letter can be
> legally omitted.  A look at the list of gfortran vendor extensions as well
> as a web search also failed to provide additional information.
> 
> 

See Table 10.1, "E and D Exponent Forms" in Fortran 2008 standard.

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  ---
Created attachment 37447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37447=edit
Patch

The attached include hack removes the XOPEN declaration for isnan.  It fixes
the build error but I'm not sure it is correct.  The macro defines for isnan
appear to be dependent on the declaration:

ia64 has

#define _ISNAN(x) 
(_IS32(x)?_Isnanf(x):_IS64(x)?(isnan)(x):_Isn
anf80(x))

and hppa

#define _ISNAN(x)  (_IS32(x)?_Isnanf(x):(isnan)(x))

On hpux10, there is no macro support.

So, I think we need to retain the declaration and use the defines from math.h.

I will try your patch.

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[Bug bootstrap/69329] [6 Regression] --with-build-config=bootstrap-asan fails because LSAN_OPTIONS is not honored

[miyuki at gcc dot gnu.org]

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

--- Comment #6 from Mikhail Maltsev  ---
Author: miyuki
Date: Sun Jan 24 15:32:17 2016
New Revision: 232777

URL: https://gcc.gnu.org/viewcvs?rev=232777=gcc=rev
Log:
Pass LSAN_OPTIONS to Makefiles in subdirectories

PR bootstrap/69329
* Makefile.tpl (BASE_FLAGS_TO_PASS): Add LSAN_OPTIONS.
* Makefile.in: Regenerate.

Modified:
trunk/ChangeLog
trunk/Makefile.in
trunk/Makefile.tpl

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
The configure check in acinclude.m4 doesn't work:

checking for obsolete isinf and isnan functions in ... no

It appears the problem is there is an obsolete isnan but not isinf.  We have
in config.log:

configure:18185: checking for obsolete isinf and isnan functions in 
configure:18209:  /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc
-B/test/gnu/gcc/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/sys-include-c -g -O2 -std=c++11 
conftest.cpp >&5
conftest.cpp:42:24: error: '::isinf' has not been declared
using ::isinf;
^

conftest.cpp:51:32: error: call of overloaded 'isinf(double)' is ambiguous
  bool b = isinf(0.0) || isnan(0.0);
^

conftest.cpp:44:21: note: candidate: bool std::isinf(long double)
bool isinf(long double);
 ^

conftest.cpp:43:21: note: candidate: bool std::isinf(float)
bool isinf(float);
 ^

configure:18209: $? = 1

It seems like test needs to be split into two.

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jschwab at gmail dot com]

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

--- Comment #3 from Josiah Schwab  ---
(In reply to kargl from comment #2)
> (In reply to Josiah Schwab from comment #0)
> > 
> > I read the code for the function parse_real in libgfortran/io/list_read.c
> > and this behavior appears to exist because the value '1+1' is permitted as a
> > shorthand for '1e+1'.  This was also surprising to me.
> > 
> > I read the Fortran 2008 specification.  I had difficulty fully understanding
> > it, but I failed to find a place where it said that exponent-letter can be
> > legally omitted.  A look at the list of gfortran vendor extensions as well
> > as a web search also failed to provide additional information.
> > 
> > 
> 
> See Table 10.1, "E and D Exponent Forms" in Fortran 2008 standard.

Thank you.  If I understand correctly, that makes it clear that r3 & r4 in my
example do conform to the standard.

The behavior of r1 & r2 still seems wrong.  (But I am very inexperienced at
reading standards, so please do correct me.)

[Bug tree-optimization/65356] [meta-bug] Port tail-merge fixes to 4.9

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
.

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #6 from Jonathan Wakely  ---
(In reply to John David Anglin from comment #5)
> It seems like test needs to be split into two.

Drat.

[Bug sanitizer/65662] AddressSanitizer CHECK failed: ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:835 "((res)) < ((kNumPossibleRegions))" (0x3ffb49, 0x80000)

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
I wonder when 52bit support will be added to AARCH64 ASAN ...  52bit VA is an
optional part of ARMv8.2.

[Bug rtl-optimization/65668] gcc does not know how to use __eabi_uldivmod properly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://gist.github.com/mrv |
   |n/0c79b146f74c28da401f  |

--- Comment #1 from Andrew Pinski  ---
There was a few patches for __eabi_uldivmod improvement floating around I don't
know what happened to them.

[Bug c++/65707] internal compiler error: in unify, at cp/pt.c:18577

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed|2015-04-09 00:00:00 |2016-1-24

--- Comment #2 from Andrew Pinski  ---
Changing:
always_true{}
to 
always_true::value

Allows it to compile.

That is the conversion operator is causing the ICE.

[Bug tree-optimization/65741] Missed loop optimization with asm

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 2016-01-24, at 2:16 PM, redi at gcc dot gnu.org wrote:

> I can prepare a patch to do that tomorrow.

This is what I'm testing.  Not quite to failure point in build.

--
John David Anglin   dave.ang...@bell.net

[Bug tree-optimization/38170] diff failure in cactusADM benchmark when -ftree-parallelize-loops=4 is enabled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-24
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Is this still a problem and if so, can you provide more details?  Otherwise,
can we close this PR?

[Bug libgcc/65281] Lots of macros using non-reserved names in gthr headers

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
GCC_GTHR_POSIX_H gets converted into _GLIBCXX_GCC_GTHR_POSIX_H

I think UNUSED was GCC_GTHR_UNUSED it would have been converted into
_GLIBCXX_GCC_GTHR_UNUSED

[Bug tree-optimization/69452] [6 Regression] gcc ICE at -O3 on x86_64-linux-gnu in with verify_ssa failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|gcc ICE at -O3 on   |[6 Regression] gcc ICE at
   |x86_64-linux-gnu in with|-O3 on x86_64-linux-gnu in
   |“verify_ssa failed” |with verify_ssa failed
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r228727.

[Bug c++/65299] Inheriting from two classes with increment operators

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
So clang bug and not a GCC bug.

[Bug c++/65189] [4.9/5/6 Regression] -fdump-classhierarchy is broken for virtual dtors

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4
Summary|Malformed (C++) |[4.9/5/6 Regression]
   |class-hierarchy dump on |-fdump-classhierarchy is
   |abstract class (in  |broken for virtual dtors
   |comparison to GCC 4.6.x)|

--- Comment #2 from Andrew Pinski  ---
I suspect the handling of dtors happens now after the dump happens.

[Bug driver/69457] New: gcc leaves temp files behind if invoked as "gcc @file"

[doko at gcc dot gnu.org]

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

Bug ID: 69457
   Summary: gcc leaves temp files behind if invoked as "gcc @file"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/810639]

How to reproduce:

$ ls /tmp/cc*
ls: cannot access /tmp/cc*: No such file or directory
$ touch main.ldscript
$ cat >main.txt
main.ldscript
$ gcc @main.txt
main.ldscript: file not recognized: File truncated
collect2: error: ld returned 1 exit status
$ ls /tmp/cc*
/tmp/cc5q7LCs

This probably isn't the usual way one uses gcc so it's hard to notice, but it
happens every time ghc (that's not a typo) builds something with profiling on.

[Bug driver/69457] gcc leaves temp files behind if invoked as "gcc @file"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|6.0 |5.4.0
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
This was fixed already for 6 by:

2015-06-23  Tristan Gingold  

* collect-utils.c (collect_wait): Unlink the response file here
instead of...
(do_wait): ...here.
(utils_cleanup): ...and here.


Dup of bug 69351.

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

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
I can prepare a patch to do that tomorrow.

[Bug libgcc/65281] Lots of macros using non-reserved names in gthr headers

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> GCC_GTHR_POSIX_H gets converted into _GLIBCXX_GCC_GTHR_POSIX_H

Indeed, most of the macros I referred to actually get transformed and so are
OK.

> I think UNUSED was GCC_GTHR_UNUSED it would have been converted into
> _GLIBCXX_GCC_GTHR_UNUSED

Maybe only UNUSED and the uses of __attribute__((unused)) are a problem and the
rest are OK.

[Bug fortran/66094] Handle transpose(A) in inline matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jan 24 18:15:08 2016
New Revision: 232779

URL: https://gcc.gnu.org/viewcvs?rev=232779=gcc=rev
Log:
2016-01-24  Thomas Koenig  

PR fortran/66094
* frontend-passes.c (matmul_lhs_realloc):  Add
forgotten break statement.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c

[Bug c++/65189] [4.9/5/6 Regression] --fdump-translation-unit is broken for virtual dtors

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #3 from Andrew Pinski  ---
Note the option -fdump-classhierarchy is not there any more but I can get the
.class file by using -fdump-tree-all.

Confirmed.

[Bug libgcc/65306] make error with clang on OSX 10.9.5 -- movq

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #12 from Andrew Pinski  ---
Works for Jack so closing as worksforme.

[Bug tree-optimization/69458] New: [graphite] compiling gmp -floop-nest-optimize over -fstrict-overflow produces wrong code (fpe)

[mahatma at eu dot by]

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

Bug ID: 69458
   Summary: [graphite] compiling gmp -floop-nest-optimize over
-fstrict-overflow produces wrong code (fpe)
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mahatma at eu dot by
  Target Milestone: ---

After rebuild gmp (6.1.0 now) with -floop-nest-optimize over -O2 or -O1
-fstrict-overflow - gmp broken (gcc floating point exception). IMHO same was
time ago with older versions of all. amd64. Same with +- asm & pgo.

[Bug driver/69351] response files on linux leave undeleted temporary files

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #7 from Andrew Pinski  ---
*** Bug 69457 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/65426] Recognize byte-swaps when writing to buffers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Last reconfirmed|2015-03-18 00:00:00 |2016-1-24
   Severity|minor   |enhancement

[Bug libgcc/65545] Demangling of char template parameters always produces integer value

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
  Component|libstdc++   |libgcc
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
demangler is part of libgcc.

Confirmed.

[Bug target/65294] No easy way of setting default Mac OS X target - darwin_minversion not enough

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug driver/65700] Documentation of internals is inconsistent in itself and diverges from reality

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
  Component|web |driver
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Ok, the issue here is that collect2 is used on some targets to do what
Collect2.html says it does.  It should say that instead.

That is:
nearly all systems
Should be changed to:
some targets

in that part of the document.

[Bug tree-optimization/38168] failure in gamess benchmark when -ftree-parallelize-loops=4 is enabled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-24
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Is this still a problem?

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |5.4

[Bug target/69459] New: [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[zsojka at seznam dot cz]

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

Bug ID: 69459
   Summary: [5/6 Regression] wrong code with -O2 and vector
arithmetics @ x86_64
   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: x86_64-*

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

Output:
$ x86_64-pc-linux-gnu-gcc -O2 testcase.c
$ ./a.out
e00b
Aborted

Tested revisions:
trunk r232760 - FAIL
5-branch r232545 - FAIL
4_[987]-branch - OK

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
   Host|x86_64-pc-linux-gnu |
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed, works on aarch64-linux-gnu but fails on x86_64-linux-gnu.

[Bug middle-end/69193] ICE: openmp + nested function + VLA

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
  Component|c   |middle-end
Version|unknown |6.0
 Ever confirmed|0   |1
  Known to fail||4.4.5, 6.0

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug rtl-optimization/30971] Wrong return value (Tail call optimization)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-24
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
I can reproduce the abort on powerpc64* and x86_64, but since
-funsafe-math-optimizations implies -fno-signed-zeros which implies that the
sign of a zero result isn't significant it's not obvious to me that there's
anything wrong.  Comment #3 suggests that the bug report might be based on a
misunderstanding of the effects of "-funsafe-math-optimizations is used
(fsigned-zeros is set in that case...)"

Revital, can you please clarify where you think the problem is?

Below is a slightly modified test case and its ouput.

$ cat gcc-30971.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -O2
-funsafe-math-optimizations gcc-30971.c && ./a.out
double __attribute__ ((noclone, noinline)) func (double d, int n)
{
  __builtin_printf ("%s(%e, %i)\n", __func__, d, n);

  if (n == 0)
return d;
  else
return d + func (d, n - 1);
}

int main ()
{
  double x = func (0.0 / -5.0, 2);
  __builtin_printf ("%e\n", x);

  if (__builtin_copysign (1.0, x) != -1.0)
__builtin_abort ();

}
func(-0.00e+00, 2)
func(-0.00e+00, 1)
func(-0.00e+00, 0)
0.00e+00
Aborted (core dumped)

[Bug fortran/68442] ICE on kind specification, depending on ordering of functions

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 24 22:18:20 2016
New Revision: 232780

URL: https://gcc.gnu.org/viewcvs?rev=232780=gcc=rev
Log:
2016-01-23  Jerry DeLisle  

PR fortran/69397
PR fortran/68442
* interface.c (gfc_arglist_matches_symbol): Replace assert with
a return false if not a procedure.
* resolve.c (resolve_generic_f): Test if we are resolving an
initialization expression and adjust error message accordingly.

2016-01-24  Jerry DeLisle  

PR fortran/69397
PR fortran/68442
* gfortran.dg/interface_38.f90: New test.
* gfortran.dg/interface_39.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/interface_38.f90
trunk/gcc/testsuite/gfortran.dg/interface_39.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69397] ICE on missing subprogram in generic interface

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 24 22:18:20 2016
New Revision: 232780

URL: https://gcc.gnu.org/viewcvs?rev=232780=gcc=rev
Log:
2016-01-23  Jerry DeLisle  

PR fortran/69397
PR fortran/68442
* interface.c (gfc_arglist_matches_symbol): Replace assert with
a return false if not a procedure.
* resolve.c (resolve_generic_f): Test if we are resolving an
initialization expression and adjust error message accordingly.

2016-01-24  Jerry DeLisle  

PR fortran/69397
PR fortran/68442
* gfortran.dg/interface_38.f90: New test.
* gfortran.dg/interface_39.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/interface_38.f90
trunk/gcc/testsuite/gfortran.dg/interface_39.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/28366] Divide with vectors cause extra stores (and more stack space) (with VMX)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
With -mcpu=power7 and later, gcc emits the following optimal code for the test
case.  With -mcpu=power6 and prior, I can confirm that the does look
suboptimal.

In light of the -power7 output and the fact that this has been open for 10
years with no activity, should the bug be closed as WONTFIX?

$ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra -O2 -maltivec
-O2 -mabi=altivec -m64 -S -o/dev/stdout -mcpu=power7 t.c
.file   "t.c"
.machine power7
.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:
xvdivsp 34,34,35
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   f,.-.L.f
.ident  "GCC: (GNU) 6.0.0 20160119 (experimental)"


-mcpu=power6 code:

$ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra -O2 -O2
-maltivec -O2 -mabi=altivec -m64 -S -o/dev/stdout -mcpu=power6 t.c
.file   "t.c"
.machine power6
.abiversion 2
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl f
.type   f, @function
f:
addi 10,1,-176
li 9,32
stvx 2,10,9
li 9,48
stvx 3,10,9
li 9,64
stvx 2,10,9
li 9,80
stvx 3,10,9
li 9,96
stvx 2,10,9
li 9,112
stvx 3,10,9
li 9,128
stvx 2,10,9
li 9,144
stvx 3,10,9
li 9,160
lfs 0,-128(1)
lfs 10,-144(1)
fdivs 10,10,0
lfs 11,-108(1)
lfs 0,-92(1)
fdivs 11,11,0
lfs 12,-72(1)
lfs 0,-56(1)
fdivs 12,12,0
lfs 9,-20(1)
lfs 0,-36(1)
fdivs 0,0,9
stfs 10,-16(1)
stfs 11,-12(1)
stfs 12,-8(1)
stfs 0,-4(1)
lvx 2,10,9
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   f,.-f
.ident  "GCC: (GNU) 6.0.0 20160121 (experimental)"
.section.note.GNU-stack,"",@progbits

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-24
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #3 from Martin Sebor  ---
Confirmed with last week's trunk. Big endian powerpc64 doesn't fail.  Here's a
slightly simplified test case:

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S -Wall
-Wextra -xc++ t.c
short a;

bool foo (short b)
{
   __sync_bool_compare_and_swap (, -1, b);
}


t.c: In function ‘bool foo(short int)’:
t.c:6:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^

t.c:6:1: error: unrecognizable insn:
(insn 10 9 11 4 (set (reg:CC 163)
(compare:CC (reg:SI 162)
(const_int 65535 [0x]))) t.c:5 -1
 (nil))
t.c:6:1: internal compiler error: in extract_insn, at recog.c:2286
0x10f7ae2f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/src/gcc/trunk/gcc/rtl-error.c:108
0x10f7aea7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/src/gcc/trunk/gcc/rtl-error.c:116
0x10eff25f extract_insn(rtx_insn*)
/src/gcc/trunk/gcc/recog.c:2286
0x10af73bb instantiate_virtual_regs_in_insn
/src/gcc/trunk/gcc/function.c:1582
0x10af914b instantiate_virtual_regs
/src/gcc/trunk/gcc/function.c:1950
0x10af92bb execute
/src/gcc/trunk/gcc/function.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #6 from Uroš Bizjak  ---
I was not able to reproduce the ICE with the first testcase from the Comment
#4, but was able to trigger the ICE with the second testcase with both gcc-5
and gcc-6.

We hit this corner case in i386.c:

  /* Emit prologue code to adjust stack alignment and setup DRAP, in case
 of DRAP is needed and stack realignment is really needed after reload */
  if (stack_realign_drap)
{
  int align_bytes = crtl->stack_alignment_needed / BITS_PER_UNIT;

  /* Only need to push parameter pointer reg if it is caller saved.  */
  if (!call_used_regs[REGNO (crtl->drap_reg)])
{
  /* Push arg pointer reg */
  insn = emit_insn (gen_push (crtl->drap_reg));
  RTX_FRAME_RELATED_P (insn) = 1;
}
...

Unfortunately, crtl->drap_reg is NULL at this point.

CC author.

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[rth at gcc dot gnu.org]

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

--- Comment #12 from Richard Henderson  ---
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01829.html

[Bug middle-end/65777] SPECOMP component 362.fma3d fails with error "SIGSEGV, segmentation fault occurred"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
No testcase and since you are using ICC you should report the bug to Intel and
not to GCC :).

[Bug preprocessor/65834] give error for #if with no expression at the previous location

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Maybe someone might want to put something else after TEST.  I think both are
correct to warn.  clang error location might be more useful in some cases but
wrong in others.  Likewise the way GCC is correct for some cases but wrong for
others.  The biggest question is which happens more often in real life.  I
don't have any thoughts on that one.