[Bug fortran/66929] [6 regression] ICE with iso_varying_string

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter  ---
Maybe stressing again: this is pretty much a blocker for us because it is in a
'standard' module which we don't want to modify, and on which all parts of our
code depend. We'd appreciate a reliable and quick fix soon.

[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
1) No explicit options, just the default ones, -S will suffice.
2) Sorry, I did not specify the target is x86-64, but I got the same with -m32
3) sub is not needed, the code should just be compiled to exhibit the bug

I have a sanitized (-fsanitize=address -fsanitize=undefined) version of
gfortran.
In the comments I put the output message from the sanitizer during compilation.
What happens is that the pointer retargs is NULL. I believe this is bad.
This fragment of code from gfc_conv_procedure_call is thus erroneous
because it dereferences a null pointer.
I did double check it by putting
gcc_assert(retargs);
immediately before its dereferencing. I then got an ICE at that line.

[Bug gcov-profile/66899] [6 Regression] ICE when compiling pkcs7_trust.c in Linux

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug bootstrap/66955] New: Bootstrap error: libcc1 compiled as shared library despite --disable-shared

[skunk at iskunk dot org]

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

Bug ID: 66955
   Summary: Bootstrap error: libcc1 compiled as shared library
despite --disable-shared
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

Bootstrapping 5.2.0 with

--disable-shared
--enable-languages=c,c++
--disable-multilib

results in

[...]
libtool: compile:  /tmp/gcc-build/./gcc/xg++ -B/tmp/gcc-build/./gcc/
-nostdinc++ -nostdinc++
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/src/gcc-5.2.0/libstdc++-v3/libsupc++
-I/home/src/gcc-5.2.0/libstdc++-v3/include/backward
-I/home/src/gcc-5.2.0/libstdc++-v3/testsuite/util
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/home/src/gcc-5.2.0/libcc1 -I /home/src/gcc-5.2.0/libcc1/../include -I
/home/src/gcc-5.2.0/libcc1/../libgcc -I ../gcc
-I/home/src/gcc-5.2.0/libcc1/../gcc -I /home/src/gcc-5.2.0/libcc1/../gcc/c -I
/home/src/gcc-5.2.0/libcc1/../gcc/c-family -I
/home/src/gcc-5.2.0/libcc1/../libcpp/include -I/usr/local/include
-I/usr/local/include -I/usr/local/include -W -Wall -fvisibility=hidden -g -O2
-D_GNU_SOURCE -MT marshall.lo -MD -MP -MF .deps/marshall.Tpo -c
/home/src/gcc-5.2.0/libcc1/marshall.cc  -fPIC -DPIC -o .libs/marshall.o
mv -f .deps/marshall.Tpo .deps/marshall.Plo
/bin/sh ./libtool --tag=CXX   --mode=link /tmp/gcc-build/./gcc/xg++
-B/tmp/gcc-build/./gcc/ -nostdinc++ `if test -f
/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags;
then /bin/sh
/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags
--build-includes; else echo -funconfigured-libstdc++-v3 ; fi`
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-W -Wall 
-fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols
/home/src/gcc-5.2.0/libcc1/libcc1.sym  -Xcompiler '-static-libstdc++'
-Xcompiler '-static-libgcc' -o libcc1.la -rpath /usr/local/lib/../lib64
findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo 
-Wc,../libiberty/pic/libiberty.a 
libtool: link:  /tmp/gcc-build/./gcc/xg++ -B/tmp/gcc-build/./gcc/ -nostdinc++
-nostdinc++
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/src/gcc-5.2.0/libstdc++-v3/libsupc++
-I/home/src/gcc-5.2.0/libstdc++-v3/include/backward
-I/home/src/gcc-5.2.0/libstdc++-v3/testsuite/util
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -fPIC -DPIC -shared
-nostdlib /usr/lib/../lib64/crti.o /tmp/gcc-build/./gcc/crtbeginS.o 
.libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o
.libs/connection.o .libs/marshall.o  
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-L/tmp/gcc-build/./gcc -L/lib/../lib64 -L/usr/lib/../lib64
/tmp/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a -lm
-lc -lgcc /tmp/gcc-build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o 
-static-libstdc++ -static-libgcc ../libiberty/pic/libiber

[Bug lto/54911] lto-wrapper fails when compiling gcc with -flto -fuse-linker-plugin

[isomorphisms at sdf dot org]

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

isomorphisms at sdf dot org changed:

   What|Removed |Added

 CC||isomorphisms at sdf dot org

--- Comment #7 from isomorphisms at sdf dot org ---
I get this error as well when trying to install.packages('maps') in R on Ubuntu
12.04.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
The problem seems to be that we inlined the function, but DECL_POSSIBLY_INLINED
remains unset, so dwarf2out doesn't think it needs to call
dwarf2out_abstract_function.

There also doesn't seem to be a cgraph edge for the inlined function call; I'm
guessing that the function was inlined in the initial compilation, and this
relationship is forgotten by the time we get to LTO.

So, doesn't look like a dwarf2out bug.

[Bug middle-end/66881] Possibly inefficient std::atomic codegen on x86 for simple arithmetic

[jfb at chromium dot org]

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

JF Bastien  changed:

   What|Removed |Added

 CC||jfb at chromium dot org

--- Comment #6 from JF Bastien  ---
I don't think this is a duplicate of PR 50677: this issue uses two *separate*
atomic operations, which inherently aren't atomic, whereas PR 50677 uses a
single volatile operations which some (misguided) developers expect to be
atomic.

The compiler may decide to be nice to developers who have misguided
expectations from using volatile, but this example clearly uses separate
load/store operations. I believe Thomas is correct: the code for f() should
codegen the same code as g().

[Bug c++/66954] New: function multiversioning fails for target "aes"

[jens.maurer at gmx dot net]

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

Bug ID: 66954
   Summary: function multiversioning fails for target "aes"
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.maurer at gmx dot net
  Target Milestone: ---

I would like to switch implementations depending on whether the (Intel) CPU has
AES instructions or not.  Simplified testcase:


__attribute__((target("default")))
void foo()
{ }

__attribute__((target("aes")))
void foo()
{ }

int main()
{
  void (*f)() = &foo;
}


yields

> g++ target-aes.cc 
target-aes.cc: In function '':
target-aes.cc:7:6: error: No dispatcher found for aes
 void foo()
  ^

[Bug tree-optimization/66952] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r225861.

[Bug tree-optimization/66949] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu in tree_ssa_phiopt_worker, at tree-ssa-phiopt.c:335

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r225722.

[Bug tree-optimization/66951] [6 Regression] ICE at -O3 on x86_64-linux-gnu, verify_ssa failed

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r225923.

[Bug libobjc/54720] libobjc install-strip target not populated

[keith.marshall at mailinator dot com]

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

--- Comment #2 from Keith Marshall  ---
Created attachment 36018
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36018&action=edit
Differences between "find staged" for each of "install-strip" and "install"
cases.

[Bug libobjc/54720] libobjc install-strip target not populated

[keith.marshall at mailinator dot com]

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

Keith Marshall  changed:

   What|Removed |Added

 CC||keith.marshall at mailinator 
dot c
   ||om

--- Comment #1 from Keith Marshall  ---
This appears to afflict version 4.8.5 too. After successfully completing a
crossed-native build for the mingw32 target,

  make prefix=`pwd`/staged install-strip

omits all libraries, associated headers, and the associated dll for the libobjc
component, whereas

  make prefix=`pwd`/staged install

includes them.  The difference in installed inventory, between execution of
each of these commands is attached.

[Bug c/66953] New: Missing documentation for support of unicode literals under -std=gnu99

[jeansaad at ca dot ibm.com]

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

Bug ID: 66953
   Summary: Missing documentation for support of unicode literals
under -std=gnu99
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeansaad at ca dot ibm.com
  Target Milestone: ---

gcc allows for the use of unicode literals under -std=gnu99 however this
support is not documented under C Extensions
(https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions). I can only
imagine that this support was intentional as an extended option to the C99
standard in support of TR 19769.

### STANDALONE SOURCE:
#include 

int main(void) {
char16_t c16 = u'\u00F6';
char32_t c32 = U'\U0010';
}

### GCC INVOCATION:
gcc -std=gnu99 -c unicode_literals.c

## gcc -v OUTPUT:
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

[Bug c++/54366] [meta-bug] decltype issues

[paolo.carlini at oracle dot com]

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

Bug 65091 Summary: decltype(~arg) fails for template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65091

   What|Removed |Added

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

[Bug c++/65091] decltype(~arg) fails for template functions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |6.0

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

[Bug tree-optimization/66952] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|wrong code at -O2 and -O3   |[6 Regression] wrong code
   |on x86_64-linux-gnu |at -O2 and -O3 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/66952] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 66952
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-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 at -O2 and
-O3 in both 32-bit and 64-bit modes. 

This is a regression from 5.1.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-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 20150719 (experimental) [trunk revision 225987] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
$ gcc-5.1 -O2 small.c; ./a.out
$ 
$ gcc-trunk -O2 small.c
$ ./a.out
Aborted (core dumped)
$ 


---


int a = 128, b;

int
fn1 (char p1, int p2)
{
  return p1 < 0 || p1 > 1 >> p2 ? 0 : p1 << 1;
}

int
fn2 ()
{
  char c = a;
  b = fn1 (c, 1);
  if ((128 | c) < 0 ? 1 : 0)
return 1;
  return 0;
}

int
main ()
{
  if (fn2 () != 1)
__builtin_abort ();

  return 0;
}

[Bug tree-optimization/66951] [6 Regression] ICE at -O3 on x86_64-linux-gnu, verify_ssa failed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE at -O3 on   |[6 Regression] ICE at -O3
   |x86_64-linux-gnu,   |on x86_64-linux-gnu,
   |verify_ssa failed   |verify_ssa failed
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/66949] [6 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu in tree_ssa_phiopt_worker, at tree-ssa-phiopt.c:335

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE at -O2 and -O3 on   |[6 Regression] ICE at -O2
   |x86_64-linux-gnu in |and -O3 on x86_64-linux-gnu
   |tree_ssa_phiopt_worker, at  |in tree_ssa_phiopt_worker,
   |tree-ssa-phiopt.c:335   |at tree-ssa-phiopt.c:335
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/66951] New: ICE at -O3 on x86_64-linux-gnu, verify_ssa failed

[su at cs dot ucdavis.edu]

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

Bug ID: 66951
   Summary: ICE at -O3 on x86_64-linux-gnu, 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: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 5.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-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 20150719 (experimental) [trunk revision 225987] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-5.1 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: error: definition in block 18 does not dominate use in block 9
 fn1 ()
 ^
for SSA_NAME: .MEM_48 in statement:
# VUSE <.MEM_48>
vect__9.18_58 = MEM[(int *)vectp_b.16_56];
small.c:4:1: internal compiler error: verify_ssa failed
0xd6a819 verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.c:1047
0xaaea3d execute_function_todo
../../gcc-trunk/gcc/passes.c:1955
0xaaf253 execute_todo
../../gcc-trunk/gcc/passes.c:2005
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





int a, b[16], c, d;

void
fn1 ()
{
  for (; d; d++)
{
  for (a = 0; a < 2; a++)
;
  c ^= b[d];
}
}

[Bug libgomp/66950] New: FAIL: libgomp.fortran/examples-4/simd-7.f90 -O0 execution test

[hjl.tools at gmail dot com]

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

Bug ID: 66950
   Summary: FAIL: libgomp.fortran/examples-4/simd-7.f90   -O0
execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

libgomp.fortran/examples-4/simd-7.f90 takes a very long time to
run on Linux/ia32.  I get random:

FAIL: libgomp.fortran/examples-4/simd-7.f90   -O0  execution test

[Bug tree-optimization/66949] New: ICE at -O2 and -O3 on x86_64-linux-gnu in tree_ssa_phiopt_worker, at tree-ssa-phiopt.c:335

[su at cs dot ucdavis.edu]

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

Bug ID: 66949
   Summary: ICE at -O2 and -O3 on x86_64-linux-gnu in
tree_ssa_phiopt_worker, at tree-ssa-phiopt.c:335
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 5.1.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-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 20150719 (experimental) [trunk revision 225987] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
$ gcc-5.1 -O2 small.c; ./a.out
$ 
$ gcc-trunk -O2 small.c
small.c: In function ‘fn2’:
small.c:10:1: internal compiler error: in tree_ssa_phiopt_worker, at
tree-ssa-phiopt.c:335
 fn2 ()
 ^
0xcf3dfd tree_ssa_phiopt_worker
../../gcc-trunk/gcc/tree-ssa-phiopt.c:335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


int a, *b = &a, c;

unsigned short
fn1 (unsigned short p1, unsigned int p2)
{
  return p2 > 1 || p1 >> p2 ? p1 : p1 << p2;
}

void
fn2 ()
{
  int *d = &a;
  for (a = 0; a < -1; a = 1)
;
  if (a < 0)
c = 0; 
  *b = fn1 (*d || c, *d);
}

int
main ()
{
  fn2 (); 
  return 0;
}

[Bug tree-optimization/66768] address space gets lost on literal pointer

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||addr-space
 CC||gjl at gcc dot gnu.org

--- Comment #10 from Georg-Johann Lay  ---
Guess the target should be x86?

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Aldy Hernandez from comment #5)
> It was my understanding that DW_AT_inline cannot appear in conjunction
> with location info.

Right.

"A debugging information entry that is a member of an abstract instance tree
should not contain any attributes which describe aspects of the subroutine
which
vary between distinct inlined expansions or distinct out-of-line expansions."

I'll take a look.

[Bug sanitizer/66908] Uninitialized variable when compiled with UBsan

[y.gribov at samsung dot com]

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

--- Comment #1 from Yury Gribov  ---
Looks like -fsanitize=bounds may introduce uninitialized variables when run
after shift.

[Bug tree-optimization/66948] New: Performance regression in bit manipulation code

[mar...@mpa-garching.mpg.de]

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

Bug ID: 66948
   Summary: Performance regression in bit manipulation code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 36017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36017&action=edit
Testcase

The attached test code requires significantly more CPU time when compiled with
current trunk, compared to gcc 4.8.4 and the gcc 5 branch.

gcc 4.8.4:
martin@marvin ~/lsnew $ gcc -std=c99 -O3 testcase.c
martin@marvin ~/lsnew $ time ./a.out

real0m4.039s
user0m4.041s
sys 0m0.000s


gcc 5 branch:
martin@marvin ~/lsnew $ gcc -std=c99 -O3 testcase.c
martin@marvin ~/lsnew $  time ./a.out

real0m3.820s
user0m3.822s
sys 0m0.000s

trunk:
martin@marvin ~/lsnew $  gcc -std=c99 -O3 testcase.c
martin@marvin ~/lsnew $ time ./a.out

real0m4.492s
user0m4.493s
sys 0m0.004s

[Bug preprocessor/66932] Preprocessor includes wrong header file

[pilot.mm at gmail dot com]

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

--- Comment #5 from Michael McWilliam  ---
(In reply to Andrew Pinski from comment #4)
> An empty : causes the current directory to be added.

Thanks for explaining that... Including the current directory with an empty :
makes sense (as it is in the documented). However that does not seem to be what
is happening considering this causes ../bfd/ to take precedent over ./. Simply
setting C_INCLUDE_PATH to any of the following will cause the error:

C_INCLUDE_PATH=":"
C_INCLUDE_PATH=":/usr/include/"
C_INCLUDE_PATH="./"
C_INCLUDE_PATH="/usr/include/:"

According to the documentation the -I directives are included first, then those
of C_INCLUDE_PATH, then the system headers. In this problem the local directory
is included first with -I. So it seems that when the compiler sees a directory
in C_INCLUDE_PATH it forgets any duplicates specified with -I and the include
precedence is being broken. Stated simply I think gcc is failing to check if an
include directory is already specified when it adds C_INCLUDE_PATH headers in
lower precedence.

So it seems it is a real bug... and a somewhat obscure bug...

[Bug fortran/66929] [6 regression] ICE with iso_varying_string

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #4 from Jürgen Reuter  ---
Also just stumbled over this one. Happens for us with r225979:

libtool: compile:  /var/lib/jenkins/slave/opt/gcc-6.0-225979/bin/gfortran -g
-O2 -c ../../../omega/src/iso_varying_string.f90  -fPIC -o
.libs/iso_varying_string.o
../../../omega/src/iso_varying_string.f90:2467:0:

   rep_string = substring//extract(work_string,
start=i_target+length_target)//rep_string
1
internal compiler error: Segmentation fault
0xbde39f crash_signal
../../source/gcc/toplev.c:352
0x6aa154 expr_may_alias_variables
../../source/gcc/fortran/trans-expr.c:4566
0x6b0d71 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../source/gcc/fortran/trans-expr.c:5405
0x6b5a12 gfc_conv_expr(gfc_se*, gfc_expr*)
../../source/gcc/fortran/trans-expr.c:7482
0x6bc4a8 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../source/gcc/fortran/trans-expr.c:7617
0x6b140f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../source/gcc/fortran/trans-expr.c:5055
0x6b5a12 gfc_conv_expr(gfc_se*, gfc_expr*)
../../source/gcc/fortran/trans-expr.c:7482
0x6bd840 gfc_trans_assignment_1
../../source/gcc/fortran/trans-expr.c:9204
0x678d35 trans_code
../../source/gcc/fortran/trans.c:1674
0x6eea43 gfc_trans_if_1
../../source/gcc/fortran/trans-stmt.c:1106
0x6f58ea gfc_trans_if(gfc_code*)
../../source/gcc/fortran/trans-stmt.c:1137
0x678b57 trans_code
../../source/gcc/fortran/trans.c:1771
0x6f78d4 gfc_trans_do_while(gfc_code*)
../../source/gcc/fortran/trans-stmt.c:2083
0x678b07 trans_code
../../source/gcc/fortran/trans.c:1791
0x6a69bf gfc_generate_function_code(gfc_namespace*)
../../source/gcc/fortran/trans-decl.c:5884
0x67d1d1 gfc_generate_module_code(gfc_namespace*)
../../source/gcc/fortran/trans.c:2045
0x63449d translate_all_program_units
../../source/gcc/fortran/parse.c:5506
0x63449d gfc_parse_file()
../../source/gcc/fortran/parse.c:5724
0x675792 gfc_be_parse_file
../../source/gcc/fortran/f95-lang.c:209

[Bug c++/66921] failure to determine size of static constexpr array that is nested within a templated class

[billydonahue at google dot com]

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

Billy Donahue  changed:

   What|Removed |Added

 CC||billydonahue at google dot com

--- Comment #2 from Billy Donahue  ---
(In reply to Vlad Petric from comment #0)
> Created attachment 36010 [details]
> straightforward file (include-less) that fails to compile
> 
> template
> struct Holder {
>   constexpr static const int array[] = { 1, 2, 3 };
>   enum {F = array[0]};
> };
> 
> class HI: public Holder {};
> 
> gcc 4.9.3/Centos linux.
> 
> $ g++ -std=c++11 ./x.cc -o x.o -c
> ./x.cc: In instantiation of ‘constexpr const int Holder::array []’:
> ./x.cc:4:18:   required from ‘struct Holder’
> ./x.cc:7:18:   required from here
> ./x.cc:3:30: error: initializer fails to determine size of
> ‘Holder::array’
>constexpr static const int array[] = { 1, 2, 3 };
>   ^
> ./x.cc:3:30: error: array must be initialized with a brace-enclosed
> initializer
> ./x.cc: In instantiation of ‘struct Holder’:
> ./x.cc:7:18:   required from here
> ./x.cc:4:8: error: enumerator value for ‘F’ is not an integer constant
>enum {F = array[0]};
> 
> 
> 
> * with gcc 4.8.3, it compiles just fine.
> 
> * if I remove the template, it also compiles just fine:
> 
> struct Holder {
>   constexpr static const int array[] = { 1, 2, 3 };
>   enum {F = array[0]};
> };
> 
> class HI: public Holder {};

I little bit of trial-and-error on gcc.godbolt.org confirms this is a problem
in gcc in the v4.9 series and beyond to the current v5.2, not a problem in the
v4.8 series.
http://goo.gl/li99SI

Clang compiles it okay, FWIW.

If I explicitly size the array[3], then all gcc's will compile it fine.

template
struct Holder {
  // builds in modern gcc as long as the 3 is specified.
  constexpr static int array[3] = { 123, 234, 345 };
  enum {F = array[0]};
};
Holder inst{};

[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Vittorio Zecca from comment #0)
> ! gcc-5.2.0/gcc/fortran/trans-expr.c:5701:19: runtime error: member call on
> null pointer of type 'struct vec'
> ! gfortran source line "retargs->splice (arglist);"
> ! retargs is NULL
> ! double check with "gcc_assert(retargs);" immediately before
>   call sub 
>   END

What compiler options?  What target?  What is sub?

With 

subroutine sub
end subroutine sub

gfortran 6.0 and 5.2.1 compile, link your code, and executes
without an error.

[Bug bootstrap/66947] New: Bootstrap error: Extraneous text after `else' directive

[skunk at iskunk dot org]

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

Bug ID: 66947
   Summary: Bootstrap error: Extraneous text after `else'
directive
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skunk at iskunk dot org
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu

Bootstrapping 5.2.0 on a 64-bit Linux system:

[...]
config.status: linking /home/src/gcc-5.2.0/libgcc/config/i386/sfp-machine.h to
sfp-machine.h
config.status: linking /home/src/gcc-5.2.0/libgcc/gthr-posix.h to
gthr-default.h
config.status: executing default commands
gmake[3]: Entering directory `/tmp/gcc-build/x86_64-unknown-linux-gnu/libgcc'
/home/src/gcc-5.2.0/libgcc/config/t-softfp:106: Extraneous text after `else'
directive
/home/src/gcc-5.2.0/libgcc/config/t-softfp:113: *** only one `else' per
conditional.  Stop.
gmake[3]: Leaving directory `/tmp/gcc-build/x86_64-unknown-linux-gnu/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


$ gmake --version
GNU Make 3.80
Copyright (C) 2002  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.


I think the "else ifneq ..." construct in the t-softfp file requires a newer
version of GNU Make. (The GCC "Prerequisites" page indicates that version 3.80
is sufficient.)

[Bug target/66217] PowerPC rotate/shift/mask instructions not optimal

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Mon Jul 20 16:30:56 2015
New Revision: 226005

URL: https://gcc.gnu.org/viewcvs?rev=226005&root=gcc&view=rev
Log:
PR target/66217
* config/rs6000/constraints.md ("S", "T", "t"): Delete.  Update
"available letters" comment.
* config/rs6000/predicates.md (mask_operand, mask_operand_wrap,
mask64_operand, mask64_2_operand, any_mask_operand, and64_2_operand,
and_2rld_operand):  Delete.
(and_operand): Adjust.
(rotate_mask_operator): New.
* config/rs6000/rs6000-protos.h (build_mask64_2_operands,
includes_lshift_p, includes_rshift_p, includes_rldic_lshift_p,
includes_rldicr_lshift_p, insvdi_rshift_rlwimi_p, extract_MB,
extract_ME): Delete.
(rs6000_is_valid_mask, rs6000_is_valid_and_mask,
rs6000_is_valid_shift_mask, rs6000_is_valid_insert_mask,
rs6000_insn_for_and_mask, rs6000_insn_for_shift_mask,
rs6000_insn_for_insert_mask, rs6000_is_valid_2insn_and,
rs6000_emit_2insn_and): New.
* config/rs6000/rs6000.c (num_insns_constant): Adjust.
(build_mask64_2_operands, includes_lshift_p, includes_rshift_p,
includes_rldic_lshift_p, includes_rldicr_lshift_p,
insvdi_rshift_rlwimi_p, extract_MB, extract_ME): Delete.
(rs6000_is_valid_mask, rs6000_is_valid_and_mask,
rs6000_insn_for_and_mask, rs6000_is_valid_shift_mask,
s6000_insn_for_shift_mask, rs6000_is_valid_insert_mask,
rs6000_insn_for_insert_mask, rs6000_is_valid_2insn_and,
rs6000_emit_2insn_and): New.
(print_operand) <'b', 'B', 'm', 'M', 's', 'S', 'W'>: Delete.
(rs6000_rtx_costs) : Delete mask_operand and mask64_operand
handling.
: Don't fall through to next case.
: Handle the various rotate-and-mask cases directly.
: Always cost as one insn.
* config/rs6000/rs6000.md (splitter for bswap:SI): Adjust.
(and3): Adjust expander for the new patterns.
(and3_imm, and3_imm_dot, and3_imm_dot2,
and3_imm_mask_dot, and3_imm_mask_dot2): Adjust condition.
(*and3_imm_dot_shifted): New.
(*and3_mask): Delete, rewrite as ...
(and3_mask): ... New.
(*and3_mask_dot, *and3_mask_dot): Rewrite.
(andsi3_internal0_nomc): Delete.
(*andsi3_internal6): Delete.
(*and3_2insn): New.
(insv, insvsi_internal, *insvsi_internal1, *insvsi_internal2,
*insvsi_internal3, *insvsi_internal4, *insvsi_internal5,
*insvsi_internal6, insvdi_internal, *insvdi_internal2,
*insvdi_internal3): Delete.
(*rotl3_mask, *rotl3_mask_dot, *rotl3_mask_dot2,
*rotl3_insert, *rotl3_insert_2, *rotl3_insert_3,
*rotl3_insert_4, two splitters for multi-precision shifts,
*ior_mask): New.
(extzv, extzvdi_internal, *extzvdi_internal1, *extzvdi_internal2,
*rotlsi3_mask, *rotlsi3_mask_dot, *rotlsi3_mask_dot2,
*ashlsi3_imm_mask, *ashlsi3_imm_mask_dot, *ashlsi3_imm_mask_dot2,
*lshrsi3_imm_mask, *lshrsi3_imm_mask_dot, *lshrsi3_imm_mask_dot2):
Delete.
(ashr3): Delete expander.
(*ashr3): Rename to ...
(ashr3): ... This.
(ashrdi3_no_power, *ashrdisi3_noppc64be): Delete.
(*rotldi3_internal4, *rotldi3_internal5 and split,
*rotldi3_internal6 and split, *ashldi3_internal4, ashldi3_internal5
and split, *ashldi3_internal6 and split, *ashldi3_internal7,
ashldi3_internal8 and split, *ashldi3_internal9 and split): Delete.
(*anddi3_2rld, *anddi3_2rld_dot, *anddi3_2rld_dot2): Delete.
(splitter for loading a mask): Adjust.
* doc/md.texi (Machine Constraints): Remove q, S, T, t constraints.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/constraints.md
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/doc/md.texi

[Bug tree-optimization/66946] New: Spurious uninitialized warning

[wdijkstr at arm dot com]

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

Bug ID: 66946
   Summary: Spurious uninitialized warning
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

Created attachment 36016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36016&action=edit
preprocessed iso-2022-cn-ext.c

Since recently (around May) GCC6 has started to emit spurious uninitialized
warnings. An example from building GLIBC (compiled attached pp file with -O2
-Wall -c out.i):

In file included from iso-2022-cn-ext.c:659:0:
../iconv/skeleton.c: In function 'gconv':
../iconv/loop.c:325:295: warning: '*((void *)&buf+1)' is used uninitialized in
this function [-Wuninitialized]
../iconv/loop.c:325:295: warning: 'buf' is used uninitialized in this function
[-Wuninitialized]
../iconv/loop.c:325:295: warning: '*((void *)&buf+1)' is used uninitialized in
this function [-Wuninitialized]
../iconv/loop.c:325:295: warning: 'buf' is used uninitialized in this function
[-Wuninitialized]
In file included from iso-2022-cn-ext.c:659:0:
../iconv/loop.c:435:295: warning: '*((void *)&buf+1)' is used uninitialized in
this function [-Wuninitialized]
../iconv/loop.c:435:295: warning: 'buf' is used uninitialized in this function
[-Wuninitialized]

I checked the control flow and it seems correct.
glibc/iconvdata/iso-2022-cn-ext.c calls one of ucs4_to_gb2312, ucs4_to_isoir165
and ucs4_to_cns11643l1 at lines 432-447 - buf is not written if
__UNKNOWN_10646_CHAR is returned. In that case however the if statement is
executed which does eventually set buf[0] and buf[1]. There is no warning if
inlining is disabled, so it is caused by the ucs4_* inline functions not always
setting buf.

[Bug c++/66944] static thread_local member in class template may cause compilation to fail

[zhykzhykzhyk at gmail dot com]

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

zhykzhykzhyk at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |major

[Bug middle-end/66945] New: ICE in generic_simplify (generic-match.c:24790)

[antoine.balestrat at gmail dot com]

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

Bug ID: 66945
   Summary: ICE in generic_simplify (generic-match.c:24790)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoine.balestrat at gmail dot com
  Target Milestone: ---

Hello !

This very pathological testcase seems to trigger an ICE with a freshly built
gcc.

$ xgcc --version
gcc (GCC) 6.0.0 20150720 (experimental)

$ cat tested.c
unsigned b;
f()
{
for(;;)
if(!b?:(b=0));
else if(b%0http://gcc.gnu.org/bugs.html> for instructions.

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

[keith.marshall at mailinator dot com]

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

--- Comment #10 from Keith Marshall  ---
(In reply to Andrew Pinski from comment #9)
> Well it is a libgfortran bug yes.

Which, being pedantic, makes it a GCC bug, because libgfortran is a component
of GCC.

>  What we could do add to io/unix.c:
> #if MINGW && !defined(S_IRWXG)
> #define S_IRWXG 0
> #endif
> #if MINGW && !defined(S_IRWXO)
> #define S_IRWXO 0
> #endif
> 
> And that will allow it to work correctly.

Conceptually, yes; you'd actually need to test on __MINGW32__, or maybe even
more generically on _WIN32, rather than on (nonexistent) MINGW.  However, that
seems every bit as much of a kludge as my own work-around.  Realistically,
calling umask() in this context on native windows would seem to be completely
redundant anyway; I can't see how it will actually achieve anything, since all
it will do will be to reproduce the already existing state, at the time of the
call.

[Bug c++/66944] New: static thread_local member in class template may cause compilation to fail

[zhykzhykzhyk at gmail dot com]

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

Bug ID: 66944
   Summary: static thread_local member in class template may cause
compilation to fail
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhykzhykzhyk at gmail dot com
  Target Milestone: ---

Affect Versions: 4.9.3, 5.1.0, 5.2.0

Expected behavior:
  compiles correctly (like clang does)

Compiler output:
bug.cc:14:34: error: redefinition of 'bool __tls_guard'
 thread_local std::vector A::v;
  ^
bug.cc:14:34: note: 'bool __tls_guard' previously declared here
bug.cc:14: confused by earlier errors, bailing out

== code ==
struct Heavy { Heavy(){} };

template 
struct A {
  virtual void foo() { v; }
  static thread_local Heavy v;
};

template 
thread_local Heavy A::v;

struct E {};
struct F {};

int main() {
  A foo;
  A bar;
  bar.v;
}
==

[Bug tree-optimization/66926] [6 regression] FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (internal compiler error)

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

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

--- Comment #3 from Andreas Schwab  ---
See .  The sources are
available in .

[Bug tree-optimization/66372] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #4 from James Greenhalgh  ---
I think this is the same issue as I spotted in the larger testcase.

Looking at the cancelled jumps:

  trunk/foo.c.096t.dom1:  Cancelling jump thread: (6, 8) incoming edge;  (8,
13) joiner;  (13, 9) normal;
  trunk/foo.c.096t.dom1:  Cancelling jump thread: (7, 9) incoming edge;  (9,
13) joiner;  (13, 10) normal;

With r223448 reverted:

  reverted/small.c.096t.dom1:  Cancelling jump thread: (6, 8) incoming edge; 
(8, 13) joiner;  (13, 9) normal;
  reverted/small.c.096t.dom1:  Cancelling jump thread: (7, 9) incoming edge; 
(9, 13) joiner;  (13, 10) normal;
  reverted/small.c.096t.dom1:  Cancelling jump thread: (2, 3) incoming edge; 
(3, 4) joiner;  (4, 5) normal;

If we fail to cancel 2 --> 3 to 5, we will probably end up in trouble given the
other blocks we've threaded through:

  trunk/small.c.096t.dom1:  Threaded jump 6 --> 10 to 16
  trunk/small.c.096t.dom1:  Threaded jump 7 --> 10 to 16
  trunk/small.c.096t.dom1:  Threaded jump 15 --> 13 to 17
  trunk/small.c.096t.dom1:  Threaded jump 8 --> 13 to 17
  trunk/small.c.096t.dom1:  Threaded jump 3 --> 4 to 15
  trunk/small.c.096t.dom1:  Threaded jump 14 --> 13 to 16
  trunk/small.c.096t.dom1:  Threaded jump 9 --> 13 to 16

And taking a look at the path we're processing just before the ICE, it does
start (2, 3).

[Bug tree-optimization/66926] [6 regression] FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (internal compiler error)

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
Could somebody provides me with an instruction how to build trunk (fresh)
compiler with graphite?

Thanks.

[Bug tree-optimization/66372] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #3 from James Greenhalgh  ---
Possibly related to this report on gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01649.html

[Bug target/66912] Copy relocation against protected symbol doesn't work

[nsz at gcc dot gnu.org]

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

--- Comment #2 from nsz at gcc dot gnu.org ---
protected only means it cannot be overridden.

so we know the symbol will be resolved to the local one,
however it may be visible externally and then the address
must be the same in the other modules which is a problem
if the main executable has a copy reloc against this symbol.

[Bug c++/55095] Wshift-overflow

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #13 from Marek Polacek  ---
Implemented for GCC 6.

[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> Will test that once the current build of r223346 has finished.

Another hint is a changelog entry for the Debian package 5.1.1-11:

 * Build with -O1 on sh4 (try to work around PR target/66358).

So it *might* be a combination of PR/65979 and using -O1 instead of -O2.

Adrian

[Bug c++/55095] Wshift-overflow

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jul 20 13:43:45 2015
New Revision: 225998

URL: https://gcc.gnu.org/viewcvs?rev=225998&root=gcc&view=rev
Log:
PR c++/55095
* c-common.c (c_fully_fold_internal): Warn about left shift overflows.
Use EXPR_LOC_OR_LOC.
(maybe_warn_shift_overflow): New function.
* c-common.h (maybe_warn_shift_overflow): Declare.
* c-opts.c (c_common_post_options): Set warn_shift_overflow.
* c.opt (Wshift-overflow): New option.

* c-typeck.c (digest_init): Pass OPT_Wpedantic to pedwarn_init.
(build_binary_op): Warn about left shift overflows.

* typeck.c (cp_build_binary_op): Warn about left shift overflows.

* doc/invoke.texi: Document -Wshift-overflow and -Wshift-overflow=.

* c-c++-common/Wshift-overflow-1.c: New test.
* c-c++-common/Wshift-overflow-2.c: New test.
* c-c++-common/Wshift-overflow-3.c: New test.
* c-c++-common/Wshift-overflow-4.c: New test.
* c-c++-common/Wshift-overflow-5.c: New test.
* g++.dg/cpp1y/left-shift-1.C: New test.
* gcc.dg/c90-left-shift-2.c: New test.
* gcc.dg/c90-left-shift-3.c: New test.
* gcc.dg/c99-left-shift-2.c: New test.
* gcc.dg/c99-left-shift-3.c: New test.
* gcc.dg/pr40501.c: Use -Wno-shift-overflow.
* gcc.c-torture/execute/pr40386.c: Likewise.
* gcc.dg/vect/pr33373.c: Likewise.
* gcc.dg/vect/vect-shift-2-big-array.c: Likewise.
* gcc.dg/vect/vect-shift-2.c: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/Wshift-overflow-1.c
trunk/gcc/testsuite/c-c++-common/Wshift-overflow-2.c
trunk/gcc/testsuite/c-c++-common/Wshift-overflow-3.c
trunk/gcc/testsuite/c-c++-common/Wshift-overflow-4.c
trunk/gcc/testsuite/c-c++-common/Wshift-overflow-5.c
trunk/gcc/testsuite/g++.dg/cpp1y/left-shift-1.C
trunk/gcc/testsuite/gcc.dg/c90-left-shift-2.c
trunk/gcc/testsuite/gcc.dg/c90-left-shift-3.c
trunk/gcc/testsuite/gcc.dg/c99-left-shift-2.c
trunk/gcc/testsuite/gcc.dg/c99-left-shift-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/pr40386.c
trunk/gcc/testsuite/gcc.dg/pr40501.c
trunk/gcc/testsuite/gcc.dg/vect/pr33373.c
trunk/gcc/testsuite/gcc.dg/vect/vect-shift-2-big-array.c
trunk/gcc/testsuite/gcc.dg/vect/vect-shift-2.c

[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #2)
> r223346 isn't affected either, 5.1.1-6 is still building and already got
> past gengtype.c in stage 2.

Going through the other logs while r223346 is still building, r224724 *is*
affected. So unless the bug is somewhere else, it has to be an issue with 
PR/65979 or PR/66611.

Will test that once the current build of r223346 has finished.

Adrian

[Bug target/66912] Copy relocation against protected symbol doesn't work

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw  ---
Erm, isn't that the whole point of marking the symbol 'protected'?

>From the ELF spec:


STV_PROTECTED
A symbol defined in the current component is protected if it is visible in
other components but not preemptable, meaning that any reference to such a
symbol from within the defining component must be resolved to the definition in
that component, even if there is a definition in another component that would
preempt by the default rules. A symbol with STB_LOCAL binding may not have
STV_PROTECTED visibility. If a symbol definition with STV_PROTECTED visibility
from a shared object is taken as resolving a reference from an executable or
another shared object, the SHN_UNDEF symbol table entry created has STV_DEFAULT
visibility.


If we know it will resolve to the definition inside this DSO, then we don't
need to indirect via the GOT to address it.

[Bug fortran/66035] [5/6 Regression] gfortran ICE segfault

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from vehre at gcc dot gnu.org ---
Fixed, closing.

[Bug fortran/64589] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from vehre at gcc dot gnu.org ---
Fixed, closing.

[Bug c/66918] Disable "inline function declared but never defined" warning

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #5)
> I don't think the C++ FE has this warning; it's about C99 inlines.

If not, it has a very similar warning:

/home/manuel/test.cc:1:13: warning: inline function ‘void test()’ used but
never defined
 inline void test(void);
 ^

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

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #17 from Wilco  ---
Well there seem to be 2 ways to address this:

* If a function is huge, emit literals as const data. This enables the use of
anchors and sharing of literals across all functions in a compilation unit.

* Reserve a register in the adr/ldr literal patterns and add a 2-instruction
sequence using adrp when out of range. Ideally the register should only be
reserved if a function is huge.

[Bug c/66918] Disable "inline function declared but never defined" warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
I don't think the C++ FE has this warning; it's about C99 inlines.

I think this should not be a part of -Wunused-function, maybe just a part of
-Wpedantic warning.

[Bug fortran/66929] [6 regression] ICE with iso_varying_string

[mikael at gcc dot gnu.org]

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

--- Comment #3 from Mikael Morin  ---
Reduced test:

module iso_varying_string
  type, public :: varying_string
 character(LEN=1), dimension(:), allocatable :: chars
  end type varying_string
  interface operator(/=)
 module procedure op_ne_VS_CH
  end interface operator (/=)
  interface trim
 module procedure trim_
  end interface
contains
  elemental function op_ne_VS_CH (string_a, string_b) result (op_ne)
type(varying_string), intent(in) :: string_a
character(LEN=*), intent(in) :: string_b
logical  :: op_ne
  end function op_ne_VS_CH
  elemental function trim_ (string) result (trim_string)
type(varying_string), intent(in) :: string
type(varying_string) :: trim_string
  end function trim_
end module iso_varying_string
module syntax_rules
  use iso_varying_string, string_t => varying_string
contains
  subroutine set_rule_type_and_key ()
type(string_t) :: key
if (trim (key) /= "") then
end if
  end subroutine set_rule_type_and_key
end module syntax_rules

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #8 from Jeffrey Walton  ---
(In reply to Jeffrey Walton from comment #6)
> > Maybe it could be in effect with `-Wextra`?
> 
> That would just move the problem somewhere else instead of fixing it. Many
> people do compile with -Wall -Wextra (like GCC itself).

Yeah, but it works for me :) But more seriously, I understand what you are
saying. When I have the luxury of a new project, I use -Wall -Wextra
-Wconversion.

> 
> > Enabling Unknown Pragma warnings for #pragma omp under -Wall when the
> > compiler supports it, coupled with the inability to manage warnings with
> > 'pragma GCC diagnostic` (Bug #53431), means we just turned OFF -Wall. We are
> > moving in the wrong direction :(
> 
> You could always use -Wall -Wno-unknown-pragmas, but yes, fixing PR53431
> seems the key here. I hope someone finds time to do that before GCC 6 closes
> for development.

-Wno-unknown-pragmas is just one of many we need. Others appear to include
-Wunused-variable, -Wunused-value and -Wunused-function. And we are no longer
managing the warnings in the source code through a GCC diagnostic block;
rather, we are polluting the command line.

We produce a library, so we not only pollute our command line, we polute the
user's command line. That's after the user complains about it because GCC
diagnostic block don't "just work".

Does GCC have a Bounty program? If so, I'd be happy to make a donation. I'd
even solicit a for grants because `-Wall` and managing warnings is *that*
important. I feel awful that we yanked it for GCC.

On the good side, our sources are cross-compiler and cross-platform, So we are
effectively using -Wall for MSVC, Clang and ICC. But others don't have that
luxury. For example, the Asterisk project uses trampolines, so the code does
not compile under Clang (and it could never compile under MSVC).

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Jeffrey Walton from comment #6)
> Maybe it could be in effect with `-Wextra`?

That would just move the problem somewhere else instead of fixing it. Many
people do compile with -Wall -Wextra (like GCC itself).

> Enabling Unknown Pragma warnings for #pragma omp under -Wall when the
> compiler supports it, coupled with the inability to manage warnings with
> 'pragma GCC diagnostic` (Bug #53431), means we just turned OFF -Wall. We are
> moving in the wrong direction :(

You could always use -Wall -Wno-unknown-pragmas, but yes, fixing PR53431 seems
the key here. I hope someone finds time to do that before GCC 6 closes for
development.

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

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #16 from Jiong Wang  ---
Have done a quick look at this, basic ideas to fix this:

  * generate a special pattern which initialize literal pool start address.
  * implement TARGET_MACHINE_DEPENDENT_REORG to calculate whehter the
pc-relative literal load is within range.
  * output final insruction sequences which initializing literal pool start
address based on the result from reorg pass analysis. Use movk/z, adrp +
add,
single adr for different distance.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #6 from Jeffrey Walton  ---
(In reply to Manuel López-Ibáñez from comment #5)
> ...
> For what is worth, I understand the point by Andrew that without -fopenmp,
> the #pragmas are effectively ignored, thus the warning seems useful. Perhaps
> it would be more useful a specific -Wopenmp-pragmas  that says:
> 

Maybe it could be in effect with `-Wextra`?

Enabling Unknown Pragma warnings for #pragma omp under -Wall when the compiler
supports it, coupled with the inability to manage warnings with 'pragma GCC
diagnostic` (Bug #53431), means we just turned OFF -Wall. We are moving in the
wrong direction :(

[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64

[vekumar at gcc dot gnu.org]

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

--- Comment #10 from vekumar at gcc dot gnu.org ---
With the patch I get 
loop:
adrpx0, array
ldr q1, .LC0
ldr q2, .LC1
adrpx1, ptrs
add x1, x1, :lo12:ptrs
ldr x0, [x0, #:lo12:array]
dup v0.2d, x0
add v1.2d, v0.2d, v1.2d <== vectorized
add v0.2d, v0.2d, v2.2d <== vectorized
str q1, [x1]
str q0, [x1, 16]
ret
.size   loop, .-loop
.align  4
.LC0:
.xword  0
.xword  16
.align  4
.LC1:
.xword  32
.xword  48

[Bug target/65952] [AArch64] Will not vectorize storing induction of pointer addresses for LP64

[vekumar at gcc dot gnu.org]

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

vekumar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vekumar at gcc dot gnu.org

--- Comment #9 from vekumar at gcc dot gnu.org ---
As per Richards, suggestion I added a pattern in vector recog.
This seems to vectorize the this PR. 

However I need some help on the following  

(1)How do I check the shift amount and also care about type/signedness.  There
could be different shift amounts allowed in the target architecture when
looking for power 2 constants.

(2)Should I need to check if target architecture supports vectorized shifts
before converting the pattern?

---Patch---
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index f034635..995c9b2 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -76,6 +76,10 @@ static gimple vect_recog_vector_vector_shift_pattern
(vec *,
  tree *, tree *);
 static gimple vect_recog_divmod_pattern (vec *,
 tree *, tree *);
+
+static gimple vect_recog_multconst_pattern (vec *,
+ tree *, tree *);
+
 static gimple vect_recog_mixed_size_cond_pattern (vec *,
  tree *, tree *);
 static gimple vect_recog_bool_pattern (vec *, tree *, tree *);
@@ -90,6 +94,7 @@ static vect_recog_func_ptr
vect_vect_recog_func_ptrs[NUM_PATTERNS] = {
vect_recog_rotate_pattern,
vect_recog_vector_vector_shift_pattern,
vect_recog_divmod_pattern,
+vect_recog_multconst_pattern,
vect_recog_mixed_size_cond_pattern,
vect_recog_bool_pattern};

@@ -2147,6 +2152,90 @@ vect_recog_vector_vector_shift_pattern (vec
*stmts,
   return pattern_stmt;
 }

+static gimple
+vect_recog_multconst_pattern (vec *stmts,
+   tree *type_in, tree *type_out)
+{
+  gimple last_stmt = stmts->pop ();
+  tree oprnd0, oprnd1, vectype, itype, cond;
+  gimple pattern_stmt, def_stmt;
+  enum tree_code rhs_code;
+  stmt_vec_info stmt_vinfo = vinfo_for_stmt (last_stmt);
+  loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
+  bb_vec_info bb_vinfo = STMT_VINFO_BB_VINFO (stmt_vinfo);
+  optab optab;
+  tree q;
+  int dummy_int, prec;
+  stmt_vec_info def_stmt_vinfo;
+
+  if (!is_gimple_assign (last_stmt))
+return NULL;
+
+  rhs_code = gimple_assign_rhs_code (last_stmt);
+  switch (rhs_code)
+{
+case MULT_EXPR:
+  break;
+default:
+  return NULL;
+}
+
+  if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
+return NULL;
+
+  oprnd0 = gimple_assign_rhs1 (last_stmt);
+  oprnd1 = gimple_assign_rhs2 (last_stmt);
+  itype = TREE_TYPE (oprnd0);
+  if (TREE_CODE (oprnd0) != SSA_NAME
+  || TREE_CODE (oprnd1) != INTEGER_CST
+  || TREE_CODE (itype) != INTEGER_TYPE
+  || TYPE_PRECISION (itype) != GET_MODE_PRECISION (TYPE_MODE (itype)))
+return NULL;
+  vectype = get_vectype_for_scalar_type (itype);
+  if (vectype == NULL_TREE)
+return NULL;
+
+  /* If the target can handle vectorized division or modulo natively,
+ don't attempt to optimize this.  */
+  optab = optab_for_tree_code (rhs_code, vectype, optab_default);
+  if (optab != unknown_optab)
+{
+  machine_mode vec_mode = TYPE_MODE (vectype);
+  int icode = (int) optab_handler (optab, vec_mode);
+  if (icode != CODE_FOR_nothing)
+return NULL;
+}
+
+  prec = TYPE_PRECISION (itype);
+  if (integer_pow2p (oprnd1))
+{
+  /*if (TYPE_UNSIGNED (itype) || tree_int_cst_sgn (oprnd1) != 1)
+return NULL;
+ */
+
+  /* Pattern detected.  */
+  if (dump_enabled_p ())
+dump_printf_loc (MSG_NOTE, vect_location,
+ "vect_recog_multconst_pattern: detected:\n");
+
+  tree shift;
+
+  shift = build_int_cst (itype, tree_log2 (oprnd1));
+  pattern_stmt
+= gimple_build_assign (vect_recog_temp_ssa_var (itype, NULL),
+   LSHIFT_EXPR, oprnd0, shift);
+  if (dump_enabled_p ())
+dump_gimple_stmt_loc (MSG_NOTE, vect_location, TDF_SLIM, pattern_stmt,
+  0);
+
+ stmts->safe_push (last_stmt);
+
+  *type_in = vectype;
+  *type_out = vectype;
+  return pattern_stmt;
+   } 
+return NULL;
+}
 /* Detect a signed division by a constant that wouldn't be
otherwise vectorized:

diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
index 48c1f8d..833fe4b 100644
--- a/gcc/tree-vectorizer.h
+++ b/gcc/tree-vectorizer.h
@@ -1131,7 +1131,7 @@ extern void vect_slp_transform_bb (basic_block);
Additional pattern recognition functions can (and will) be added
in the future.  */
 typedef gimple (* vect_recog_func_ptr) (vec *, tree *, tree *);
-#define NUM_PATTERNS 12
+#define 

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
(In reply to Mikael Morin from comment #9)
> The components are deallocated after the containing object.
> Draft patch:

Yes, this fixes the testsuite failure for me.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Jeffrey Walton from comment #4)
> (For what its worth, I understand the compiler writers are always right.
> They are demi-gods in my little corner of the universe :)

You can also be a compiler writer:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

For what is worth, I understand the point by Andrew that without -fopenmp, the
#pragmas are effectively ignored, thus the warning seems useful. Perhaps it
would be more useful a specific -Wopenmp-pragmas  that says:

 warning: ignoring '#pragma omp parallel' without '-fopenmp' [-Wopenmp-pragmas]

But it seems more important to fix PR53431, if someone has time for that.

The zero-column ":0" in the diagnostic is also a bug.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #15 from Andrew Pinski  ---
Not working on this any time soon.  But someone from ARM really should look
into fixing this as it blocks standard C/C++ code from HPC and distros.

[Bug middle-end/66915] [6 Regression] FAIL: gcc.dg/fixed-point/unary.c execution test on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 36015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36015&action=edit
Diff between good and bad versions of the assembly

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez  ---
(In reply to Allan Chandler from comment #11)
> Now you've done it. This was reported over three years ago and now it's
> affected someone on Stack Overflow. You guys are in for it now :-)

Unfortunately, the C/C++ FEs in GCC have very very few developers relative to
their importance and amount work they require. There is a patch in comment #10,
but it requires some additional work for which I do not have enough free time.
If you or someone else has some free time to finish this work, this is how I
would proceed:

1. Try to figure out why the preprocessor removes the pragmas (and not other
#-directives)
2. If you cannot figure it out, ask in gcc@ with explicit CC to C/C++/libcpp
maintainers (see MAINTAINERS file).
3. Complete the patch, bootstrap®ression test, add a Changelog, submit to
gcc-patches and ping until it is approved.

More details:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

Otherwise, given that this hasn't been fixed in more than 4 years (see
PR48914), it seems likely that active developers have higher priority things to
work on and it will remain unfixed until some new volunteer steps up to the
task.

If/When I have a little free time to work on GCC, there are at least a couple
of other bugs I would rather fix before this one.

[Bug preprocessor/66932] Preprocessor includes wrong header file

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
An empty : causes the current directory to be added.

[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #1)
> (In reply to John Paul Adrian Glaubitz from comment #0)
> > As previously discussed in private mail, I am now filing a bug report for
> > the regression in gcc-5 that was introduced somewhere between r222550 and
> > r225710 which leads to the miscompilation of gcc/gengtype.c when building a
> > native compiler on SH [1]:
> 
> Looking at the SVN log for gcc-5-branch:
>svn log -r222550:r225710

r223346 isn't affected either, 5.1.1-6 is still building and already got past
gengtype.c in stage 2.

Adrian

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gcc.hall at gmail dot com]

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

--- Comment #17 from Jeremy  ---
Did you mean "stc" rather than "setc" ???

But yes, it looks like its working well.

On 20 July 2015 at 10:05, gccbugzilla at limegreensocks dot com <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
>
> --- Comment #16 from David  ---
> I've tried it now and it seems to do good things.  This code:
>
> int main(int argc, char *argv[])
> {
>char x;
>
>asm("setc" : "=@ccc"(x));
>
>if (!x)
>   return 6;
>else
>   return argc;
> }
>
> produces this output (-O3):
>
> movl$6, %eax
> /APP
>  # 6 "./r.cpp" 1
> setc
>  # 0 "" 2
> /NO_APP
> cmovc   %ebx, %eax
> addq$32, %rsp
> popq%rbx
> ret
>
> Although a minor variation (change "return argc" to "return 7") ends up
> doing
> setc+cmpb, so it's not a perfect solution.
>
> Still, if I were Richard, I'd be closing this bug.  If someone has
> optimization
> issues with his solution, that's a new bug.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Keith Marshall from comment #8)
> (In reply to kargl from comment #7)
> > So add
> > 
> > #define S_IRWXG 0
> > #define S_IRWXO 0
> > 
> > to the header file wherever mingw defines the available mask bits
> > for umask(3).  The bug is clearly in mingw were it gratuitously maps
> > umask() to _umask() without properly adding the mappings for the
> > mode_t argument bits of umask(3).
> 
> Absolutely not!  Those bits are utterly irrelevant for the windows (MinGW)
> platform; to add them would be do nothing more than create confusion.  The
> mask bits for umask(), on the windows platform are S_IREAD | S_IWRITE; those
> are the only mask bits YOUR code should be passing to non-POSIX
> umask(5axxx3be.aspx).
> 
> This is NOT a MinGW bug; it's a GCC bug, and that's where it should be
> fixed.  Until you do fix it, I have my work-around, (which I'm perfectly
> willing to publish in MinGW forked source for GCC, prominently commented as
> a ghastly hack to circumvent a gross upstream GCC bug).


Well it is a libgfortran bug yes.  What we could do add to io/unix.c:
#if MINGW && !defined(S_IRWXG)
#define S_IRWXG 0
#endif
#if MINGW && !defined(S_IRWXO)
#define S_IRWXO 0
#endif

And that will allow it to work correctly.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #4 from Jeffrey Walton  ---
(In reply to Andrew Pinski from comment #3)
> The warning is correct though, maybe it should add a message about needing
> -fopenmp to have them to be known.

>From a dumb user's point of view (folks like me): that behavior squashes a lot
of the benefit of cross-platform sources and using parallel tasks.

I think the OpenMP folks feel about the same. From
http://openmp.org/wp/openmp-specifications/ and
http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf:

Each directive starts with #pragma omp. The remainder of the
directive follows the conventions of the C and C++ standards
for compiler directives. In particular, white space can be
used before and after the #, and sometimes white space must
be used to separate the words in a directive. Preprocessing
tokens following the #pragma omp are subject to macro
replacement. 

There's no expectation that a conforming compiler will issue a warning for
#pragma omp when -fopenmp is not in effect. In fact, I can't find authority to
issue a warning from a conforming compiler.

I think it would be much better to always accept `#pragma omp` *if* the
compiler supports OpenMP, regardless of the status of `-fopenmp`. Conversely,
if the compiler does not support OpenMP, then always issue an unknown pragma
warning (modulo expected behavior of the diagnostic).

Speaking from experience, OpenBSD and Cygwin get into an odd area where they
advertise support for OpenMP by accepting -fopenmp and defining _OPENMP, but
then fail to compile the program. But I think that's a different issue.

(For what its worth, I understand the compiler writers are always right. They
are demi-gods in my little corner of the universe :)

[Bug inline-asm/49611] Inline asm should support input/output of flags

[gccbugzilla at limegreensocks dot com]

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

--- Comment #16 from David  ---
I've tried it now and it seems to do good things.  This code:

int main(int argc, char *argv[])
{
   char x;

   asm("setc" : "=@ccc"(x));

   if (!x)
  return 6;
   else
  return argc;
}

produces this output (-O3):

movl$6, %eax
/APP
 # 6 "./r.cpp" 1
setc
 # 0 "" 2
/NO_APP
cmovc   %ebx, %eax
addq$32, %rsp
popq%rbx
ret

Although a minor variation (change "return argc" to "return 7") ends up doing
setc+cmpb, so it's not a perfect solution.

Still, if I were Richard, I'd be closing this bug.  If someone has optimization
issues with his solution, that's a new bug.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The warning is correct though, maybe it should add a message about needing
-fopenmp to have them to be known.

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #2 from Jeffrey Walton  ---
My bad... Here's the error message:

g++ -DNDEBUG -g2 -O3 -Wall -march=native -pipe -c nbtheory.cpp
nbtheory.cpp:655:0: warning: ignoring #pragma omp parallel [-Wunknown-pragmas]
  #pragma omp parallel
 ^
nbtheory.cpp:656:0: warning: ignoring #pragma omp sections [-Wunknown-pragmas]
   #pragma omp sections
 ^
...

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

--- Comment #1 from Jeffrey Walton  ---
I've experienced this issue on Cygwin i386 and x86_64 running GCC 4.8.1; Fedora
21 and 22, i386 and x86_64 running GCC 4.9 and 5.1, and a few others.

So it appears to be a widespread issue, and not an isolated case.

[Bug c++/66943] New: GCC warns of Unknown Pragma for OpenMP, even though it support it.

[noloader at gmail dot com]

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

Bug ID: 66943
   Summary: GCC warns of Unknown Pragma for OpenMP, even though it
support it.
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

The following source code results in a slew of Unknown Pragma messages. The
problem is, GCC supports OpenMP. GCC responds properly to -fopenmp, and even
defines _OPENMP when it encounters -fopenmp.

This is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431, and
managing warnings with pragmas when using -Wall. The relation to 53431 is: I
can't seem to get "pragma GCC diagnostic" to work to ignore the warnings when
-Wall is in effect.

// Defines GCC_DIAGNOSTIC_AWARE if GCC 4.7 or above.
#define GCC_DIAGNOSTIC_AWARE 1

#if GCC_DIAGNOSTIC_AWARE
# pragma GCC diagnostic ignored "-Wunknown-pragmas"
#endif

...
Integer ModularRoot(const Integer &a, const Integer &dp, const Integer &dq,
const Integer &p, const Integer &q, const Integer &u)
{
Integer p2, q2;
#pragma omp parallel
#pragma omp sections
{
#pragma omp section
p2 = ModularExponentiation((a % p), dp, p);
#pragma omp section
q2 = ModularExponentiation((a % q), dq, q);
}
return CRT(p2, p, q2, q, u);
}
...

**

To duplicate:

git clone https://github.com/weidai11/cryptopp.git cryptopp-warn
cd cryptopp-warn
export CXXFLAGS="-g2 -O3 -DNDEBUG -Wall"
make

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[allan.chandler at oakton dot com.au]

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

Allan Chandler  changed:

   What|Removed |Added

 CC||allan.chandler at oakton dot 
com.a
   ||u

--- Comment #11 from Allan Chandler  ---
http://stackoverflow.com/questions/31509434/gcc-does-not-honor-pragma-gcc-diagnostic-to-silence-warnings

Now you've done it. This was reported over three years ago and now it's
affected someone on Stack Overflow. You guys are in for it now :-)

[Bug middle-end/66931] ICE in convert_move, at expr.c:316

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-20
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #2 from Uroš Bizjak  ---
Confirmed  with [trunk revision 225993]

~/cc1plus -m32 -mno-sse pr66931.C
pr66931.C:5:1: warning: always_inline function might not be inlinable
[-Wattributes]
 counter(tcounter *self, long, long) {
 ^
ppr66931.C: In function ‘bool test_sp()’:
pr66931.C:6:25: internal compiler error: in convert_move, at expr.c:281
   *(v2di *)self + v2di{};
 ^
0xb83e07 convert_move(rtx_def*, rtx_def*, int)
/home/uros/gcc-svn/trunk/gcc/expr.c:281
0xb9aa13 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
/home/uros/gcc-svn/trunk/gcc/expr.c:5475
[...]


(gdb) f 2
#2  0x00b83e08 in convert_move (to=0x2e960eb8, from=0x2e9621e0,
unsignedp=0) at /home/uros/gcc-svn/trunk/gcc/expr.c:281
281   gcc_assert (from_mode != BLKmode);
(gdb) list
276   : (unsignedp ? ZERO_EXTEND :
SIGN_EXTEND));
277
278
279   gcc_assert (to_real == from_real);
280   gcc_assert (to_mode != BLKmode);
281   gcc_assert (from_mode != BLKmode);
282
283   /* If the source and destination are already the same, then there's
284  nothing to do.  */
285   if (to == from)
(gdb) p debug_rtx (to)
(reg:V4SI 92 [ D.2412 ])
$1 = void
(gdb) p debug_rtx (from)
(mem/c:BLK (plus:SI (reg/f:SI 82 virtual-stack-vars)
(const_int -32 [0xffe0])) [0 D.2405+0 S16 A128])
$2 = void

This happens due to ISA mismatch, and the compiler warns with:

pr66931.C: At global scope:
pr66931.C:5:1: warning: always_inline function might not be inlinable
[-Wattributes]
 counter(tcounter *self, long, long) {

There is no V4SImode available without -msse, so BLKmode is used instead. IIRC,
we already have a PR about this issue.

[Bug fortran/66942] New: trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'

[zeccav at gmail dot com]

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

Bug ID: 66942
   Summary: trans-expr.c:5701 runtime error: member call on null
pointer of type 'struct vec'
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! gcc-5.2.0/gcc/fortran/trans-expr.c:5701:19: runtime error: member call on
null pointer of type 'struct vec'
! gfortran source line "retargs->splice (arglist);"
! retargs is NULL
! double check with "gcc_assert(retargs);" immediately before
  call sub 
  END

[Bug target/66920] ICE in expand_debug_locations, at cfgexpand.c:3826

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|debug   |target
 Resolution|--- |DUPLICATE

--- Comment #3 from Uroš Bizjak  ---
(In reply to Jan Smets from comment #1)
> Likely related/identical to 66931

True, this ICE is due to ISA mismatch, it just happens to be in debug part.
There is no vector register available, so BLKmode is used instead of V4SImode.

Please note that gcc warns:

pr66920.C: At global scope:
pr66920.C:15:1: warning: always_inline function might not be inlinable
[-Wattributes]
 counter_inc(struct counter *, long, long) {

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

[Bug middle-end/66931] ICE in convert_move, at expr.c:316

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
*** Bug 66920 has been marked as a duplicate of this bug. ***